Draft: draft-ietf-quic-manageability

Commentary: General : s / e.g. /e.g . , / ( 6 places ) s1 : A note about the origin of terminology ( e.g. , Connection ID ) is needed . Primarily RFC 9000 , I take it . s1 , para 3 : s / This is achieved through integrity protection of the wire image / This is enforced through integrity protection of the wire image/ Figures 1 and 6 : The terms 0 - RTT and 1 - RTT are shown as 0RTT and 1RTT in the figures . Please make consistent . s1 , para 4 : s / an QUIC / a QUIC/ s2.1 , para 6 : s / QUIC version 1 uses version / QUIC version 1 uses version number/ ; s / All deployed versions / Details of all deployed versions/ s2.3 , para 1 : In the last sentence s / the use of    the of the HTTP Alternative Services mechanism [ RFC7838]/ s2.3 , para 2 ( and 4 other places ): The abbreviation or term 5 - tuple is not in the RFC Edito'r 's list of abbreviations and is not used in RFC 9000 . I think this term needs to be expanded ( probably in the list of terms - see comment on s1 ) . s2.4 and elsewhere : The term ' flights [ of datagrams ] ' is not defined . I notice that the term was not defined in RFC 9000 where it is introduced originally . s2.4 , para : s / detailed Figure 2 / detailed in Figure 2/ s2.4 , para 8 : s / Figure4/(Figure 4)/ , s / Figure 5/(Figure 5)/ s2.4 , para 11 : s / than in the Client / that is sent in the Client/ s2.4 , para 13 : " When the client uses 0 - RTT connection resumption , the Client Initial flight can also include one or more 0 - RTT packets , as shown in Figure " Where is this connection resumption defined ? It is n't in RFC 9000 AFAICS . Maybe Please supply a suitable explanation / reference . s2.6 , para 1 and s3.5 , para 4 : Be consistent between 5 - tuple and five - tuple please . s3.1 , para 2 : I think the ' DNS ' protocol deserves its full title DNS over Dedicated QUIC Connections . s3.1 , para 2 : The second sentence regarding implementations at the time of writing is not future proof . This needs to be rewritten to express that there is an expectation of multiple applications without tying it to somewhat hypothetical implementations that might or might not exist by the time this document is published as an RFC.s3.5 , paa 4 : s3.2 , para 2 : " Connection establishment can therefore be detected using heuristics similar to those used to detect TLS over TCP . " Where would a reader find out what are hese heuritics ? s3.4 , last para : s / E.g./For example/ s3.8.2 , para 8 : s / i.e.  . , / s4.2 , para 4 : s / well- defined / well - defined/ s4.2 , para 6 : s / unnecessary / unnecessarily/ s4.2 , para 10 : s / Specially / In particular/
Paragraph (version A):
QUIC is an end-to-end transport protocol.  No information in the
protocol header, even that which can be inspected, is mutable by the
network.  This is achieved through integrity protection of the wire
image WIRE-IMAGE.  Encryption of most transport-layer control
signaling means that less information is visible to the network than
is the case with TCP.
Paragraph (version B):
QUIC is an end-to-end transport protocol.  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.  Encryption of most transport-layer control
signaling means that less information is visible to the network than
is the case with TCP.
Paragraph (version A):
Integrity protection can also simplify troubleshooting at the end
points as none of the nodes on the network path can modify transport
layer information.  However, it means in-network operations that
depend on modification of data (e.g. see RFC9065 are not possible
without the cooperation of an QUIC endpoint.  Such cooperation might
be possible with the introduction of a proxy which authenticates as
an endpoint.  Proxy operations are not in scope for this document.
Paragraph (version B):
Integrity protection can also simplify troubleshooting at the end
points as none of the nodes on the network path can modify transport
layer information.  However, it means in-network operations that
depend on modification of data (for examples, see RFC9065) are not
possible without the cooperation of a QUIC endpoint.  Such
cooperation might be possible with the introduction of a proxy which
authenticates as an endpoint.  Proxy operations are not in scope for
this document.
Paragraph (version B):
QUIC-specific terminology used in this document is defined in QUIC-
TRANSPORT.
Paragraph (version A):
Applications that have a mapping for TCP as well as QUIC are expected
to use the same port number for both services.  However, as for all
other IETF transports RFC7605, there is no guarantee that a specific
application will use a given registered port, or that a given port
carries traffic belonging to the respective registered service,
especially when application layer information is encrypted.  For
example, QUIC-HTTP specifies the use of Alt-Svc for discovery of
HTTP/3 services on other ports.
Paragraph (version A):
Further, as QUIC has a connection ID, it is also possible to maintain
multiple QUIC connections over one 5-tuple.  However, if the
connection ID is zero-length, all packets of the 5-tuple likely
belong to the same QUIC connection.
Paragraph (version B):
Applications that have a mapping for TCP as well as QUIC are expected
to use the same port number for both services.  However, as for all
other IETF transports RFC7605, there is no guarantee that a specific
application will use a given registered port, or that a given port
carries traffic belonging to the respective registered service,
especially when application layer information is encrypted.  For
example, QUIC-HTTP specifies the use of the HTTP Alternative Services
mechanism RFC7838 for discovery of HTTP/3 services on other ports.
Paragraph (version B):
Further, as QUIC has a connection ID, it is also possible to maintain
multiple QUIC connections over one 5-tuple (protocol, source and
destination IP address, and source and destination port).  However,
if the connection ID is zero-length, all packets of the 5-tuple
likely belong to the same QUIC connection.
Paragraph (version A):
The QUIC handshake can normally be recognized on the wire through
four flights of datagrams labelled "Client Initial", "Server
Initial", "Client Completion", and "Server Completion", in the
illustration shown in fig-handshake.
Paragraph (version A):
A handshake starts with the client sending one or more datagrams
containing Initial packets, detailed fig-client-initial, which
elicits the Server Initial response detailed in fig-server-initial
typically containing three types of packets: Initial packet(s) with
the beginning of the server's side of the TLS handshake, Handshake
packet(s) with the rest of the server's portion of the TLS handshake,
and 1-RTT packet(s), if present.
Paragraph (version B):
The QUIC handshake can normally be recognized on the wire through
four flights of datagrams labelled "Client Initial", "Server
Initial", "Client Completion", and "Server Completion", as
illustrated in fig-handshake.
Paragraph (version B):
A handshake starts with the client sending one or more datagrams
containing Initial packets, detailed in fig-client-initial, which
elicits the Server Initial response detailed in fig-server-initial
typically containing three types of packets: Initial packet(s) with
the beginning of the server's side of the TLS handshake, Handshake
packet(s) with the rest of the server's portion of the TLS handshake,
and 1-RTT packet(s), if present.
Paragraph (version A):
Initial, Handshake, and 1-RTT packets belong to different
cryptographic and transport contexts.  The Client Completion fig-
init-complete and the Server Completion fig-hs-complete flights
conclude the Initial and Handshake contexts, by sending final
acknowledgments and CRYPTO frames.
Paragraph (version B):
Initial, Handshake, and 1-RTT packets belong to different
cryptographic and transport contexts.  The Client Completion (fig-
init-complete) and the Server Completion (fig-hs-complete) flights
conclude the Initial and Handshake contexts, by sending final
acknowledgments and CRYPTO frames.
Paragraph (version A):
The Client Completion flight does not expose any additional
information; however, as the destination connection ID is server-
selected, it usually is not the same ID than in the Client Initial.
Client Completion flights contain 1-RTT packets which indicate the
handshake has completed (see sec-confirm) on the client, and for
three-way handshake RTT estimation as in sec-rtt.
Paragraph (version A):
When the client uses 0-RTT connection resumption, the Client Initial
flight can also include one or more 0-RTT packets, as shown in fig-
client-initial-0rtt.
Paragraph (version B):
The Client Completion flight does not expose any additional
information; however, as the destination connection ID is server-
selected, it usually is not the same ID that is sent in the Client
Initial.  Client Completion flights contain 1-RTT packets which
indicate the handshake has completed (see sec-confirm) on the client,
and for three-way handshake RTT estimation as in sec-rtt.
Paragraph (version B):
When the client uses 0-RTT data, the Client Initial flight can also
include one or more 0-RTT packets, as shown in fig-client-initial-
0rtt.
Paragraph (version A):
The connection ID in the QUIC packet headers allows association of
QUIC packets using information independent of the five-tuple.  This
allows rebinding of a connection after one of the endpoints - usually
the client - has experienced an address change.  Further it can be
used by in-network devices to ensure that related 5-tuple flows are
appropriately balanced together.
Paragraph (version B):
The connection ID in the QUIC packet headers allows association of
QUIC packets using information independent of the 5-tuple.  This
allows rebinding of a connection after one of the endpoints - usually
the client - has experienced an address change.  Further it can be
used by in-network devices to ensure that related 5-tuple flows are
appropriately balanced together.
Paragraph (version A):
At the time of writing, two application bindings for QUIC have been
published or adopted by the IETF: HTTP/3 QUIC-HTTP and DNS I-D.ietf-
dprive-dnsoquic.  These are both known 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.
Paragraph (version B):
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.
Paragraph (version A):
of QUIC-TRANSPORT.  E.g.  PADDING frames, each consisting of a single
zero byte, may occur before, after, or between CRYPTO frames.
However, extensions might define additional frame types.  If an
unknown frame type is encountered, it is impossible to know the
length of that frame which prevents skipping over it, and therefore
parsing fails.
Paragraph (version B):
of QUIC-TRANSPORT.  E.g., PADDING frames, each consisting of a single
zero byte, may occur before, after, or between CRYPTO frames.
However, extensions might define additional frame types.  If an
unknown frame type is encountered, it is impossible to know the
length of that frame which prevents skipping over it, and therefore
parsing fails.
Paragraph (version A):
A network function that attempts to use the connection ID to
associate flows must be robust to the failure of this technique.
Since the connection ID may change multiple times during the lifetime
of a connection, packets with the same five-tuple but different
connection IDs might or might not belong to the same connection.
Likewise, packets with the same connection ID but different five-
tuples might not belong to the same connection, either.
Paragraph (version B):
A network function that attempts to use the connection ID to
associate flows must be robust to the failure of this technique.
Since the connection ID may change multiple times during the lifetime
of a connection, packets with the same 5-tuple but different
connection IDs might or might not belong to the same connection.
Likewise, packets with the same connection ID but different 5-tuples
might not belong to the same connection, either.
Paragraph (version A):
Use of the spin bit for RTT measurement by devices on path is only
possible when both endpoints enable it.  Some endpoints may disable
use of the spin bit by default, others only in specific deployment
scenarios, e.g. for servers and clients where the RTT would reveal
the presence of a VPN or proxy.  To avoid making these connections
identifiable based on the usage of the spin bit, all endpoints
randomly disable "spinning" for at least one eighth of connections,
even if otherwise enabled by default.  An endpoint not participating
in spin bit signaling for a given connection can use a fixed spin
value for the duration of the connection, or can set the bit randomly
on each packet sent.
Paragraph (version B):
Use of the spin bit for RTT measurement by devices on path is only
possible when both endpoints enable it.  Some endpoints may disable
use of the spin bit by default, others only in specific deployment
scenarios, e.g., for servers and clients where the RTT would reveal
the presence of a VPN or proxy.  To avoid making these connections
identifiable based on the usage of the spin bit, all endpoints
randomly disable "spinning" for at least one eighth of connections,
even if otherwise enabled by default.  An endpoint not participating
in spin bit signaling for a given connection can use a fixed spin
value for the duration of the connection, or can set the bit randomly
on each packet sent.
Paragraph (version A):
However, application-limited and flow-control-limited senders can
have application and transport layer delay, respectively, that are
much greater than network RTT.  When the sender is application-
limited and e.g. only sends small amount of periodic application
traffic, where that period is longer than the RTT, measuring the spin
bit provides information about the application period, not the
network RTT.
Paragraph (version B):
However, application-limited and flow-control-limited senders can
have application and transport layer delay, respectively, that are
much greater than network RTT.  When the sender is application-
limited and e.g., only sends small amount of periodic application
traffic, where that period is longer than the RTT, measuring the spin
bit provides information about the application period, not the
network RTT.
Paragraph (version A):
If state is removed too early, this could lead to black-holing of
incoming packets after a short idle period.  To detect this
situation, a timer at the client needs to expire before a re-
establishment can happen (if at all), which would lead to unnecessary
long delays in an otherwise working connection.
Paragraph (version B):
If state is removed too early, this could lead to black-holing of
incoming packets after a short idle period.  To detect this
situation, a timer at the client needs to expire before a re-
establishment can happen (if at all), which would lead to
unnecessarily long delays in an otherwise working connection.
Paragraph (version A):
The QUIC header optionally contains a connection ID which could
provide additional entropy beyond the 5-tuple.  The QUIC handshake
needs to be observed in order to understand whether the connection ID
is present and what length it has.  However, connection IDs may be
renegotiated after the handshake, and this renegotiation is not
visible to the path.  Therefore, using the connection ID as a flow
key field for stateful treatment of flows is not recommended as
connection ID changes will cause undetectable and unrecoverable loss
of state in the middle of a connection.  Specially, the use of the
connection ID for functions that require state to make a forwarding
decison is not viable as it will break connectivity or at minimum
cause long timeout-based delays before this problem is detected by
the endpoints and the connection can potentially be re-established.
Paragraph (version B):
The QUIC header optionally contains a connection ID which could
provide additional entropy beyond the 5-tuple.  The QUIC handshake
needs to be observed in order to understand whether the connection ID
is present and what length it has.  However, connection IDs may be
renegotiated after the handshake, and this renegotiation is not
visible to the path.  Therefore, using the connection ID as a flow
key field for stateful treatment of flows is not recommended as
connection ID changes will cause undetectable and unrecoverable loss
of state in the middle of a connection.  In particular, the use of
the connection ID for functions that require state to make a
forwarding decison is not viable as it will break connectivity, or at
minimum cause long timeout-based delays before this problem is
detected by the endpoints and the connection can potentially be re-
established.
Paragraph (version A):
to survive address changes, e.g. by NAT rebindings, blocking a
portion of the traffic based on 5-tuple hashing increases the risk of
black-holing an active connection when the address changes.
Paragraph (version B):
to survive address changes, e.g., by NAT rebindings, blocking a
portion of the traffic based on 5-tuple hashing increases the risk of
black-holing an active connection when the address changes.
Paragraph (version A):
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.
Paragraph (version B):
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.
Paragraph (version A):
However, it is questionable whether connection migrations must be
supported during a DDoS attack.  While unintended migration without a
connection ID change can be more easily supported, it might be
acceptable to not support migrations of active QUIC connections that
are not visible to the network functions performing the DDoS
detection.  As soon as the connection blocking is detected by the
client, the client may be able to rely on the 0-RTT session
resumption mechanism provided by QUIC.  When clients migrate to a new
path, they should be prepared for the migration to fail and attempt
to reconnect quickly.
Paragraph (version B):
However, it is questionable whether connection migrations must be
supported during a DDoS attack.  While unintended migration without a
connection ID change can be more easily supported, it might be
acceptable to not support migrations of active QUIC connections that
are not visible to the network functions performing the DDoS
detection.  As soon as the connection blocking is detected by the
client, the client may be able to rely on the 0-RTT data mechanism
provided by QUIC.  When clients migrate to a new path, they should be
prepared for the migration to fail and attempt to reconnect quickly.
Paragraph (version A):
It is expected that any QoS handling in the network, e.g. based on
use of DiffServ Code Points (DSCPs) RFC2475 as well as Equal-Cost
Multi-Path (ECMP) routing, is applied on a per flow-basis (and not
per-packet) and as such that all packets belonging to the same active
QUIC connection get uniform treatment.
Paragraph (version B):
It is expected that any QoS handling in the network, e.g., based on
use of DiffServ Code Points (DSCPs) RFC2475 as well as Equal-Cost
Multi-Path (ECMP) routing, is applied on a per flow-basis (and not
per-packet) and as such that all packets belonging to the same active
QUIC connection get uniform treatment.