[HN Gopher] S2n-QUIC (Rust implementation of QUIC)
___________________________________________________________________
S2n-QUIC (Rust implementation of QUIC)
Author : jeffbarr
Score : 48 points
Date : 2022-02-17 20:43 UTC (2 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| rektide wrote:
| 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-o...
| jeffbee wrote:
| I wonder why ye olde CUBIC without offering a choice of BBR or
| - dare I dream it - Swift.
| zokier wrote:
| Does this mean that they are considering adding QUIC termination
| to ELB and/or ApiGW?
| JoshTriplett wrote:
| 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 wrote:
| 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
| batisteo wrote:
| https://github.com/quinn-rs/quinn
| hunterb123 wrote:
| Also: https://github.com/cloudflare/quiche CloudFlare's QUIC
| implementation written in Rust
| wongarsu wrote:
| Also: https://github.com/mozilla/neqo - Neqo, an
| Implementation of QUIC written in Rust
| FullyFunctional wrote:
| 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 wrote:
| 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 wrote:
| 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
| tialaramex wrote:
| 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.
___________________________________________________________________
(page generated 2022-02-17 23:00 UTC)