Using WG for transport security in a p2p network

[Ximin Luo <ximin@dfinity.org>]

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

Hi WireGuard mailing list,

As part of my day job we're building a p2p broadcast network for a new type
of
blockchain, where latency is very important and certain objects need to be
delivered with greater priority than other objects. So I've looked into both
QUIC and SCTP since they offer stream multiplexing within a single
connection.
To secure these connections, QUIC uses TLS 1.3 [1] which is in the process
of
being finalised, and there is an S-SCTP extension [2] with unclear delivery
date and no implementations.

[1] https://tools.ietf.org/html/draft-ietf-quic-tls-09
[2] https://tools.ietf.org/html/draft-hohendorf-secure-sctp-25

Another option would be to run insecure QUIC or SCTP on top of WireGuard,
ignoring TLS and S-SCTP completely. Noise is much simpler and we already
authenticate node public keys via other means, so have no use for the
certificate logic that both TLS and S-SCTP include. Since WireGuard runs as
a
network interface, it should be easy to transparently run QUIC or SCTP on
top
of it, allowing us to decouple the security mechanism from the transport
mechanism. Then there are other issues to consider hence my email:

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. For example in [1] Jason says:

> Secondly, I'm wondering if you tend to do, "anything strange". For
> example -- are you setting up and taking down the device often in an
> automated way? Or reconfiguring the interface (via wg(8), for example)
> often in an automated way?

[1] https://lists.zx2c4.com/pipermail/wireguard/2018-February/002370.html

Our usage would indeed involve setting up and tearing down interfaces ~30
times
a week in an automated fashion, which might be "strange" going by the above.

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? Would the
program
need any extra system-level privileges? 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.

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.

Best,

Ximin

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