Open gloinul opened 5 months ago
Yes it updates/changes this rule.
The rule in 8.1.1 is about distinguishing "real time" tokens created when sending a RETRY packet, and "long term" tokens send in NEW_TOKEN frames. The general expectation is that real time tokens are very short lived, but that NEW_TOKEN are valid longer. That's explained in section 8.1.3.
The NEW_TOKEN serve to attest that the client can legitimately send packets from a source IP address, and thus that address validation can be bypassed. This is generally done by linking the token to exactly one address, but there is no hard rule against linking to several IP addresses, as long as the server is convinced that the client can legitimately send packets from these IP addresses.
Okay, I guess the statement above is vague enough that there is actually no conflict with RFC9000 as it only says "identify how it was provided to a client". We now add to this requirement and say all IP addresses used by the client need to be validated. Or I guess if you can't validate all IP addresses that have been used before, resumption might simply fails from some addresses, which I guess is okay as well.
Two quick questions:
Do we want to change this text now that we have an explicit path ID and say that a token is valid for the address of that path only?
@huitema maybe the action here is to clarify that this paragraph talks about the long term address validation token that can be used for future connections. For such tokens, maybe the address valdidation token the server provides the client should contain all currently validated client addresses. So that the client actually can get a benefit from the address validation when establishing a new connection.
Section 4.1:
"To alleviate such a token ambiguity issue, a server may issue a token that is capable of validating any of the previously validated addresses."
isn't this against this normative rule in Section 8.1.1 of RFC 9000:
"A token sent in a NEW_TOKEN frame or a Retry packet MUST be constructed in a way that allows the server to identify how it was provided to a client. These tokens are carried in the same field but require different handling from servers."?