RE: Non-Last Small IPv6 Fragments

[Ron Bonica <[e-mail]>]

Brian,

The following are two more fundamental questions:

- Would the attack be effective?
- If the attack is effective, is there a better way to mitigate it (e.g., by limiting the number of fragments that a receiving node is willing to reassemble for a single packet)?

                                                                        Ron


> -----Original Message-----
> From: Brian E Carpenter <[e-mail]>
> Sent: Thursday, January 10, 2019 3:01 PM
> To: Ron Bonica <[e-mail]>; [e-mail]
> Cc: IPv6 List <[e-mail]>; Bob Hinden <[e-mail]>
> Subject: Re: Non-Last Small IPv6 Fragments
> 
> On 2019-01-11 08:52, Ron Bonica wrote:
> > Erik,
> >
> > Thanks for the response.
> >
> > So, I understand that if I were to launch a stream of such packets at a target:
> >
> >
> >   *   The target might drop many of the attack packets (but that’s ok)
> >   *   The target would still process non-fragmented packets at a reasonable
> speed
> >   *   The target would still be able to reassemble fragments that are from
> other sources and not part of the attack
> >
> > If this is the case, we have nothing to worry about.
> 
> Well, we have to worry about a broken Linux implementation unless this "fix"
> is reversed.
> 
> (I can see a pragmatic argument for dropping non-final fragments that are
> really small, which might be diagnostic of an attack. But then you have to
> define "really small".)
> 
>    Brian
> 
> >
> >                                                           Ron
> >
> >
> > From: Erik Kline <[e-mail]>
> > Sent: Thursday, January 10, 2019 2:42 PM
> > To: Ron Bonica <[e-mail]>
> > Cc: Bob Hinden <[e-mail]>; Timothy Winters
> <[e-mail]>; IPv6 List <[e-mail]>
> > Subject: Re: Non-Last Small IPv6 Fragments
> >
> > On Thu, 10 Jan 2019 at 11:32, Ron Bonica
> <[e-mail]<mailto:[e-mail]>> wrote:
> >> I read some of the reports on the link, but am still not clear what the
> >> underlying problem is.   Why does Linux have a problem with receving
> >> intermediate fragments less than 1280?
> >>
> >
> > Hi Bob,
> >
> > Might we be defending against an attack in which a packet contains:
> >
> > - An IPv6 header (40 bytes)
> > - A Fragment Header (8 bytes)
> > - A TCP header (20 bytes)
> > - TCP Payload (1200 bytes)
> >
> > This packet doesn't need to be fragmented at all because the total length is
> only 1268 bytes. However, a mischievous source node divides the packet into
> 1200 fragments. The first fragment contains an IPv6 header, a fragment
> header, the TCP header, and one byte of the TCP payload. Each subsequent
> fragment contains the IPv6 header, a fragment header, and one byte of TCP
> payload.
> >
> > Are reassembly algorithms clever enough to protect against such attacks? If
> so, I don't see the problem either. But if not, we may have a problem.
> >
> > I'm recently familiar with an IPv6 fragment reassembly implementation, as it
> turns out.  The core implementation uses/makes liberal reference to:
> >
> >     https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__tools.ietf.org_html_rfc815&d=DwIFaQ&c=HAkYuh63rsuhr6Scbfh0UjBX
> eMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-
> AWF2EfpHcAwrDThKP8&m=sK5K5wuiRYsxdqBoO01uXstXrB6pcOH7vIaVlqPk
> bw8&s=wRD2EDX32nGJdkVKcg_MlfkjpiweHbKU_7X3BJXHQks&e=<https://u
> rldefense.proofpoint.com/v2/url?u=https-
> 3A__tools.ietf.org_html_rfc815&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjB
> XeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-
> AWF2EfpHcAwrDThKP8&m=-
> dVqPKvvhh60cA1adnmR9mFsqrX0ADki0K4BlrOQqGc&s=6m7aXa5azbXR0bS
> ACw5GJgOfJx06tbs_1LydP-h2aqs&e=>
> >
> > It works generally in terms of managing a hole descriptor list.  It would
> successfully reassemble the sequence of packets you describe.  Whether that's
> an "attack" or not, I don't really see it.  With local policy caps on the lifetime of
> unreassembled fragment bits and so on, it seems possible to limit and manage
> the total resources allocated to reassembly.
> >
> >
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list
> > [e-mail]
> > Administrative Requests:
> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_mailman_listinfo_ipv6&d=DwIFaQ&c=HAkYuh63rsuhr6S
> cbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-
> AWF2EfpHcAwrDThKP8&m=sK5K5wuiRYsxdqBoO01uXstXrB6pcOH7vIaVlqPk
> bw8&s=aU3laJhpXnj8ataCCjgCdmeHhXP6jyerRBW6vUlk-SI&e=
> > --------------------------------------------------------------------
> >