Re: Non-Last Small IPv6 Fragments

On 2019-01-11 08:52, Ron Bonica wrote:
> Erik,
> 
> Thanks for the response.
> 
> So, I understand that if I were to launch a stream of such packets at a target:
> 
> 
>   *   The target might drop many of the attack packets (but that’s ok)
>   *   The target would still process non-fragmented packets at a reasonable speed
>   *   The target would still be able to reassemble fragments that are from other sources and not part of the attack
> 
> If this is the case, we have nothing to worry about.

Well, we have to worry about a broken Linux implementation unless this "fix" is reversed.

(I can see a pragmatic argument for dropping non-final fragments that are really small, which might be diagnostic of an attack. But then you have to define "really small".)

   Brian

> 
>                                                           Ron
> 
> 
> From: Erik Kline <ek@loon.co>
> Sent: Thursday, January 10, 2019 2:42 PM
> To: Ron Bonica <rbonica@juniper.net>
> Cc: Bob Hinden <bob.hinden@gmail.com>; Timothy Winters <twinters@iol.unh.edu>; IPv6 List <ipv6@ietf.org>
> Subject: Re: Non-Last Small IPv6 Fragments
> 
> On Thu, 10 Jan 2019 at 11:32, Ron Bonica <rbonica@juniper.net<mailto:rbonica@juniper.net>> wrote:
>> I read some of the reports on the link, but am still not clear what the
>> underlying problem is.   Why does Linux have a problem with receving
>> intermediate fragments less than 1280?
>>
> 
> Hi Bob,
> 
> Might we be defending against an attack in which a packet contains:
> 
> - An IPv6 header (40 bytes)
> - A Fragment Header (8 bytes)
> - A TCP header (20 bytes)
> - TCP Payload (1200 bytes)
> 
> This packet doesn't need to be fragmented at all because the total length is only 1268 bytes. However, a mischievous source node divides the packet into 1200 fragments. The first fragment contains an IPv6 header, a fragment header, the TCP header, and one byte of the TCP payload. Each subsequent fragment contains the IPv6 header, a fragment header, and one byte of TCP payload.
> 
> Are reassembly algorithms clever enough to protect against such attacks? If so, I don't see the problem either. But if not, we may have a problem.
> 
> I'm recently familiar with an IPv6 fragment reassembly implementation, as it turns out.  The core implementation uses/makes liberal reference to:
> 
>     https://tools.ietf.org/html/rfc815<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc815&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8&m=-dVqPKvvhh60cA1adnmR9mFsqrX0ADki0K4BlrOQqGc&s=6m7aXa5azbXR0bSACw5GJgOfJx06tbs_1LydP-h2aqs&e=>
> 
> It works generally in terms of managing a hole descriptor list.  It would successfully reassemble the sequence of packets you describe.  Whether that's an "attack" or not, I don't really see it.  With local policy caps on the lifetime of unreassembled fragment bits and so on, it seems possible to limit and manage the total resources allocated to reassembly.
> 
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
> 