Draft: draft-ietf-quic-manageability

Commentary: Currently I find this section worded in a way which could cause the reader to believe using CID would typically work . 
 While we say in multiple places that it is not recommended to to use the connection ID , it is still true that you can use it to associate a new 5 - tuple to an existing connection . This is what this text describes and that 's inline the with the goal of section 2 which basically only describes what possible with the wire image and what 's not . Therefore I would n't want to remove this text here . Note that there can be stateful functions like spin - bit based monitoring that would benefit from map connections with the same connection ID but do n't break anything otherwise . However , I guess we could add a warning already here that it is usually not recommended to use the connection ID as it might change . I think that 's what the next part already says but not directly as a warning or recommendation ( given that was not the goal of this section ) . 
 I another paragraph to clarify what is possible , PTAL 
 I think that it is good to remove that text . It is true that in some narrow cases the same connection ID on two paths means that the connection moved from one path to the other . However , this is not a guarantee and to suggest otherwise is not very helpful . I support removing the text . This is ready to merge now !
Paragraph (version B):
A typical handshake starts with the client sending of a Client
Initial datagram as shown in fig-client-initial, which elicits a
Server Initial datagram as shown in fig-server-initial typically
containing three packets: an Initial packet with the Server Initial,
a Handshake packet with the rest of the server's side of the TLS
handshake, and initial 1-RTT data, if present.
Paragraph (version B):
The Client Completion datagram contains at least one Handshake packet
and some also include an Initial packet.
Paragraph (version B):
Datagrams that contain a Client Initial Packet (Client Initial,
Server Initial, and some Client Completion) contain at least 1200
octets of UDP payload.  This protects against amplification attacks
and verifies that the network path meets the requirements for the
minimum QUIC IP packet size; see Section 14 of QUIC-TRANSPORT.  This
is accomplished by either adding PADDING frames within the Initial
packet, coalescing other packets with the Initial packet, or leaving
unused payload in the UDP packet after the Initial packet.  A network
path needs to be able to forward at least this size of packet for
QUIC to be used.
Paragraph (version B):
The content of Client 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):
Initial, Handshake, and the Short Header packets transmitted after
the handshake belong to cryptographic and transport contexts.  The
Client Completion fig-init-complete and the Server Completion fig-hs-
complete datagrams finish these first two contexts, by sending the
final acknowledgment and finishing the transmission of CRYPTO frames.
Paragraph (version B):
Similar to Client Completion, Server Completion also exposes no
additional information; observing it serves only to determine that
the handshake has completed.
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 0RTT data to
at least 1200 bytes.  Additional datagrams containing only 0-RTT
protected long header packets may 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 round is limited by the initial congestion window,
typically around 10 packets (see Section 7.2 of QUIC-RECOVERY).
Paragraph (version A):
The connection ID in the QUIC packet headers allows routing of QUIC
packets at load balancers using information independent of the five-
tuple.  This helps ensure that related flows are appropriately
balanced together and allows rebinding of a connection after one of
the endpoints experiences an address change - usually the client.
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 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 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 B):
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 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 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 A):
The QUIC connection ID (see rebinding) is designed to allow an on-
path device such as a load-balancer to associate two flows as
identified by five-tuple when the address and port of one of the
endpoints changes; e.g. due to NAT rebinding or address migration.
An observer keeping flow state can associate a connection ID, if
present, with a given flow, and can associate a known flow with a new
flow when when observing a packet sharing the same connection ID in
the same direction between client and server and sharing one endpoint
address (IP address and port) with the known flow.
Paragraph (version A):
However, since the connection ID may change multiple times during the
lifetime of a flow, and the negotiation of connection ID changes is
encrypted, packets with the same 5-tuple but different connection IDs
might or might not belong to the same connection.
Paragraph (version B):
The QUIC connection ID (see rebinding) is designed to allow a
coordinating on-path device, such as a load-balancer, to associate
two flows when one of the endpoints changes address or port.  This
change can be due to NAT rebinding or address migration.
Paragraph (version B):
The connection ID must change upon intentional address change by an
endpoint, and connection ID negotiation is encrypted, so it is not
possible for a passive observer to link intended changes of address
using the connection ID.
Paragraph (version B):
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):
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):
While QUIC has no clear network-visible end-of-connection signal and
therefore does require timer-based state removal, the QUIC handshake
indicates confirmation by both ends of a valid bidirectional
transmission.  As soon as the handshake completed, timers should be
set long enough to also allow for short idle time during a valid
transmission.
Paragraph (version B):
Even though QUIC has explicitly been designed tolerate NAT
rebindings, decreasing the NAT timeout is not recommended, as it may
negatively impact application performance or incentivize endpoints to
send very frequent keep-alive packets.  Instead it is recommended,
even when lower timers are used for other UDP traffic, to use a timer
of at least two minutes for QUIC traffic.
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 unnecessary
long delays in an otherwise working connection.
Paragraph (version B):
Furthermore, not all endpoints use routing architectures where
connections will survive a port or address change.  So even when the
client revives the connection, a NAT rebinding can cause a routing
mismatch where a packet is not even delivered to the server that
might support address migration.  For these reasons, the limits in
RFC4787 are important to avoid black-holing of packets (and hence
avoid interrupting the flow of data to the client), especially where
devices are able to distinguish QUIC traffic from other UDP payloads.
Paragraph (version A):
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 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 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):
Today, UDP is the most prevalent DDoS vector, since it is easy for
compromised non-admin applications to send a flood of large UDP
packets (while with TCP the attacker gets throttled by the congestion
controller) or to craft reflection and amplification attacks.
Networks should therefore be prepared for UDP flood attacks on ports
used for QUIC traffic.  One possible response to this threat is to
police UDP traffic on the network, allocating a fixed portion of the
network capacity to UDP and blocking UDP datagram over that cap.
Paragraph (version B):
In the case of networking architectures that include load balancers,
the connection ID can be used as 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):
Today, UDP is the most prevalent DDoS vector, since it is easy for
compromised non-admin applications to send a flood of large UDP
packets (while with TCP the attacker gets throttled by the congestion
controller) or to craft reflection and amplification attacks.  Some
networks therefore block UDP traffic.  With increased deployment of
QUIC, there is also an increased need to allow UDP traffic on ports
used for QUIC.  However, if UDP is generally enabled on these ports,
UDP flood attacks may also use the same ports.  One possible response
to this threat is to throttle UDP traffic on the network, allocating
a fixed portion of the network capacity to UDP and blocking UDP
datagrams over that cap.  As the portion of QUIC traffic compared to
TCP is also expected to increase over time, using such a limit is not
recommended but if done, limits might need to be adapted dynamically.
Paragraph (version B):
On-path observation of the transport headers of packets can be used
for various security functions.  For example, Denial of Service (DOS)
and Distributed DOS (DDOS) attacks against the infrastructure or
against an endpoint can be detected and mitigated by characterising
anomalous traffic.  Other uses include support for security audits
(e.g., verifying the compliance with ciphersuites); client and
application fingerprinting for inventory; and to provide alerts for
network intrusion detection and other next generation firewall
functions.
Paragraph (version B):
Current practices in detection and mitigation of DDoS attacks
generally involve classification of incoming traffic (as packets,
flows, or some other aggregate) into "good" (productive) and "bad"
(DDoS) traffic, and then differential treatment of this traffic to
forward only good traffic.  This operation is often done in a
separate specialized mitigation environment through which all traffic
is filtered; a generalized architecture for separation of concerns in
mitigation is given in DOTS-ARCH.
Paragraph (version B):
Efficient classification of this DDoS traffic in the mitigation
environment is key to the success of this approach.  Limited first-
packet garbage detection as in sec-garbage and stateful tracking of
QUIC traffic as in sec-stateful above may be useful during
classification.
Paragraph (version B):
Note that the use of a connection ID to support connection migration
renders 5-tuple based filtering insufficient to detect active flows
and requires more state to be maintained by DDoS defense systems if
support of migration of QUIC flows is desired.  For the common case
of NAT rebinding, where the client's address changes without the
client's intent or knowledge, DDoS defense systems can detect a
change in the client's endpoint address by linking flows based on the
server's connection IDs.  However, QUIC's linkability resistance
ensures that a deliberate connection migration is accompanied by a
change in the connection ID.  In this case, the connection ID can not
be used to distinguish valid, active traffic from new attack traffic.
Paragraph (version B):
Another potential method could use an on-path network device that
relies on pattern inferences in the traffic and heuristics or machine
learning instead of processing observed header information.
Paragraph (version B):
Beyond in-network DDoS protection mechanisms, TCP syncookies RFC4937
are a well-established method of mitigating some kinds of TCP DDoS
attacks.  QUIC Retry packets are the functional analogue to
syncookies, forcing clients to prove possession of their IP address
before committing server state.  However, there are safeguards in
QUIC against unsolicited injection of these packets by intermediaries
who do not have consent of the end server.  See QUIC_LB for standard
ways for intermediaries to send Retry packets on behalf of consenting
servers.
Paragraph (version A):
Special thanks to Martin Thomson and Martin Duke for the detailed
reviews and feedback.  Thanks also to Sean Turner and Mike Bishop for
their last call reviews.
Paragraph (version B):
Thanks to Thomas Fossati, Jana Iygengar, Marcus Ihlar for their early
reviews and feedback.  Special thanks also to Martin Thomson and
Martin Duke for their detailed reviews and input.  And thanks to Sean
Turner, Mike Bishop, Ian Swett, and Nick Banks for their last call
reviews.