Re: [quicwg/base-drafts] What needs to be checked for address validation (#3327)

[Martin Thomson <[e-mail]>]

martinthomson commented on this pull request.



> @@ -1829,10 +1829,21 @@ tokens that would be accepted by the server.  Only the server requires access to
 the integrity protection key for tokens.
 
 There is no need for a single well-defined format for the token because the
-server that generates the token also consumes it.  A token could include
-information about the claimed client address (IP and port), a timestamp, and any
-other supplementary information the server will need to validate the token in
-the future.
+server that generates the token also consumes it.  Tokens sent in Retry packets
+SHOULD include information that allows the server to verify that the source IP
+address and port in client packets remains constant.
+
+Servers might use tokens from NEW_TOKEN in deciding not to send a Retry packet,
+even if the client address has changed.  A token that was provided in
+NEW_TOKEN cannot be used for address validation if the client address is not the
+same, though servers MAY allow for the possibility of changes arising from new
+mappings at a NAT.

I think that new mappings at a NAT are all I really want to allow for here, recognizing that this is likely indistinguishable from a new address from SLAAC or a DHCP lease.

We shouldn't really want a server to spray packets at unwitting hosts within the network just because another one of those hosts has a valid token, more so for large carrier-grade NATs.  But nor can we realistically prevent that, so this needs to be a little squishy.

-- 
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/3327#discussion_r377995957