Subject: [quicwg/base-drafts] Path Migration makes unjustified assumptions about a new path. (#2909)

From: Gorry Fairhurst <[email-masked]>
Date: Thu, 18 Jul 2019 06:25:13 -0700

This is awkward, because the issue of assumptions about the path appears spread over multiple places.

Section 9.4 of draft-ietf-quic-transport  :
   The capacity available on the new path might not be the same as the
   old path.  Packets sent on the old path SHOULD NOT contribute to
   congestion control or RTT estimation for the new path.
GF: That would be fine **IF** the new path were a separate CC context, which I am not yet clear whether it is, read on:
—
Section 9.4 of draft-ietf-quic-transport  :
   On confirming a peer's ownership of its new address, an endpoint
   SHOULD immediately reset the congestion controller and round-trip
   time estimator for the new path.
GF: Why not MUST? - because I think this is a new path, I think it can only be should if something can confirm this is the same set of network-devices and classifiers on the path. I don't know how you would know that, and I don't like the guess.
—
draft-ietf-quic-transport :
   For instance, a change in the client's port
   number is likely indicative of a rebinding in a middlebox and not a
   complete change in path. 
GF: So. maybe this is the guess, and I don't believe it! In a world of ECMP and other methods, this needs to be treated as a potential change of path.
—
Section 9.4 of draft-ietf-quic-transport:
   While multiple paths might be used during connection migration, a
   single congestion control context and a single loss recovery context
   (as described in [QUIC-RECOVERY]) may be adequate.  
GF: Well it could if the paths **WERE** known to be identical, but how would an endpoint guarantee that? Section 9.2 of QUIC transport seems to suggest the CC is reset for the new path, which I would agree with, but which part of QUIC recovery says that?
—
draft-ietf-quic-recovery:
   For instance, an
   endpoint might delay switching to a new congestion control context
   until it is confirmed that an old path is no longer needed (such as
   the case in Section 9.3.3).
GF:  This seems underspecified and novel to me. I think it may b quite OK to continue using the old path and the old CC, for a while. Same question: is this implying the two paths share a single CC and is there some real mechanism to detect that they are really the same set of network devices on path?

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

---

From: ianswett <[email-masked]>
Date: Sun, 21 Jul 2019 10:49:35 -0700

1) 
SHOULD NOT -> MUST NOT
Suggestion: "New paths have new congestion control contexts, implementations can reset the existing congestion control context."

2) 
In keeping with the first resolution, it's a new CC, and whether a new CC is created or the existing one is reset is an implementation decision.

3) 
Instead of saying it's the same path, say that the path parameters(RTT and CC state) are likely to be similar.

4) 
This is resolved with the resolution to 1, we can decide where the implementation note should live.

5) (In Section 9.4 of transport)
This is really "A path can be validated, but not switched to immediately, particularly in the presence of a potential attack.  When you switch, you need to use a new(or reset) congestion controller."

-- 
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/2909#issuecomment-513574181

---

From: Jana Iyengar <[email-masked]>
Date: Sun, 21 Jul 2019 10:57:00 -0700

For 5, we need to say a bit more about the fact that the attack is that when a sender receives data on a new path causing it to potentially reset its CC state immediately if it switches immediately.

-- 
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/2909#issuecomment-513574684

---

From: Eric Kinnear <[email-masked]>
Date: Sun, 21 Jul 2019 11:09:40 -0700

> In keeping with the first resolution, it's a new CC, and whether a new CC is created or the existing one is reset is an implementation decision.

I think this was always the intent -- some implementations don't want to have two CC contexts so they can reset it and start with zero assumptions about the new path. Implementations that are okay with having more than one will make a new one and use that on the new path, switching back to the old one if they use the old path and the information is still relevant (i.e. it's been <1 RTT and you decided the new path wasn't actually better -- pick some threshold I don't have a strong preference).

3: 
Yes, it's not necessarily exactly the same path. An endpoint that wants to put in extra effort in determining which paths are equivalent to make a smarter decision can do so while the default behavior is a complete reset every time (after confirming the migration). This also impacts (5) around some of the attacks. 

5: 
I agree with @janaiyengar we should be a bit more explicit about preventing an off-path attacker from being able to cause continuous resets as you go back and forth between paths, that's a good case where you would want to keep CC state around (if you're being told to swap multiple times per-RTT you've got other issues, too, which are mostly addressed but might need some more text, likely in transport).

-- 
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/2909#issuecomment-513575528