Re: Robert Wilton's Discuss on draft-ietf-quic-bit-grease-04: (with DISCUSS and COMMENT)

[Martin Thomson <[e-mail]>]

Hi Rob,

On Thu, Jun 30, 2022, at 19:15, Robert Wilton via Datatracker wrote:
> (1) The purpose of having a fixed value is to allow QUIC to be
>    efficiently distinguished from other protocols;
>
> This sentence seems inconsistent with draft-ietf-quic-manageability that states
> that this bit cannot be used reliably to indicate QUIC traffic.

That appears to be a misreading of the text.  The failing here is that this text doesn't say *by whom*.  It only refers to RFC 7983[bis].  I thought that was sufficient.

Would this be clearer?

> The purpose of having a fixed value is to allow endpoints to efficiently distinguish QUIC from other protocols; [...]

Note that this is only *mostly* correct.  Endpoints can cooperate with intermediaries to disable this extension if identification or demultiplexing is useful.  I believe that this is what Google's current deployment does, for example.  That's independent of the RFC 7983-related use, where the same is also possible.

> Ultimately, for QUIC, it isn't really clear to me whether:
> (i) Intermediates nodes are not expected to be able to efficiently identify
> QUIC traffic. (ii) Intermediate nodes are expected to efficiently identify QUIC
> v1 traffic only.
>
> Assuming that the quic bit grease extension ends up with reasonable deployment
> then I think that we end up with (i).  Is that correct and the intention?

Yes.

> (2)
> This document already has a comment in the security section about the potential
> security impact of using this extension.  I think that this document could
> benefit from an Operational Considerations section to highlight that using this
> extension is likely to impact the ability of intermediate devices to identify
> QUIC packets which may change how the network handles QUIC packets, either by
> giving them special treatment compared to other UDP traffic, or categorizing
> them and handling them the same as all other UDP traffic.  Or perhaps the
> security section paragraph could be expanded to cover this point (although it
> isn't really security, but observed functionality).

I'm happy to add a pointer to the manageability draft to that text.  That covers all of that material much better than any new section I could write might.

See https://github.com/quicwg/quic-bit-grease/pull/28 for the two tweaks mentioned.