Re: Interest in adding multicast support to Wireguard?

[Reid Rankin <reidrankin@gmail.com>]

I looked at this a while back. As far as I could tell, there's nothing
fundamental about the protocol or the security model that prevents it
from happening; conceptually, it's as simple as overlapping AllowedIP
ranges. This is easy for incoming traffic, but outgoing traffic is
more difficult; each outgoing packet would need to be duplicated and
encrypted separately for each target peer. What's more, each of these
duplicate unicast packets would have to be queued separately because
each peer may be in a different handshake state.

None of this makes multicast over WireGuard impossible, however, just
difficult to fit into the existing implementation. I've toyed with the
idea of a one-interface-per-peer setup with bridging or some fancy
netfilter stuff to handle duplication and dispatch between them, but
it seems like it would be a PITA so I've never taken it farther.

As far as "special" multicast ranges, heck no. One of the fundamental
assurances of WG is that you'll only ever receive packets from a peer
which have a source address listed in that peer's AllowedIPs. If you
want to put ff00::/8 and 224.0.0.0/4 in a peer's AllowedIPs, by all
means, but I'm strongly against WG itself having any special notion of
what a "multicast address" is or any special handling -- or sneaky
emergent properties -- for them. DHCPv6, for example, requires only
ff02::1:2; if that's what you want, I probably wouldn't whitelist a
whole /8 to get it. YMMV, of course, but that should be the user's
choice and responsibility.

Another reason not to treat certain address ranges specially is that
there's more use cases for what would effectively be a "link-layer"
multicast than there are for IP multicast. You could have something
like port mirroring going on; say you've got a gateway with ::/0 as
well as an IDS with the same range. Both could receive the same
traffic, which could be useful in some applications. Obviously, you'd
need to realize the security implications -- both client-side (sending
copies of all your traffic) and IDS-side (trusting that you'll really
be sent copies of all the traffic) -- but flexibility is good, and I
can imagine some usecases (especially embedded systems) where that
would be a desirable property. (Sure beats sending the traffic in the
clear and having the IDS -- and whoever's hacked your switch -- get it
that way.)

--Reid

On Mon, Sep 21, 2020 at 7:27 AM Jason A. Donenfeld <Jason@zx2c4.com> wrote:
>
> We've discussed this extensively and repeatedly. I made a few
> proposals a few years ago that we discussed. It doesn't fit into
> WireGuard's strong binding model.
>
> Jason