Hacker News Reader

Comment by ibotty | Hacker News Reader

I failed to find anything a few times in the last years, so maybe it does not yet exist, but maybe someone here has any pointers.

How can linux' iptables/netfilter match quic packages. Because quic is no ip protocol (but on top of udp) `-p quic` will not be implemented. Will one has to write a quic helper, so that one could match using `-m helper --helper quic`? I tend to think so, but I failed to find such a helper.

Is there some difficulty I fail to see? Or is nobody interested (because nobody uses linux as a router)?

View on HN

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.

I 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.

> 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):

"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.

I 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.

Simply classifying on UDP port 443 would cover most usecases I'd guess?

Where did you get 443 from? AFAIK even Google aren't using that. I didn't think there was any standardized port number at all

Google 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...

Yoiks, 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

> Because quic is no ip protocol (but on top of udp)

Did you mean to write something else?

UDP very much is an IP protocol, just like TCP is an IP protocol.

https://en.wikipedia.org/wiki/Internet_Protocol_Suite

TCP and UDP are "IP protocols" in that their packets are nested directly inside an IP packet and they have associated protocol numbers [1] to distinguish them from other things that might be inside an IP packet. QUIC theoretically deserves to be one of these too but for pragmatic reasons it has to be nested inside UDP. GP is asserting that `-p quic` will not be implemented, because it would be a layering violation.

[1] https://en.wikipedia.org/wiki/List_of_IP_protocol_numbers

Exactly! Thank you for putting in the time to elaborate what I meant.

Ahh, thanks!

I think the GP wanted to know how a firewall can tell quic traffic from other UDP traffic.

can't you do it easily with eBPF?

There might be a way to use eBFP, but it won't be as easy as having a netfilter module. I assert that would be useful.

I'm talking out of my knowledge bucket here, but isn't an eBPF script basically the same as having a netfilter module?

Not entirely, but it's possible to convince flowing traffic through eBPF. The main difference will be the ease of use! Thank you for the suggestion though.

Reply on news.ycombinator.com