Message ID | 20171211203837.2540-1-tom@quantonium.net |
---|---|
Headers | show |
Series | net: Generic network resolver backend and ILA resolver | expand |
From: Tom Herbert <tom@quantonium.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.
On Mon, Dec 11, 2017 at 1:34 PM, David Miller <davem@davemloft.net> wrote: > From: Tom Herbert <tom@quantonium.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
On Mon, Dec 11, 2017 at 2:16 PM, Tom Herbert <tom@quantonium.net> wrote: > On Mon, Dec 11, 2017 at 1:34 PM, David Miller <davem@davemloft.net> wrote: >> From: Tom Herbert <tom@quantonium.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
From: Tom Herbert <tom@quantonium.net> Date: Mon, 11 Dec 2017 14:16:17 -0800 > How can we build a system that allows an unlimited number of > resolutions without drop? IPV4 routing solves this with a prefixed trie, for example. The fundamental backing datastructure for the switching or whatever operation must be in-memory, in the kernel, scalable, and without a fronting "cache".