Re: Non-Last Small IPv6 Fragments

[Tom Herbert <[e-mail]>]

On Fri, Jan 11, 2019 at 8:49 PM Fernando Gont <[e-mail]> wrote:
>
> On 12/1/19 00:47, Tom Herbert wrote:
> > On Fri, Jan 11, 2019 at 7:32 PM Fernando Gont <[e-mail]> wrote:
> >>
> >> On 11/1/19 19:47, Tom Herbert wrote:
> >>> On Fri, Jan 11, 2019 at 2:33 PM David Farmer <[e-mail]> wrote:
> >>>>
> >>>>
> >>>> On Fri, Jan 11, 2019 at 3:27 PM Tom Herbert <[e-mail]> wrote:
> >>>>>
> >>>>> On Fri, Jan 11, 2019 at 1:13 PM David Farmer <[e-mail]> wrote:
> >>>>>>
> >>>>>> On Fri, Jan 11, 2019 at 1:58 PM Fernando Gont <[e-mail]> wrote:
> >>>>>>>
> >>>>>>> On 11/1/19 15:38, Simon Hobson wrote:
> >>>>>>>> Fernando Gont <[e-mail]> wrote:
> >>>>>>>>
> >> [....]
> >>>>>>
> >>>>>> I just had a thought for the guidance;
> >>>>>>
> >>>>>> 1. System-wide limit the number of fragments based on the overall system resources available.
> >>>>>> 2. As you near said limit, maybe 75% of the limit, drop outright, or at a high probability, non-final fragments smaller than (1280/2) 640 bytes.
> >>>>>>
> >>>>>> The reasonable fragmentation algorithms I can think of do not generate non-final fragments that are less than 640 bytes. Nevertheless, such fragments SHOULD NOT be dropped except for when the system is under stress.
> >>>>>>
> >>>>>> What do others think?
> >>>>>
> >>>>> I don't see any practical purpose of sending tiny fragments with eight
> >>>>> byte payloads in non-first fragments, these can only happens under DOS
> >>>>> attack or synthetic testing. So I do believe it's prudent to have some
> >>>>> guidance on setting limits for minimal sizes of non-first fragments.
> >>>>> The limit should probably be configurable with some recommended
> >>>>> default value. I believe the 1280 limit in Linux is too high, but
> >>>>> there are some compelling arguments for 640.
> >>>>
> >>>>
> >>>> Why non-first fragments? Did you mean non-final? Maybe both first and last should be exempted?
> >>>>
> >>> Yes.
> >>
> >> So why should I, as an attacker, send you first fragments, then? If for
> >> some reason I just want to send you, I'd send fragments such that
> >> Offset!=0 and M=0, with small size, WHat have you gained with the check
> >> you propose?
> >
> > That sort of attack would exhaust the limit on how many packets are
> > allowed to be in reassembly at which point such packets would start to
> > be dropped. It's also easy enough to prioritize packets for reassmbly
> > for which the first fragment has already been received when
> > considering eviction from the reassembly queue.
>
> 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.
>
Hi Fernando,

Consider that the smallest packet containing an IPv6 fragment is:

IP hdr. 40
Fragment header: 8
Fragment data: 8

Sums to 56 bytes. Maximum reassemble packet size is 65,535, so a
single packet could be composed of 8,186 such fragments. A stream of
these packet creates high load on both CPU and memory. Fundamentally,
I see no other purpose for sending a stream of fragments like this
other than DOS attack. I don't think it's at all unreasonable for a
host to outright reject these packets.

But as you point out, this isn't on the only way to attack
fragmentation, and it's easy to contrive other attacks. Consider, a
fragment like this:

IP hdr:40
Dst: opt: 2
722 Destination options of two byte length, where each option type is
00 in high order bits
Fragment header: 8
Fragment data: 8

Sums to 1500, ie. typical MTU. So this fragment will pass the minimum
1280 check but still carries the minimum fragment data so it can
attack memory used in reassembly. Processing long lists of options is
also a good attack on CPU. This attack could be mitigated by applying
limits on headers like in draft-int-area-header-limits. The default
limit number of bytes in network headers in that draft is 256 bytes,
so the minimum size of fragment data that could be accepted under that
limit is 384 bytes (much better then 8 bytes).

In any case, this discussion underscores a big challenge we have with
have with IPv6. There are several very powerful mechanisms in the
specifications that were defined without any limits. To get to
practical and deployable implementations we need to set some limits.
IMO the best way do that is to publically define the limits needed,
make them configurable, and suggest default values. I believe this is
a *FAR* better approach than implementions providing their own ad hoc
solutions (such as those that just drop all fragments or packets with
extension headers).

Tom









> 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.
>
> Thanks,
> --
> Fernando Gont
> SI6 Networks
> e-mail: [e-mail]
> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
>
>
>
>