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  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:   Tue, 26 May 2020 09:54:17 +0200
From:   Michal Kubecek <mkubecek@...e.cz>
To:     netdev@...r.kernel.org
Cc:     강유건 <yugun819@...pkinnet.com>
Subject: Re: With regard to processing overlapping fragment packet

On Tue, May 26, 2020 at 02:47:25PM +0900, 강유건 wrote:
> Hello
> 
> Actually, I'm not sure if it's right to send mail here.
> 
> I'm testing ipv6ready Self Test 5.0.4 using linux-4.19.118 kernel.
> ( https://www.ipv6ready.org.cn/home/views/default/resource/logo/phase2-core/index.htm
> )
> 
> Test failed in 82. Part B: Reverse Order Fragments ( Link-Local ) in
> Section 1. spec
> 
> In test 82, source transmits 3 fragment packets in reverse order that
> are originally a icmpv6 packet.
> There is an overlapping interval between the 2nd and 3rd packet.
> 
> The test requires the destination MUST drop all packets and respond nothing,
> but the dest replies Time Exceeded / Reassembly Timeout.
> 
> I've read some /net/ipv6 codes and think when the kernel receives the
> 2nd packet ( overlapping occurs ), it drops 3rd and 2nd packets and
> recognizes the 1st packet as a new fragment packet.
> ( Is it right ? )
> 
> In RFC5722, when a node receives the overlapping fragment, it MUST
> discard those not yet received. (  In this case, I think it applies to
> 1st packet )
> 
> Please let me know if I misunderstood RFC or if it wasn't implemented
> in the kernel.

You understood the requirement of the RFC correctly but the problem is
that implementing it would be too complicated, would make the
implementation susceptible to DoS attacks and could even result in
dropping legitimate (new) fragments. Therefore an erratum to RFC 5722
was accepted which drops the requirement to also drop fragments not
received yet:

  https://www.rfc-editor.org/errata/eid3089

Michal

Powered by blists - more mailing lists