Re: [quicwg/base-drafts] Servers are not expected to validate multiple paths simultaneously (#3932)

[Eric Kinnear <[e-mail]>]

> I'm a bit confused about why a client needs to probe multiple paths simultaneously, given we have connection migration, not multipath.

I think there's a pretty big distinction between probing a path to establish the potential for connectivity and migrating the connection to that path. For example, I would not be at all surprised if a client were to probe all available paths and choose the "best" one to migrate to when the need arises (often, although not always, there is some warning that conditions are worsening on the current path which provides the opportunity to evaluate alternatives).

> What if they all succeed? A client can still only use one.

That said, I think a large part of the reason to allow probing on multiple paths is to avoid requiring synchronization of a shared understanding as to the state of current probes. We don't want to add a bunch of machinery to establish _failure_ of a probe on a different path. So even if we don't think that a client would ever _intentionally_ probe multiple paths, if a client probes one path and hears no response, it seems completely reasonable to think that it would switch and probe a different path if it had one available. If it turns out that there was just some delay for that initial path, say it had a 1.5s RTT, now the server is going to think the client probed two paths at the same time, when in reality the client thinks it's just talking to one.

It also doesn't seem particularly harmful to allow this?

As @kazuho noted, there's some good text in there about limiting state required on the server, and of course path validation can happen at any time, so it seems completely reasonable to "forget" that any given path was validated if a client probes and then doesn't end up using the path. (Note that you'd likely want to retire the CID used on that path, so as to replace it with a new one when you did that forgetting, which also serves as a nice heuristic for the other endpoint to say "oh, hmm, they don't think they're talking to me over there", but we can dig into that later.)

> @ekinnear can you clarify the packet racing issue a bit more or point me to text that already does?

The packet racing thing is a reference to [9.3.3](https://quicwg.org/base-drafts/draft-ietf-quic-transport.html#section-9.3.3) and the previous section. This led us to require endpoints to validate both the current and the new path when it changes, which conveniently provokes some traffic to reconfirm the active path and makes it more difficult to disrupt a connection that's gone idle.

```
In response to an apparent migration, endpoints MUST validate the previously active 
path using a PATH_CHALLENGE frame. This induces the sending of new packets on 
that path. If the path is no longer viable, the validation attempt will time out and fail;
if the path is viable, but no longer desired, the validation will succeed, but only
results in probing packets being sent on the path.

An endpoint that receives a PATH_CHALLENGE on an active path SHOULD send a 
non-probing packet in response. If the non-probing packet arrives before any copy 
made by an attacker, this results in the connection being migrated back to the original 
path. Any subsequent migration to another path restarts this entire process.
```

While technically this is only discussing one "new" path and then the old path being validated at the same time, it seems as though it would be trivial for such an attacker to convince an endpoint that it was seeing "probes" (since we've discussed that it's not that difficult to identify a probing packet as an observer) from multiple paths and therefore be quite upset if such behavior were restricted.

> future hardware could make that possible

I'm not saying this happens all the time, but it seems pretty reasonable to have a Wi-Fi interface and then a dual SIM device with multiple cellular interfaces.

Overall, it seems as though (even if this isn't crazy common) it's not unreasonable to expect that this behavior might happen, and it doesn't seem like there's a big benefit to restricting it, nor harm in allowing it, beyond the existing text reminding endpoints to be careful with the amount of state they're willing to allocate to any individual client (which is a thing outside of any probing/migration concept anyways).

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/3932#issuecomment-663925866