Manageability of the QUIC Transport Protocol
draft-ietf-quic-manageability-18

Thank you for the work on this document.

Many thanks to Peter Saint-Andre for his review: https://mailarchive.ietf.org/arch/msg/art/jB34IuU065v-PcPjUwL4QX6Dz00/ , and thanks to the authors for addressing it.

Francesca

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/

Thank you for the work put into this document. 

Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education).

Special thanks to Matt Joras for the shepherd's write-up including the WG consensus and the intended status. 

I hope that this helps to improve the document,

Regards,

-éric

Note for the shepherding AD: missing consensus boilerplate.

Should there be a section on the usefulness of IPFIX with QUIC ?

## Section 2.1

"All deployed versions are maintained in an IANA registry" is it "deployed" or "specified" ? I.e., an operator could always deploy an experimental version not yet in the IANA registry.

The text appears inconsistent to me:

- "Short headers contain only an optional destination connection ID"

- "source and destination connection ID: short and long headers carry a destination connection ID", i.e., is it optional or not ?

Also some inconsistency about the spin bit, is it only in v1 or is it an invariant ?

Security ADs will know more of course but for me "cryptographically protected" is unclear whether it is confidentiality or integrity or both... Suggest to use "is confidentiality/integrity protected with cryptography" (or a lighter sentence than this one).

## Section 3

"Here we assume a bidirectional observer", let's also state that there is no section about unidirectional observer ?

## Section 3.1

Could the first 1200-byte QUIC packet be used to suspect a QUIC connection establishment ?

## Section 3.7

Can the data rate in each direction always be used to detect which side is the client/initiator vs. server/responder ? Even for HTTP/3 a POST can be larger than the reply. Or did I misread this paragraph ?

## Section 4.1

Suggest to expand "CE markings"

## Section 4.2

Thank you for this section, this may be the most useful one :-) (together with section 4.9)

BTW, should there be 2 different time-outs? One for the "connection establishment" and one, longer, for "normal traffic".

## Section 4.6

"DDoS" is used while 4.7 use "DDOS" and expand the acronym ;-) (reading the I-D as first task in the morning with 2 cups of coffee has some side effects on my eyes ;-) )

Section 2.1, paragraph 1, comment:
>       All deployed versions are maintained in an IANA
>       registry (see Section 22.2 of [QUIC-TRANSPORT]).

