Draft: draft-ietf-quic-manageability

Commentary: still has two open points ( " is RFC8701 the right reference for greasing " and " should we refer draft - ietf - tsvwg - transport - encrypt " ) . However we might just open two new issue for those if needed ... 
 Comments from ( but were posted on the wrong PR ): From PR : I 'd also like to see something like : /In this section , we discuss those aspects of the QUIC transport protocol that / This section discusses those aspects of the QUIC transport protocol that/ /Here , we are concerned primarily with the unencrypted part of QUIC 's wire image { { WIRE - IMAGE } } , which we define as the information available in the packet / This section is concerned primarily with the unencrypted part of QUIC 's wire image { { WIRE - IMAGE } } , defined as the information available in the packet/ and /least four datagrams we 'll call " Client Initial",/least four datagrams , labelled " Client Initial",/ and / 0 - RTT data may also be seen in the Client Initial datagram , as shown in /When the client uses 0 - RTT connection resumption , the Client Initial datagram can also carry 0 - RTT data , as shown in/ and /typically around 10 packets / typically to around 10 packets/ and /of a connection after one of one endpoint / of a connection after an endpoint/ I 'd prefer more like : /Though the guidance there holds , a particularly unwise behavior admits a handful of UDP packets and then makes a decision as to whether or not to filter later packets in the same connection . QUIC applications are encouraged to fail over to TCP if early packets do/ ... and I 'll close PR . 
 Added  's additional comments . This should be ready to go ! 
 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 ) , so there will likely be some false positives . There is no need to let me know what you did with these suggestions . 
 thanks ! to 
 In this text : “ When one endpoint unintentionally changes its address , as is the case with NAT rebinding , “ actually the endpoint does n’t change the address , except in  ( odd to find that in use ! ) , it is the “ received endpoint address ” that changes , . 
 passivize , perhaps : " when one endpoint 's address unintentionally changes ? " 
 This issue captires a number of minor wording issues , references etc : Operators should expect to observe packets with other version numbers as a result of various Internet experiments , future standards , and greasing . Since greasing might not be understood by all operations staff , a reference here would help , e.g. : RFC8701 . Style : “ four datagrams we 'll call “ why suddenly a use of “ we ” , can you reword to remove that ? This could be clearer : “ When the client uses 0 - RTT connection resumption , 0 - RTT data may also be seen in the Client Initial datagram , as shown in Figure 6 . ” what does “ seen ” mean ? is “ can be present ” equivalent , in which case it is better than implying it is observable . “ will result in connection establishment failing later on . ” Can we just remove the spurious word “ on ” at the end of the sentence ? “ This allows rebinding of a connection after one of one endpoint experienced an address change ” what is “ one of one ” ? “ also supports migration which opens an attack vector on specific servers or pools . ” add comma before “ which ” or use “ that ” ? Section 2.7 could refer to , ( now in    ) for examples of sequence number observation and alternatives for encrypted transports . Section 3 : “ This section addresses the different kinds of observations and inferences that can be made about QUIC flows by a passive observer in the network based on the wire image in Section 2 . ” This seems correct , although may be helpful to also say this observer does not have access to keying information . Actually the set of possible things that can be done is more than the say , please add a reference for example by queueing ACKs differently or manipulating ACK .... It might be worth citing RFC3449 as example ? or Although other things also are done and also some links compress ACKs , etc there is a more modern view in : per The title here : 4.8 . Quality of Service handling and ECMP should this title be “ 4.8 . Quality of Service handling and ECMP Routing ” just to complete the concept of ECMP in the section title ? 
 And ... The text says : “ a particularly unwise behavior is to admit a handful of UDP packets and then make a decision as to whether or not to filter it ” “ it ” is presumably “ later packets in the flow ” ? 
 first to make sure we did n't already merge a PR for these ... 
 There was already a reference but should we rather replace " greasing " with " aliasing " and refer to draft - duke - quic - version - aliasing ? 
 for example by queueing ACKs differently or manipulating ACK .... I did n't add a reference to draft - ietf - tsvwg - transport - encrypt as I really was n't sure where and how given it talks more about TCP and I think a lot of topics are otherwise already covered in this document . can you maybe propose a PR ? 
 My PR was . 
 From a discussion on this assertion with he observed that while client - side CIDs are uncommon on " actual " clients , they 're likely to be very common on proxies ( e.g.  ) . Anyone monitoring traffic at the server network might well see lots of client - side CIDs . That suggests this statement about what " typically " happens might be overly specific to one deployment or viewpoint . 
 Agreed . I think the strongest statement I could agree with are that they 're more likely to be present in the client to server direction than server to client , but I 'm not sure that 's very useful in practice ? 
 How about : 
 As this is advice for network operators and middlebox vendors , this reads to me as permission to use a lower timeout . I think that it still makes sense to maintain the recommendation in RFC 4787 . The advice for applications ( do n't rely on 2 minutes ) still applies , but a 2 minute recommendation is worth sticking to . 
 I thought the text is pretty clear in saying that a bit later : I would rather want to keep this part because the message really is : yes we know these too short timers are implemented for UDP but please , please use at least 2 minutes for QUIC . Maybe removing some paragraph breaks would make it clearer that these parts belong together ? Also this part got now edited quite extensively , so I rather not change it again ... 
 Each of the sentences looks fine to me , but together I also have a hard time seeing the recommendation v. current experience . Here is a proposal : . 
 Is this a promise ? Because there are a number of designs floating around that would allow a client and server to agree - out of band or by prior arrangement - that version 1 means something else entirely . If the above were a promise , that 's perhaps reasonable . It is an interpretation that seems consistent with the invariants . However , the invariants do n't make this particular ( that was deliberate ) , so this is technically stretching it . This might be better phrased with a " might infer the version number in use " to admit the possibility of error .
Paragraph (version A):
In this section, we discuss those aspects of the QUIC transport
protocol that have an impact on the design and operation of devices
that forward QUIC packets.  Here, we are concerned primarily with the
unencrypted part of QUIC's wire image WIRE-IMAGE, which we define as
the information available in the packet header in each QUIC packet,
and the dynamics of that information.  Since QUIC is a versioned
protocol, the wire image of the header format can also change from
version to version.  However, the field that identifies the QUIC
version in some packets, and the format of the Version Negotiation
Packet, are both inspectable and invariant QUIC-INVARIANTS.
Paragraph (version B):
This section discusses those aspects of the QUIC transport protocol
that have an impact on the design and operation of devices that
forward QUIC packets.  This section is therefore primarily
considering the unencrypted part of QUIC's wire image WIRE-IMAGE,
which is defined as the information available in the packet header in
each QUIC packet, and the dynamics of that information.  Since QUIC
is a versioned protocol, the wire image of the header format can also
change from version to version.  However, the field that identifies
the QUIC version in some packets, and the format of the Version
Negotiation Packet, are both inspectable and invariant QUIC-
INVARIANTS.
Paragraph (version A):
The QUIC handshake can normally be recognized on the wire through at
least four datagrams we'll call "Client Initial", "Server Initial",
and "Client Completion", and "Server Completion", for purposes of
this illustration, as shown in fig-handshake.
Paragraph (version B):
The QUIC handshake can normally be recognized on the wire through at
least four datagrams labelled "Client Initial", "Server Initial", and
"Client Completion", and "Server Completion", in the illustration
shown in fig-handshake.
Paragraph (version A):
The content of Initial packets are encrypted using Initial Secrets,
which are derived from a per-version constant and the client's
destination connection ID; they are therefore observable by any on-
path device that knows the per-version constant.  They are therefore
considered visible in this illustration.  The content of QUIC
Handshake packets are encrypted using keys established during the
initial handshake exchange, and are therefore not visible.
Paragraph (version B):
The content of Initial packets is encrypted using Initial Secrets,
which are derived from a per-version constant and the client's
destination connection ID; they are therefore observable by any on-
path device that knows the per-version constant.  They are therefore
considered visible in this illustration.  The content of QUIC
Handshake packets are encrypted using keys established during the
initial handshake exchange, and are therefore not visible.
Paragraph (version A):
When the client uses 0-RTT connection resumption, 0-RTT data may also
be seen in the Client Initial datagram, as shown in fig-client-
initial-0rtt.
Paragraph (version B):
When the client uses 0-RTT connection resumption, the Client Initial
datagram can also carry 0-RTT data, as shown in fig-client-initial-
0rtt.
Paragraph (version A):
In a 0-RTT Client Initial datagram, the PADDING frame is only present
if necessary to increase the size of the datagram with 0-RTT data to
at least 1200 bytes.  Additional datagrams containing only 0-RTT
packets with long headers could be sent from the client to the server
after the Client Initial datagram, containing the rest of the 0-RTT
data.  The amount of 0-RTT protected data that can be sent in the
first flight is limited by the initial congestion window, typically
around 10 packets (see Section 7.2 of QUIC-RECOVERY).
Paragraph (version B):
In a 0-RTT Client Initial datagram, the PADDING frame is only present
if necessary to increase the size of the datagram with 0-RTT data to
at least 1200 bytes.  Additional datagrams containing only 0-RTT
packets with long headers could be sent from the client to the server
after the Client Initial datagram, containing the rest of the 0-RTT
data.  The amount of 0-RTT protected data that can be sent in the
first flight is limited by the initial congestion window, typically
to around 10 packets (see Section 7.2 of QUIC-RECOVERY).
Paragraph (version A):
in those fields will result in connection establishment failing later
on.
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 one endpoint
experienced an address change - usually the client.  Further it can
be used by in-network devices to ensure that related 5-tuple flows
are appropriately balanced together.
Paragraph (version A):
Client and server negotiate connection IDs during the handshake;
typically, however, only the server will request a connection ID for
the lifetime of the connection.  Connection IDs for either endpoint
may change during the lifetime of a connection, with the new
connection ID being supplied via encrypted frames (see Section 5.1 of
QUIC-TRANSPORT).  Therefore, observing a new connection ID does not
necessary indicate a new connection.
Paragraph (version A):
QUIC_LB specifies algorithms for encoding the server mapping in a
connection ID in order to share this information with selected on-
path devices such as load balancers.  Server mappings should only be
exposed to selected entities.  Uncontrolled exposure would allow
linkage of multiple IP addresses to the same host if the server also
supports migration which opens an attack vector on specific servers
or pools.  The best way to obscure an encoding is to appear random to
any other observers, which is most rigorously achieved with
encryption.  As a result, any attempt to infer information from
specific parts of a connection ID is unlikely to be useful.
Paragraph (version B):
in those fields will result in connection establishment failing
later.
Paragraph (version B):
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
experienced an address change - usually the client.  Further it can
be used by in-network devices to ensure that related 5-tuple flows
are appropriately balanced together.
Paragraph (version B):
Client and server each choose a connection ID during the handshake;
for example, a server might request that a client use a connection
ID, whereas the client might choose a zero-length value.  Connection
IDs for either endpoint may change during the lifetime of a
connection, with the new connection ID being supplied via encrypted
frames (see Section 5.1 of QUIC-TRANSPORT).  Therefore, observing a
new connection ID does not necessarily indicate a new connection.
Paragraph (version B):
QUIC_LB specifies algorithms for encoding the server mapping in a
connection ID in order to share this information with selected on-
path devices such as load balancers.  Server mappings should only be
exposed to selected entities.  Uncontrolled exposure would allow
linkage of multiple IP addresses to the same host if the server also
supports migration that opens an attack vector on specific servers or
pools.  The best way to obscure an encoding is to appear random to
any other observers, which is most rigorously achieved with
encryption.  As a result, any attempt to infer information from
specific parts of a connection ID is unlikely to be useful.
Paragraph (version A):
Version Negotiation packets are used by the server to indicate that a
requested version from the client is not supported (see Section 6 of
QUIC-TRANSPORT.  Version Negotiation packets are not intrinsically
protected, but future QUIC versions will use later encrypted messages
to verify that they were authentic.  Therefore any modification of
this list will be detected and may cause the endpoints to terminate
the connection attempt.
Paragraph (version B):
Version Negotiation packets are used by the server to indicate that a
requested version from the client is not supported (see Section 6 of
QUIC-TRANSPORT.  Version Negotiation packets are not intrinsically
protected, but future QUIC versions will use later encrypted messages
to verify that they were authentic.  Therefore, any modification of
this list will be detected and may cause the endpoints to terminate
the connection attempt.
Paragraph (version A):
QUIC is expected to evolve rapidly, so new versions, both
experimental and IETF standard versions, will be deployed in the
Internet more often than with traditional Internet- and transport-
layer protocols.  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, and is therefore not
recommended.  In addition, due to the speed of evolution of the
protocol, devices that attempt to distinguish QUIC traffic from non-
QUIC traffic for purposes of network admission control should admit
all QUIC traffic regardless of version.
Paragraph (version B):
QUIC is expected to evolve rapidly, so new versions, both
experimental and IETF standard versions, will be deployed on the
Internet more often than with traditional Internet- and transport-
layer protocols.  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, and is therefore not
recommended.  In addition, due to the speed of evolution of the
protocol, devices that attempt to distinguish QUIC traffic from non-
QUIC traffic for purposes of network admission control should admit
all QUIC traffic regardless of version.
Paragraph (version A):
This section addresses the different kinds of observations and
inferences that can be made about QUIC flows by a passive observer in
the network based on the wire image in sec-wire-image.  Here we
assume a bidirectional observer (one that can see packets in both
directions in the sequence in which they are carried on the wire)
unless noted.
Paragraph (version B):
This section addresses the different kinds of observations and
inferences that can be made about QUIC flows by a passive observer in
the network based on the wire image in sec-wire-image.  Here we
assume a bidirectional observer (one that can see packets in both
directions in the sequence in which they are carried on the wire)
unless noted, but typically without access to any keying information.
Paragraph (version A):
An in-network observer assuming that a set of packets belongs to a
QUIC flow can infer the version number in use by observing the
handshake: for QUIC version 1, if the version number in the Initial
packet from a client is the same as the version number in the Initial
packet of the server response, that version has been accepted by both
endpoints to be used for the rest of the connection.
Paragraph (version B):
An in-network observer assuming that a set of packets belongs to a
QUIC flow might infer the version number in use by observing the
handshake: for QUIC version 1, if the version number in the Initial
packet from a client is the same as the version number in the Initial
packet of the server response, that version has been accepted by both
endpoints to be used for the rest of the connection.
Paragraph (version A):
When one endpoint unintentionally changes its address, as is the case
with NAT rebinding, an on-path observer may be able to use the
connection ID to associate the flow on the new address with the flow
on the old address.
Paragraph (version B):
When one endpoint's address unintentionally changes, as is the case
with NAT rebinding, an on-path observer may be able to use the
connection ID to associate the flow on the new address with the flow
on the old address.
Paragraph (version A):
Note that this measurement, as with passive RTT measurement for TCP,
includes any transport protocol delay (e.g., delayed sending of
acknowledgements) and/or application layer delay (e.g., waiting for a
response to be generated).  It therefore provides devices on path a
good instantaneous estimate of the RTT as experienced by the
application.
Paragraph (version B):
Note that this measurement, as with passive RTT measurement for TCP,
includes any transport protocol delay (e.g., delayed sending of
acknowledgments) and/or application layer delay (e.g., waiting for a
response to be generated).  It therefore provides devices on path a
good instantaneous estimate of the RTT as experienced by the
application.
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.  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 A):
RFC4787 describes possible packet filtering behaviors that relate to
NATs but is often also used is other scenarios where packet filtering
is desired.  Though the guidance there holds, a particularly unwise
behavior is to admit a handful of UDP packets and then make a
decision as to whether or not to filter it.  QUIC applications are
encouraged to fail over to TCP if early packets do not arrive at
their destination I-D.ietf-quic-applicability, as QUIC is based on
UDP and there are known blocks of UDP traffic (see sec-udp-1312).
Admitting a few packets allows the QUIC endpoint to determine that
the path accepts QUIC.  Sudden drops afterwards will result in slow
and costly timeouts before abandoning the connection.
Paragraph (version B):
RFC4787 describes possible packet filtering behaviors that relate to
NATs but is often also used is other scenarios where packet filtering
is desired.  Though the guidance there holds, a particularly unwise
behavior admits a handful of UDP packets and then makes a decision to
whether or not filter later packets in the same connection.  QUIC
applications are encouraged to fail over to TCP if early packets do
not arrive at their destination I-D.ietf-quic-applicability, as QUIC
is based on UDP and there are known blocks of UDP traffic (see sec-
udp-1312).  Admitting a few packets allows the QUIC endpoint to
determine that the path accepts QUIC.  Sudden drops afterwards will
result in slow and costly timeouts before abandoning the connection.
Paragraph (version A):
Further, if UDP traffic is desired to be throttled, it is recommended
to block individual QUIC flows entirely rather than dropping packets
indiscriminately.  When the handshake is blocked, QUIC-capable
applications may fail over to TCP.  However, blocking a random
fraction of QUIC packets across 4-tuples will allow many QUIC
handshakes to complete, preventing a TCP failover, but these
connections will suffer from severe packet loss (see also sec-
filtering).  Therefore UDP throttling should be realized by per-flow
policing, as opposed to per-packet policing.  Note that this per-flow
policing should be stateless to avoid problems with stateful
treatment of QUIC flows (see sec-stateful), for example blocking a
portion of the space of values of a hash function over the addresses
and ports in the UDP datagram.  While QUIC endpoints are often able
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):
Further, if UDP traffic is desired to be throttled, it is recommended
to block individual QUIC flows entirely rather than dropping packets
indiscriminately.  When the handshake is blocked, QUIC-capable
applications may fail over to TCP.  However, blocking a random
fraction of QUIC packets across 4-tuples will allow many QUIC
handshakes to complete, preventing a TCP failover, but these
connections will suffer from severe packet loss (see also sec-
filtering).  Therefore, UDP throttling should be realized by per-flow
policing, as opposed to per-packet policing.  Note that this per-flow
policing should be stateless to avoid problems with stateful
treatment of QUIC flows (see sec-stateful), for example blocking a
portion of the space of values of a hash function over the addresses
and ports in the UDP datagram.  While QUIC endpoints are often able
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):
Version Negotiation packets do not contain any mechanism to prevent
version downgrade attacks.  However, future versions of QUIC that use
Version Negotiation packets are require to define a mechanism that is
robust against version downgrade attacks.  Therefore a network node
should not attempt to impact version selection, as version downgrade
may result in connection failure.
Paragraph (version B):
Version Negotiation packets do not contain any mechanism to prevent
version downgrade attacks.  However, future versions of QUIC that use
Version Negotiation packets are required to define a mechanism that
is robust against version downgrade attacks.  Therefore, a network
node should not attempt to impact version selection, as version
downgrade may result in connection failure.