| 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
| ||
|
Date: Mon, 14 Jul 2014 07:52:23 -0400 From: Karl Heiss <kheiss@...il.com> To: Steffen Klassert <steffen.klassert@...unet.com> Cc: netdev@...r.kernel.org Subject: Re: IPSEC: tunnel breakage with out-of-order IPv4 fragments On Mon, Jul 14, 2014 at 5:33 AM, Steffen Klassert <steffen.klassert@...unet.com> wrote: > On Fri, Jul 11, 2014 at 08:51:14AM -0400, Karl Heiss wrote: >> On Fri, Jul 11, 2014 at 7:00 AM, Steffen Klassert >> <steffen.klassert@...unet.com> wrote: >> >> > >> > 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. >> > >> >> If I am reading the tcpdump correctly, the issue is that the packets >> are getting fragmented after IPsec processing. >> >> 10.240.34.75.35689 > linux.local.60000: sctp (1) [COOKIE ECHO] >> 08:23:05.821858 IP (tos 0x2,ECT(0), ttl 64, id 0, offset 0, flags >> [DF], proto ESP (50), length 104) >> linux.local > 10.240.34.75: ESP(spi=0x0d34ea75,seq=0x44be), length 84 >> 08:23:06.823989 IP (tos 0x2,ECT(0), ttl 60, id 0, offset 0, flags [+], >> proto ESP (50), length 1500) >> 10.240.34.75 > linux.local: ESP(spi=0xedc4a797,seq=0x89b5), length 1480 >> 08:23:06.824001 IP (tos 0x2,ECT(0), ttl 60, id 0, offset 1480, flags >> [none], proto ESP (50), length 32) >> 10.240.34.75 > linux.local: esp >> 08:23:06.824030 IP (tos 0x2,ECT(0), ttl 60, id 0, offset 0, flags [+], >> proto ESP (50), length 1500) >> 10.240.34.75 > linux.local: ESP(spi=0xedc4a797,seq=0x89b6), length 1480 >> 08:23:06.824035 IP (tos 0x2,ECT(0), ttl 60, id 0, offset 1480, flags >> [none], proto ESP (50), length 32) >> 10.240.34.75 > linux.local: esp >> 08:23:06.824057 IP (tos 0x2,ECT(0), ttl 60, id 0, offset 0, flags [+], >> proto ESP (50), length 1500) >> 10.240.34.75 > linux.local: ESP(spi=0xedc4a797,seq=0x89b7), length 1480 >> 08:23:06.824060 IP (tos 0x2,ECT(0), ttl 60, id 0, offset 1480, flags >> [none], proto ESP (50), length 32) > > 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. >> > >> > Do you have some odd MTU/PMTU value on this route? If so, you might >> > get post IPsec fragmented packets without that commit. >> > >> >> The MTU for this path is 1500 all the way through. >> >> Yes, this commit most likely fixes the post IPsec fragmentation, as >> SCTP was not previously accounting for the IPsec headers when sizing >> chunks. However, if the traffic worked in this case without >> reordering, wouldn't we hope it could handle the reordered case, even >> with the post IPsec fragmentation? > > Sure, I just wanted to know whether I look into the right direction :) > Karl -- 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