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

[ekr <[e-mail]>]

ekr commented on this pull request.



> @@ -1814,10 +1814,13 @@ 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

I agree with @kazuho: suppose that one has a scheme where you store tokens, then the token wouldn't contain this information. Isn't the requirement here that the token be *bound* to an IP.

> @@ -1814,10 +1814,13 @@ 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 MUST ensure that
+replay of tokens is prevented or limited.  For instance, servers might limit the
+time over which a token is accepted.  Tokens sent in NEW_TOKEN frames MAY omit
+the client port and allow for use over a longer period.  Tokens MAY include
+additional information about clients to further narrow applicability or reuse.

This is actually a pretty confusing situation that the document sees to handle badly.

Suppose that a client connects with address 1.2.3.4 and the server issues a NEW_TOKEN with address 1.2.3.4. When the client comes back it has 5.6.7.8. The server might accept the token for purposes of anti-DoS (e.g., it might otherwise send Retry), but should not accept it for the purposes of exempting the client from the anti-amplification limits. 

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