Re: Non-Last Small IPv6 Fragments

[Mark Andrews <[e-mail]>]

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]