Subject: [quicwg/base-drafts] Confirm Retire Prior To via Acknowledgement (#3548)

From: Nick Banks <[email-masked]>
Date: Sat, 28 Mar 2020 13:31:32 -0700

Another proposal to fix #3509. Summary of design changes:

- CIDs retired via RPT are not individually, explicitly retired by the receiver of the NCID frame.
- The sender of the RPT gets its confirmation of the retirement when it receives an ACK for the packet that contained the NCID frame.

This proposal eliminates the extra state required to retire the CIDs requested by their peer because the CIDs can immediately be discarded. The only state required by the receiver is what was already required to acknowledge the packet.
You can view, comment on, or merge this pull request online at:

  https://github.com/quicwg/base-drafts/pull/3548

-- Commit Summary --

  * Confirm Retire Prior To via Acknowledgement

-- File Changes --

    M draft-ietf-quic-transport.md (38)

-- Patch Links --

https://github.com/quicwg/base-drafts/pull/3548.patch
https://github.com/quicwg/base-drafts/pull/3548.diff

-- 
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/pull/3548

---

From: Martin Thomson <[email-masked]>
Date: Sat, 28 Mar 2020 14:54:28 -0700

I don't think that we should go against established principles to solve something that can be solved more trivially.

-- 
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/pull/3548#issuecomment-605524576

---

From: ianswett <[email-masked]>
Date: Sat, 28 Mar 2020 15:28:43 -0700

@ianswett commented on this pull request.

I don't think this direction is untenable, but I think we need to not rely on acknowledgements to drive the state machine.

Instead, I'd suggest keying off use of a CID issued after the Retire Prior To as indication that the RPT was received.

In that world, I think the model is: a receiver of Retire Prior To doesn't need to use RCID to explicitly retire prior CIDs and instead as soon as it starts using a CID issued after the Retire Prior To, it's assumed all the prior CIDs have been retired.  Given there's already a MUST about no longer using the new CID immediately, this doesn't seem that problematic.

I think that's a fairly solid direction, now that I write it down, are there any issues I'm not thinking of?

-- 
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/pull/3548#pullrequestreview-383355075

---

From: Nick Banks <[email-masked]>
Date: Sat, 28 Mar 2020 15:32:04 -0700

> I don't think that we should go against established principles to solve something that can be solved more trivially.

IMO, #3547 is a heuristic that mitigates the problem, but doesn't quite solve it. Additionally, it is more complex to implement, than this proposal, as it requires tracking all the additional state to retire the CIDs.

> Instead, I'd suggest keying off use of a CID issued after the Retire Prior To as indication that the RPT was received.

I still prefer the ACK approach, personally, but I do think I'd prefer this suggestion over #3547. I think it would work pretty much the same as the ACK approach, but just uses a different implicit signal.

-- 
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/pull/3548#issuecomment-605528294

---

From: Kazuho Oku <[email-masked]>
Date: Sat, 28 Mar 2020 16:37:07 -0700

Does this PR give us protection against the other attack, that uses intentional migration as the attack vector? The problem is not limited to the use of RPT.

-- 
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/pull/3548#issuecomment-605533882

---

From: Mike Bishop <[email-masked]>
Date: Tue, 31 Mar 2020 12:05:27 -0700

> In that world, I think the model is: a receiver of Retire Prior To doesn't need to use RCID to explicitly retire prior CIDs and instead as soon as it starts using a CID issued after the Retire Prio…

The complication is that RPT doesn't have to immediately get rid of all old CIDs and start fresh; that's just one scenario.  Consider the load-balancer key rotation case:

- CIDs contain a bit to indicate if they're from key phase 0 or key phase 1.
- I've issued you CIDs under phase 0 and phase 1; your active CIDs include a mix
- I'm about to rotate key 0, so all the outstanding phase 0 keys need to get scrapped
- I send you NCID(<a CID from the new phase 0>, RPT=<your newest phase 0 CID>).
- There's no need for you to skip the phase 1 CIDs and start using your shiny new phase 0 key, but if you don't, I can't know for sure that you've dropped the old-phase-0 keys.

-- 
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/pull/3548#issuecomment-606815082