[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CALx6S35HmhzcSrtSL=SeL6qZjBSWEepzxkbcL1TKC9qirWegkA@mail.gmail.com>
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
Powered by blists - more mailing lists