Draft: draft-ietf-quic-manageability

Commentary: Note that the main point about using CID in a NAT can break connectivity was already covered the section " Stateful Treatment of QUIC Traffic " . The new section now only covers the NAT for routing stability case . 
 Note also that this PR also contains some rearrangement of sections . 
 I updated the text in the " Address Rewriting to Ensure Routing Stability " as agreed with The remaining comments are on sections where I did n't change any of the text but did move them to a different position in the document . Please open separate issue for them ! I would really like to merge this PR now / first so we have all the pieces in the right place . We can then create new PRs on further changes needed . Is that okay ? 
 addresses and addresses 
 I do n't think so , but the structure of makes it hard to tell . 
 We left this open as we did n't merge the bigger NAT section rewrite yet . 
 was reworded with the larger rewrite 
 Getting better . Though this PR is now at the point that I ca n't follow all the different pieces .
Paragraph (version A):
The spin bit provides an additional method to measure per-flow RTT
from observation points on the network path throughout the duration
of a connection.  Endpoint participation in spin bit signaling is
optional in QUIC.  That is, while its location is fixed in this
version of QUIC, an endpoint can unilaterally choose to not support
"spinning" the bit.  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):
In the case of content distribution networking architectures
including load balancers, the connection ID provides a way for the
server to signal information about the desired treatment of a flow to
the load balancers.  Guidance on assigning connection IDs is given in
QUIC-APPLICABILITY.
Paragraph (version B):
While QUIC's migration capability makes it possible for an server to
survive address changes, this does not work if the routers or
switches in the server infrastructure route using the address-port
4-tuple.  If infrastructure routes on addresses only, NAT rebinding
or address migration will cause packets to be delivered to the wrong
server.  QUIC_LB describes a way to addresses this problem by
coordinating the selection and use of connection IDs between load-
balancers and servers.
Paragraph (version B):
In addition, a change of IP address or port is also an input signal
to other internal mechanisms in QUIC.  When a path change is
detected, path-dependent variables like congestion control parameters
will be reset protecting the new path from overload.
Paragraph (version B):
In the case of networking architectures including load balancers, the
connection ID provides a way for the server to signal information
about the desired treatment of a flow to the load balancers.
Guidance on assigning connection IDs is given in QUIC-APPLICABILITY.
QUIC_LB describes a system for coordinating selection and use of
connection IDs between load-balancers and servers.
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 I-D.ietf-quic-applicability, as QUIC is based on
UDP and there are known block of UDP (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):
The recommended way to police QUIC packets is to either drop them all
or to throttle them based on the hash of the UDP datagram's source
and destination addresses, blocking a portion of the hash space that
corresponds to the fraction of UDP traffic one wishes to drop.  When
the handshake is blocked, QUIC-capable applications may failover to
TCP (at least applications using well-known UDP ports).  However,
blindly blocking a significant fraction of QUIC packets will allow
many QUIC handshakes to complete, preventing a TCP failover, but the
connections will suffer from severe packet loss.
Paragraph (version A):
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 A):
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 A):
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 A):
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 A):
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 A):
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 A):
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 A):
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 A):
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 A):
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 A):
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 A):
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 A):
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 A):
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 A):
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.
Paragraph (version B):
Networks with configurations that would lead to fragmentation of
large packets should drop such packets rather than fragmenting them.
Network operators who plan to implement a more selective policy may
start by focussing on QUIC.  QUIC flows cannot always be easily
distinguished from other UDP traffic, but we assume at least some
portion of QUIC traffic can be identified (see sec-identifying).  For
QUIC endpoints using DPLPMTUD it is recommended for the path to drop
a packet larger than the supported size.  A QUIC probe packet is used
to discover the PMTU.  If lost, this does not impact the flow of QUIC
data.
Paragraph (version B):
IPv4 routers generate an ICMP message when a packet is dropped
because the link MTU was exceeded.  RFC8504 specifies how an IPv6
node generates an ICMPv6 Packet Too Big message (PTB) in this case.
PMTUD relies upon an endpoint receiving such PTB messages RFC8201,
whereas DPLPMTUD does not reply upon these messages, but still can
optionally use these to improve performance Section 4.6 of DPLPMTUD.