Subject: [quicwg/base-drafts] Packet Number Gap and Connection Probing (#1174)

From: Mike Bishop <[email-masked]>
Date: Thu, 08 Mar 2018 20:56:37 +0000 (UTC)

#1012 says that a client SHOULD use one of its new CIDs when probing for server reachability on a new network, and the spec says that you MUST increment your packet number by the defined amount when you switch to the new CID.  However, that leaves the next packet number somewhat ambiguous when the client continues to use the old connection for data in parallel.

So:

- Client sends packets up through N on CCID1 on current path
- Server has previously issued client CCID2, packet number gap P2
- Client probes server with packet N+P2 and CCID2 on second path
- Client sends more packets on current path with CCID1

What packet number do those packets use?  Does the client continue with N+1?  Does the client jump to N+P2+1, thereby providing a potential correlator between the paths?  The client could side-step the issue by moving to N+P2+P3 and switching to CCID3 on the main path, but rotating CCIDs on the main path every time you probe on an alternate path might also leak information, as well as buring CIDs even more quickly.

Regardless, the spec should say what the client needs to do.  (Or we just encrypt the packet number and get rid of the gap...?)

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

---

From: janaiyengar <[email-masked]>
Date: Fri, 09 Mar 2018 12:26:33 -0800

The answer IMO is that the client goes back to N+1.  I don't believe this causes any linkability issues -- N onwards is only used with CCID1 on the first path and N+P1 onwards is only used with CCID2 on the second path.

This definitely goes in the bucket of things we can happily close if we encrypt the packet number.

-- 
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/1174#issuecomment-371935917

---

From: Martin Thomson <[email-masked]>
Date: Fri, 09 Mar 2018 22:34:58 +0000 (UTC)

There isn't a good answer here.  Unless we encrypt the packet number.

If you send N+1 on the old path and abandon the probed path, what happens when you reach N+Gap ?  Mayhem is my guess.

-- 
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/1174#issuecomment-371964885

---

From: Mike Bishop <[email-masked]>
Date: Fri, 09 Mar 2018 14:37:56 -0800

Plus, when you eventually do switch to CCID3 at packet number X, is your new packet number X+P3?  N+P2+P3?  The greater of the two?  This whole gap-jumping thing seems too loosely defined to actually employ except for CID rotation along a single 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/1174#issuecomment-371965467

---

From: Martin Thomson <[email-masked]>
Date: Fri, 09 Mar 2018 22:45:30 +0000 (UTC)

The way it is intended to work is that you move progressively forward.  So a one-off probe would cause a move from CCID1 on the old path, to CCID2 on the probe to CCID3 on the old path again.

Unfortunately, the probing design makes that transaction much more common than anticipated in the packet number gaps design, so there is a risk of running the spare connection IDs down very quickly.

Thus, my conclusion: packet number encryption is the only sensible answer.

-- 
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/1174#issuecomment-371966912

---

From: janaiyengar <[email-masked]>
Date: Thu, 15 Mar 2018 11:50:27 +0000 (UTC)

Discussed at editors' meeting: This is hairy and terrible, since using packet number gaps in order is not in line with the way probes will get sent in #1012. Packet number encryption seems to be the only good way to do this right.

-- 
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/1174#issuecomment-373350362

---

From: MikkelFJ <[email-masked]>
Date: Thu, 15 Mar 2018 06:28:07 -0700

Maybe I'm missing details, but I have previously suggested segmented packet numbers

https://github.com/quicwg/base-drafts/issues/1105

It might be slightly more complicated, but it is faster, it helps monitoring, and it helps ACK timings per path, and it allows for larger packet number space. But it dos not provide a unique packet ordering.

-- 
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/1174#issuecomment-373375189