Hi Roman, thanks for your review I have a couple comments and follow-up questions below!
Mirja On 19.04.22, 05:19, "Roman Danyliw via Datatracker" <[email protected]> wrote: 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. [MK] This was discussed quite heavily and last revised during IETF LC based on the opsdir review, see here: https://github.com/quicwg/ops-drafts/pull/467/files [MK] The comment from the opsdir review was basically say that this document should not try "tell operators what to do". (Sorry if I paraphrasing this to strongly). So we tried to rather explain than givng concrete guidance. However, the whole point is that using version is a problem and we have a strong that is should not be done. Yes, we understand that operator have a desire to distinguish "valid" QUIC traffic (whatever) that means, but QUIC has been designed to reveal as little information as possible and trying to (mis-)use any of the existing exposed information for that purpose has problems. Given this was just revised and discussed extensively, I rather not change the text again. Please let me know if you feel strong that some more adaption is required here. -- Consider if the text "... likely to rapidly lead to unintended failure modes” will age well. [MK] I don't think this is specific tot eh current version but rather the general design principle that version are expected to change quickly. -- 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)? [MK] I guess that is the whole point here and I think the answer is no. You might see new experimental version that come and go quickly and are deployed only by one vendor but I don't think that will give you necessarily much insights about the application within the encrypted payload. Also experimental version are expected to be around for short times only and change quickly, thus you would be very busy to adapt your fingerprinting continuously. That's why the recommendation is to not do it. ** 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? [MK] Why do you think it's a problem to have it. Do we maybe need to change the section title rather? ** 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. [MK] Doesn't the rate limiting also require the classification first, or are you saying all traffic is rate limited (if certain thresholds are exceeded)? ** 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? [MK] No, that needs work :-) Typos: ** Section 4.8. Typo. s/connnection/connection/ ** Section 4.8. Typo. s/usualy/usually/ [MK] Thanks!
