| Message ID | 20171221193332.15303-1-tom@quantonium.net |
|---|---|
| Headers | show |
| Series | net: ILA notification mechanism and fixes | expand |
From: Tom Herbert <tom@quantonium.net> Date: Thu, 21 Dec 2017 11:33:25 -0800 > This patch set adds support to get netlink notifications for ILA > routes when a route is used. > > This patch set contains: > > - General infrastructure for route notifications > - The ILA route notification mechanism > - Add net to ila build_state > - Add flush command to ila_xlat > - Fix use of rhashtable for latest fixes > > Route notifications will be used in conjunction with populating > ILA forwarding caches. Tom, this is just a wolf in sheep's clothing. It's still a cache controllable by external entities. It still therefore has the DoS'ability aspects. You can keep reframing this thing you want out there, either by explicitly filling the cache in the kernel or doing it via userspace responding the netlink events, but it's still the same exact thing with the same set of problems. I'm sorry, but I can't apply this series. Nor any series that adds a DoS'able facility of forwarding/switching/route objects to the kernel. Thanks.
On Tue, Dec 26, 2017 at 2:29 PM, David Miller <davem@davemloft.net> wrote: > From: Tom Herbert <tom@quantonium.net> > Date: Thu, 21 Dec 2017 11:33:25 -0800 > >> This patch set adds support to get netlink notifications for ILA >> routes when a route is used. >> >> This patch set contains: >> >> - General infrastructure for route notifications >> - The ILA route notification mechanism >> - Add net to ila build_state >> - Add flush command to ila_xlat >> - Fix use of rhashtable for latest fixes >> >> Route notifications will be used in conjunction with populating >> ILA forwarding caches. > > Tom, this is just a wolf in sheep's clothing. > Dave, > It's still a cache controllable by external entities. > Yep, that's the nature of the problem. In networks of even modest scale we anticipate that we'll see the number of virtual addresses (identifiers) far exceed the number of physical hosts. The mapping of virtual to physical address is not aggregable, so at full we expect 10s of billions of these discrete mappings in a single network. No single device will be able hold all these mappings, so they'll be sharded amongst some number of routers. This works fine for connectivity except that it would be nice to eliminate the triangular routing by having the source perform encapsulation for destination itself. So this is the motivation for a working set cache. It is an optimization, but in networks like 3GPP, it's a big win to eliminate anchor points in mobility. > It still therefore has the DoS'ability aspects. > True, if implemented without consideration of DOS this is a very bad thing as proven already by others. However if we know this going in then DOS'ability can be mitigated or eliminated depending on the rest of the implementation and architecture, similar to how SYN attacks can be dealt with. For example, suppose a device has 10G input link, we want a cache entry to be usable for at least 30 seconds, and we have no control over the users on the other side of the link (a typical eNodeB scenario). That gives a worse case of 19M pps, 585M packets over 30 seconds. Assuming 64 bytes per cache entry that gets us to 37G of memory needed in the host. That amount of memory is reasonable for a networking device. Cost of memory should drop over next few years so 10X scaling within ten years seems feasible. > You can keep reframing this thing you want out there, either by > explicitly filling the cache in the kernel or doing it via userspace > responding the netlink events, but it's still the same exact thing > with the same set of problems. > I would point out that the attack surface area using a redirect mechanism is _way_ less than request/response that was used by LISP or OVS. > I'm sorry, but I can't apply this series. Nor any series that adds a > DoS'able facility of forwarding/switching/route objects to the > kernel. > Technically, this patch set was just adding route notificates that facilitate but aren't a requirement for cache management. However, I do sympathsize with your concerns. Scaling and DOS are precisely the big problem to overcome in network virtualization and identifier/locator split. Happy Holidays! Tom
This patch set adds support to get netlink notifications for ILA routes when a route is used. This patch set contains: - General infrastructure for route notifications - The ILA route notification mechanism - Add net to ila build_state - Add flush command to ila_xlat - Fix use of rhashtable for latest fixes Route notifications will be used in conjunction with populating ILA forwarding caches. There are three methods described in the ILA Mapping Protocol. These are redirects, request/reply, and push. The ILA route mechanism is relevant to the first two methods. - ILA router secure redirect mechanism-- This is used on an ILA router where a notification is sent when an ILA host route is used. The purpose of this notification is to send an ILA redirect towards the ILA forwarding node of a source to inform it of a direct ILA route. When the forwarding node receives the redirect it can populate its cache so that subsequent packets take the direct path. This is the RECOMMENDED method. - Cache address resolution-- This used to perform request/reply address resolution on a route. As noted on netdev list, a request/reply mechanism is susceptible to DOS attacks. For this reason, this method is not NOT RECOMMENDED as the primary means to populate an ILA cache. ILAMP is described in https://www.ietf.org/internet-drafts/draft-herbert-ila-ilamp-00.txt Tested: Ran ILA traffic, set up ILA notify routes and observed correct routing message via ip monitor. v5: - Fix some compiler and sparse warnings - Generalize route notify with RTM_NOTIFYROUTE, RTNLGRP_ROUTE_NOTIFY (suggested by Roopa) v4: - Remove front end cache per davem feedback - Eliminate separate LWT type just use ILA LWT already in place v3: - Removed rhashtable changes to their own patch set - Restructure ILA code to be more amenable to changes - Remove extra call back functions in resolution interface Changes from initial RFC: - Added net argument to LWT build_state - Made resolve timeout an attribute of the LWT encap route - Changed ILA notifications to be regular routing messages of event RTM_ADDR_RESOLVE, family RTNL_FAMILY_ILA, and group RTNLGRP_ILA_NOTIFY Tom Herbert (7): lwt: Add net to build_state argument rtnetlink: Add notify route message types ila: Fix use of rhashtable walk in ila_xlat.c ila: Call library function alloc_bucket_locks ila: Create main ila source file ila: Flush netlink command to clear xlat table ila: Route notify include/net/lwtunnel.h | 6 +- include/uapi/linux/ila.h | 3 + include/uapi/linux/rtnetlink.h | 6 + net/core/lwt_bpf.c | 2 +- net/core/lwtunnel.c | 4 +- net/ipv4/fib_semantics.c | 13 +- net/ipv4/ip_tunnel_core.c | 4 +- net/ipv6/ila/Makefile | 2 +- net/ipv6/ila/ila.h | 27 +++- net/ipv6/ila/ila_common.c | 30 ----- net/ipv6/ila/ila_lwt.c | 275 ++++++++++++++++++++++++++------------ net/ipv6/ila/ila_main.c | 121 +++++++++++++++++ net/ipv6/ila/ila_xlat.c | 290 ++++++++++++++++++++--------------------- net/ipv6/route.c | 2 +- net/ipv6/seg6_iptunnel.c | 2 +- net/ipv6/seg6_local.c | 5 +- net/mpls/mpls_iptunnel.c | 2 +- 17 files changed, 511 insertions(+), 283 deletions(-) create mode 100644 net/ipv6/ila/ila_main.c