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

[Kazuho Oku <[e-mail]>]

kazuho commented on this pull request.

As pointed out in the inline comments, I am concerned that the proposed changes might be confusing.

As this section is about integrity protection, I think it might be better to delegate the discussion regarding how the server should use each type of tokens to the dedicated sections, namely [section 8.1.2 (Address Validation using Retry Packets)](https://quicwg.org/base-drafts/draft-ietf-quic-transport.html#section-8.1.2), and [section 8.1.3 (Address Validation for Future Connections)](https://quicwg.org/base-drafts/draft-ietf-quic-transport.html#section-8.1.3).

FWIW, we already state in section 8.1.3 that "validating the port is therefore unlikely to be successful", and that it "SHOULD have an expiration time." Therefore, the first sentence of this PR discussing NEW_TOKENS is redundant.

> @@ -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 am unsure if this SHOULD is necessary. As we suggest in the preceding paragraph, offloading state to client is just one way of implementing retries, the proposed text changes that to a recommendation.

If there is a need to better clarify the requirements on a server performing address validation, I think we should make changes to 8.1.2.

> @@ -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.

The last two sentences are bit confusing to me, as it can be read as if a server must check that client IP address matches the original IP address stored in the NEW_TOKEN token.

-- 
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#pullrequestreview-342509782