Subject: [quicwg/base-drafts] MUST retire Connection IDs becoming stale (#3096)

From: Kazuho Oku <[email-masked]>
Date: Tue, 15 Oct 2019 17:45:19 -0700

Closes #3046.

@martinthomson:
&gt; As discussed, should be that the receiving side will retire within one PTO. The sending side can enforce at 3PTO, by dropping the connection.

The text in the PR adopts 1 PTO as a suggestion, as I am not sure if there is a point in that value being the exact limit. If it needs to be, we can rephrase the text to &quot;MUST retire the corresponding connection IDs in one PTO and send corresponding RETIRE_CONNECTION_ID frames.&quot;
You can view, comment on, or merge this pull request online at:

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

-- Commit Summary --

  * MUST retire, suggest within 1 PTO

-- File Changes --

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

-- Patch Links --

https://github.com/quicwg/base-drafts/pull/3096.patch
https://github.com/quicwg/base-drafts/pull/3096.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/3096

---

From: Martin Thomson <[email-masked]>
Date: Wed, 16 Oct 2019 08:29:41 -0700

martinthomson commented on this pull request.

I think that the most interesting behaviour to specify is at the endpoint that requests retirement.  "Endpoints that request that peers retire connection IDs SHOULD be prepared to receive packets that contain connection IDs that they have requested be retired for a period of approximately three times the PTO."

> @@ -1032,10 +1032,11 @@ longer plans to use that address.
 
 An endpoint can request that its peer retire connection IDs by sending a
 NEW_CONNECTION_ID frame with an increased Retire Prior To field.  Upon receipt,
-the peer SHOULD retire the corresponding connection IDs and send the
-corresponding RETIRE_CONNECTION_ID frames in a timely manner.  Failing to do so
-can cause packets to be delayed, lost, or cause the original endpoint to send a
-stateless reset in response to a connection ID it can no longer route correctly.
+the peer MUST retire the corresponding connection IDs and send corresponding
+RETIRE_CONNECTION_ID frames.  Failing to retire the connection IDs within one
+PTO can cause packets to be delayed, lost, or cause the original endpoint to

Maybe we could even say "approximately", and add "Endpoints that request that peers retire connection IDs SHOULD be prepared to receive packets that contain connection IDs that they have requested be retired for a period of approximately three times the PTO."

-- 
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/3096#pullrequestreview-302670225

---

From: Nick Banks <[email-masked]>
Date: Wed, 16 Oct 2019 15:37:20 +0000 (UTC)

nibanks approved this pull request.

Looks fine to me. I'm also fine with Martin's suggestions as well.

-- 
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/3096#pullrequestreview-302676912

---

From: ianswett <[email-masked]>
Date: Wed, 16 Oct 2019 14:19:09 -0700

ianswett approved this pull request.

LG, but I like @martinthomson suggestion

-- 
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/3096#pullrequestreview-302883774

---

From: Eric Kinnear <[email-masked]>
Date: Wed, 16 Oct 2019 14:50:17 -0700

erickinnear approved this pull request.

The endpoint here has always been going to do whatever it does, regardless of whether we said SHOULD or MUST, so this seems fine. I do like the direction for the other endpoint to wait 3PTO, that would be nice to include.

-- 
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/3096#pullrequestreview-302898634

---

From: Kazuho Oku <[email-masked]>
Date: Wed, 23 Oct 2019 23:22:07 -0700

@kazuho pushed 2 commits.

afba2abcdda91bde3c8ba6b82821ed9144b7d30f  approximately
1ecfb27bead5c9d0b7daeeaf302ecbffa13bdbc1  prepared to receive, until retired

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3096/files/f10a749d33a7e5885f0e5dd0cd67d6525272cf28..1ecfb27bead5c9d0b7daeeaf302ecbffa13bdbc1

---

From: Kazuho Oku <[email-masked]>
Date: Wed, 23 Oct 2019 23:23:13 -0700

kazuho commented on this pull request.

Thank you for the suggestions. I've added "approximately", and merged the other suggestion into the next paragraph. PTAL.

-- 
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/3096#discussion_r338398409

---

From: Martin Thomson <[email-masked]>
Date: Thu, 24 Oct 2019 01:37:15 -0700

martinthomson approved this pull request.

-- 
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/3096#pullrequestreview-306404426

---

From: MikkelFJ <[email-masked]>
Date: Thu, 24 Oct 2019 05:38:35 -0700

I'm a bit worried that a stateless reset from a retired CID could be used as an attack vector by simply delaying packets en-route. However, if the reset is only effective on CIDs that are no longer recognised that shouldn't be a problem.

-- 
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/3096#issuecomment-545897942

---

From: ianswett <[email-masked]>
Date: Thu, 24 Oct 2019 06:41:12 -0700

-- 
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/3096#pullrequestreview-306581965

---

From: Mike Bishop <[email-masked]>
Date: Tue, 29 Oct 2019 15:20:46 +0000 (UTC)

MikeBishop approved this pull request.

@mikkelfj, the delayed packets are handled by this text:

>  Tokens are invalidated when their associated connection ID is retired via a RETIRE_CONNECTION_ID frame (Section 19.16).

> An endpoint MUST NOT check for any Stateless Reset Tokens associated with connection IDs it has not used or for connection IDs that have been retired.

If you've followed the requirement to retire as indicated, then a delayed packet triggering stateless reset can't hurt you.

> @@ -1032,16 +1032,19 @@ longer plans to use that address.

This isn't really a request any more, is it?
```suggestion
An endpoint can cause its peer to retire connection IDs by sending a
```

-- 
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/3096#pullrequestreview-308596243

---

From: Kazuho Oku <[email-masked]>
Date: Tue, 29 Oct 2019 22:55:15 -0700

@kazuho pushed 1 commit.

57a466f77afc99f32769e59596395a5848121859  Update draft-ietf-quic-transport.md

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3096/files/1ecfb27bead5c9d0b7daeeaf302ecbffa13bdbc1..57a466f77afc99f32769e59596395a5848121859

---

From: Martin Thomson <[email-masked]>
Date: Wed, 30 Oct 2019 22:31:07 -0700

Merged #3096 into master.

-- 
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/3096#event-2758503401