netdev - Re: [PATCH net-next 2/4] net: IP6 defrag: use rbtrees for IPv6 defrag

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 22 Jan 2019 18:49:05 -0800
From:   Eric Dumazet <eric.dumazet@...il.com>
To:     Tom Herbert <tom@...bertland.com>, Peter Oskolkov <posk@...gle.com>
Cc:     David Miller <davem@...emloft.net>,
        Linux Kernel Network Developers <netdev@...r.kernel.org>,
        Peter Oskolkov <posk.devel@...il.com>,
        Eric Dumazet <edumazet@...gle.com>,
        Florian Westphal <fw@...len.de>
Subject: Re: [PATCH net-next 2/4] net: IP6 defrag: use rbtrees for IPv6 defrag



On 01/22/2019 06:13 PM, Tom Herbert wrote:
> On Tue, Jan 22, 2019 at 5:13 PM Peter Oskolkov <posk@...gle.com> wrote:
>>
>> On Tue, Jan 22, 2019 at 5:04 PM Tom Herbert <tom@...bertland.com> wrote:
>>>
>>> On Tue, Jan 22, 2019 at 4:53 PM Peter Oskolkov <posk@...gle.com> wrote:
>>>>
>>>> On Tue, Jan 22, 2019 at 4:37 PM Tom Herbert <tom@...bertland.com> wrote:
>>>>>
>>>>> On Tue, Jan 22, 2019 at 10:03 AM Peter Oskolkov <posk@...gle.com> wrote:
>>>>>>
>>>>>> Currently, IPv6 defragmentation code drops non-last fragments that
>>>>>> are smaller than 1280 bytes: see
>>>>>> commit 0ed4229b08c1 ("ipv6: defrag: drop non-last frags smaller than min mtu")
>>>>>>
>>>>> Peter,
>>>>>
>>>>> I'm a bit confused on why so much code is required to undo this patch
>>>>> which was a whole three lines of code to begin with.
>>>>
>>>> I agree that if the goal is to just lower the 1280 IPv6 fragment
>>>> limit, but keep it reasonably high, then my patchset is not needed.
>>>> However, if the decision (ultimately by David Miller, I guess) is to
>>>> accept fragments of any size, as the standard seems to imply, then
>>>> something similar to what I suggested here is needed, I think. This
>>>> was done in IPv4...
>>>
>>> Peter,
>>>
>>> Sorry, I'm still not following. Before "ipv6: defrag: drop non-last
>>> frags smaller than min mtu" wouldn't we have accepted fragments of any
>>> size? Are you saying that things were previously broken otherwise?
>>
>> Yes, before the patch you reference above, fragments of any size had
>> been accepted. And this had been identified as a DDOS threat and
>> mitigated in IPv6 by setting the 1280 fragment limit and in IPv4 by
>> using rbtrees. The IPv4/IPv6 difference was due to the belief, at the
>> time, that IPv6 standard actually required non-last fragments less
>> than 1280 to be dropped, while IPv4 standard required accepting
>> fragments of any size.
>>
>> So things were broken in the sense of having this DDOS vulnerability,
>> and the vulnerability was fixed in IPv4 and IPv6 using different
>> approaches...
> 
> I see, thanks for the explanation! Even if there is a limit on
> fragment size, it should be configurable so your patches would still
> be relevant. As for eliminating the limit completely, I think that
> question is what is the remaining DOSability with a tiny fragment
> attack. Have you done any analysis that might shed light on that?
>

Given that we have no limit for IPv4, IPv6 should behave the same.

We already have memory limits, so the rbtree handling make sure any
incoming fragment will find the insertion point in O(log2(N)),
which is good enough, even if N is around 8000.