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
_______________________________________________ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
