netdev - Re: [PATCH net-next] xfrm: Call IP receive handler directly for inbound tunnel-mode packets

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, 2 Jan 2012 14:52:36 -0500
From:	"Ward, David - 0663 - MITLL" <david.ward@...mit.edu>
To:	Herbert Xu <herbert@...dor.apana.org.au>
CC:	"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: [PATCH net-next] xfrm: Call IP receive handler directly for
 inbound tunnel-mode packets

Hi Herbert,

On 01/02/2012 02:28 AM, Herbert Xu wrote:
> On Sun, Jan 01, 2012 at 10:32:34PM -0500, David Ward wrote:
>> For IPsec tunnel mode (or BEET mode), after inbound packets are xfrm'ed,
>> call the IPv4/IPv6 receive handler directly instead of calling netif_rx.
>> In addition to avoiding unneeded re-processing of the MAC layer, packets
>> will not be received a second time on network taps. (Note that outbound
>> packets are only received on network taps post-xfrm, but inbound packets
>> were being received both pre- and post-xfrm. So now network taps will
>> receive packets in either direction only once, in the form that they go
>> "over the wire".)
>>
>> Signed-off-by: David Ward<david.ward@...mit.edu>
>> Cc: Herbert Xu<herbert@...dor.apana.org.au>
> You can't do this as this may cause stack overruns if we nest
> too deeply.
Sorry if I'm missing something, but how are such overruns avoided on the 
outbound side?

> Changing the existing tap processing behaviour will also break
> existing setups.
Assuming there might be a better way to make this change, are there 
examples of existing setups that would be negatively affected? From my 
perspective this behavior is just an unintended artifact of xfrm'ed 
packets being placed back into netif_rx, which only occurs for inbound 
packets, and it complicates the usage of network taps on these 
interfaces (i.e. how do you systematically determine whether any packet 
is post-xfrm and was already seen in an earlier form?). It seems to me 
that network taps operate at a lower layer than xfrm, and so xfrm should 
be invisible to the network taps. If users are, for example, capturing 
ESP packets from a PF_PACKET socket and want to examine the decrypted 
payload, I think the capture application should be responsible for the 
decryption, just as it would be at higher layers with something like 
SSL/TLS (and again for example, both protocols can be decrypted by 
Wireshark when provided the keys).

I would appreciate your feedback.

David



Download attachment "smime.p7s" of type "application/pkcs7-signature" (4558 bytes)