First pass at server preferred address

draft-ietf-quic-transport.md

@@ -717,8 +717,9 @@ A Version Negotiation ({{packet-version}}) packet MUST use both connection IDs
 selected by the client, swapped to ensure correct routing toward the client.
 
 The connection ID could change over the lifetime of a connection, especially in
-response to connection migration ({{migration}}). NEW_CONNECTION_ID frames
-({{frame-new-connection-id}}) are used to provide new connection ID values.
+response to connection migration ({{migration-client}}}). NEW_CONNECTION_ID
+frames ({{frame-new-connection-id}}) are used to provide new connection ID
+values.
 
 ## Packet Numbers {#packet-numbers}
 
@@ -858,8 +859,8 @@ connection establishment intertwines version negotiation with the cryptographic
 and transport handshakes to reduce connection establishment latency, as
 described in {{handshake}}.  Once established, a connection may migrate to a
 different IP or port at either endpoint, due to NAT rebinding or mobility, as
-described in {{migration}}.  Finally a connection may be terminated by either
-endpoint, as described in {{termination}}.
+described in {{migration-client}}}.  Finally a connection may be terminated by
+either endpoint, as described in {{termination}}.
 
 ## Matching Packets to Connections {#packet-handling}
 
@@ -1082,6 +1083,7 @@ language from Section 3 of {{!I-D.ietf-tls-tls13}}.
       initial_max_data(1),
       initial_max_stream_id_bidi(2),
       idle_timeout(3),
+      preferred_address(4),
       max_packet_size(5),
       stateless_reset_token(6),
       ack_delay_exponent(7),
@@ -1105,6 +1107,14 @@ language from Section 3 of {{!I-D.ietf-tls-tls13}}.
       };
       TransportParameter parameters<22..2^16-1>;
    } TransportParameters;
+
+   struct {
+     enum { IPv4(4), IPv6(6), (15)} ip_version;
+     opaque ip_address<4..2^8-1>;
+     uint16 port;
+     opaque connectionId<4..18>;
+     opaque statelessResetToken[16];
+   } PreferredAddress;
 ~~~
 {: #figure-transport-parameters title="Definition of TransportParameters"}
 
@@ -1204,9 +1214,14 @@ stateless_reset_token (0x0006):
 : The Stateless Reset Token is used in verifying a stateless reset, see
   {{stateless-reset}}.  This parameter is a sequence of 16 octets.
 
-A client MUST NOT include a stateless reset token.  A server MUST treat receipt
-of a stateless_reset_token transport parameter as a connection error of type
-TRANSPORT_PARAMETER_ERROR.
+preferred_address (0x0004):
+
+: The server's Preferred Address is used to effect a server address migration at
+  the end of the handshake, as described in {{migration-server}}.
+
+A client MUST NOT include a stateless reset token or a preferred address.  A
+server MUST treat receipt of either transport parameter as a connection error of
+type TRANSPORT_PARAMETER_ERROR.
 
 
 ### Values of Transport Parameters for 0-RTT {#zerortt-parameters}
@@ -1237,6 +1252,10 @@ Omitting or setting a zero value for certain transport parameters can result in
 SHOULD be set to non-zero values for 0-RTT: initial_max_stream_id_bidi,
 initial_max_stream_id_uni, initial_max_data, initial_max_stream_data.
 
+The value of the server's previous preferred_address MUST NOT be used when
+establishing a new connection; rather, the client should wait to observe the
+server's new preferred_address value in the handshake.
+
 A server MUST reject 0-RTT data or even abort a handshake if the implied values
 for transport parameters cannot be supported.
 
@@ -1427,9 +1446,10 @@ therefore unlikely to be successful.
 This token can be provided to the cryptographic handshake immediately after
 establishing a connection.  QUIC might also generate an updated token if
 significant time passes or the client address changes for any reason (see
-{{migration}}).  The cryptographic handshake is responsible for providing the
-client with the token.  In TLS the token is included in the ticket that is used
-for resumption and 0-RTT, which is carried in a NewSessionTicket message.
+{{migration-client}}}).  The cryptographic handshake is responsible for
+providing the client with the token.  In TLS the token is included in the ticket
+that is used for resumption and 0-RTT, which is carried in a NewSessionTicket
+message.
 
 
 ### Address Validation Token Integrity {#token-integrity}
@@ -1462,12 +1482,12 @@ and a specific peer address, where an address is the two-tuple of IP address and
 port.  Path validation tests that packets can be both sent to and received from
 a peer.
 
-Path validation is used during connection migration (see {{migration}}) by the
-migrating endpoint to verify reachability of a peer from a new local address.
-Path validation is also used by the peer to verify that the migrating endpoint
-is able to receive packets sent to the its new address.  That is, that the
-packets received from the migrating endpoint do not carry a spoofed source
-address.
+Path validation is used during connection migration (see {{migration-client}}
+and {{migration-server}}) by the migrating endpoint to verify reachability of a
+peer from a new local address. Path validation is also used by the peer to
+verify that the migrating endpoint is able to receive packets sent to the its
+new address.  That is, that the packets received from the migrating endpoint do
+not carry a spoofed source address.
 
 Path validation can be used at any time by either endpoint.  For instance, an
 endpoint might check that a peer is still in possession of its address after a
