Re: Non-Last Small IPv6 Fragments

[David Farmer <[e-mail]>]

So basically you are adding a limitation of "but not more fragments than
the number of Minimum MTU fragments necessary to send the original packet"
to the current rule allowing the "for sending any fragment for fragments as
long they add up to the original packet."

I was thinking along these lines too, and it seems prudent to limit the
number of fragments that can be created.

Or, maybe "but not more than one additional fragment than the number of
Minimum MTU fragments necessary to send the original packet"

Which would be essentially 1280/3, this would allow some flexibility
without leaving it completely open-ended.

On Thu, Jan 10, 2019 at 3:24 PM Mark Andrews <[e-mail]> wrote:

> A resonable limit is 1280/2.  This allow a 1281 packet to be split into
> 2 even sizes packets.  Even sized packets have less reordering issues
> than all PMTU but the last.
>
> > On 11 Jan 2019, at 8:19 am, Tom Herbert <[e-mail]> wrote:
> >
> > On Thu, Jan 10, 2019 at 12:33 PM Ron Bonica <[e-mail]> 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 <[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=
> >>>> --------------------------------------------------------------------
> >>>>
> >>
> >> --------------------------------------------------------------------
> >> IETF IPv6 working group mailing list
> >> [e-mail]
> >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> >> --------------------------------------------------------------------
> >
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list
> > [e-mail]
> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------
>
> --
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: [phone]              INTERNET: [e-mail]
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>


-- 
===============================================
David Farmer               Email:[e-mail]
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE        Phone: [phone]
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================