From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: georgewalkeriv@gmail.com Received: from krantz.zx2c4.com (localhost [127.0.0.1]) by krantz.zx2c4.com (ZX2C4 Mail Server) with ESMTP id 3e797e1b for ; Sat, 8 Apr 2017 15:37:51 +0000 (UTC) Received: from mail-qt0-f173.google.com (mail-qt0-f173.google.com [209.85.216.173]) by krantz.zx2c4.com (ZX2C4 Mail Server) with ESMTP id 28c85ce8 for ; Sat, 8 Apr 2017 15:37:51 +0000 (UTC) Received: by mail-qt0-f173.google.com with SMTP id c45so38334798qtb.1 for ; Sat, 08 Apr 2017 08:44:24 -0700 (PDT) Return-Path: Content-Type: multipart/alternative; boundary=Apple-Mail-0FA68DCD-8618-4A69-B5F3-E0EED4A93BD6 Mime-Version: 1.0 (1.0) Subject: Re: [RFC] Multicast and IPv6 Link Local Addresses From: George Walker In-Reply-To: Date: Sat, 8 Apr 2017 11:44:21 -0400 Message-Id: <907F3B78-F081-4CE9-A689-6B87285FBF80@gmail.com> References: <03B23E99-75C4-4598-AC0A-3C65F346675F@gmail.com> To: "Jason A. Donenfeld" Cc: =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= , Juliusz Chroboczek , WireGuard mailing list , =?utf-8?Q?Dave_T=C3=A4ht?= List-Id: Development discussion of WireGuard List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , --Apple-Mail-0FA68DCD-8618-4A69-B5F3-E0EED4A93BD6 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable > If I understand correctly You do. > I find that a very nice UI > solution. Wonderful. Thanks! Thinking about it definitely got me excited about what I could do w= ith a secure multicast-capable network overlay... Sent from my iPhone > On Apr 7, 2017, at 4:42 PM, Jason A. Donenfeld wrote: >=20 > Hey George, >=20 > More excellent feedback, thanks. Be sure to CC the list next time though. >=20 > 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. >=20 > Jason >=20 >> On Fri, Apr 7, 2017 at 6:02 PM, George Walker w= rote: >> Cons: >> - A bit too magical. >> - Seems to break paradigm. >>=20 >>=20 >> Another is scalability --the computational and network overhead associate= d >> with making every peer irrevocably a member of every multicast group. >> Sending all multicast messages to all peers eliminates much of the benefi= t >> of having more than one multicast address. That could mean a lot of >> unnecessary handshakes! I can imagine applications for which this behavi= or >> would make (accidental or malicious) DoS very easy. >>=20 >> 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 n= ot >> being able to afford to broadcast everything to everyone. >>=20 >> 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? >>=20 >>=20 >> 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-know= n, >> specified in RFCs. That they behave a little bit differently from unicas= t >> addresses is expected behavior. Most of us ignore them and don't use tho= se >> 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. expecte= d >> behavior of the unicast traffic most people use most of the time. >>=20 >> 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 o= r >> not). >>=20 >> 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 secon= d). >> It sounds to me like doing the right (intuitive) thing in each case. --Apple-Mail-0FA68DCD-8618-4A69-B5F3-E0EED4A93BD6 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
If I und= erstand correctly
<= br>
You do.

<= font color=3D"#000000">I find that a very nice UI
solution. Wonderful.
Thanks!  Thinking about i= t definitely got me excited about what I could do with a secure multicast-ca= pable network overlay...

Sent from my iPhone

On 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 cluttereverything with a horrible "multi:" prefix, but instead allow=
multicast addressees, which are well defined, to be added to multi= ple
peers, and only allow unicast addresses to be added to o= ne 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 P= M, George Walker <georgewalke= riv@gmail.com> wrote:
Cons:=
- A bit too magical.=
- Seems to break par= adigm.


Another is scalability --the computational and network= overhead associated
= with making every peer irrevocably a member of every multicast group.=
Sending all multicast messa= ges 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 b= ehavior
would make (a= ccidental 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 bi= g far-flung networks that may
well have need for lots of multicast groups (e.g. industrial IoT), w= hile not
being able t= o afford to broadcast everything to everyone.

<= span>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?


<= /blockquote>
I respectfully disagree concerni= ng the necessity to add special, ugly,
inconsistent UI for the multicast-as-multicast (instead of=
multicast-as-broadca= st) approach.  Multicast address ranges are well-known,
specified in RFCs.  That they b= ehave a little bit differently from unicast
addresses is expected behavior.  Most of us igno= re them and don't use those
ranges most or all of the time, which works fine.  Thus Multicas= t support
(e.g. in ro= uters) doesn't generally interfere with the actual vs. expected
behavior of the unicast traffic m= ost people use most of the time.

Anyone w= ho is diddling with networking at this level already knows how to
=
avoid multicast IPs when they i= ntend unicast (whether they know they do or
not).

It doesn't s= eem problematic for a layer 3 VPN to treat adding a unicast
address when such an address is alrea= dy an allowedIP as different from
adding a multicast address (moving in the first case, adding in= the second).
It soun= ds to me like doing the right (intuitive) thing in each case.
= --Apple-Mail-0FA68DCD-8618-4A69-B5F3-E0EED4A93BD6--