4 ms·
It should in principle be possible to classify brand new Quic connections, since a tiny handful of its fields are cleartext during the initial handshake (flags
by _wmd 9y ago
It should in principle be possible to classify brand new Quic connections, since a tiny handful of its fields are cleartext during the initial handshake (flags and version, in both client/server directions)
As for classifying existing Quic connections, it might get a little messier. There are still some cleartext fields but it might require observing multiple packets in the flow before making a guess the traffic is likely to be Quic.
Meanwhile an explicit design goal of Quic is to avoid interference from middleboxes, so it would be no surprise if a perfect iptables Quic match is or remains impossible.
- londons_explore 9y agoSimply classifying on UDP port 443 would cover most usecases I'd guess?
- _wmd 9y agoWhere did you get 443 from? AFAIK even Google aren't using that. I didn't think there was any standardized port number at all
- londons_explore 9y agoGoogle uses UDP 443 for all it's quic services. Chrome will autoconnect to UDP 443 for any https request in parallel with TCP, and prefer QUIC if it works. Sure you could use another port, but it looks like UDP 443 is becoming the unofficial standard, even if not IETF endorsed...
- _wmd 9y agoYoiks, good to know! When scanning the Quic docs, especially around the HTTP header that advertises an alternative protocol, the examples showed some random >1024 high port. I assumed that was part of the middlebox aversion stuff But it makes perfect sense to have a defined port, so that connection racing can work without first having to receive a HTTP header
- ibotty 9y agoI don't want to mess with the content in any way, I do want to send connections over more than one WAN, depending on utilization. That works great with https?-connections on tcp. It would be great to be able to do the same with quic connections.
- cesarb 9y ago> I do want to send connections over more than one WAN QUIC has something which can help with that (from https://tools.ietf.org/html/draft-ietf-quic-transport-09 https://tools.ietf.org/html/draft-ietf-quic-transport-09): "QUIC connections are identified by a Connection ID, a 64-bit unsigned number randomly generated by the server. QUIC's consistent connection ID allows connections to survive changes to the client's IP and port, such as those caused by NAT rebindings or by the client changing network connectivity to a new address." If that's not enough for your use cases, now is a good opportunity to mention them and suggest enhancements, since the IETF standard is still under development.
- ibotty 9y agoI don't think this will work for randomly sending over one or the other connection, but I will just have to test to be sure.