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

[Martin Thomson <[e-mail]>]

martinthomson requested changes on this pull request.

Thanks for writing this up.  It's a pretty solid design overall (not nearly as prescriptive as ICE, which is good).  I think that there are a number of details that need more meat on them to support the new features that this adds.  I've tried to highlight them.

I also think that the structure of this is unfortunate.  I would prefer to see a generic description of path validation that is role-agnostic.  I realize that we do have a fundamentally asymmetric protocol and I'm not suggesting that this be perfectly symmetric, but this is unnecessarily asymmetric and the structure you have chosen has what appears to be errors in symmetry.  There are some generic requirements that are only in one or other of the client or server sections where they should (at least from my brief review) be shared.  Some of the differences seem like errors, but they could be intentional.  If there are intentional differences (like the fact that you have chosen to allow only clients to migrate here), then those asymmetries should be more explicit.

There needs to be a more explicit mention of NEW_CONNECTION_ID in relation to the client-initiated path probe.  If the client uses a new connection ID for that probe, what does that do to packet numbers on the existing path?  That could be a hard problem given the current design (this is something I hope to address with packet number obfuscation/encryption, so you might decide not to address that and instead leave a TODO for packet numbers).

Finally, I'm not quite done with reviewing this.  I want to do a gap analysis between this and STUN to see if this is a reasonable substitute (because you are effectively replicating STUN capabilities now, albeit in a more integrated and minimal fashion).

> -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 connections are identified by 64-bit connection IDs. QUIC's connection IDs
+allow connections to survive changes to the client's address (client's IP
+address and/or port), such as those caused by a client migrating to a new
+network or a NAT rebinding changing the client's public address.
+
+
+### Path Validation and PMTU Verification
+
+PATH_CHALLENGE ({{frame-path-challenge}}) and PATH_RESPONSE
+({{frame-path-response}}) frames MAY be used for validating that an endpoint
+owns an address, or to verify the PMTU to/from an address.

This section doesn't talk about verifying PMTU from.

> +
+A server validates a client's address by sending a PATH_CHALLENGE frame
+containing a payload that is hard to guess to that address.  The server
+considers the address to be valid when a PATH_RESPONSE frame containing the same
+payload is received from the client.
+
+Similarly, a client verifies the PMTU of a network path from a new client
+address to the server by sending a PMTU-sized packet carrying a PATH_CHALLENGE
+frame. The client considers the PMTU verified when a PATH_RESPONSE frame
+containing the same payload sent by the server to the new client address is
+received.
+
+
+### Client Behavior {#migration-client}
+
+A client triggers connection migration to a new address by sending a

I hope that this isn't a trigger for migration.  The path verification might be a prerequisite for a conscious migration by a client, but it's not what we should be using to trigger the switch on the server end.

> +can perform more accurate measurements by associating the server's response with
+the causative PATH_CHALLENGE.
+
+When the client receives a PATH_RESPONSE from the server and verifies that the
+included data matches the data it sent in a previous PATH_CHALLENGE, the server
+is considered reachable from the new address and the PMTU of the new network
+path is considered verified.
+
+A client SHOULD abandon the new address if it does not receive a PATH_RESPONSE
+after sending some number of PATH_CHALLENGE frames and/or after some time has
+passed. Note that the client may be receiving data from the server during this
+period, but not receiving a PATH_RESPONSE may be indicative of a PMTU detection
+failure.
+
+
+#### Responding to a Server's Validation

I would prefer that we talk about the different types of migration rather than have this talk about client and server behaviour separately.  Having this text here is hard to contextualize because it comes before any of the text about what might have happened to cause it to be necessary.

Also, I think that initiating and responding to validation is a generic thing that could be described independent of the different use cases/scenarios.

> +is considered reachable from the new address and the PMTU of the new network
+path is considered verified.
+
+A client SHOULD abandon the new address if it does not receive a PATH_RESPONSE
+after sending some number of PATH_CHALLENGE frames and/or after some time has
+passed. Note that the client may be receiving data from the server during this
+period, but not receiving a PATH_RESPONSE may be indicative of a PMTU detection
+failure.
+
+
+#### Responding to a Server's Validation
+
+A client may receive a PATH_CHALLENGE from a server that is validating the
+client's ownership of its address, as described in {{migration-server}}. The
+client MUST respond to this frame by echoing the data from the server's
+PATH_CHALLENGE frame in a PATH_RESPONSE frame.

This doesn't say what path the response follows.  It's important here to note that the client doesn't need to change its addressing info in any way when responding.

