5 ms·

S2n-QUIC (Rust implementation of QUIC)

105 points by jeffbarr 5y ago

batisteo 5y ago
https://github.com/quinn-rs/quinn https://github.com/quinn-rs/quinn
- hunterb123 5y ago
  Also: https://github.com/cloudflare/quiche https://github.com/cloudflare/quiche CloudFlare's QUIC implementation written in Rust
  - wongarsu 5y ago
    Also: https://github.com/mozilla/neqo https://github.com/mozilla/neqo - Neqo, an Implementation of QUIC written in Rust
- FullyFunctional 5y ago
  I wonder how they compare (but I'm not willing to spend hours comparing for myself). I do note in passing that S2n-QUIC has a really nice set of examples of how to use right up front in the README. All libraries should ideally have that. Without reading anything else, I already have a good idea of how hard it would be to use S2n-QUIC (looks easy).
  - mlindner 5y ago
    BTW I will note that almost all Rust crypto (including that used by both packages) is all based on the ring crate, which is rather problematically managed and is itself a bunch of assembly and C code that's just taken straight from BoringSSL and OpenSSL.
    - agency 5y ago
      It looks like by default s2n-quic uses this TLS implementation, which is not based on the ring crate (though it is written in C) https://github.com/aws/s2n-tls https://github.com/aws/s2n-tls
      - tialaramex 5y ago
        However, that TLS implementation still thinks accepting TLS 1.0 is not only a reasonable default but also something you won't ever want to switch off except via an "I know what I'm doing" setting, and their "default" configuration has rusted into place several years ago.
        colmmacc 5y ago
        I think we're getting closer to TLS1.0 disabled by default, but there are still clients out there and that's all they do. Especially embedded systems. It's a good practice to turn off old protocols but it has to be balanced with system availability. We go pretty deep on TLS and pay a lot of attention to what the problems in each protocol version are and having mitigations for them. A big source of comfort too is that it's been a long time since new clients can be made to fallback to old versions when they shouldn't.
        tialaramex 5y ago
        You're coming up on a year after RFC 8996 (saying to stop using TLS 1.0), which is itself almost three years after the die-die-die draft and RFC 8446 (TLS 1.3) I get why s2n has an SSLv3 implementation, even if it SSLv3 was already a bad idea by the time s2n existed, and I would likewise understand why it still has TLS 1.0, but I don't understand how it makes sense to advertise a "default" strategy that enables TLS 1.0 but not TLS 1.3 in 2022. If as I assumed in my earlier comment "default" is rusted in place as meaning "The thing that happened to work when this was popularised and now we dare not change it" then I guess that's a sad way for s2n's team to learn about Hyrum's Law but you should just stop advertising the "default" feature having learned that lesson, continuing to have docs that say "Use the defaults" when the defaults are rusted in place is bad. Or maybe I just don't understand and s2n is only intended for some niche legacy scenarios where TLS 1.3 won't make sense?
    - eptcyka 5y ago
      That's because currently it's impossible to ensure that rustc won't short-circuit a function if it sees an opportunity to do so, which means it's impossible to write constant-time functions which is a necessity for any kind of production ready crypto code.
    - capableweb 5y ago
      Keyword being almost all. I ran `cargo tree | grep -i ring` in all four currently listed QUIC implementations, and three of them have ring somewhere in the dependency tree, except for mozilla/neqo.
JoshTriplett 5y ago
Is there a "can I use" for networks/middleboxes/etc and the problems that arise with them, that talks about the real-world aspects of trying to use QUIC universally? I'd love to use QUIC between a (non-browser) client and server for which both ends are code I've written, without having to have fallbacks to HTTP/1.1 or HTTP/2. (Among other things, I love the idea of just establishing one connection and using it for two-way communication, without worrying about things like WebSocket.) However, the client also needs to run in random places, and while it doesn't necessarily need to support hostile networks, it does need to support broken networks, which to a first approximation can be similar. Are there statistics available for whether and how often QUIC (or more generally UDP) works with: - Random ISPs of varying quality - Cell data connections - Shops and airports and similar, which commonly use captive portals and try to intercept traffic when they shouldn't, and come pretty close to being hostile networks - Vaguely reasonable corporate networks, that aren't trying to block QUIC but might do so through misconfiguration or through some misguided policy put in place for unrelated reasons (e.g "our firewall rules are written about TCP and just drop all UDP and ICMP, and people complain but nobody with the power to change it") - Somewhat less reasonable corporate networks, that force everything through a proxy and may require things like CONNECT-UDP or SOCKS, but still aren't actively trying to block QUIC I'm hoping that efforts like fly.io's userspace wireguard stack (which uses UDP) might have data here. I'm specifically not asking about the case of networks that are actually trying to be hostile (to QUIC or otherwise), both because such networks may break any number of things including TLS or WebSockets, and because I'd like to avoid restarting the recurring discussion about whether QUIC/etc are a conspiracy to disempower network administrators. I'd love to know the statistics there too, though, if they're available. I'm also curious about the best-known method to reliably and efficiently tunnel QUIC out of a network within a client, for the purposes of separating always-QUIC logic from weird-network-handling logic. Does it make sense, for instance, to have a standard way to tunnel a secure QUIC connection through an insecure TCP connection?
- benmmurphy 5y ago
  i think tunnelling quic over TCP might run into the same problems you have when tunnelling TCP/IP over TCP. if you have two congestion algorithms running then you get weird performance issues. http://sites.inka.de/~W1011/devel/tcp-tcp.html http://sites.inka.de/~W1011/devel/tcp-tcp.html
rektide 5y ago
there's a bunch of bullet points going through some staple material, but the last bullet point has some absurdly good high grade features! > and much more, including CUBIC congestion controller support, packet pacing, Generic Segmentation Offload support, Path MTU discovery, and unique connection identifiers detached from the address also, a blog announcement appeared for this, https://aws.amazon.com/blogs/security/introducing-s2n-quic-open-source-protocol-rust/ https://aws.amazon.com/blogs/security/introducing-s2n-quic-o...
- jeffbee 5y ago
  I wonder why ye olde CUBIC without offering a choice of BBR or - dare I dream it - Swift.
  - electricshampo1 5y ago
    Is Swift (https://dl.acm.org/doi/pdf/10.1145/3387514.3406591 https://dl.acm.org/doi/pdf/10.1145/3387514.3406591) expected/designed to be used in non-intra dc environments where primarily quic is expected to have an advantage relative to tcp? I agree that it still would be nice to have as an option.
    - jeffbee 5y ago
      Well I don’t really agree with the premise of your statement. I think that the benefit of the new protocol is going to mostly be felt inside the data center.
  - Matthias247 5y ago
    CUBIC is a good baseline congestion controller. It's the default one that is being used in Linux, so it should provide adequate performance for a wide range of use-cases. Plus it's not so "olde" - the specification is actively improved (see https://github.com/NTAP/rfc8312bis https://github.com/NTAP/rfc8312bis), and the implementation of the algorithm inside s2n-quic even lead to the discovery of spec gaps that had been fixed as part of this effort. Like most other QUIC libraries the congestion controller is also pluggable. So if a different one makes more sense for a particular use-case, it could be integrated in the future.
deleted 5y ago
[deleted]

105 points by jeffbarr 5y ago

batisteo 5y ago

https://github.com/quinn-rs/quinn https://github.com/quinn-rs/quinn

hunterb123 5y ago
Also: https://github.com/cloudflare/quiche https://github.com/cloudflare/quiche CloudFlare's QUIC implementation written in Rust
- wongarsu 5y ago
  Also: https://github.com/mozilla/neqo https://github.com/mozilla/neqo - Neqo, an Implementation of QUIC written in Rust
FullyFunctional 5y ago
I wonder how they compare (but I'm not willing to spend hours comparing for myself). I do note in passing that S2n-QUIC has a really nice set of examples of how to use right up front in the README. All libraries should ideally have that. Without reading anything else, I already have a good idea of how hard it would be to use S2n-QUIC (looks easy).
- mlindner 5y ago
  BTW I will note that almost all Rust crypto (including that used by both packages) is all based on the ring crate, which is rather problematically managed and is itself a bunch of assembly and C code that's just taken straight from BoringSSL and OpenSSL.
  - agency 5y ago
    It looks like by default s2n-quic uses this TLS implementation, which is not based on the ring crate (though it is written in C) https://github.com/aws/s2n-tls https://github.com/aws/s2n-tls
    - tialaramex 5y ago
      However, that TLS implementation still thinks accepting TLS 1.0 is not only a reasonable default but also something you won't ever want to switch off except via an "I know what I'm doing" setting, and their "default" configuration has rusted into place several years ago.
      - colmmacc 5y ago
        I think we're getting closer to TLS1.0 disabled by default, but there are still clients out there and that's all they do. Especially embedded systems. It's a good practice to turn off old protocols but it has to be balanced with system availability. We go pretty deep on TLS and pay a lot of attention to what the problems in each protocol version are and having mitigations for them. A big source of comfort too is that it's been a long time since new clients can be made to fallback to old versions when they shouldn't.
        tialaramex 5y ago
        You're coming up on a year after RFC 8996 (saying to stop using TLS 1.0), which is itself almost three years after the die-die-die draft and RFC 8446 (TLS 1.3) I get why s2n has an SSLv3 implementation, even if it SSLv3 was already a bad idea by the time s2n existed, and I would likewise understand why it still has TLS 1.0, but I don't understand how it makes sense to advertise a "default" strategy that enables TLS 1.0 but not TLS 1.3 in 2022. If as I assumed in my earlier comment "default" is rusted in place as meaning "The thing that happened to work when this was popularised and now we dare not change it" then I guess that's a sad way for s2n's team to learn about Hyrum's Law but you should just stop advertising the "default" feature having learned that lesson, continuing to have docs that say "Use the defaults" when the defaults are rusted in place is bad. Or maybe I just don't understand and s2n is only intended for some niche legacy scenarios where TLS 1.3 won't make sense?
  - eptcyka 5y ago
    That's because currently it's impossible to ensure that rustc won't short-circuit a function if it sees an opportunity to do so, which means it's impossible to write constant-time functions which is a necessity for any kind of production ready crypto code.
  - capableweb 5y ago
    Keyword being almost all. I ran `cargo tree | grep -i ring` in all four currently listed QUIC implementations, and three of them have ring somewhere in the dependency tree, except for mozilla/neqo.

JoshTriplett 5y ago

Is there a "can I use" for networks/middleboxes/etc and the problems that arise with them, that talks about the real-world aspects of trying to use QUIC universally? I'd love to use QUIC between a (non-browser) client and server for which both ends are code I've written, without having to have fallbacks to HTTP/1.1 or HTTP/2. (Among other things, I love the idea of just establishing one connection and using it for two-way communication, without worrying about things like WebSocket.) However, the client also needs to run in random places, and while it doesn't necessarily need to support hostile networks, it does need to support broken networks, which to a first approximation can be similar. Are there statistics available for whether and how often QUIC (or more generally UDP) works with: - Random ISPs of varying quality - Cell data connections - Shops and airports and similar, which commonly use captive portals and try to intercept traffic when they shouldn't, and come pretty close to being hostile networks - Vaguely reasonable corporate networks, that aren't trying to block QUIC but might do so through misconfiguration or through some misguided policy put in place for unrelated reasons (e.g "our firewall rules are written about TCP and just drop all UDP and ICMP, and people complain but nobody with the power to change it") - Somewhat less reasonable corporate networks, that force everything through a proxy and may require things like CONNECT-UDP or SOCKS, but still aren't actively trying to block QUIC I'm hoping that efforts like fly.io's userspace wireguard stack (which uses UDP) might have data here. I'm specifically not asking about the case of networks that are actually trying to be hostile (to QUIC or otherwise), both because such networks may break any number of things including TLS or WebSockets, and because I'd like to avoid restarting the recurring discussion about whether QUIC/etc are a conspiracy to disempower network administrators. I'd love to know the statistics there too, though, if they're available. I'm also curious about the best-known method to reliably and efficiently tunnel QUIC out of a network within a client, for the purposes of separating always-QUIC logic from weird-network-handling logic. Does it make sense, for instance, to have a standard way to tunnel a secure QUIC connection through an insecure TCP connection?

benmmurphy 5y ago
i think tunnelling quic over TCP might run into the same problems you have when tunnelling TCP/IP over TCP. if you have two congestion algorithms running then you get weird performance issues. http://sites.inka.de/~W1011/devel/tcp-tcp.html http://sites.inka.de/~W1011/devel/tcp-tcp.html

rektide 5y ago

there's a bunch of bullet points going through some staple material, but the last bullet point has some absurdly good high grade features! > and much more, including CUBIC congestion controller support, packet pacing, Generic Segmentation Offload support, Path MTU discovery, and unique connection identifiers detached from the address also, a blog announcement appeared for this, https://aws.amazon.com/blogs/security/introducing-s2n-quic-open-source-protocol-rust/ https://aws.amazon.com/blogs/security/introducing-s2n-quic-o...

jeffbee 5y ago
I wonder why ye olde CUBIC without offering a choice of BBR or - dare I dream it - Swift.
- electricshampo1 5y ago
  Is Swift (https://dl.acm.org/doi/pdf/10.1145/3387514.3406591 https://dl.acm.org/doi/pdf/10.1145/3387514.3406591) expected/designed to be used in non-intra dc environments where primarily quic is expected to have an advantage relative to tcp? I agree that it still would be nice to have as an option.
  - jeffbee 5y ago
    Well I don’t really agree with the premise of your statement. I think that the benefit of the new protocol is going to mostly be felt inside the data center.
- Matthias247 5y ago
  CUBIC is a good baseline congestion controller. It's the default one that is being used in Linux, so it should provide adequate performance for a wide range of use-cases. Plus it's not so "olde" - the specification is actively improved (see https://github.com/NTAP/rfc8312bis https://github.com/NTAP/rfc8312bis), and the implementation of the algorithm inside s2n-quic even lead to the discovery of spec gaps that had been fixed as part of this effort. Like most other QUIC libraries the congestion controller is also pluggable. So if a different one makes more sense for a particular use-case, it could be integrated in the future.

deleted 5y ago

[deleted]