Greasing the QUIC Bit
draft-ietf-quic-bit-grease-04

Thank you for the work on this document.

Many thanks to Julian Reschke for his ART ART review: https://mailarchive.ietf.org/arch/msg/art/Uh8jVF7_xYDuk--gWV5BAyYBp9c/.

Francesca

Thank you to Russ Housley for the SECDIR review.

Apologies for not being able to do a more in-depth review, I'm currently traveling (an emergency trip to South Africa), and so am relying on Scott Bradner's OpsDir review (https://datatracker.ietf.org/doc/review-ietf-quic-bit-grease-04-opsdir-telechat-bradner-2022-06-14/). 

I'd like to thank Scott and the authors for addressing Scott's comments in the -03 version and to Scott for updating it for -04.
Like Scott I really think that this should use the Updates tag - yes, Updates is very poorly defined, and perhaps we should have a "See Also" / "Worth Reading" / "Closely Related" / "If you enjoyed this RFC, you may also enjoy these other ones" / "NOTICE TO IMPLEMENTERS: See RFCxxxx" tags -- but without them, we use Updates for this. I'll be on a plane during the telechat, but I urge the rest of the IESG to discuss / consider this...

Completely trusting the internet directorate review by Wassim Haddad:

https://datatracker.ietf.org/doc/review-ietf-quic-bit-grease-04-intdir-telechat-haddad-2022-06-26/

-éric

Clearing my discuss, thank you for the resolution on the concerns raised and apologies on the slight delay

Clearing discuss based on proposed updates from Martin Thompson.



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

draft-ietf-quic-manageability states: 
   The QUIC wire image is not specifically designed to be
   distinguishable from other UDP traffic by a passive observer in the
   network.  While certain QUIC applications may be heuristically
   identifiable on a per-application basis, there is no general method
   for distinguishing QUIC traffic from otherwise-unclassifiable UDP
   traffic on a given link.  Any unrecognized UDP traffic may therefore
   be QUIC traffic.

   *  "fixed bit": The second-most-significant bit of the first octet of
      most QUIC packets of the current version is set to 1, enabling
      endpoints to demultiplex with other UDP-encapsulated protocols.
      Even though this bit is fixed in the version 1 specification,
      endpoints might use an extension that varies the bit.  Therefore,
      observers cannot reliably use it as an identifier for QUIC.

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?

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