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

From: ianswett <[email-masked]>
Date: Tue, 21 Jul 2020 16:11:58 -0700

I believe this is already implied, but I couldn't find it stated anywhere.  I think it'd be ideal to set expectations that servers are not expected to validate multiple paths at the same time.

Validating multiple paths seems like a plausible feature for multipath, but adds undue complexity for connection migration.

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

---

From: Marten Seemann <[email-masked]>
Date: Tue, 21 Jul 2020 19:11:38 -0700

Does that imply that a client can only probe a single path at a time? What's the time it has to wait after apparent unsuccessful probing of one path until it can probe the next?

-- 
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-662200444

---

From: Kazuho Oku <[email-masked]>
Date: Tue, 21 Jul 2020 19:34:53 -0700

@ianswett I'm not sure if I agree. It has been my assumption that a server is expected to respond to clients probing multiple paths concurrently.

Note that in #3557, we added the following text:
> An endpoint MAY also limit the issuance of connection IDs to reduce the amount of  per-path state it maintains, such as path validation status, as its peer  might interact with it over as many paths as there are issued connection IDs.

-- 
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-662206628

---

From: Eric Kinnear <[email-masked]>
Date: Tue, 21 Jul 2020 19:34:56 -0700

Hmm, I didn't think this was already implied. You're not expected (or allowed) to send non-probing packets on multiple paths, but you can certainly get probes in from multiple different remote endpoints. This is somewhat necessary if we're to be resilient to the various packet racing attacks -- if an attacker can cause you to be upset about a packet coming in from a different destination then they can really mess you up.

-- 
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-662206640

---

From: ianswett <[email-masked]>
Date: Wed, 22 Jul 2020 04:07:34 -0700

I'm a bit confused about why a client needs to probe multiple paths simultaneously, given we have connection migration, not multipath.  To me, it just adds complexity.  I guess I can just give out a single CID to mitigate the issue, but do we really expect servers to correctly implement probing on multiple paths?  What if they all succeed?  A client can still only use one.

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

I'd like to draw a state transition diagram for path validation, but if we can have multiple paths being validated at once, I'm not sure that's practical.

-- 
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-662391821

---

From: ianswett <[email-masked]>
Date: Wed, 22 Jul 2020 04:19:59 -0700

@marten-seemann So the scenario is that a client is using one path and has 2 or more new ones available?  I've heard future hardware could make that possible, though I've never seen that case myself.

The short of this is now that we're trying to move to IETF QUIC style connection migration and path validation, and I'm finding it fairly confusing.

-- 
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-662396977

---

From: Eric Kinnear <[email-masked]>
Date: Sat, 25 Jul 2020 18:59:05 -0700

> 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

---

From: Kazuho Oku <[email-masked]>
Date: Sat, 25 Jul 2020 19:19:06 -0700

+1 to what @ekinnear says.

The resolution of #3489 (which ended up as PR #3557) was that a server has to remember state of N paths where N is the number of CIDs active at one time.

As @ekinnear says, a client cannot tell when a server *thinks* that it received two probes concurrently. Therefore, it is very tricky to have this kind of restriction within a specification that allows clients to retain multiple backup paths.

-- 
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-663926936

---

From: David Schinazi <[email-masked]>
Date: Sun, 26 Jul 2020 16:11:40 -0700

I agree with @erickinnear and @kazuho here. If a client sends a probe on interface A, and then interface A disconnects and then interface B appears immediately, the client should be able to probe on interface B even though to the server will receive two independent probes at roughly the same time. Servers need to be able to handle multiple concurrent probes in order for migration to be reliable.

-- 
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-664052496