Re: Non-Last Small IPv6 Fragments

[Tom Herbert <[e-mail]>]

On Sat, Jan 12, 2019 at 10:50 AM Ole Troan <[e-mail]> wrote:
>
>
>
> > On 12 Jan 2019, at 18:17, Tom Herbert <[e-mail]> wrote:
> >
> >> On Sat, Jan 12, 2019 at 1:49 AM Ole Troan <[e-mail]> wrote:
> >>
> >> 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.
> >>
> > Ole,
> >
> > I don't know what the protocol requirements are for virtual
> > reassembly. Is there an I-D or RFC on this?
>
> Virtual reassembly is just an optimization. The protocol requirements are the same.
>
The same as what requirements? RFC8200 defines how reassembly occurs
at a destination (the addressed node), not how an intermediate node in
the network reassembles packets. It is not the same thing. For
instance, there is an additional implicit requirement in virtual
reassembly that all fragments are routed through the same node. Also,
Hop-by-Hop options and Destination options can precede the fragment
header, so is the requirement that same that nodes MUST process these
before the fragmentation header is processed?

If virtual reassembly is brought up in the context of standard
protocol discussion, it would really be nice to have a normative
desciption of that protocol mechanism.

Tom

> Cheers
> Ole
>
>
> >
> > Thanks,
> > Tom
> >
> >> 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.org”,
> >> 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
> >> --------------------------------------------------------------------
>