Re: Non-Last Small IPv6 Fragments

[Brian E Carpenter <[e-mail]>]

On 2019-01-11 09:32, Ron Bonica wrote:
> Brian,
> 
> The following are two more fundamental questions:
> 
> - Would the attack be effective?

Like all resource-consumption attacks, it all depends. Yes, one-byte fragments would probably be an issue but would 256-byte fragments? I just don't know.

Once in my misspent youth I wrote code for fragmentation/reassembly of CLNP packets over a PMTU of 64 bytes. I did not enjoy writing the code, but I never saw any particular performance issues, even on a microsecond-per-instruction minicomputer. However, I think there's no generic answer to your question.

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

Yes, I think quite a few pragmatic suggestions have been made in this thread. But given that this is 6man, maybe we should be asking whether this is a gap in the IPv6 specification.

     Brian

> 
>                                                                         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=
>>> --------------------------------------------------------------------
>>>
>