Re: Using WG for transport security in a p2p network

[Ximin Luo <ximin@dfinity.org>]

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

On Thu, Apr 5, 2018 at 8:32 AM, Kalin KOZHUHAROV <me.kalin@gmail.com> wrote:

> On Thu, Apr 5, 2018 at 5:22 AM, Ximin Luo <ximin@dfinity.org> wrote:
> > Our network churn is not expected to be very heavy, perhaps on the order
> of
> > ~30 new connections per node per week or so. So any extra latency in the
> initial
> > connection caused by this separation of layers, should not be
> significant.
> > However this churn is probably higher than what current typical WG usages
> > get exposed to.
> >
> Few times a day, I would even say few times per hour is a very normal use
> and
> should not be strange, AFAIK.
>

OK great, thanks for clarifying.


> > I'm also wondering how easy this would be to program. It would clearly be
> > much more heavyweight than simply opening a socket, but I guess it can
> be done
> > via invocations of the `wg` or `wg-quick` tools. Has anyone had any
> experience
> > with this level of WG automation, could you share your thoughts?
> >
> Definitely not "hard", it will depend more on what you are trying to
> achieve exactly.
>
> > Would the program need any extra system-level privileges?
> >
> Yes for sure ;-D Adding interfaces is a admin task, using sudo or
> similar should be trivial.
>
> > Ideally we wouldn't need root, of course - does that mean we're forced
> to wait for a userspace WG library such
> > as wireguard-rs? I understand there is a performance penalty here, but
> I'd have
> > to run benchmarks to know if this affects our use-case significantly.
> >
> I don't think performance matters in your case, as it will be only
> during setup; once setup,
> all data goes to a socket/kernel and it doesn't matter how it was set up.
>

Application-level data goes to a socket, but AIUI adding/removing WG
protocol wrapping is done either in the kernel (as in the main
implementation) or in userspace (as in wireguard-rs). In the latter case
there is apparently a performance penalty in terms of throughput (i.e. not
only for the setup phase), judging by Jason's comments in various places.
Did I understand wrong / could you explain in more detail if so?


> > Once the network is live, we'd need the transport protocol to be
> relatively
> > stable, or at least be easily upgradeable - perhaps using the noise
> > negotiation subprotocol to support two protocols during network upgrade
> times. This is
> > an extra requirement that seems beyond WG's current main use-case so I
> was also
> > wondering if that is something that you guys plan to cover.
> >
> Making it "support 2 protocols" in the design phase is a good practice
> for availability.
> It will introduce complexity, maintainability issues and thus possible
> security issues.
> Working out a "maintenance mode" might be easier.
>

Could you elaborate what is meant by "maintenance mode"?

I suppose in the worst case we could do something like: add logic "change
from protocol X to protocol Y at future round N" to software version V and
expect that everyone upgrades to software version V before round N. That
should hopefully work even if protocol X doesn't explicitly define a smooth
upgrade path to protocol Y (e.g. X = WG version 3, Y = WG version 4).

X

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