search

quicwg / multipath

In-progress version of draft-ietf-quic-multipath
Other
49 stars 17 forks source link

Recommendation on token ambiguity issue is violating RFC 9000 #303

Open gloinul opened 5 months ago

gloinul commented 5 months ago

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 commented 5 months ago

Yes it updates/changes this rule.

huitema commented 5 months ago

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 commented 3 months ago

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?
mirjak commented 1 month ago

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?

gloinul commented 1 month ago

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