Subject: Re: [quicwg/base-drafts] Description of the use of Preferred Address is unclear (#3353)

From: Eric Kinnear <[email-masked]>
Date: Sun, 02 Feb 2020 06:59:53 -0800

So far, we haven't tied the server's knowledge of the client's address to anything about a CID, and a lot of the attacks against migration involve an actor on the network changing the path & address from which the server thinks the packets are coming, even if the client does not actually change anything. I haven't thought this all the way through yet, but it seems as though trying to have the server issue "address-specific" CIDs leads us into some potentially tricky territory.

-- 
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/3353#issuecomment-581143587

---

From: Martin Thomson <[email-masked]>
Date: Sun, 02 Feb 2020 08:53:31 -0800

@erickinnear made me realize the nature of the hazard here.

It seems fairly natural for an server to bind connection IDs to the current socket address.  That is part of why we have new connection IDs attached to the preferred address and the forced retirement.  After all, if the server uses a different target address, the hash at a load balancer could change and cause packets to be badly routed.  Not including the target address in the hash would work, but it would force connection IDs to be bigger.

But this all assumes that you never expect the server to migrate.  If the server ever wanted to migrate, then the client is stuck with a bunch of unusable connection IDs for its own migrations.

We decided that only clients can initiate migration in this version, which might mean that we don't need to worry about this case.  We decided not to allow server migration primarily to avoid having to deal with the complex problems that ICE handles.  But it was only the lack of mechanisms, not a structural constraint.  Now it seems like we have a structural constraint that would prevent server migration.

At a minimum, it seems like we should probably acknowledge this constraint somehow.

-- 
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/3353#issuecomment-581154363

---

From: Mike Bishop <[email-masked]>
Date: Thu, 06 Feb 2020 00:38:43 -0800

The summary of our discussion over dinner last night is that there are various mechanisms a server could employ, but they all depend on one key point:  Both endpoints are under joint control, because they're cooperating to handle the connection.  Therefore, it's possible to generate a CID that each endpoint will be able to work with.  (There are various approaches to generating such a CID, which are implementation-specific; one or more approaches might be described in the QUIC-LB draft.)

That means we don't need to separate CIDs by endpoint; if the migration is successful, the server could choose to issue CIDs that aren't valid on the handshake endpoint, which is now out of the picture.

-- 
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/3353#issuecomment-582794240

---

From: Christian Huitema <[email-masked]>
Date: Thu, 06 Feb 2020 00:43:50 -0800

Seems like a great task for V2: define a policy for handling CID. Or we could try do that in V1 and ship in 2021.

-- 
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/3353#issuecomment-582795966

---

From: Lars Eggert <[email-masked]>
Date: Thu, 06 Feb 2020 00:50:42 -0800

Discussed in ZRH. Proposed resolution is to close with no action. New Editorial issue to be opened to explain the intended use of `preferred_address` and the CID it contains. 

-- 
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/3353#issuecomment-582798337

---

From: Martin Thomson <[email-masked]>
Date: Thu, 06 Feb 2020 00:51:03 -0800

An important point to capture here is that the server is responsible for ensuring that the connection IDs are not bound to one or other address at this stage (if migration is successful, later ones might be).  Thus, the connection ID in the transport parameter is no different to any other connection ID; it only exists here because using the new address is unusable without more connection IDs being available.

-- 
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/3353#issuecomment-582798449

---

From: Kazuho Oku <[email-masked]>
Date: Thu, 06 Feb 2020 01:15:48 -0800

@larseggert 
> Proposed resolution is to close with no action. New Editorial issue to be opened to explain the intended use of `preferred_address` and the CID it contains.

Please do note that this issue points out to other editorial concerns (see the original problem statement). I'd prefer seeing them being addressed to (and we have a WIP text in #3354).

-- 
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/3353#issuecomment-582807938