netdev - Re: Question with commit 299b0767(ipv6: Fix IPsec slowpath fragmentation problem)

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]

Message-ID: <20120215104021.GC31660@secunet.com>
Date:	Wed, 15 Feb 2012 11:40:21 +0100
From:	Steffen Klassert <steffen.klassert@...unet.com>
To:	Li Wei <lw@...fujitsu.com>
Cc:	netdev <netdev@...r.kernel.org>
Subject: Re: Question with commit 299b0767(ipv6: Fix IPsec slowpath
 fragmentation problem)

On Wed, Feb 15, 2012 at 03:00:04PM +0800, Li Wei wrote:
> 
> Hi Steffen,
> 
> Thank you for your reply!
> 
> I see in your patch that you use the "mtu" of &rt->dst (which taken IPSec
> into account) instead of rt->dst.path, but the "exthdrlen" and "dst_exthdrlen"
> things process IPSec again. Does some duplication there?
> 
> After reverted the patch and put some "printk" things in the slow_path of
> ip6_fragment(), setup IPSec transport mode between two hosts, when sending
> some echo request which exceeds the MTU, I don't see any "printk" in slow_path
> outputed. Could you tell me how to reproduce the slow_path things?
> 

Ok, I see what's going on. The slowpath fragmentation problem appeared
in tunnel mode. This is because commit ad0081e43a 
"ipv6: Fragment locally generated tunnel-mode IPSec6 packets as needed"
changed tunnel mode to do fragmentation before the transformation
while transport mode still does fragmentation after transformation.
Now, tunnel mode needs IPsec headers and trailer for all fragments,
while on transport mode it is sufficient to add the headers to the
first fragment and the trailer to the last.

Not quite sure what to do here. We would have the information
to check for tunnel/transport mode when we calculate the packet
lenght in ip6_append_data(), but it would look quite ugly to
search through the xfrm state bundle to figure out which mode
this is using.
--
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