Draft: draft-ietf-quic-manageability

Commentary: Comment from PR from on UDP policing : " This is recommending something that relies on the 4 - tuple , but particularly if there 's another NAT involved , the 4 - tuple may not be stable . So this puts connections in a situation where the handshake completes , they use the connection for a bit , a NAT rebind occurs , and then the connection is blackholed . There are defenses against this problem , but this seems like a fairly dangerous recommendation . " 
 LG , some editorial comments .
Paragraph (version A):
The QUIC header optionally contains a connection ID which can be used
as additional entropy beyond the 5-tuple, if needed.  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 during after the handshake, and this
renegotiation is not visible to the path.  Using the connection ID as
a flow key field for stateful treatment of flows may therefore cause
undetectable and unrecoverable loss of state in the middle of a
connection.  Use of connection IDs is specifically discouraged for
NAT applications.
Paragraph (version A):
If a NAT hits an operational limit, it is recommended to rather drop
the initial packets of a flow (see also sec-filtering), which
potentially triggers a fallback to TCP, than using the connection ID
to muliplex mulitple connections on the same IP address port pair
which risks connectivity breakage later, in case the connection ID
changes.
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 B):
QUIC endpoints support address migration and a QUIC connection can
survive a change of the IP address or ports by mapping the connection
ID, if present, to an existing connection.  Ideally a new connection
ID is used at the same time when the address/port changes to avoid
linkability.  As new connection IDs belonging to the same connection
are not known to on-path devices, network devices are not able to map
QUIC connections after a 4-tuple change.  As such, when the 4-tuple
changes, stateful devices lose their state and break connectivity if
state is required for forwarding, while the endpoints would otherwise
survive such a change.
Paragraph (version B):
Use of connection IDs is specifically discouraged for NAT
applications.  If a NAT hits an operational limit, it is recommended
to rather drop the initial packets of a flow (see also sec-
filtering), which potentially triggers a fallback to TCP, than using
the connection ID to muliplex mulitple connections on the same IP
address port pair which risks connectivity breakage later, in case
the connection ID changes.