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]
Message-Id: <20171211.163416.1305681033764328226.davem@davemloft.net>
Date:   Mon, 11 Dec 2017 16:34:16 -0500 (EST)
From:   David Miller <davem@...emloft.net>
To:     tom@...ntonium.net
Cc:     netdev@...r.kernel.org, roopa@...ulusnetworks.com,
        rohit@...ntonium.net
Subject: Re: [PATCH v3 net-next 0/9] net: Generic network resolver backend
 and ILA resolver

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.

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.

Please, learn from OVS, the ipv4 routing cache, and the IPSEC
flow cache.  This kind of architecture, _especially_ when the
resolution is user side, is deeply flawed.

We're trying to remove code that does this kind of stuff, rather
than add new instances.

Thank you.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