@@ -1485,6 +1505,11 @@ path validation with other frames.  For instance, an endpoint may pad a packet
 carrying a PATH_CHALLENGE for PMTU discovery, or an endpoint may bundle a
 PATH_RESPONSE with its own PATH_CHALLENGE.
 
+Differences in routing on the Internet might cause the same destination address
+and connection ID to reach a different server instance which does not posses the
+necessary connection state. Receiving a Stateless Reset in response to a probing
+packet SHOULD NOT terminate the connection, but MUST cause the endpoint to
+consider path validation to have failed.
 
 ### Initiation
 
@@ -1558,7 +1583,7 @@ failure. Primarily, this happens if a connection migration to a new path is
 initiated while a path validation on the old path is in progress.
 
 
-## Connection Migration {#migration}
+## Client Connection Migration {#migration-client}
 
 QUIC allows connections to survive changes to endpoint addresses (that is, IP
 address and/or port), such as those caused by a endpoint migrating to a new
@@ -1568,11 +1593,6 @@ new address.
 An endpoint MUST NOT initiate connection migration before the handshake is
 finished and the endpoint has 1-RTT keys.
 
-This document limits migration of connections to new client addresses.
-Migrating a connection to a new server address is left for future work. If a
-client receives packets from a new server address, the client MAY discard these
-packets.
-
 
 ### Probing a New Path
 
@@ -1792,6 +1812,64 @@ number. "packet_number_secret" is derived from the TLS key exchange,
 as described in Section 5.6 of {{QUIC-TLS}}.
 
 
+## Server Connection Migration {#migration-server}
+
+QUIC allows servers to accept connections on one IP address and attempt to
+transfer these connections to a more preferred address shortly after the
+handshake.  This section describes the protocol for migrating a connection to a
+new server address.
+
+Migrating a connection to a new server address mid-connection is left for future
+work. If a client receives packets from a new server address not indicated by
+the preferred_address transport parameter, the client SHOULD discard these
+packets.
+
+### Initiating Connection Migration
+
+A server initiates connection migration by including the preferred_address
+transport parameter in the TLS handshake.
+
+Once the handshake is finished, the client MUST initiate path validation (see
+{{migrate-validate}}) of the server's preferred IP address using the connection
+ID provided in the preferred_address transport parameter.
+
+If path validation succeeds, the client SHOULD immediately begin sending all
+non-probe packets to the new server address using the new connection ID and
+discontinue use of the old server address.  If path validation fails, the client
+MUST continue sending all future packets to the server's original IP address.
+
+### Responding to Connection Migration
+
+A server might receive a packet addressed to its preferred IP address at any
+time during the connection after the handshake is completed.  If this packet
+contains a PATH_CHALLENGE frame, the server sends a PATH_RESPONSE frame as per
+{{migrate-validate}}, but the server MUST continue sending all other packets
+from its original IP address.
+
+Once the server has received a non-probing packet on its preferred address which
+is the largest packet number seen so far, the server begins sending to the
+client exclusively from its preferred IP address.
+
+
+## Interaction of Client and Server Migration
+
+A client might need to perform a connection migration before the server's
+connection migration has completed.  In this case, the client SHOULD perform
+path validation to both the original and preferred server address from the
+client's new address concurrently.
+
+If path validation of the server's preferred address succeeds, the client MUST
+abandon validation of the original address and migrate to using the server's
+preferred address.  If path validation of the server's preferred address fails,
+but validation of the server's original address succeeds, the client MAY migrate
+to using the original address from the client's new address.
+
+If the connection to the server's preferred address is not from the same client
+address, the server MUST protect against potential attacks as described in
+{{address-spoofing}} and {{on-path-spoofing}}.  In addition to intentional
+simultaneous migration, this might also occur because the client's access
+network used a different NAT binding for the server's preferred address.
+
 ## Connection Termination {#termination}
 
 Connections should remain open until they become idle for a pre-negotiated
@@ -1856,11 +1934,11 @@ draining.  A key update might prevent the endpoint from moving from the closing
 state to draining, but it otherwise has no impact.
 
 An endpoint could receive packets from a new source address, indicating a client
-connection migration ({{migration}}), while in the closing period. An endpoint
-in the closing state MUST strictly limit the number of packets it sends to this
-new address until the address is validated (see {{migrate-validate}}). A server
-in the closing state MAY instead choose to discard packets received from a new
-source address.
+connection migration ({{migration-client}}}), while in the closing period. An
+endpoint in the closing state MUST strictly limit the number of packets it sends
+to this new address until the address is validated (see {{migrate-validate}}). A
+server in the closing state MAY instead choose to discard packets received from
+a new source address.
 
 
 ### Idle Timeout