RE: Non-Last Small IPv6 Fragments

["Lubashev, Igor" <[e-mail]>]

> - how long are fragment chains (both in packets and in time span)
> - ratio of out of order fragments
> - which applications use fragments
> - ratio of attack traffic using fragments
> - average/min/maximum sizes, same for numbers of fragments in chain
> - ratio of complete fragment chain following the same path in the network
> - ratio of fragments to total traffic

Ole, I do not think a study of ratios and averages will provide much value.  A general implementation like Linux kernel must (will want to) support all use cases. No regressions!  I've seen several applications, all homegrown so you are unlikely to encounter them for any study, where the use of fragments is an effect of the application's long life and evolution -- it started with reasonably-sized UDP packets but demands on the amount of data in a single datagram grew over the years.


As for the Linux implementation, I think the limit there is not a complete solution but an assertion that non-final fragments shorter than X cannot possibly be legit.  This assertion increases the costs on the attacker.

Ultimately, Fragment Smack and Segment Smack are NOT attacks on memory of the machine but on the bookkeeping Algorithm. For obvious reasons, Linux tries hard to avoid memcopy to consolidate the fragments as they arrive, so it keeps each fragment in its own buffer, which has a significant memory overhead.  Once the entire IP packet is received and processed (discarded, forwarded, or copied to userspace), all these buffers are freed.  However, Linux does careful memory accounting, and if the memory for these fragment buffers grows past a certain threshold, Linux attempts to perform compaction (the dreaded memcopy), which requires a linear scan through all the accumulated fragment buffers.  In a well-behaved case, that compaction will free up a lot of extra memory, but in the attack case, that compaction will free only a little memory (just enough for one more fragment).  All subsequent attack packets will cause the linear compaction scan.

The algorithmic improvement to the above could include a faster compaction (extra bookkeeping to know in advance which fragments can be coalesced and not spend any time examining the ones that cannot be coalesced) and/or a simple heuristic after a single compaction that determines whether "enough" progress has been made and/or a "quality" heuristic that is maintained as fragments are being received.

- Igor

> -----Original Message-----
> From: Ole Troan <[e-mail]>
> Sent: Saturday, January 12, 2019 4:49 AM
> To: 6man WG <[e-mail]>
> Subject: Re: Non-Last Small IPv6 Fragments
> 
> Fernando said:
> > I agree with the above (please see the ref I posted to RFC6274, which
> > basically argues about this). HOowever, it is still not clear to me
> > what's the problem you are addressing by enforcing a minimum fragment
> > size. If you allow MIN_MTU/2, then you require first frags to be 640
> > bytes.. and teh attacker is required to send 640 as opposed to 60
> > bytes or  so. Doesn't seem to be much of a difference to me.
> > And as noted by Bob, I still don't see what's the big deal with the
> > small fragments.
> >
> > There are some DoS attacks where you send a last frag and possibly a
> > first frag, and the implementation allocates a buffer that would fit
> > the rest of the missing fragments -- obviously exacerbating the
> > problem a bit. BUt still i this cases, the size of the first frag is not a big deal.
> 
> In e.g. VPP limiting fragment size would not help at all.
> The scarce resource is number of available buffers. One fragment occupies at
> least one buffer regardless of how much smaller than 2K (default buffer size)
> it is.
> 
> Mitigations against attack is highly likely to be implementation specific.
> As an example see:
> https://github.com/FDio/vpp/blob/master/src/vnet/ip/ip6_reassembly.c
> 
> Default reassembly timeout is 100ms (constrasting that with the RFC 60s)
> Maximum consequtive reassemblies in progress is limited to 1024.
> And in other virtual reassembly algorithms we have also limited maximum
> allowed number of fragments in chain to 5.
> 
> Now, if we in the IETF think we can provide some guidance here, I will second
> Erik’s suggestion of getting more research.
> 
> The packet traces I have looked at in the past, the majority of fragmeted
> packets looked like attacks. UDP port 80, DNS queries to
> “thisdomainnamewillgiveaverylongresponsepurelyforthepurposeofattack.or
> g”,
> didn’t reassemble, 64K size… But it would be interesting to understand
> fragmentation behaviour in various parts of the network.
> 
> - how long are fragment chains (both in packets and in time span)
> - ratio of out of order fragments
> - which applications use fragments
> - ratio of attack traffic using fragments
> - average/min/maximum sizes, same for numbers of fragments in chain
> - ratio of complete fragment chain following the same path in the network
> - ratio of fragments to total traffic
> 
> Cheers,
> Ole
> 
> 
> 
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------