multiple endpoints for a single peer -- implementation details

[Toke Høiland-Jørgensen]

Motiejus Jakštys <motiejus.jakstys at gmail.com> writes:

> On Thu, Jan 16, 2020 at 11:55 AM Toke Høiland-Jørgensen <toke at toke.dk> wrote:
>>
>> Motiejus Jakštys <motiejus.jakstys at gmail.com> writes:
>>
>> > [...]
>> Before you go and re-invent the happy eyeballs algorithm, may I suggest
>> you read the RFC? :)
>>
>> https://tools.ietf.org/html/rfc8305
>>
>> Specifically, the considerations for how to do multiple connection
>> attempts safely without overloading the network is relevant for this. As
>> is the bit about sorting DNS responses.
>
> From the RFC I learned that the client should not issue parallel
> requests, and time between tries must be reasonable (say 100ms). So
> the original problem goes away. Thanks for the link.

You're welcome :)

>> [...]
>>
>> > 2. more a concern: neither kernel, nor wireguard-go implementations
>> > are willing to accept more than one endpoint, and it would be messy to
>> > extend:
>> >
>> > include/uapi/linux/wireguard.h
>> >   WGPEER_A_ENDPOINT: struct sockaddr_in or struct sockaddr_in6
>> >
>> > device/uapi.go:
>> >   case "endpoint":
>> >   ...
>> >     endpoint, err := CreateEndpoint(value)
>> >
>> > Endpoint is fixed to be a single UDP address, and both kernel and
>> > wireguard-go refuse unknown keys. To have tooling
>> > backwards-compatibility (i.e. use newer wireguard-tools with older
>> > kernel implementations), wireguard-tools would need to know the
>> > supported "features" of the underlying implementation. And there is no
>> > version negotiation between the user/kernel space. Which makes it
>> > tricky to add features like this.
>>
>> Eh? The kernel API is netlink - you could just add multiple
>> WGPEER_A_ENDPOINT attributes. Or add a new one
>> (WGPEER_A_ENDPOINTS_MULTI?). Same thing for wireguard-go (I assume).
>
> New netlink attribute in userspace alone would mean that older kernels
> will not understand the message. Now that I looked at the headers
> again, kernel does send WGPEER_A_PROTOCOL_VERSION. Which solves the
> problem. Go has an equivalent "protocol_version".

Or a new userspace just adds the new attribute, and if the kernel
doesn't understand it, it will be rejected and userspace can fall back
to the old behaviour. At least I hope that's what the kernel does :)

-Toke