netdev - Re: [PATCH v3 23/30] ipv6: defrag: drop non-last frags smaller than min mtu

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: Windows password security audit tool. GUI, reports in PDF.

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

Date:   Fri, 11 Jan 2019 09:09:04 -0800
From:   Peter Oskolkov <posk@...gle.com>
To:     Timothy Winters <twinters@....unh.edu>
Cc:     Michal Kubecek <mkubecek@...e.cz>, netdev <netdev@...r.kernel.org>,
        Eric Dumazet <edumazet@...gle.com>,
        Eric Dumazet <eric.dumazet@...il.com>,
        Florian Westphal <fw@...len.de>,
        Tom Herbert <tom@...bertland.com>,
        David Miller <davem@...emloft.net>
Subject: Re: [PATCH v3 23/30] ipv6: defrag: drop non-last frags smaller than
 min mtu

On Fri, Jan 11, 2019 at 6:54 AM Timothy Winters <twinters@....unh.edu> wrote:
>
> Hi Michal and Eric,
>
> Thanks for the clarification.   I'm thinking about creating a draft to say no fragments less then 640 unless it's the last fragment.   Does that work for your code going forward?

I will prepare a patchset to convert IPv6 defrag queue to rbtree+list,
similarly to how IPv4 defrag queue currently works. Just in case it is
decided to go this route. I don't think having an
arbitrary/non-standard size cap (640) is a good approach.

Thanks,
Peter


>
> ~Tim
>
> On Fri, Jan 11, 2019 at 9:21 AM Michal Kubecek <mkubecek@...e.cz> wrote:
>>
>> On Friday, 11 January 2019 14:26 Timothy Winters wrote:
>> > Hi Eric,
>> >
>> > So I understand correctly the attack that you are trying to prevent is
>> > many small fragments from different IPs?
>> >
>> > The 6MAN working group has had some discussion about this topic, if
>> > you want read some IPv6 networking prospectives.
>> >
>> > https://mailarchive.ietf.org/arch/browse/ipv6/?gbt=1&index=zsYUwQTt0mA
>> > dXdk9MN4dP-uiiag
>>
>> I haven't read all mails in that discussion but most seem to be missing
>> the point. The problem is not memory consumption, we have a (runtime
>> configurable) limit for that. The problem is that by sending many small
>> (8 bytes) fragments of a large (up to 64 KB) packet but never finishing
>> it, an attacker can force receiving host into using quite a lot of CPU
>> time just by looking up the fragment queue of the partially reassembled
>> packet.
>>
>> Currently, IPv6 reassembly uses a simple linear list which is fine with
>> 1280 byte long fragments (up to ~50 of them) but not with 8 byte long
>> ones (there could be as many as ~8000). The IPv4 reassembly code (where
>> we cannot assume minimal size of non-last fragment) switched to rbtree
>> (with logarithmic lookup time) exactly for this reason.
>>
>> > What about lowering the value of accepted fragments?  to something
>> > like 1280/2?
>>
>> That would be probably sufficient to mitigate the DoS attacks.
>>
>> Michal Kubecek
>>
>>