Hi WireGuard mailing list,

As part of my day job we're building a p2p broadcast network for a new type
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
To secure these connections, QUIC uses TLS 1.3 [1] which is in the process
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
network interface, it should be easy to transparently run QUIC or SCTP on
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
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
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
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
more heavyweight than simply opening a socket, but I guess it can be done
invocations of the `wg` or `wg-quick` tools. Has anyone had any experience
this level of WG automation, could you share your thoughts? Would the
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
subprotocol to support two protocols during network upgrade times. This is
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.


WireGuard mailing list

Reply via email to