netdev - Re: [PATCH v3 net-next 0/9] net: Generic network resolver backend and ILA resolver

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-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 11 Dec 2017 14:32:42 -0800
From:   Tom Herbert <tom@...bertland.com>
To:     Tom Herbert <tom@...ntonium.net>
Cc:     David Miller <davem@...emloft.net>,
        Linux Kernel Network Developers <netdev@...r.kernel.org>,
        Roopa Prabhu <roopa@...ulusnetworks.com>,
        Rohit LastName <rohit@...ntonium.net>
Subject: Re: [PATCH v3 net-next 0/9] net: Generic network resolver backend and
 ILA resolver

On Mon, Dec 11, 2017 at 2:16 PM, Tom Herbert <tom@...ntonium.net> wrote:
> On Mon, Dec 11, 2017 at 1:34 PM, David Miller <davem@...emloft.net> wrote:
>> From: Tom Herbert <tom@...ntonium.net>
>> Date: Mon, 11 Dec 2017 12:38:28 -0800
>>
>>> DOS mitigations:
>>>
>>> - The number of outstanding resolutions is limited by the size of the
>>>   table
>>> - Timeout of pending entries limits the number of netlink resolution
>>>   messages
>>> - Packets are not queued that are pending resolution. In the current
>>>   model that can be forwarded to a router that has all reachability
>>>   information (ILA use case for example)
>>
>> None of these mitigation schemes matter.
>>
>> If packet traffic can influence the table of entries (your cache
>> or whatever), then you will be DoS'able.
>>
>> If you limit outstanding resolutions, you harm legitimate traffic
>> whose resolutions will not be processed now too just as equally
>> as you will harm "bad guy" traffic.
>>
> David,
>
Actually, please disregard. I will respin to use secure redirects.

> How can we build a system that allows an unlimited number of
> resolutions without drop? Unless the resolution path can handle a
> higher packet load than the receive path, there will be some place in
> the system where memory is allocated and that limits the amount of
> pending resolutions (i.e. pending packet skbs, entry in a resolution
> table, skbs on a netlink socket).
>
>> If you forward in the case of pending resolution, the bad guy can
>> make you forward everything there.  The bad guy can effectively
>> make your caching node stop caching completely.
>>
> But a DOS attack doesn't stop fowarding, at best it forces suboptimal
> forwarding. This analogous to when the SYN cache is filled up but SYN
> cookies allow forward progress in a degraded operational mode.
>
> Thanks,
> Tom