<div dir="ltr"><div class="gmail_extra">(reposting to the list)<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Apr 5, 2018 at 12:13 AM, Matthias Urlichs <span dir="ltr"><<a href="mailto:matthias@urlichs.de" target="_blank">matthias@urlichs.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div bgcolor="#FFFFFF"><span class="gmail-">
<blockquote type="cite">Another option would be to run insecure QUIC or SCTP on top of
WireGuard,<br>
</blockquote></span>
You cannot run SCTP on the Internet anyway. Too many routers block
anything that's not TCP/UDP/ICMP.<span class="gmail-"><br></span></div></blockquote><div><br>Well, that's another advantage of running on top of WG. AIUI the content
should be encrypted and authenticated so to all routers the traffic
would look like opaque UDP traffic. The endpoints will decrypt and pass
it to their SCTP/QUIC stack. <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div bgcolor="#FFFFFF"><span class="gmail-">
<blockquote type="cite">
<div dir="ltr">I'm also wondering how easy this would be to
program. It would clearly be much<br>
more heavyweight than simply opening a socket, but I guess it
can be done via<br>
invocations of the `wg` or `wg-quick` tools.</div>
</blockquote></span>
Don't use the tools. There's a library around that you can use to do
all of the heavy lifting via netlink sockets. You'll also need the
privilege to assign addresses and routes to the WG interfaces.<span class="gmail-"><br>
<blockquote type="cite">
<div dir="ltr">Ideally we wouldn't need root</div>
</blockquote></span>
If you go the netlink route, you do need one process that has the
appropriate privilege, which means root at install time (but not
runtime).<span class="gmail-"><br></span></div></blockquote><div><br></div><div>OK, thanks for the pointer to the netlink library I'll check that out. Someone else mentioned CAP_NET_ADMIN, I'll follow that up in a separate email.<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div bgcolor="#FFFFFF"><span class="gmail-">
<blockquote type="cite">
<div dir="ltr"><br>
Once the network is live, we'd need the transport protocol to be
relatively<br>
stable, or at least be easily upgradeable</div>
</blockquote></span>
Well, the WG wire protocol is supposed to be stable by now.
Switching away from it would require new code on your side anyway,
so you can implement the exact method of switching at that time.<span class="gmail-HOEnZb"><font color="#888888"></font></span><br></div></blockquote><div><br></div><div>What does "stable" mean exactly here though? At some point the WG protocol might need a new version, e.g. to reselect ciphers to e.g. add post-quantum crypto. In the typical WG use-case this is not an issue because the network admin controls both endpoints and can upgrade both simultaneously, but this wouldn't be the case for our p2p network.<br><br></div><div>X<br><br></div></div></div></div>