Re: [quicwg/base-drafts] Rework Retry packet (#1498)

[ekr <[e-mail]>]

ekr requested changes on this pull request.

IIRC, there was some resistance to having a token length, though I can't recall why.

> @@ -532,6 +532,82 @@ See {{version-negotiation}} for a description of the version negotiation
 process.
 
 
+## Retry Packet {#packet-retry}
+
+A Retry packet uses long headers with a type value of 0x7E. It carries an

The comment suggests that we shouldn't say it uses long headers.

> ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+|DCIL(4)|SCIL(4)|
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+|               Destination Connection ID (0/32..144)         ...
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+|                 Source Connection ID (0/32..144)            ...
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+|    ODCIL(8)   |      Original Destination Connection ID (*)   |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+|                        Retry Token (*)                      ...
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+~~~
+{: #retry-format title="Retry Packet"}
+
+A Retry packet (shown in {{retry-format}}) only uses part of the long packet
+header.  The contents of the Retry packet are not protected.  Like Version

I would say "The first X fields of a Retry packet are the same as the long header"

> +: An opaque token that the server can use to validate the client's address.
+
+The server populates the Destination Connection ID with the connection ID that
+the client included in the Source Connection ID of the Initial packet.
+
+The server includes a connection ID of its choice in the Source Connection ID
+field.  The client MUST use this connection ID in the Destination Connection ID
+of subsequent packets that it sends.
+
+A Retry packet does not include a packet number and cannot be explictly
+acknowledged by a client.
+
+A server MUST only send a Retry in response to a client Initial packet.
+
+If the Original Destination Connection ID field does not match the Destination
+Connection ID from most recent the Initial packet it sent, clients MUST discard

the most recent

> +
+A server MUST only send a Retry in response to a client Initial packet.
+
+If the Original Destination Connection ID field does not match the Destination
+Connection ID from most recent the Initial packet it sent, clients MUST discard
+the packet.  This prevents an off-path attacker from injecting a Retry packet
+with a bogus new Source Connection ID.
+
+The client responds to a Retry packet with Initial packet that includes the
+provided Retry Token to continue connection establishment.
+
+A server that might send another Retry packet in response to a subsequent
+Initial packet MUST set the Source Connection ID to new value of at least 8
+octets in length.  This allows clients to distinguish between Retry packets when
+the server sends multiple rounds of Retry packets.  A server that will not send
+additional Retry packets can set the Source Connection ID to any value.

I think you need to add that a client MUST reject a retry that contains an ODCID of less than 8 bytes.

>  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                            Token (*)                        ...
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+|                           Length (i)                        ...
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+|                     Packet Number (8/16/32)                   |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+|                          Payload (*)                        ...
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

I am assuming these haven't changed.

>  
-If the client has a suitable token available from a previous connection, it
-SHOULD populate the Token field.
+If the client has an unused token that it received in a NEW_TOKEN frame on a
+previous connection to what it believes to be the same server, it includes that
+value in the Token field of its Initial packet.

This seems oddly non-normative.

Also, I notice you have removed "suitable" but if you think you changed your IP then you probably shouldn;t.

-- 
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/1498#pullrequestreview-133068343