Subject: [quicwg/base-drafts] Define a safe algorithm for changing CID in response to a change in CID (#1795)

From: Martin Thomson <[email-masked]>
Date: Mon, 24 Sep 2018 17:50:41 -0700

Ideally, we want an endpoint to change connection ID if its peer changes connection ID.  However, this leads to infinite changing of connection IDs if you implement the naive version of this.  We need an algorithm that is simple enough to implement, but immune to the looping problem.

This isn't critical (we can live without it), but it would be a nice to have.

Currently Section 6.11.5 is where this would live.

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

---

From: Kazuho Oku <[email-masked]>
Date: Mon, 24 Sep 2018 21:18:53 -0700

FWIW, my view is that each endpoint maintains the number of send and receive CIDs used for every 5-tuple (as the endpoint sees it). The endpoint starts sending a new CID when the number of CIDs being received on that 5-tuple exceeds the number of CIDs that it has already sent.

I assume that such an approach is not difficult to implement now that we have `RETIRE_CONNECTION_ID` frames.

-- 
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/1795#issuecomment-424202322

---

From: MikkelFJ <[email-masked]>
Date: Mon, 24 Sep 2018 23:01:07 -0700

I'm slightly worried that some ill-advised an endpoint might spam the other endpoint with endless IDs that are being naively stored by the peer instead of retired causing a targeted or involuntary DoS attack. Even if the peer retires the IDs timely, it might not have credits to get rid of them. Of course, defense is to shut down bad behavior, but perhaps it should be considered in an advisory algorithm.

-- 
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/1795#issuecomment-424217202

---

From: Martin Thomson <[email-masked]>
Date: Tue, 25 Sep 2018 10:16:56 -0700

@kazuho, you need a small tweak there to deal with the possibility that a peer changes >1 times before you send anything yourself.  But that seems workable.

@mikkelfj the nice thing there is that bad behaviour leads to connections closing, which seems like a good outcome.  When the only thing at stake is the continued existence of the connection, there is no need for further defenses.

-- 
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/1795#issuecomment-424426182

---

From: MikkelFJ <[email-masked]>
Date: Tue, 25 Sep 2018 11:59:20 -0700

@martinthomson I agree, my concern is only that this might not be obvious to implementers - in that they could kill an entire server instead of just a connection if not careful. It's a balance on how much advice to give.

-- 
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/1795#issuecomment-424461694