netdev - Re: [IPV4] LVS: Allow to send ICMP unreachable responses when real-servers are removed

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 17 May 2007 18:40:28 +0200
From:	Patrick McHardy <kaber@...sh.net>
To:	Julian Anastasov <ja@....bg>
CC:	Simon Horman <horms@...ge.net.au>,
	Janusz Krzysztofik <jkrzyszt@....icnet.pl>,
	David Miller <davem@...emloft.net>, netdev@...r.kernel.org
Subject: Re: [IPV4] LVS: Allow to send ICMP unreachable responses when real-servers
 are removed

Julian Anastasov wrote:
> 	 To summarize, what can help is a flag (eg. RT_ANYSRC) to
> ip_route_output* that all special users can provide to skip the
> check, for example:
> 	- RTCF_LOCAL packets in icmp_send() can avoid the check
> 	- NAT can avoid the check (ip_route_me_harder can be simplified?)


We want to be able to use iif in rules, so ip_route_me_harder still
needs to use ip_route_input().


> 	 Currently, all callers use the check, so may be the goal can be
> to start with small set of callers that can set the new flag. It looks
> like we can save some CPU cycles too, ip_route_me_harder looks too
> overloaded.
> 
> 
>>>I think that your patch looks good, assuming that inet_addr_type(VIP)
>>>is going to return RTN_LOCAL (except in the unlikely case that VIP is
>>>multicast or something silly like that.
>>
>>I'm not familiar with the IPVS terms, but as far as I understand,
>>it is _not_ going to return RTN_LOCAL, so we get the desired
>>behaviour of selecting a local address as source.
> 
> 
> 	But what is preferred is to use VIP in ICMP.
> 
> ip route add local VIP dev lo table user_defined
> 
> 	returns RTCF_LOCAL but inet_addr_type() does not return RTN_LOCAL,
> we fix one thing but break another :)


Actually thats exactly the case that my patch handles. Why does it
matter which source address the ICMP packet uses, as long as its
routed properly?

In any case some better solution than the current one needs to be
found, allowing users to send spoofed packets is far worse than
using a non-desired source address for ICMP packets.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html