Subject: [quicwg/base-drafts] Tighten error processing of NEW CONNECTION ID (#1739)

From: Christian Huitema <[email-masked]>
Date: Mon, 10 Sep 2018 23:08:30 -0700

Generate an error if the same connection ID is announced twice, with different reset secret or different sequence number. Also prohibits repeating the connection ID used in handshake in a new connection ID frame.
You can view, comment on, or merge this pull request online at:

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

-- Commit Summary --

  * Merge pull request #5 from quicwg/master
  * Tighten error processing of NEW CONNECTION ID
  * Fix typo

-- File Changes --

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

-- Patch Links --

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

---

From: MikkelFJ <[email-masked]>
Date: Tue, 11 Sep 2018 07:12:05 +0000 (UTC)

mikkelfj commented on this pull request.

> @@ -3218,6 +3218,19 @@ value of the connection ID changed.  An endpoint that is sending packets with a
 zero-length Destination Connection ID MUST treat receipt of a NEW_CONNECTION_ID
 frame as a connection error of type PROTOCOL_VIOLATION.
 
+Transmission errors, time-outs and retransmission may cause the same
+NEW_CONNECTION_ID frame to be received multiple time. Additional
+transmissions SHOULD be ignored and MUST NOT cause a connection
+error.
+
+If an endpoint receives a NEW_CONNECTION_ID frame that repeats the same
+connection ID as a previous NEW_CONNECTION_ID frame but with a different
+Stateless Reset Token or a different Sequence, the endpoint MUST
+treat that receipt as a connection error of type PROTOCOL_VIOLATION.
+Similarly, if an endpoint receives a NEW_CONNECTION_ID frame that repeats

That MUST is hard to achieve if the context has been erased meanwhile. Surely the intention is not to log ID's forever?

-- 
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/1739#pullrequestreview-154073928

---

From: Martin Thomson <[email-masked]>
Date: Tue, 11 Sep 2018 04:50:36 -0700

martinthomson commented on this pull request.

In reading this, I wonder if it isn't reasonable to send NEW_CONNECTION_ID with the same connection ID and a different token just to refresh the stateless reset keys.  I think that the answer there is "that's crazy, make a new connection ID as well", but I wanted to check.

s/time/times

As @mikkelfj says, I think that we only need to say "MAY" for these and let nature take its course.  A "MAY treat as a protocol error" turns into a fairly firm requirement not to send duplicates.

-- 
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/1739#pullrequestreview-154164794

---

From: Christian Huitema <[email-masked]>
Date: Tue, 11 Sep 2018 10:07:17 -0700

@huitema pushed 1 commit.

42d9792  Change MUST error on wrong NEW CID to MAY

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1739/files/8ffda9e3efae7267bfea629019fd489c195f4cb2..42d9792421d4092b6bbd2494b3d753660f61f751

---

From: Christian Huitema <[email-masked]>
Date: Tue, 11 Sep 2018 10:52:03 -0700

Just pushed a commit that replaces MUST by MAY. I am still pondering @martinthomson question whether it is _"reasonable to send NEW_CONNECTION_ID with the same connection ID and a different token just to refresh the stateless reset keys."_ There are pros and cons either way.

Sending an error is simpler, it does not require updating state. But asking to update the reset token may be a better specification, because it is more likely result in consistent implementations. The error will only be sent if it is detected, and it will not be detected if the implementation lost trace of the old CID. We are thus getting potentially inconsistent results, some implementations generating errors and some not.

We will get better consistency if we ask endpoints to just update the reset secret associated with the CID. The implementations that keep trace of the old CID would just perform the update. The implementations that lost trace would register a new CID with the new reset secret. Both types of implementation would end up with the same result, which might be more consistent with the idea that frames are idempotent.

But then, there is an ordering issue. QUIC does not guarantee that frames are delivered in order. Even if implementation track whether the previous frame has been acknowledged, there is always the risk of a delayed copy popping up later. In that case, we are playing reset-roulette. I suppose we could build machinery to guarantee the ordering of the frames, but asking implementations to "only use a connection ID once" feels much simpler. Hence my choice of just detecting an error if parameters change.

-- 
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/1739#issuecomment-420362112

---

From: Martin Thomson <[email-masked]>
Date: Tue, 11 Sep 2018 15:11:13 -0700

> asking implementations to "only use a connection ID once" feels much simpler

My conclusion exactly. :)

-- 
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/1739#issuecomment-420443323

---

From: Martin Thomson <[email-masked]>
Date: Tue, 11 Sep 2018 15:14:17 -0700

@martinthomson pushed 1 commit.

ae09532  MUST ignore duplicate NEW_CID

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1739/files/42d9792421d4092b6bbd2494b3d753660f61f751..ae0953282d227ceb2805b02da3556e1b81ed6cbf

---

From: Martin Thomson <[email-masked]>
Date: Tue, 11 Sep 2018 15:17:37 -0700

f1c0b39  MUST NOT be an error to receive twice

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1739/files/ae0953282d227ceb2805b02da3556e1b81ed6cbf..f1c0b399a22fbae31dd560d6cc4b43ffbdf74feb

---

From: Christian Huitema <[email-masked]>
Date: Tue, 11 Sep 2018 20:27:02 -0700

@mikkelfj are you referring to "_MUST NOT be an error to receive twice_" when you say "_This MUST actually reintroduces the problem of remembering old ID transmissions. It cannot ignore without remembering forever_"? Because there is no such requirement. You need to remember if you want to signal errors, but we are rpecisely telling you, "don't do that".

-- 
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/1739#issuecomment-420499895

---

From: MikkelFJ <[email-masked]>
Date: Tue, 11 Sep 2018 22:04:48 -0700

No, I made the comment seconds after Martin comitted a change, snd Martin comited a new change seconds after my comment. The MUST NOT in its current form is fine.

-- 
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/1739#issuecomment-420513265

---

From: Martin Thomson <[email-masked]>
Date: Wed, 12 Sep 2018 06:24:27 +0000 (UTC)

I reached the same conclusion immediately after hitting "edit" :)

-- 
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/1739#issuecomment-420526711

---

From: Martin Thomson <[email-masked]>
Date: Tue, 11 Sep 2018 23:24:47 -0700

Merged #1739 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/1739#event-1840250049