search

quicwg / multipath

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

PATH_CHALLENGE as an explicit signal in path initialization. #261

Closed yfmascgy closed 2 months ago

yfmascgy commented 1 year ago

I think this issue repeats some of discussions we had earlier regarding using path_challenge as an explicit signal during a path creation. The inclusion of a client initiated path_challenge frame helps differentiate a path creation from a simultaneous NAT rebinding and CID rotation.

My question is do we want to state such a role of path_challenge more explicitly in this draft? I find people may still be confused about that, and such a sentence could clarify things a lot. Currently, in our implementation, yes, we use PATH_CHALLENGE as an explicit signal when creating a new path. The logic on the server is to first process a path_challenge_frame and if the server does not find a path associated with the in-coming packet's dcid, then try to create a new path and validate the client's address.

huitema commented 1 year ago

I don't think we should change the meaning of "path challenge" -- it has other use than path initialization. But I also think that we have an issue about the default state of paths. It would be nice to add a recommendation to bundle a "path status" with the "path challenge" when the client is probing a new path, so the peer knows whether the intended status is "standby" or "available".

huitema commented 1 year ago

We also have the related issue #188: packets that arrive on a new path and do not contain a PATH CHALLENGE frame.

mirjak commented 10 months ago

I don't think we should change the meaning of "path challenge" -- it has other use than path initialization. But I also think that we have an issue about the default state of paths. It would be nice to add a recommendation to bundle a "path status" with the "path challenge" when the client is probing a new path, so the peer knows whether the intended status is "standby" or "available".

@huitema this part is addresses now with PR #277

@yfmascgy is there anything else we want to do here or can we close this issue?

michael-eriksson commented 10 months ago

As proposed in #180, path setup should be really explicit and not just some overloaded semantics of the PATH_CHALLENGE frame. A PATH_SETUP frame can't be misunderstood and would include all necessary information, including the initial path status.

mirjak commented 10 months ago

Can we close this issue?

mirjak commented 2 months ago

With PR #277 and the explicit path ID that makes it more clear when a new path is initiated, I think this issue is addressed. Closing it now. Please open a new issue if anything else needed to be considered!