I don't think it's correct to claim that "all deployed versions are maintained
in an IANA registry" - many versions are being and have been deployed that are
not in that IANA registry at all (see
https://github.com/quicwg/base-drafts/wiki/QUIC-Versions); there is a huge range
for experimental versions.

Section 3.1, paragraph 1, comment:
>    At the time of writing, two application bindings for QUIC have been
>    published or adopted by the IETF: HTTP/3 [QUIC-HTTP] and DNS over
>    Dedicated QUIC Connections [I-D.ietf-dprive-dnsoquic].  These are
>    both known at the time of writing to have active Internet
>    deployments, so an assumption that all QUIC traffic is HTTP/3 is not
>    valid.  HTTP/3 uses UDP port 443 by convention but various methods
>    can be used to specify alternate port numbers.  Simple assumptions
>    about whether a given flow is using QUIC based upon a UDP port number
>    may therefore not hold; see also Section 5 of [RFC7605].

AFAIK Microsoft's SMB-over-QUIC also uses 443.

The datatracker state does not indicate whether the consensus boilerplate
should be included in this document.

Found terminology that should be reviewed for inclusivity; see
https://www.rfc-editor.org/part2/#inclusive_language for background and more
guidance:

 * Term "traditional"; alternatives might be "classic", "classical", "common",
   "conventional", "customary", "fixed", "habitual", "historic",
   "long-established", "popular", "prescribed", "regular", "rooted",
   "time-honored", "universal", "widely used", "widespread"
 * Term "invalid"; alternatives might be "not valid", "unenforceable", "not
   binding", "inoperative", "illegitimate", "incorrect", "improper",
   "unacceptable", "inapplicable", "revoked", "rescinded"

Thanks to Elwyn Davies for their General Area Review Team (Gen-ART) review
(https://mailarchive.ietf.org/arch/msg/gen-art/5c_ZgBH4YmAn13j0IszsrYKTVmI).

-------------------------------------------------------------------------------

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

Section 2.1, paragraph 1, nit:
-       used to identify the connection associated with a QUIC packet, for
+       used by the endpoints to identify the connection associated with a QUIC packet, for
+           +++++++++++++++++

Section 2.1, paragraph 1, nit:
-       is implicit.
+       is only known to the endpoints.

Section 2.1, paragraph 1, nit:
-       endpoints might use an extension that varies the bit.  Therefore,
+       endpoints might use an extension that varies the bit [QUIC-GREASE].  Therefore,
+                                                           ++++++++++++++

Section 2.1, paragraph 1, nit:
-       headers, while it is implicit (depending on destination connection
-                             ^^^^^^
+       headers, while it is known only to the endpoints (depending on destination connection
+                            +++++++++++++++++++++++ ^ +

Section 2.8, paragraph 1, nit:
-    ossification in the implementation on the selection mechanism.
-                                        ^
+    ossification in the implementation of the selection mechanism.
+                                        ^

Section 2.8, paragraph 1, nit:
-    traffic recognition will therefore behave differently than with these
-                                         ^^^  ^ ^^^^^^^^^
+    traffic recognition will therefore be more problematic than with these
+                                         ^^^^  ^^^^^^^^^ ^

Section 4.2, paragraph 1, nit:
-    forwarding decison is not viable as it will break connectivity, or at
+    forwarding decision is not viable as it will break connectivity, or at
+                    +

Section 4.8, paragraph 1, nit:
-    Note that the 5-tuple of a QUIC connnection can change due to
-                                        -

Section 4.8, paragraph 1, nit:
-    maybe be treated differently, as congestion control is usualy reset
+    maybe be treated differently, as congestion control is usually reset
+                                                                +

Section 4.10, paragraph 1, nit:
-    DF bit set, because fragmention occurs below the IP layer.  However,
+    DF bit set, because fragmentation occurs below the IP layer.  However,
+                               ++

Section 6, paragraph 1, nit:
-    However, some information is still observerable, as supporting
-                                             --

Section 8, paragraph 1, nit:
-    Special thanks to last call reviewers Elwyn Davies, Barry Lieba, Al
-                                                                -
+    Special thanks to last call reviewers Elwyn Davies, Barry Leiba, Al
+                                                               +

Section 2.4, paragraph 1, nit:
>    delays that trigger a spurious Probe Timeout ({Section 6.2 of
>    RFC9002}).  If QUIC packets get lost or reordered, packets belonging

This looks like broken Markdown.

Document references draft-ietf-quic-applicability-15, but -16 is the latest
available revision.

Document references draft-ietf-tsvwg-transport-encrypt, but that has been
published as RFC9065.

Paragraph 7659, nit:
> TP/3 uses UDP port 443 by convention but various methods can be used to speci
>                                     ^^^^
Use a comma before "but" if it connects two independent clauses (unless they
are closely connected and short).

Hi,

Thanks for this document that is well written and gives a lot of detail about various aspects of the QUIC.  I would also like to thank Al Morton for his review and for the authors diligently working with Al to reach a consensus position.

I have to confess that I find some aspects of this document to be a bit of a odd duck, which I think that is based on the underlying design goals of QUIC to maximize privacy and prevent interference.  I.e., a lot of the sections seem to end up implying that "you can't really do that in easy/reliable way with QUIC, or you shouldn't do it".  From my reading of this doc, I get the overriding feeling that QUIC is not really designed to be easily distinguishable from regular UDP traffic, and at the same time, there seem to be some recommendations or suggestions about how QUIC traffic should be handled potentially differently from other UDP traffic under some circumstances.  It will be interesting to see how QUIC deployment evolves over time, and whether some operators will restrict its usage to a few well known ports.  Hopefully not.

A few specific minor comments:

1.
Section 1 states:

   No information in the
   protocol header, even that which can be inspected, is mutable by the
   network.  This is enforced through integrity protection of the wire
   image [WIRE-IMAGE]. 
   
Section 2.1 states:

   Retry (Section 17.2.5 of [QUIC-TRANSPORT]) and Version Negotiation
   (Section 17.2.1 of [QUIC-TRANSPORT]) packets are not encrypted or
   protected in any way. 
   
Do these two statements conflict: re protection?

2.
      On long header
      packets, the length of the connection IDs is also present; on
      short header packets, the length of the destination connection ID
      is implicit.

I presume that it is implicit in the sense that each endpoint knows how long the connection IDs are? 

3.
   2.6.  Connection ID and Rebinding

   Further it can be
   used by in-network devices to ensure that related 5-tuple flows are
   appropriately balanced together.

When I read this, I thought that you were talking about ECMP and L2 load-balancing over LAG, but I presume that is not the intention here, and that you are referring to application layer load balancing?

Regards,
Rob