Re: [tsvwg] [saag] Comments on draft-ietf-tsvwg-transport-encrypt-08.txt

["Martin Thomson" <[e-mail]>]

On Mon, Nov 4, 2019, at 13:15, Tom Herbert wrote:
> QUIC presents a problem in itself since the QUIC harders are inside
> the UDP payload so intermediate devices end up needing to parse the
> UDP transport payload. I believe the only way to identify a QUIC
> packet is by matching port numbers, but per RFC7605 interpretation of
> port numbers in the middle of the network is prone to
> misinterpretation. Eventually, something that looks like a QUIC packet
> based on port number will be misinterpreted. Looking at
> draft-ietf-quic-transport-23, I don't see any discussion about this or
> reference to RFC7605. 

Please refer to draft-ietf-quic-manageability for that discussion.

Note that while there has been extensive discussion on what QUIC should expose in terms of loss and latency, I recall relatively little discussion about distinguishing QUIC from other protocols outside of the narrow context of ensuring that QUIC can be effectively multiplexed with certain other protocols.

My sense is that some people are assuming that they can use port numbers, which are fraught for the reasons you identify.  Others might choose to infer the use of QUIC using the "QUIC bit": the 0x40 bit in QUIC version 1 is fixed.  

Personally, I think that endpoints are not obligated to signal which protocol they are using to the network.  Maybe the QUIC bit is that signal and I'm just in denial.  I guess we'll see whether I can send packets with a 0 value for that bit...

> This can be contrasted to putting the information in HBH options which
> can be correctly and unambiguously identified anywhere in the network.

I happen to agree, though I don't think that this is as simple as you might be implying.  https://tools.ietf.org/html/rfc8558 makes a similar assertion, but identifies some of the underlying complexities.