Development discussion of WireGuard
 help / color / mirror / Atom feed
From: "Daniel Gröber" <dxld@darkboxed.org>
To: wireguard@lists.zx2c4.com
Cc: bird-users@network.cz, babel-users@alioth-lists.debian.net
Subject: [RFC] Replace WireGuard AllowedIPs with IP route attribute
Date: Sat, 19 Aug 2023 16:02:18 +0200	[thread overview]
Message-ID: <20230819140218.5algu2nfmfostngh@House.clients.dxld.at> (raw)

Hi wireguard, birds, and babelers,

tl;dr I want to add a new Linux route attribute (think "via $wgpeer") to
supplement wireguard's internal AllowedIPs logic for both routing and
source address filtering.

I've been pondering how to better integrate wireguard into dynamic routing
daemons, particularly BIRD and babeld. Essentially we want to be able to
dynamically add/remove AllowedIPs depending on current reachability and/or
link quality stats.

Looking at the wg netlink API I see two major efficiency/scalability
problems: 1) there is no way to be notified of changes in AllowedIPs made
by other processes meaning we have to do periodic scans and 2) a peer's
AllowedIPs set can only be replaced wholesale, not modified
incrementally. This is problematic as "someone" might, in the worst case,
want to install an entire internet routing table's worth of AllowedIPs and
the set will likely change frequently. FYI: The IPv4 table has ~1M entries
at present, yikes.

Assuming external AllowedIPs changes are infrequent occationally dumping
them all to keep a consistent view of the state shouldn't be too much of an
issue as long as the netlink interface is performant enoug, so I'm going to
concentrate on the add/remove API for now.

Instead of doing the obvious thing and adding a more efficient incremental
AllowedIPs netlink interface I figure why not just add a route attribute to
select a target wg peer on a device. That way we could not only save memory
(no separate AllowedIPs trie) but also simplify routing daemon
implementation considerably.

This would mirror how on ethernet you can have `dev eth0 via $router_ip`.
I'm still reviewing the net/ code to find the best way to do this, but I'm
thinking either a new RTA_WGPEER, like: `default dev wg0 via-wgpeer
$peer_pubkey` or perhaps re-using RTA_VIA and keying off a statically
configured AllowedIP addresses.

To start I'd make this an opt-in replacement for our usual AllowedIPs
logic, making sure to only activate it if any via* RTAs are active on a
particular device, but if it proves to work well I don't see why we
couldn't adapt the netlink code to maintain AllowedIPs using this RTA (but
invisible to userspace) to re-use the same code and get rid of allowedips.c
altogether. That's assuming this ends up being less code overall or perhaps
more performant.

Happy to hear your thoughts,
--Daniel

             reply	other threads:[~2023-08-19 14:02 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-19 14:02 Daniel Gröber [this message]
     [not found] ` <5112ea1f-0f67-4907-a3c5-b6c7b9e591ca@kr217.de>
2023-08-19 18:17   ` Daniel Gröber
2023-08-19 20:00 ` [Babel-users] " Steffen Vogel
2023-08-19 21:23   ` Daniel Gröber
2023-08-28 15:40     ` Kyle Rose
2023-08-28 16:07       ` Daniel Gröber
2023-08-28 17:40         ` Juliusz Chroboczek
2023-08-28 17:55           ` Kyle Rose
2023-08-28 22:13           ` Daniel Gröber
2023-09-03  3:21             ` Ivan Labáth
2023-09-29 13:12               ` Daniel Gröber
2023-09-29 16:19                 ` Reto
     [not found]             ` <804a0c0a-78df-7f4c-1d0d-213e8bdb4120@nic.cz>
2023-11-09 11:57               ` [Babel-users] " Alexander Zubkov
2023-11-18  2:19                 ` Daniel Gröber
     [not found]                   ` <918e1d5b-9f11-4f9c-bf9a-94cb0d41ce2b@app.fastmail.com>
2023-11-18 12:22                     ` Juliusz Chroboczek
2023-11-20  2:05                       ` Daniel Gröber
     [not found]                         ` <CABr+u0b6vrZoYzQcMiCXX7W0XsQRNMzQfZnT5cK1MQoZ4NoqkA@mail.gmail.com>
2023-11-22  7:39                           ` Daniel Gröber
2023-08-19 20:05 ` Kyle Rose

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20230819140218.5algu2nfmfostngh@House.clients.dxld.at \
    --to=dxld@darkboxed.org \
    --cc=babel-users@alioth-lists.debian.net \
    --cc=bird-users@network.cz \
    --cc=wireguard@lists.zx2c4.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).