On 2023-07-10, Anthony Coulter <b...@anthonycoulter.name> wrote: > 2. I abandon my quest to get NDP proxying added to iked and instead ask > if we can add a "rtlabel" keyword to iked.conf to make it easier for > me to write a separate process that monitors the routing table to > detect when the tunnel gets set up.
Currently iked (and isakmpd) use flows, not routes. These use messages on the PF_KEY socket not the route socket. (If I watch route -nv monitor while iked starts and brings up tunnels, I don't see any messages). IIUC the parts you found which currently exist are for the "iface" option which tells an iked initiator (a machine, typically but not necessarily mobile) to use mode-config to fetch an address, and configure it on an interface. There is a diff for route-based IPsec which does use the route table (https://marc.info/?l=openbsd-tech&m=168844868110327&w=2), but I think if you were using that, you could just look for messages relating to sec(4) interfaces anyway and not have to worry about labels? >> NDP proxying is also vulnerable to NDP cache DoS. It's more than just NDP proxying that results in this. Put a big chunk of address space on an interface that requires IP-to-physical address resolution and you end up having to do that resolution for a bunch of junk traffic coming from the internet. Say someone does some kind of sweep looking for hosts and sending unsolicited traffic to a bunch of addresses within a prefix, each address attempt will result in having to try to resolve that address. Whether it's successful or not, some work must be done for that (e.g. slow-path lookups on the gateway router, caching, etc). FWIW if I was a VPS/colo provider wanting to keep router resources low, I would probably assign a single address from a /64 to the customer machine/VM, and filter traffic from the internet so that packets to other addresses in the /64 are blocked - so junk traffic would not trigger junk NDP attempts.. (alternatively it's possible to use link-locals for that one "route via" address, though I would prefer to have that on a routable address for ease of debugging - traceroutes etc). Then for any additional addresses I'd route either multiple /64's, or a /56 or /48, via that one address - that way NDP is only ever done for the one address and it's likely to stay in cache. If you're on a low end VPS that is not already doing filtering like this, you may find that later on they change to implement that, when they figure out why the L3 switch they're using as a router is running out of steam when handling junk traffic... > Since my proposal to have iked enable NDP proxying itself failed to > gain traction I looked into other options (that don't involve > requesting a larger subnet from my ISP and VPS providers). I think you're thinking of having a subnet routed across as something that is going to cause more pain for the upstream provider. The reality is the opposite. If the provider doesn't understand this, there are probably a few other things they don't understand too, it would be a bit of a red flag for me. Yes there are a huge number of addresses in a /64, but really a /64 is what providers are expected to assign where they would assign an individual address for IPv4. For a situation where you'd have a couple of addresses with v4, with v6 it's really normal to have a /56 or /48.
