Re: [quicwg/base-drafts] Server's preferred address (#1251)

[Martin Thomson <[e-mail]>]

martinthomson requested changes on this pull request.

This needs working group review and feedback.  Especially the part where support of this feature is mandatory.  We need consensus that forcing clients to do this is a good thing.

(For the record, I don't think that the changes needed are big, but I'll request changes until it's clear that there is consensus to adopt the change.)

> @@ -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;

Please be consistent about snake_case and camelCase.

> @@ -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>;

To be clear, this only works if the server chooses to use a connection ID.

> @@ -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.

Can we make this change in a separate PR?

> +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

drop "during the connection", it's redundant with "after the handshake"

> +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.

I think that this is problematic.  Managing two migrations concurrently is just hard.  Though your stated design works (effectively trialing all three new paths), it's unnecessarily complicated.

I would revise the client migration and forbid it (or state that it isn't going to work) until the server has finished its migration.  That is, the client has to wait until after the server's migration occurs.  The odds that a client is forced to migrate in this period is low enough that starting over might be better than taking on the combinatorial mess.  That way leads to ICE.

> +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

A potential problem here is that the client concludes that the handshake is finished before the server does.  That leads to retransmissions of the client Finished getting confused.  I can't see any concrete issues (other than the ones we already have), but you should convince yourself that it's OK.

> +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.

This could be clearer: the server probes toward the client when?  After receiving a probe (no?), or after receiving non-probing packets (yes?).

> @@ -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}

I don't think that we should make this "client" connection migration.  This is the generic description, and the addition you made below is just a special case for the server that can be initiated during the handshake.

> @@ -1791,6 +1811,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}

I like (and prefer) the suggested name change.

When you say that not changing network attachment is a necessary assumption, why is that important?  The new address will be validated and congestion control rebooted in the same way that any other migration would be.  So even if this points to a completely different server instance (with keys being shipped across as needed), it still works.

> +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

This feature is only effective if it can be relied upon.  That said, it's a big deal, so we should talk about it.

-- 
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/1251#pullrequestreview-107519251