Draft: draft-ietf-quic-manageability

Commentary: I addressed all of the comments except where I had no idea for what to write . As for making the section more " crisp " , I would much prefer that we land this PR and have another one composed by someone else who has a firm idea of what to do about it . 
 Per feedback at IETF 109 , Martin will take his quic - natsupp draft and put it somewhere in quic - manageability . 
 Thanks ! 
 lgtm now thanks !
Paragraph (version A):
QUIC QUIC-TRANSPORT is a new transport protocol focusing on support
of semantics as needed for HTTP QUIC-HTTP.  QUIC is encapsulated in
UDP and encrypted by default.  QUIC integrates TLS QUIC-TLS to
encrypt all payload data and most control information.  The version
of HTTP that operates over QUIC is HTTP/3.
Paragraph (version A):
This document provides guidance for network operations that manage of
QUIC traffic.  This includes guidance on how to interpret and utilize
information that is exposed by QUIC to the network, requirements and
assumptions that the QUIC design with respect to network treatment,
and a description of how common network management practices will be
impacted by QUIC.
Paragraph (version A):
Since QUIC's wire image WIRE-IMAGE is integrity protected and not
modifiable on path, in-network operations are not possible without
terminating the QUIC connection, for instance using a back-to-back
proxy.  Proxy operations are not in scope for this document.  QUIC
proxies must be fully-fledged QUIC endpoints, implementing the
transport as defined in QUIC-TRANSPORT and QUIC-TLS, proxy-relevant
semantics for the application(s) running over QUIC (e.g.  HTTP/3 as
defined in QUIC-HTTP), and have the TLS credentials to authenticate
as the server and (in some cases) client.
Paragraph (version A):
sec-google-version provides non-normative guidance on the
identification of QUIC version 1 packets compared to pre-standard
versions.
Paragraph (version A):
"fixed bit": the second most significant bit of the first octet
most QUIC packets of the current version is currently set to 1,
for demultiplexing with other UDP-encapsulated protocols.
Endpoints that do not need this demultiplexing function might
assign arbitrary values.  See I-D.thomson-quic-bit-grease for more
details.
Paragraph (version A):
version number: the version number is present in the long header,
and identifies the version used for that packet.  Note that during
Version Negotiation (see version and Section 17.2.1 of QUIC-
TRANSPORT), the version number field has a special value
(0x00000000) that identifies the packet as a Version Negotiation
packet.  QUIC versions that start with 0xff are IETF drafts.  QUIC
versions that start with 0x0000 are reserved for IETF consensus
documents, for example the QUIC version 1 is expected to use
version 0x00000001.  Operators should expect to observe packets
with other version numbers as a result of various internet
experiments and future standards.
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 with TCP-
based services, especially when application layer information is
encrypted, there is no guarantee that a specific application will use
the registered port, or the used port is carrying traffic belonging
to the respective registered service.  For example, QUIC-TRANSPORT
specifies the use of Alt-Svc for discovery of QUIC/HTTP3 services on
other ports.
Paragraph (version A):
The Client Hello datagram, Server Hello datagram, and Initial
Completion datagram, which all contain a QUIC Initial Packet, must be
at least 1200 octets long.  This protects against amplification
attacks and verify the network path meets minimum Maximum
Transmission Unit (MTU) requirements.  This is usually accomplished
with either the addition of PADDING frames to the Initial packet, or
coalescing of the Initial Packet with packets from other encryption
contexts.
Paragraph (version A):
Version negotiation packets are not intrinsically protected, but QUIC
versions can use later encrypted messages to verify that they were
authentic.  Therefore any manipulation of this list will be detected
and will cause the endpoints to terminate the connection.
Paragraph (version A):
While the second most significant bit (0x40) of the first octet is
set to 1 in most QUIC packets of the current version (see public-
header), this method of recognizing QUIC traffic is NOT RECOMMENDED.
First, it only provides one bit of information and is quite prone to
collide with UDP-based protocols other than those that this static
bit is meant to allow multiplexing with.  Second, this feature of the
wire image is not invariant QUIC-INVARIANTS and may change in future
versions of the protocol, or even be negotiated during the handshake
via proposed transport parameters.
Paragraph (version A):
Connection establishment uses Initial and Handshake packets
containing a TLS handshake.  Connection establishment can therefore
be detected using heuristics similar to those used to detect TLS over
TCP.  A client initiating 0-RTT connection may also send data packets
in 0-RTT Protected packets directly after the Initial packet
containing the TLS Client Hello.  Since these packets may be
reordered in the network, note that 0-RTT Protected data packets may
be seen before the Initial packet.
Paragraph (version A):
Note that clients send Initial packets before servers do, servers
send Handshake packets before clients do, and only clients send
Initial packets with tokens.  Therefore, identity as a client or
server can generally be confirmed by an on- path observer.  An
attempted connection after Retry can be detected by correlating the
token on the Retry with the token on the subsequent Initial packet
and the Destination Connection ID of the new Initial packet.
Paragraph (version B):
Note that clients send Initial packets before servers do, servers
send Handshake packets before clients do, and only clients send
Initial packets with tokens.  Therefore, the role as a client or
server can generally be confirmed by an on- path observer.  An
attempted connection after Retry can be detected by correlating the
token on the Retry with the token on the subsequent Initial packet
and the destination connection ID of the new Initial packet.
Paragraph (version A):
Note that client Initial packets that do not contain the Client Hello
message generally also do not always use the Destination Connection
ID that was used to generate the Initial keys.  Therefore, attempts
to decrypt these packets using the procedure above will fail.
Paragraph (version B):
Note that client Initial packets after the first do not always use
the destination connection ID that was used to generate the Initial
keys.  Therefore, attempts to decrypt these packets using the
procedure above might fail.
Paragraph (version A):
these connections identifiable based on the usage of the spin bit, it
is recommended that 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):
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):
RFC4787 recommends a 2 minute timeout interval for UDP.  However,
timers are often lower, in the range of 15 to 30 seconds.  In
contrast, RFC5382 recommends a timeout of more than 2 hours for TCP,
given that TCP is a connection-oriented protocol with well-defined
closure semantics.  For network devices that are QUIC-aware, it is
recommended to also use longer timeouts for QUIC traffic, as QUIC is
connection-oriented.  As such, a handshake packet from the server
indicates the willingness of the server to communicate with the
client.
Paragraph (version B):
QUIC Connection IDs are opaque byte fields that are expressed
consistently across all QUIC versions QUIC-INVARIANTS, see rebinding.
This feature may appear to present opportunities to optimize NAT port
usage and simplify the work of the QUIC server.  In fact, NAT
behavior that relies on CID may instead cause connection failure when
endpoints change Connection ID, and disable important protocol
security features.  NATs should retain their existing 4-tuple-based
operation and refrain from parsing or otherwise using QUIC connection
IDs.
Paragraph (version B):
This section uses the colloquial term NAT to mean NAPT (section 2.2
of RFC3022), which overloads several IP addresses to one IP address
or to an IP address pool, as commonly deployed in carrier-grade NATs
or residential NATs.
Paragraph (version B):
The remainder of this section explains how QUIC supports NATs better
than other connection-oriented protocols, why NAT use of Connection
ID might appear attractive, and how NAT use of CID can create serious
problems for the endpoints.
Paragraph (version B):
RFC4787 contains some guidance on building NATs to interact
constructively with a wide range of applications.  This section
extends the discussion to QUIC.
Paragraph (version B):
By using the CID, QUIC connections can survive NAT rebindings as long
as no routing function in the path is dependent on client IP address
and port to deliver packets between server and NAT.  Reducing the
timeout on UDP NATs might be tempting in light of this property, but
not all QUIC server deployments will be robust to rebinding.
Paragraph (version B):
NATs sometimes hit an operational limit where they exhaust available
public IP addresses and ports, and must evict flows from their
address/port mapping.  CIDs might appear to offer a way to multiplex
many connections over a single address and port.
Paragraph (version B):
However, QUIC endpoints may negotiate new connection IDs inside
cryptographically protected packets, and begin using them at will.
Imagine two clients behind a NAT that are sharing the same public IP
address and port.  The NAT is differentiating them using the incoming
Connection ID.  If one client secretly changes its connection ID,
there will be no mapping for the NAT, and the connection will
suddenly break.
Paragraph (version B):
It is possible, in principle, to encode the client's identity in a
connection ID using the techniques described in QUIC_LB and explicit
coordination with the NAT.  However, this implies that the client
shares configuration with the NAT, which might be logistically
difficult.  This adds administrative overhead while not resolving the
case where a client migrates to a point behind the NAT.
Paragraph (version B):
Note that multiplexing connection IDs over a single port anyway
violates the best common practice to avoid "port overloading" as
described in RFC4787.
Paragraph (version B):
Concealing client address changes in order to simplify operational
routing issues will mask important signals that drive security
mechanisms, and therefore opens QUIC up to various attacks.
Paragraph (version B):
One challenge in QUIC deployments that want to benefit from QUIC's
migration capability is server infrastructures with routers and
switches that direct traffic based on address-port 4-tuple rather
than connection ID.  The use of source IP address means that a NAT
rebinding or address migration will deliver packets to the wrong
server.  As all QUIC payloads are encrypted, routers and switches
will not have access to negotiated but not-yet-in-use CIDs.  This is
a particular problem for low-state load balancers.  QUIC_LB addresses
this problem proposing a QUIC extension to allow some server-load
balancer coordination for routable CIDs.
Paragraph (version B):
It seems that a NAT anywhere in the front of such an infrastructure
setup could save the effort of converting all these devices by
decoding routable connection IDs and rewriting the packet IP
addresses to allow consistent routing by legacy devices.
Paragraph (version B):
Unfortunately, the change of IP address or port is an important
signal to QUIC endpoints.  It requires a review of path-dependent
variables like congestion control parameters.  It can also signify
various attacks that mislead one endpoint about the best peer address
for the connection (see section 9 of QUIC-TRANSPORT).  The QUIC
PATH_CHALLENGE and PATH_RESPONSE frames are intended to detect and
mitigate these attacks and verify connectivity to the new address.
This mechanism cannot work if the NAT is bleaching peer address
changes.
Paragraph (version B):
For example, an attacker might copy a legitimate QUIC packet and
change the source address to match its own.  In the absence of a
bleaching NAT, the receiving endpoint would interpret this as a
potential NAT rebinding and use a PATH_CHALLENGE frame to prove that
the peer endpoint is not truly at the new address, thus thwarting the
attack.  A bleaching NAT has no means of sending an encrypted
PATH_CHALLENGE frame, so it might start redirecting all QUIC traffic
to the attacker address and thus allow an observer to break the
connection.
Paragraph (version B):
RFC4787 describes possible packet filtering behaviors that relate to
NATs.  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.  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.