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

[Robert Wilton via Datatracker <[e-mail]>]

Robert Wilton has entered the following ballot position for
draft-ietf-quic-bit-grease-04: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-quic-bit-grease/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Hi,

Sorry for the late DISCUSS, and hopefully not tricky to resolve, but there are
two points that I think it would be helpful to clarify:

(1) Ensuring the language is consistent with draft-ietf-quic-manageability.
(2) Possibly whether a short Operational Considerations section could/should be
added.

Details in the comments.

Regards,
Rob


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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