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

[Mirja Kuehlewind <[e-mail]>]

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" <[e-mail]> 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!