Re: Non-Last Small IPv6 Fragments

[Fernando Gont <[e-mail]>]

On 12/1/19 06:48, Ole Troan wrote:
[...]
> 
> 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.

Some might argue that, by sending small fragments an attacker need not
waste bandwidth for the attack. But I don't think *that* is the
bottleneck the attacker will have for attacking. -- i.e., as you note, I
don't think requiring any minimum size for first frags will help the
implementation defending against this.



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

Seems good. 60s frag timeout is just asking for trouble. And even
attacks aside, you will not get anything useful by trying to reassemble
a packet after a few seconds of receiving some frag.



> Now, if we in the IETF think we can provide some guidance here, I will second Erik’s suggestion of getting more research.

I will do some testing, plus assessment of what happens in TCP-land, too
(the later being unrelated to 6man).

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: [e-mail]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492