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

From: Martin Thomson <[email-masked]>
Date: Mon, 01 Jan 2018 23:56:56 +0000 (UTC)

martinthomson commented on this pull request.

I found these old comments.  I haven't double-checked if they are still valid though.

I agree with Christian about the packet number gap, but I'd like to address that separately.

> +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 an assumption in the current design that connection IDs are used in series.  If a client wants to send on a new path, then it will want to use a new connection ID.  But it will then send on the original path, and that will need a different connection ID.  It can't use the original connection ID, or the one that it used on the path it was probing with the current design.

With the potential need for multiple probes on the new path, interleaved with continuing packets on the old path, this will consume far more connection IDs than our current design really allows for.  Or it will be linkable.

This is where I think packet number encryption/obfuscation will help.  It will allow us to switch back to the old connection ID without having to worry about gaps in packet numbers.  I think that we will need to fix that.

That doesn't make me think that this is a broken design, only that it reveals that our current design for unlinkability across paths is not suitable any more.

> @@ -2358,17 +2419,56 @@ Application Error Code:
   {{app-error-codes}}).

+## PATH_CHALLENGE Frame {#frame-path-challenge}
+
+Endpoints can use PATH_CHALLENGE frames (type=0x0e) to check reachability to the
+peer, to verify a new path's PMTU, and to perform address validation during
+connection migration.

Yeah, I think that the requirement for a minimum size on probes is a requirement on the probing packet, not a property of any particular frame that it contains.

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

Maybe look at it this way.  We have a certain dependency on the connection ID for path verification during the handshake and that is only 64 bits.  So, maybe we can reasonably say that 64 bits is enough here as well.

> +: This 8-bit value describes the length of the Data field.
+
+Data:
+
+: This variable-length field contains arbitrary data.
+
+
+The sender of this frame MUST include at least one octet of data in the Data
+field.
+
+The recipient of this frame MUST generate a PATH_RESPONSE frame
+({{frame-path-response}}) containing the same Data.  An endpoint that receives a
+PATH_CHALLENGE frame containing an empty payload MUST generate a connection
+error of type FRAME_ERROR, indicating the PATH_CHALLENGE frame (that is, 0x0e).
+
+A PATH_CHALLENGE frame MUST NOT elicit acknowledgements; the corresponding

But frames do elicit acknowledgments.  Generally.  ACK doesn't.  The "MUST NOT" isn't appropriate; it seems like the intent is to say that it doesn't elicit acknowledgment (that is, it's not an interoperability requirement, it's just a property).

I don't think that it makes sense to have special acknowledgment rules for PATH_CHALLENGE though.  Acknowledging PATH_CHALLENGE doesn't contribute to path validation, but on the other hand explicitly excluding it creates another exception.  I don't see any reason to suppress acknowledgments in this case.

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