netdev - Re: IPSEC: tunnel breakage with out-of-order IPv4 fragments

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: <20140715091613.GD6633@secunet.com>
Date:	Tue, 15 Jul 2014 11:16:13 +0200
From:	Steffen Klassert <steffen.klassert@...unet.com>
To:	Karl Heiss <kheiss@...il.com>
CC:	<netdev@...r.kernel.org>
Subject: Re: IPSEC: tunnel breakage with out-of-order IPv4 fragments

On Mon, Jul 14, 2014 at 07:52:23AM -0400, Karl Heiss wrote:
> On Mon, Jul 14, 2014 at 5:33 AM, Steffen Klassert
> <steffen.klassert@...unet.com> wrote:
> >
> > Your tcpdump looks interesting. Is it possible that all your
> > fragmented packets have the id field set to 'id 0'? This should
> > be only the case if the DF flag is set on that packet, but this
> > is apparently not the case here. If all the fragmented packets
> > have id 0, it is not possible to determine the correct fragment
> > chain. If only one fragment gets lost, all further packets might
> > be reassembled wrong.
> >
> 
> Yes, all fragments have 'id 0'.
> 
> > When looking at the code, is seems that sctp sets the DF flag
> > on packets as the default. The IPsec encapsulation code copies
> > the DF bit from the inner header and sets 'id 0' in this case.
> > A first guess would be that someone removes the DF flag after
> > the IPsec encapsulation.
> >
> > Is the DF flag set on your inner sctp packets?
> >
> 
> Yes, the inner packets have DF set, but the outer do not.

So we need to find where the DF flag disappears.

I tried to reproduce your issue with the current net tree,
but I was not able to do so.

With the plain net tree, all packets have the DF flag set
(sctp and esp), no fragments.

With the net tree and commit c08751c851b78514f6ec5 reverted,
I have some packets with the DF flag and some without. The
packets without the DF flag got fragmented after IPsec
processing. But even in this case, the ESP packet has the
DF flag set whenever the inner sctp packet has it set.
And also, the DF flag is set whenever a packet has 'id 0'.
The fragmented packets never have the 'id 0'.

Can you describe your usecase more precisely? Do you use
any additional tunnel like ipip/gre etc. or packet mangling?
--
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