The case for anycast (contra move semantics for unicast AllowedIPs).

* The case for anycast (contra move semantics for unicast AllowedIPs).
@ 2018-04-19 19:44 George Walker
  2018-04-20  9:37 ` Toke Høiland-Jørgensen
  0 siblings, 1 reply; 3+ messages in thread
From: George Walker @ 2018-04-19 19:44 UTC (permalink / raw)
  To: Jason A. Donenfeld
  Cc: Toke Høiland-Jørgensen, Juliusz Chroboczek,
	WireGuard mailing list

[-- Attachment #1: Type: text/plain, Size: 4134 bytes --]

Hi Jason, Juliusz, Toke, Dave, et. al.,

A year ago we discussed Multicast addressing and the move semantics for
allowedIPs. Recently, I've been mulling over move semantics and their
implication for WireGuard's support for anycast addressing.

Unlike Multicast addresses, there are no designated address ranges for
anycast: an anycast address is just a unicast address that's advertised in
more than one place. As I understand it, the move semantics for allowedIPs
preclude anycast addressing, as IP addresses can only be assigned to one
peer at a time. This makes me wonder if it might be more correct to allow
unicast allowedIPs to be assigned to more than one peer, treating them as
anycast in that case.

The problem I see with allowing anycast addressing in WireGuard is the
potential for breaking TCP and other stateful protocols. Perhaps that could
be addressed by somehow keeping sessions localized to a particular peer,
e.g., by using a distance metric (perhaps based upon GeoIP lookups) or
hash-based binning. I'm not sure what the best way to handle failover.

Also, if memory serves, move semantics account for a large proportion of
the troubleshooting requests that show up on this list, suggesting to me
that the status quo --elegant though it is!-- may not
be especially intuitive.

What do y'all think?

Best regards,
George

On Fri, Apr 7, 2017 at 4:42 PM, Jason A. Donenfeld <Jason@zx2c4.com> wrote:

> Hey George,
>
> More excellent feedback, thanks. Be sure to CC the list next time though.
>
> If I understand correctly, your suggestion is to not clutter
> everything with a horrible "multi:" prefix, but instead allow
> multicast addressees, which are well defined, to be added to multiple
> peers, and only allow unicast addresses to be added to one peer at a
> time keeping the current behavior. I find that a very nice UI
> solution. Wonderful.
>
> Jason
>
> On Fri, Apr 7, 2017 at 6:02 PM, George Walker <georgewalkeriv@gmail.com>
> wrote:
> > Cons:
> > - A bit too magical.
> > - Seems to break paradigm.
> >
> >
> > Another is scalability --the computational and network overhead
> associated
> > with making every peer irrevocably a member of every multicast group.
> > Sending all multicast messages to all peers eliminates much of the
> benefit
> > of having more than one multicast address.  That could mean a lot of
> > unnecessary handshakes!  I can imagine applications for which this
> behavior
> > would make (accidental or malicious) DoS very easy.
> >
> > If you only have a lab-scale deployment and generous bandwidth, of course
> > receive-side filtering is fine.  But Wireguard's performance and general
> > utility would suggest that some will want big far-flung networks that may
> > well have need for lots of multicast groups (e.g. industrial IoT), while
> not
> > being able to afford to broadcast everything to everyone.
> >
> > Thus, there'd have to be
> > some explicit way of telling it, "yes I really do want this to be
> > duplicated, not moved". Perhaps a "multi:" prefix?
> >
> >
> > I respectfully disagree concerning the necessity to add special, ugly,
> > inconsistent UI for the multicast-as-multicast (instead of
> > multicast-as-broadcast) approach.  Multicast address ranges are
> well-known,
> > specified in RFCs.  That they behave a little bit differently from
> unicast
> > addresses is expected behavior.  Most of us ignore them and don't use
> those
> > ranges most or all of the time, which works fine.  Thus Multicast support
> > (e.g. in routers) doesn't generally interfere with the actual vs.
> expected
> > behavior of the unicast traffic most people use most of the time.
> >
> > Anyone who is diddling with networking at this level already knows how to
> > avoid multicast IPs when they intend unicast (whether they know they do
> or
> > not).
> >
> > It doesn't seem problematic for a layer 3 VPN to treat adding a unicast
> > address when such an address is already an allowedIP as different from
> > adding a multicast address (moving in the first case, adding in the
> second).
> > It sounds to me like doing the right (intuitive) thing in each case.
>

[-- Attachment #2: Type: text/html, Size: 5188 bytes --]

^ permalink raw reply	[flat|nested] 3+ messages in thread