[RFC] Handling multiple endpoints for a single peer

[Jason A. Donenfeld]

On Mon, Jan 9, 2017 at 3:37 AM, Samuel Holland <samuel at sholland.org> wrote:
> I think there should be a distinction between endpoint addresses
> provided in explicit configuration and those discovered through roaming.
> Presumably, users put those addresses in the configuration file because
> they expect them to be relatively stable. So I think those endpoints
> should always be remembered.
>
> As for addresses learned from roaming, a simple solution is some form of
> aging. If the endpoint is changing because the machine is physically
> moving (e.g. to a different wireless network), it's not likely that
> previous address:port combinations will work again in the future, except
> for a few common locations (home, work). So there's not much reason to
> remember more than the last few. On the other hand, consider a
> fixed-location user whose IP only changes when the router reboots every
> few months. In that case, there's no chance of even the last one or two
> endpoints being reused. So a time-based aging seems more appropriate.
> Assuming (for illustration) you pick an endpoint every handshake, then
> "this endpoint hasn't been chosen in the last 50 handshakes" means it's
> okay to forget about.
>
> So: 1) always keep manually added endpoints, and 2) only keep a few
> roaming endpoints, and drop them when they are unused for a while.

I don't like the complexity of adding that kind of distinction,
between explicit and learned addresses. I think in the end that will
prove to be confusing. But I like the idea of keeping track of metrics
and cycling out based on that.

> As a separate point, I have a use case that I haven't seen discussed
> yet. I have a WireGuard peer at Site A with a public IP. I have two
> peers, a desktop and a laptop, at Site B, both behind NAT. Both of them
> are configured with the machine at Site A as their only peer. Often I
> take the laptop offsite, and then traffic between the desktop and laptop
> goes through Site A. Good. However, when I have them on the same local
> network, I'd like them to communicate directly (avoiding the round trip
> to Site A).
>
> The problem is that, if I add the desktop and laptop as peers to each
> other, they stop sending traffic through Site A at all. Thus, when they
> are _not_ on the same network (so behind two different NATs, as opposed
> to no NAT) they cannot communicate at all.
>
> It would be nice to get the desktop and laptop able to directly
> communicate (which is what we're discussing mostly in this thread), but,
> as a fallback, it would be nice to be able to say "if you can't
> handshake with the peer for this internal IP, send their traffic through
> the peer with the next larger enclosing subnet of allowed IPs. Then the
> peer with the public IP and the allowed IPs of 0.0.0.0/0 could act as a
> hub for peers behind stricter NATs.

Right now the cryptokey routing is very strict. All entries must work
one-to-one, and they're always enforced and active when present. What
you're suggesting here is that the cryptokey routing table entries
would sort of "disappear" when there isn't a current handshake. That's
interesting; I'll give it some thought.

One thing that comes to mind is how to detect when the local LAN peer
comes back online there. Should wireguard just be trying to initiate a
new handshake _always_, and eventually it will succeed and promote the
cryptokey routing table entry to "active"?