Hey Linus, Thanks for the patch and sorry for the delay in reviewing it. Seeing the basic scaffolding for getting netlink notifiers working with WireGuard is enlightening; it looks surprisingly straightforward.
There are three classes of things that are interesting to receive notifications for: 1) Things that the admin changes locally. This is akin to the `ip monitor`, in which you can see various things that other programs (or the kernel) modify. This seems straightforward and uncontroversial. 2) Authenticated events from peers. This basically amounts to new sessions being created following a successful handshake. This seems mostly okay because authenticated actions already have various DoS protections in place. 3) Unauthenticated events. This would be things like (a) your patch -- a peer's endpoint changes -- or, more interestingly, (b) public keys of unknown peers trying to handshake. (b) is interesting because it allows doing database lookups in userspace, adding the looked up entry, adding it to the interface, and initiating a handshake in the reverse direction using the endpoint information. It's partially DoS-protected due to the on-demand cookie mac2 field. (a) is also interesting for the use cases you outlined, but much more perilous, as these are highspeed packets where the outer IP header is totally unauthenticated. What prevents a man in the middle from doing something nasty there, causing userspace to be inundated with expensive calls and filling up netlink socket buffers and so forth? I wonder if this would be something better belonging to (2) -- getting an event on an authenticated peer handshake -- and combining that with the ability to disable roaming (something discussed a few times on wgml). Alternatively, maybe you have a different idea in mind about this? I also don't (yet) know much about the efficiency of multicast netlink events and what the overhead is if nobody is listening, and questions like that. So I'd be curious to hear your thoughts on the matter. Regards, Jason
