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:	Mon, 17 Sep 2007 20:14:56 -0700 (PDT)
From:	david@...g.hm
To:	YOSHIFUJI Hideaki / 吉藤英明 
	<yoshfuji@...ux-ipv6.org>
cc:	ytht.net@...il.com, netdev@...r.kernel.org,
	linux-kernel@...r.kernel.org, davem@...emloft.net
Subject: Re: [PATCH] 2.6.22.6 NETWORKING [IPV4]: Always use source addr in
 skb to reply packet

On Tue, 18 Sep 2007, YOSHIFUJI Hideaki / ^[$B5HF#1QL@^[(B wrote:

> In article <20070917.192044.48396034.davem@...emloft.net> (at Mon, 17 Sep 2007 19:20:44 -0700 (PDT)), David Miller <davem@...emloft.net> says:
>
>> From: lepton <ytht.net@...il.com>
>> Date: Tue, 18 Sep 2007 10:16:17 +0800
>>
>>> Hi,
>>>   In some situation, icmp_reply and ip_send_reply will send
>>>   out packet with the wrong source addr, the following patch
>>>   will fix this.
>>>
>>>   I don't understand why we must use rt->rt_src in the current
>>>   code, if this is a wrong fix, please correct me.
>>>
>>> Signed-off-by: Lepton Wu <ytht.net@...il.com>
>>
>> That the address is wrong is your opinion only :-)
>>
>> Source address selection is a rather complex topic, and
>> here we are definitely purposefully using the source
>> address selected by the routing lookup for the reply.
>
> And, if you do think something is "wrong", you need to describe it
> in detail, at least.

I missed the beginning of the discussion, so apologies if I'm way off 
base.

it sounds like the question is, when a packet hits the box that causes a 
icmp_reply (or other packet) to be generated, which IP address should be 
used as the source

1. the destination address of the packet that generated the message

or.

2. the IP address that the machine would use by default if the machine 
were to generate a new connection to the destination.

I understand that in many cases the historical approach has been #2, but 
as more machines get multiple IP addresses on each interface, I believe 
that it's less of a surprise to other systems if the default is #1. most 
of the time the other systems don't care (and useusally don't want to 
know) if the service they are contacting is on a dedicated machine or is 
just one IP among many sharing a box.

it gets especially bad when you have load balancing going on and the 
results could come from multiple boxes.

yes, sysadmins deal with this today, but it's a pain to do so and is a 
continuing dribble of suprises when things don't quite work the way you 
expect them to as you consoldate things onto more powerful systems (or 
distribute them among multiple systems).

if the packet got to the machine and the machine is accepting it, replying 
back from the destination IP of that packet should be legitimate (it's 
what you would do if there was a full connection after all) and greatly 
reduces the cases where things change.

David Lang
-
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