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:16:17 -0800
From:   Tom Herbert <tom@...ntonium.net>
To:     David Miller <davem@...emloft.net>
Cc:     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 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,

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

Powered by Openwall GNU/*/Linux Powered by OpenVZ