Re: Non-Last Small IPv6 Fragments

On Thu, Jan 10, 2019 at 12:33 PM Ron Bonica <rbonica@juniper.net> wrote:
>
> Brian,
>
> The following are two more fundamental questions:
>
> - Would the attack be effective?
Hi Ron,

I imagine it could be. In Linux for instance, the reassembly queue
requires an skbuf structure for each fragment. That means one packet
in reassembly could tie up thousands of such structures in memory in
your proposed attack.

> - 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)?

That might be reasonable, however requiring intermediate fragments to
be at least 1280 MTU in IPv6 also solves that without needing to
define some aritrary new limit. I'd also point out that while Linux
was changed to enforce a minimum size on intermediate fragments for
IPv6, doing the same thing in IPv4 was rejected since intermediate
nodes can fragment.

Tom

>
>                                                                         Ron
>
>
> > -----Original Message-----
> > From: Brian E Carpenter <brian.e.carpenter@gmail.com>
> > Sent: Thursday, January 10, 2019 3:01 PM
> > To: Ron Bonica <rbonica@juniper.net>; ek@loon.co
> > Cc: IPv6 List <ipv6@ietf.org>; Bob Hinden <bob.hinden@gmail.com>
> > 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 <ek@loon.co>
> > > Sent: Thursday, January 10, 2019 2:42 PM
> > > To: Ron Bonica <rbonica@juniper.net>
> > > Cc: Bob Hinden <bob.hinden@gmail.com>; Timothy Winters
> > <twinters@iol.unh.edu>; IPv6 List <ipv6@ietf.org>
> > > Subject: Re: Non-Last Small IPv6 Fragments
> > >
> > > On Thu, 10 Jan 2019 at 11:32, Ron Bonica
> > <rbonica@juniper.net<mailto:rbonica@juniper.net>> 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
> > > ipv6@ietf.org
> > > 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=
> > > --------------------------------------------------------------------
> > >
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------