Subject: Re: [quicwg/base-drafts] CID change still required in response to migration? (#2778)

From: Martin Thomson <[email-masked]>
Date: Wed, 14 Aug 2019 19:35:43 -0700

In reviewing this, I think we've messed up badly.  We currently only mandate the use of a new connection ID for the initiator of a migration.  A peer that responds to a connection migration has to change a connection ID if the initiator changed their connection ID.  

> An endpoint MUST use a new connection ID if it initiates connection migration. Using a new connection ID eliminates the use of the connection ID for linking activity from the same connection on different networks.

That needs to be fixed promptly.  Then the concerns that @tatsuhiro-t raises here might seem less surprising.

@mnot, @larseggert, can we recategorize this as design?  Thanks.

-- 
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/2778#issuecomment-521491892

---

From: MikkelFJ <[email-masked]>
Date: Wed, 14 Aug 2019 22:50:32 -0700

> In reviewing this, I think we've messed up badly. We currently only mandate the use of a new connection ID for the initiator of a migration. A peer that responds to a connection migration has to ch…

This has been discussed at length and while I tend to agree that this is not a good design, I believe things ended up as they are due to concerns about endless CID change loops. I think that can be prevented without too much complexity, but that argument was one of the drivers, as I recall.

-- 
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/2778#issuecomment-521523040

---

From: Martin Thomson <[email-masked]>
Date: Wed, 14 Aug 2019 23:01:57 -0700

The problem was that we over-rotated.  Now we don't require any change on the responding endpoint's part, which means we have near-perfect linkability across migrations.  I think that the proposed change is the minimal one we can mandate.

I might prefer to have something slightly better, but doing that without also flirting with the infinite loop was too hard.

-- 
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/2778#issuecomment-521525415

---

From: Kazuho Oku <[email-masked]>
Date: Wed, 14 Aug 2019 23:51:38 -0700

Agreed. IIUC, the only endpoint that "initiates" a CID change is the client, because only the client side that migrates (or probes) a new path. This is the case for SPA too.

Therefore, I believe that stating something along the lines of the following is sufficient: a server MUST respond with a new CID to a packet that has been received on a new path with a new CID.

-- 
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/2778#issuecomment-521536111

---

From: Eric Kinnear <[email-masked]>
Date: Thu, 15 Aug 2019 11:21:06 -0700

I definitely agree that we should change this to require a change in response, it would be worth wordsmithing something that achieves this -- the PR is a good start. Differentiating by client/server might be interesting, although there appear to be two cases: 
1. A CID change on a link without any address change. 
2. A change in any part of address (IP/port)

We can talk about initiator/responder to migration rather than client/server and that might be a good approach (which is pretty close to what the PR does right now).

-- 
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/2778#issuecomment-521743750

---

From: Mike Bishop <[email-masked]>
Date: Mon, 19 Aug 2019 07:39:03 -0700

I thought where we landed (in concept, not necessarily text) was that you MUST change CID any time you're using a different local or remote IP:port.  That means the client MUST change if it knows it's migrating (new source address); the server will change in response because it's going to a new destination.  The client SHOULD change if it has been quiescent and anticipates a NAT-rebind (i.e. uncertain about source address); if it actually got rebound, the server would change as well (new destination address).  If it turns out the client didn't get rebound, then IP:port already correlate it; perhaps slightly better if the server rotates, but it's not required to.

-- 
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/2778#issuecomment-522604831