Roman Danyliw's No Objection on draft-ietf-quic-manageability-16: (with COMMENT)

[Roman Danyliw via Datatracker <[e-mail]>]

Roman Danyliw has entered the following ballot position for
draft-ietf-quic-manageability-16: No Objection

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-manageability/



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

Thank you to Barry Leiba for the SECDIR review.

Thank you for this companion document considering the operational view of the
wire image.  It is a model to pattern for other protocols.

** Section 2.8
   Using a particular version number to recognize valid QUIC
   traffic is likely to persistently miss a fraction of QUIC flows, and
   completely fail in the near future.  Reliance on the version number
   field for the purposes of admission control is similarly likely to
   rapidly lead to unintended failure modes.  Admission of QUIC traffic
   regardless of version avoids these failure modes, avoids unnecessary
   deployment delays, and supports continuous version-based evolution.

-- True, but this guidance seems a bit too strong.  Operators may choose to
explicitly exclude traffic from particular “experimental versions" and should
likely be curating their ACLs/admission control practices.

-- Consider if the text "... likely to rapidly lead to unintended failure
modes” will age well.

-- Would there be an opportunity to fingerprint a unique application using a
specific experimental version number (in an ecosystem of continuous evolution
and experimentation suggested above)?

** Section 4.7.
   Other uses include support for security audits
   (e.g., verifying the compliance with ciphersuites); client and
   application fingerprinting for inventory; and to provide alerts for
   network intrusion detection and other next generation firewall
   functions.

This text seems unrelated to the focus of this section -- DDoS  detection and
mitigation.  Is it really needed?

** Section 4.7
      Current practices in detection and mitigation of DDoS attacks
   generally involve classification of incoming traffic (as packets,
   flows, or some other aggregate) into "good" (productive) and "bad"
   (DDoS) traffic,

This describes a “scrubbing” approach.  DDoS mitigation can use the less
nuanced rate limiting approach.  DOTS has support for that too.

** Section 4.7
   It is also possible for endpoints to directly support security
   functions such as DoS classification and mitigation.  Endpoints can
   cooperate with an in-network device directly by e.g., sharing
   information about connection IDs.

Does that happen now?  How would that signaling work?

Typos:
** Section 4.8. Typo. s/connnection/connection/

** Section 4.8.  Typo. s/usualy/usually/