Re: [quicwg/base-drafts] QUIC header format/demultiplexing (#426)

[janaiyengar <[e-mail]>]

This *may* be one of those things where keeping WebRTC in the back of our minds might help QUIC not get stuck badly in the future.

So, as a thought exercise (not assuming that we need to solve this problem here) I'd like to walk through what we *could* do if we actually supported both WebRTC protocols and QUIC on the same port.

I think the simplest thing to do would be to pass everything through a QUIC "dispatcher" that determines if this packet belongs to QUIC --- basically confirms whether this packet should be consumed by QUIC or not --- and if it isn't consumed by QUIC (including packets that QUIC decides MUST be dropped because they are QUIC packets but violate some property) then it can be consumed by non-QUIC applications on the same port.

The question of course is how bad is the likelihood of false positives/negatives. With the encrypted packet types in QUIC, the QUIC dispatcher will safely reject non-QUIC packets. 

With the plaintext types, which are used during handshake, QUIC packets are covered by a non-crypto FNV-1a hash. The cost that QUIC bears of a mis-classification among plaintext packets as a QUIC packet is limited to cases where the contents of the packet are not part of the final key derivation. These packet types are limited to a few long-form packet types, all of which have a number of version-independent fields upfront, including version, which could be checked for sanity (since connection ID and packet number can be arbitrary.) This still doesn't seem great, since 0x0001 is a fine version number to have in QUIC and may be a completely reasonable string in RTP.  So alternatively, we could renumber the long-form packet types to start at 255 and count down, since 192 - 255 is left open by RFC 7983, and since we just need  6 cleartext packet types at the moment to be distinct from the RTP packet types (it's smaller than that, since Stateless Reject and Version Negotiation packets need to echo stuff from the client's packets.)

TL;DR of this is that *if* we wanted to allow for a future coexistence of WebRTC protocols with QUIC on the same port -- and this is a big "if", since I wonder if they need to be on the same port --- we could renumber just the long-form packets to start at 255 and grow downwards. We only need <= 6 plaintext packet types to be out of the collision region with  RFC 7983.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/426#issuecomment-306500276