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

[Tom Herbert <[e-mail]>]

On Sun, Nov 3, 2019 at 7:18 PM Martin Thomson <[e-mail]> wrote:
>
> 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.
>
Martin,

I looked at that draft. While it does mention RFC7605, the explanation
for how non-QUIC packets that match port 443 aren't misinterpreted
isn't particularly satisfying. Other than assuming port number match
is sufficient, the recommended approach seems to be for middleboxes to
track flows by handshake. But, that then requires state to be
maintained and implies that packets for the flow must be consistently
be routed through the same device (a common problem for any stateful
device in the network). I don't think the QUIC spin bit serves as an
exemplar for reliably exposing transport layer information in a
transport protocol that is otherwise encrypted.

Tom

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