Re: [quicwg/base-drafts] A more complete connection migration (#1012)

[janaiyengar <[e-mail]>]

janaiyengar commented on this pull request.

Thanks folks, I've addressed comments this far. PTAL.
Ian -- happy to add a state machine, which I think is a great idea. But if we can agree on the mechanism, I'd like to consider that a next step and do it after we've got the mechanism in the draft first.

> @@ -1477,35 +1481,236 @@ connection if the integrity check fails with a PROTOCOL_VIOLATION error code.
 
 ## Connection Migration {#migration}
 
-QUIC connections are identified by their 64-bit Connection ID.  QUIC's
-consistent connection ID allows connections to survive changes to the client's
-IP and/or port, such as those caused by client or server migrating to a new
-network.  Connection migration allows a client to retain any shared state with a
-connection when they move networks.  This includes state that can be hard to
-recover such as outstanding requests, which might otherwise be lost with no easy
-way to retry them.
+QUIC allows connections to survive changes to endpoint addresses (that is, IP
+address and/or port), such as those caused by a client migrating to a new
+network.  This section describes the protocol for migrating a connection to a
+new client address.
+
+Migrating a connection to a new server address is left for future work. If a
+client receives packets from a new server address that are decryptable, the
+client MAY discard these packets.

Fair enough, changed text.

> +sent, path validation is considered to have failed, even if the data matches
+that sent in the PATH_CHALLENGE.
+
+The PATH_RESPONSE frame MUST be received on the same local address from which
+the corresponding PATH_CHALLENGE was sent.  If a PATH_RESPONSE frame is received
+on a different local address than the one from which the PATH_CHALLENGE was
+sent, path validation is considered to have failed, even if the data matches
+that sent in the PATH_CHALLENGE.
+
+Thus, the endpoint considers the path to be valid when a PATH_RESPONSE frame is
+received on the same path with the same payload as the PATH_CHALLENGE frame.
+
+The endpoint MAY send additional PATH_CHALLENGE frames to handle packet loss,
+but is subject to the following limit to avoid excessive network load: an
+endpoint SHOULD NOT send more than one PATH_CHALLENGE frame in 200ms.  This
+limit is approximately equivalent to the network load due to a new connection,

There's no timer prescribed, which I'd like to avoid prescribing, so exponential backoff is a step after that. I was trying to avoid specifying exactly what the sender should do to detect loss of these packets,  but put a safe cap on network load.

> +
+The PATH_RESPONSE frame MUST be received on the same local address from which
+the corresponding PATH_CHALLENGE was sent.  If a PATH_RESPONSE frame is received
+on a different local address than the one from which the PATH_CHALLENGE was
+sent, path validation is considered to have failed, even if the data matches
+that sent in the PATH_CHALLENGE.
+
+Thus, the endpoint considers the path to be valid when a PATH_RESPONSE frame is
+received on the same path with the same payload as the PATH_CHALLENGE frame.
+
+The endpoint MAY send additional PATH_CHALLENGE frames to handle packet loss,
+but is subject to the following limit to avoid excessive network load: an
+endpoint SHOULD NOT send more than one PATH_CHALLENGE frame in 200ms.  This
+limit is approximately equivalent to the network load due to a new connection,
+and is based on the initial Handshake Timeout defined in {{QUIC-RECOVERY}}.
+

200ms is the default recommended in the recovery draft for new connections. Since this is a new path, there's no info available about this path, hence I'm using the default.

> +
+An endpoint MAY bundle PATH_CHALLENGE and PATH_RESPONSE frames with other
+frames, as appropriate.  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.
+
+
+### Initiating Connection Migration {#initiating-migration}
+
+A client MAY initiate connection migration to a new local address in one of two
+ways.
+
+The client may immediately migrate the connection by sending all packets from
+the new local address.  Receiving acknowledgments for this data serves as proof
+of the server's reachability from the new address.
+

PATH_CHALLENGE/PATH_RESPONSE is used for reachability tests, to ensure that the reverse path works fine, before migrating data. Sending Data is a bit more aggressive, where the sender is "committing" to the new path without testing it. That said, you raise a good point. I've changed some text here.

> +
+The client may immediately migrate the connection by sending all packets from
+the new local address.  Receiving acknowledgments for this data serves as proof
+of the server's reachability from the new address.
+
+Alternatively, the client may probe for server reachability from the new local
+address first using path validation {{migrate-validate}} and migrate the
+connection to the new address at a later time.  Failure of path validation
+simply means that the new local address is not usable for this connection and
+should not be fatal to the connection when alternative local addresses are
+available.
+
+A client migrating to a new local address SHOULD use a new connection ID for
+packets sent from that address, see {{migration-linkability}} for further
+discussion.
+

I think this is adequate for now. The section on migration linkability has the real normative text anyways.

>  
-An endpoint MUST validate that its peer can receive packets at the new address
-before sending any significant quantity of data to that address, or it risks
-being used for denial of service.  See {{migrate-validate}} for details.
+It is possible that the client is spoofing its source address to cause the
+server to send excessive amounts of data to an unwilling host.  If the server
+sends significantly more data than the client, connection migration might be
+used to amplify the volume of data that an attacker can generate toward a
+victim.
+
+Thus, on receiving and decrypting a packet from an unvalidated address, the
+server MUST immediately validate the client's new address to confirm the
+client's possession of the new address.
+
+Until a client's address is deemed valid, the server MUST limit the rate at
+which it sends data to this address.  The server MUST NOT send more than 4 * MSS

It's a bit arbitrary, but I was shooting for something > min cwnd. Honestly, any number SGTM. Do you prefer min cwnd? 

I assumed the initial RTO period implied a default if path RTT was unknown. Happy to clarify if you think it's not clear.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/1012#pullrequestreview-98003702