From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Miller Subject: Re: [PATCH v3 net-next 0/9] net: Generic network resolver backend and ILA resolver Date: Mon, 11 Dec 2017 16:34:16 -0500 (EST) Message-ID: <20171211.163416.1305681033764328226.davem@davemloft.net> References: <20171211203837.2540-1-tom@quantonium.net> Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netdev@vger.kernel.org, roopa@cumulusnetworks.com, rohit@quantonium.net To: tom@quantonium.net Return-path: Received: from shards.monkeyblade.net ([184.105.139.130]:40578 "EHLO shards.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751123AbdLKVeR (ORCPT ); Mon, 11 Dec 2017 16:34:17 -0500 In-Reply-To: <20171211203837.2540-1-tom@quantonium.net> Sender: netdev-owner@vger.kernel.org List-ID: From: Tom Herbert 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.