Re: Non-Last Small IPv6 Fragments

[Tom Herbert <[e-mail]>]

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.

Tom

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