> +frame. The client considers the PMTU verified when a PATH_RESPONSE frame
+containing the same payload sent by the server to the new client address is
+received.
+
+
+### Client Behavior {#migration-client}
+
+A client triggers connection migration to a new address by sending a
+PATH_CHALLENGE as a probe or by switching to sending all packets to the new
+address. The client SHOULD do PMTU verification before considering migration
+complete. The client also participates in an address validation that the server
+may initiate to confirm the client's ownership of its address (see
+{{migration-server}}).
+
+A client migrating to a new network might use a new connection ID for packets
+sent from the new address, see {{migration-linkability}} for further discussion.

There's nothing here about the use of connection ID and packet numbers for the probes on the new path. 

> +but it MUST limit the rate at which data is sent to an unvalidated address, and
+it MUST limit the amount of time for which it sends data to an unvalidated
+address.
+
+
+#### Responding to a Client's Probe
+
+When a server receives a PATH_CHALLENGE frame from a client, it MUST generate a
+PATH_RESPONSE frame that contains the same data as the challenge. The server's
+PATH_RESPONSE MUST be sent to the address from which the client's PATH_CHALLENGE
+was received.
+
+The server sends the PATH_RESPONSE in a packet that is padded to no more than
+the size of the client's packet carrying the PATH_CHALLENGE.  The server SHOULD
+pad the packet to the same size as the client's packet, unless the server has
+reasonable assurance of a smaller PMTU.

Why does the server pad its PATH_RESPONSE, but the client does not?  Also, this smaller PMTU seems confusing, even if it isn't explicitly wrong.  We definitely need a 1200 in here somewhere.

> +A server MAY skip address validation for a client address that it considers to
+be already valid.
+
+After validating a client address, the server MAY send an updated address
+validation token to the client ({{address-validation}}).
+
+
+#### Committing to a New Address
+
+When a server receives a packet containing a frame other than PATH_CHALLENGE,
+PATH_RESPONSE, or PADDING from a client address with a packet number that is the
+largest seen thus far on the connection, the server "commits" to this client
+address. The server MUST send all subsequent packets to this address, with the
+following exception.  PATH_CHALLENGE, PATH_RESPONSE, and PADDING frames are used
+for probing a network path, and receiving only these frames MUST NOT cause the
+server to commit to a new address.

I think that this can be simpler.  Any packet containing PATH_CHALLENGE is ignored.

You do allow STREAM frames with that packet in earlier text (and STREAM frames aren't a terrible waste of octets, so I can imagine people using the bandwidth for that rather than padding, even if the probability of loss is that much greater).  But this text would cause the recipient to latch.

> +Before sending any other packets to a client address that is not yet considered
+valid, the server MUST send a PATH_CHALLENGE frame with its own validation data
+to this address to verify the client's ownership of it. The server's
+PATH_CHALLENGE MAY be bundled with other frames and does not require additional
+padding.
+
+When the server receives a PATH_RESPONSE from a client and verifies that the
+included data matches that sent by the server in a previous PATH_CHALLENGE to
+the client, the server considers the client address to which the corresponding
+PATH_CHALLENGE was sent as valid.
+
+A server MAY send additional PATH_CHALLENGE frames to handle packet loss,
+subject to the congestion controller's limits.
+
+A PATH_CHALLENGE frame used for validation MUST contain at least 12 randomly
+generated octets {{?RFC4086}}, making the payload sufficiently hard to guess.

This is a generic requirement, but you have it here in the server-specific section.

> +
+~~~
+ 0                   1                   2                   3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+|   Length(8)   |                 Data (*)                    ...
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+~~~
+
+Length:
+
+: This 8-bit value describes the length of the Data field.
+
+Data:
+
+: This variable-length field contains arbitrary data.

Can we make this a fixed length?

>  
-An endpoint that receives an unsolicited PONG frame - that is, a PONG frame
-containing a payload that is empty MUST generate a connection error of type
-FRAME_ERROR, indicating the PONG frame (that is, 0x10d).  If the content of a
-PONG frame does not match the content of a PING frame previously sent by the
-endpoint, the endpoint MAY generate a connection error of type UNSOLICITED_PONG.
+A PATH_RESPONSE frame MUST NOT elicit acknowledgements.

I don't think that this is a necessary requirement.  Given that it's the packet that generates the acknowledgments, that PADDING causes ACKs to be sent, and that this will never fill an entire packet, I think that you can drop this line.

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