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 for Android: free password hash cracker in your pocket

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

Message-ID: <20140711110035.GB6633@secunet.com>
Date:	Fri, 11 Jul 2014 13:00:35 +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 Thu, Jul 10, 2014 at 10:57:21AM -0400, Karl Heiss wrote:
> I believe I have found an issue whereby IPv4 fragments arriving
> out-of-order will cause an IPSEC tunnel to stop passing any traffic
> which arrived fragmented, citing 'SA-icv-failure'.  

Why do you think the arriving order causes our problems? SA-icv-failure
means that the integrity check failed and this is independent of the
packet order, unless you use 64 bit extended sequence numbers (ESN).
I would guess you don't use ESN because you noticed these problems
already with v2.6.32 and this had no ESN support.

If this happens just with fragmented packets, I'd guess there is a
problem when packets get fragmented after IPsec and reassembled
before IPsec processing.

> Packets which were
> not fragmented will validate and pass successfully, even once the
> condition has been triggered.  I have decrypted the traffic and have
> verified that the traffic is arriving correctly.  It appears as if the
> condition persists until all connections are closed.
> 
> The issue was originally discovered in RHEL 6.5 (2.6.32-431.11.2.el6)
> kernel and verified with Fedora 20 running 3.15.0-rc8-nn on x86_64.
> 
> The easiest way I have found to reproduce the issue is to use a kernel
> without commit c08751c851b78514f6ec5 (Fix data chunk fragmentation for
> MTU values which are not multiple of 4) to generate fragmented SCTP
> traffic using multiple single-homed connections.  

Do you have some odd MTU/PMTU value on this route? If so, you might
get post IPsec fragmented packets without that commit.

I have a lot of testcases where I test PMTU discovery and fragmentation
with IPsec. I've never seen such problems, but I don't use sctp. Is there
any chance to reproduce this with another protocol?

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