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

[Martin Thomson <[e-mail]>]

martinthomson commented on this pull request.



> +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 the most recent Initial packet it sent, clients MUST discard
+the packet.  This prevents an off-path attacker from injecting a Retry packet.
+
+The client responds to a Retry packet with an 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 a 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.  Consequently, a valid Retry

@nibanks, I think that the idea was to give the server better control over where to send subsequent Retry packets.  That is, it can choose a value that is better for load, DoS prevention, or whatever it needs.  The server can use the token to validate that the value was its own choice as well, removing concerns about the client stacking load on certain servers.

(I thought that this was one of your design constraints, but I realize now I don't know where that idea came from.)

-- 
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#discussion_r205999174