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