Should NEW_TOKEN frames be scoped per path?

[marten-seemann]

RFC 9000 Section 9.3 says that the server should send new address validation token (in NEW_TOKEN frames) after a successful migration event. When resuming a connection, this allows the client to pick the token associated with the correct path.

This doesn’t work any more in multipath, as it’s not clear which path a token is associated with. While we could define that NEW_TOKEN frames are associated with the path they’re sent on, the general design principle of this document suggests to be explicit about it - i.e. add the path information to the frame itself.

Either way, the document should probably provide some guidance regarding address validation tokens.

[yfmascgy]

RFC9000 specifies that "Tokens sent in NEW_TOKEN frames MUST include information that allows the server to verify that the client IP address has not changed from when the token was issued." Thus, my understanding is that the token should be associated with the interface (or a client's IP address) rather than the path (or 4-tuple).

[kazuho]

Regarding the issue, during the development of QUIC v1 I recall we discussed that endpoints can include in one token the information to validate multiple addresses (e.g., one cellular and one Wifi).

What is stored in a token is up to each implementation, maybe all we need to do is state that endpoints may want to do so and call it a day.

[marten-seemann]

That’s neat, I like this approach. We should definitely add some text, but we don’t need any protocol changes.

[huitema]

We can indeed leave it to the application, but there is still an issue of signalling. The token is tied to a source IP address. The server will verify that the source IP address of the incoming client-hello matches the source address programmed in the token. But the NEW_TOKEN frame does not convey that IP address. The client implementations have to guess which of their IP address that is. In RFC9000 implementations, the client will typically assume that the token is linked to the IP address used during the handshake.

The tempting solution is to defined a "better" new token frame that carries the IP address verified by the server, but I would rather not try to define that as part of the multipath extension. The issue also arise in basic RFC9000 after NAT rebinding or after path migration, which indicates we would be better of with a focused "better new token" extension, independent of multipath.

I am also concerned that doing this "better new token" correctly assumes that the client knows which IP address it is using. For clients behind NAT, that's not obvious. Adding ways to learn that smells a lot like dipping into peer-to-peer support, which definitely seems out of scope for the multipath draft.

For now, we might simply note the issue and that the token is tied to the client IP address used during the handshake. That's a limitation, but that's the same limitation as RFC9000.

[mirjak]

Let's explain and add a ref to RFC9000

[kazuho]

@huitema

In RFC9000 implementations, the client will typically assume that the token is linked to the IP address used during the handshake.

I'm not sure if that is the case. As @marten-seemann pointed out, Section 9.3 of RFC 9000 states quote: After verifying a new client address, the server SHOULD send new address validation tokens (Section 8) to the client.

Therefore, the expectation that v1 clients have is that the token being issued is for the last active path that it used.

But in Multipath, we have more than one active path, there becomes an ambiguity regarding for to which one of the active paths is the token bound.

Fortunately, as stated in my last comment, there is nothing that prevents servers from issuing tokens carrying validation information for multiple paths.

Hence the proposal to document this as an implementation advice and proceed.

[huitema]

@kazuho Yes, you are right about the handling of migration in RFC 9000. Picoquic does not do that, because I like to keep things simple.

I like your suggestion that if servers want to handle that, they can handle multi-address tokens. But that is still ambiguous for the client. The client maintains a store of tokens indexed by source address. If a token validates multiple addresses, how does the client know which ones? How does the client chose the token to use for the next connection?

[kazuho]

@huitema I think that clients typically do not remember their source address. That's something that cannot be done easily in presence of NATs.

I think the assumption we have is that clients retain tokens by their server names. FWIW, it's not even the server address; quoting from RFC 9000 section 21.5.2, _clients could avoid using NEWTOKEN if the server address changes (emphasis mine).

[huitema]

That's one of the reasons why I would rather keep it simple, just acknowledge the problem, and defer the solution to another extension...

[yfmascgy]

Try to fix the issue in PR #260.

[mirjak]

PR #280 was merged but we forgot to close this issue. Closing it now.