Introduce Wireguard support to bird

[Toke Høiland-Jørgensen]

Bernd Naumann <bena at spreadshirt.net> writes:

> On 08.06.19 00:18, Toke Høiland-Jørgensen wrote:
>
>> - The algorithm is basically O(P*M*N) for inserting N routes on an
>>   interface with P peers that each have M existing AllowedIPs. That is
>>   not going to scale very far :/
>> 
>> -Toke
>
> Hi Toke,
>
> Could you give me an example for a topology/setup where you have one
> server with only one wireguard interface, but n peers (sharing a
> key-pair(?)), connecting to that one server endpoint and have proper
> routing of the packets? Routing decision then happens in wireguard,
> but --let me repeat-- this implies that all "clients" share the same
> key-pair?

Why would they need to share the same key pair? Each node would have its
own key (but yeah, all of their peers would see the same public key from
that node).

> As far as I have understood wireguard setups I thought that per peer,
> a server has an individual interface with either specific networks or
> a 0.0.0.0/0 wildcard and then uses dynamic routing to fill the (os)
> kernels routing table to reach each client or client-network.

Sure, that is the most common deployment now, but (to me) the whole
point of having wg support in a routing daemon is to avoid having to do
this :)

> Off topic: Does this patch supports unnumbered ospf and bgp? I have not
> implemented this based on limited knowledge about the boundary condition
> and what is really needed from a linux perspective. (More info welcomed)
>
>
> Toff topic #2: Was there any progress on implementing/enable multicast
> support on wireguard interfaces? Just curious. See:
> https://lists.zx2c4.com/pipermail/wireguard/2016-December/000813.html
> (as far as "my" google outputs...)

Don't think so, but as far as I'm concerned, that would be part of the
"full" routing-based solution... :)

-Toke