diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index d174b64393..58832506af 100644 --- a/draft-ietf-quic-transport.md +++ b/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