Recommendation on token ambiguity issue is violating RFC 9000

[gloinul]

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."?

[mirjak]

Yes it updates/changes this rule.

[huitema]

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.

[mirjak]

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:

1. Not sure anymore if we need to say more. Do we? What?
2. Should the sentence also use normative language?