<div dir="ltr">Hi WireGuard mailing list,<br><br>As part of my day job we're building a p2p broadcast network for a new type of<br>blockchain, where latency is very important and certain objects need to be<br>delivered with greater priority than other objects. So I've looked into both<br>QUIC and SCTP since they offer stream multiplexing within a single connection.<br>To secure these connections, QUIC uses TLS 1.3 [1] which is in the process of<br>being finalised, and there is an S-SCTP extension [2] with unclear delivery<br>date and no implementations.<br><br>[1] <a href="https://tools.ietf.org/html/draft-ietf-quic-tls-09">https://tools.ietf.org/html/draft-ietf-quic-tls-09</a><br>[2] <a href="https://tools.ietf.org/html/draft-hohendorf-secure-sctp-25">https://tools.ietf.org/html/draft-hohendorf-secure-sctp-25</a><br><br>Another option would be to run insecure QUIC or SCTP on top of WireGuard,<br>ignoring TLS and S-SCTP completely. Noise is much simpler and we already<br>authenticate node public keys via other means, so have no use for the<br>certificate logic that both TLS and S-SCTP include. Since WireGuard runs as a<br>network interface, it should be easy to transparently run QUIC or SCTP on top<br>of it, allowing us to decouple the security mechanism from the transport<br>mechanism. Then there are other issues to consider hence my email:<br><br>Our network churn is not expected to be very heavy, perhaps on the order of ~30<br>new connections per node per week or so. So any extra latency in the initial<br>connection caused by this separation of layers, should not be significant.<br>However this churn is probably higher than what current typical WG usages get<br>exposed to. For example in [1] Jason says:<br><br>> Secondly, I'm wondering if you tend to do, "anything strange". For<br>> example -- are you setting up and taking down the device often in an<br>> automated way? Or reconfiguring the interface (via wg(8), for example)<br>> often in an automated way?<br><br>[1] <a href="https://lists.zx2c4.com/pipermail/wireguard/2018-February/002370.html">https://lists.zx2c4.com/pipermail/wireguard/2018-February/002370.html</a><br><br>Our usage would indeed involve setting up and tearing down interfaces ~30 times<br>a week in an automated fashion, which might be "strange" going by the above.<br><br>I'm also wondering how easy this would be to program. It would clearly be much<br>more heavyweight than simply opening a socket, but I guess it can be done via<br>invocations of the `wg` or `wg-quick` tools. Has anyone had any experience with<br>this level of WG automation, could you share your thoughts? Would the program<br>need any extra system-level privileges? Ideally we wouldn't need root, of<br>course - does that mean we're forced to wait for a userspace WG library such as<br>wireguard-rs? I understand there is a performance penalty here, but I'd have to<br>run benchmarks to know if this affects our use-case significantly.<br><br>Once the network is live, we'd need the transport protocol to be relatively<br>stable, or at least be easily upgradeable - perhaps using the noise negotiation<br>subprotocol to support two protocols during network upgrade times. This is an<br>extra requirement that seems beyond WG's current main use-case so I was also<br>wondering if that is something that you guys plan to cover.<br><br>Best,<br><br>Ximin<br><br></div>