6 ms·

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/netfi

by ibotty 9y ago

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

_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 ago
  Simply classifying on UDP port 443 would cover most usecases I'd guess?
  - _wmd 9y ago
    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
    - londons_explore 9y ago
      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...
      - _wmd 9y ago
        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
- ibotty 9y ago
  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.
  - 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 ago
      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.
baby 9y ago
can't you do it easily with eBPF?
- ibotty 9y ago
  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.
  - baby 9y ago
    I'm talking out of my knowledge bucket here, but isn't an eBPF script basically the same as having a netfilter module?
    - ibotty 9y ago
      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.
mpweiher 9y ago
> 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 https://en.wikipedia.org/wiki/Internet_Protocol_Suite
- krylon 9y ago
  I think the GP wanted to know how a firewall can tell quic traffic from other UDP traffic.
- bchallenor 9y ago
  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 https://en.wikipedia.org/wiki/List_of_IP_protocol_numbers
  - ibotty 9y ago
    Exactly! Thank you for putting in the time to elaborate what I meant.
  - mpweiher 9y ago
    Ahh, thanks!

by ibotty 9y ago

_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 ago
Simply classifying on UDP port 443 would cover most usecases I'd guess?
- _wmd 9y ago
  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
  - londons_explore 9y ago
    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...
    - _wmd 9y ago
      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
ibotty 9y ago
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.
- 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 ago
    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.

baby 9y ago

can't you do it easily with eBPF?

ibotty 9y ago
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.
- baby 9y ago
  I'm talking out of my knowledge bucket here, but isn't an eBPF script basically the same as having a netfilter module?
  - ibotty 9y ago
    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.

mpweiher 9y ago

> 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 https://en.wikipedia.org/wiki/Internet_Protocol_Suite

krylon 9y ago
I think the GP wanted to know how a firewall can tell quic traffic from other UDP traffic.
bchallenor 9y ago
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 https://en.wikipedia.org/wiki/List_of_IP_protocol_numbers
- ibotty 9y ago
  Exactly! Thank you for putting in the time to elaborate what I meant.
- mpweiher 9y ago
  Ahh, thanks!