Subject: [quicwg/base-drafts] Mandate the use of short header for stateless reset (#2600)

From: Martin Thomson <[email-masked]>
Date: Tue, 09 Apr 2019 22:49:49 +0000 (UTC)

Closes #2599.
You can view, comment on, or merge this pull request online at:

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

-- Commit Summary --

  * Allow use of long header for stateless reset
  * Move the mandatory check to the detecting section
  * Use normative language about CID reuse
  * a an
  * Mention retired connection IDs too
  * Review comments
  * Mandate the use of short header for stateless reset

-- File Changes --

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

-- Patch Links --

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

---

From: ianswett <[email-masked]>
Date: Tue, 09 Apr 2019 18:03:28 -0700

ianswett commented on this pull request.

The normative text LG, some editorial comments

>  An endpoint MAY send a stateless reset in response to a packet with a long
-header.  This would not be effective if the stateless reset token was not yet
-available to a peer.  In this QUIC version, packets with a long header are only
-used during connection establishment.   Because the stateless reset token is not
-available until connection establishment is complete or near completion,
-ignoring an unknown packet with a long header might be more effective.
+header.  Sending a stateless reset is not effective prior to the stateless reset
+token being available to a peer.  In this QUIC version, packets with a long
+header are only used during connection establishment.   Because the stateless
+reset token is not available until connection establishment is complete or near

nit: is it complete or near complete?  Is the stateless reset token available at handshake completion or near completion(ie: upon receipt of the server's Initial)

>  An endpoint MAY send a stateless reset in response to a packet with a long
-header.  This would not be effective if the stateless reset token was not yet
-available to a peer.  In this QUIC version, packets with a long header are only
-used during connection establishment.   Because the stateless reset token is not
-available until connection establishment is complete or near completion,
-ignoring an unknown packet with a long header might be more effective.
+header.  Sending a stateless reset is not effective prior to the stateless reset
+token being available to a peer.  In this QUIC version, packets with a long
+header are only used during connection establishment.   Because the stateless
+reset token is not available until connection establishment is complete or near
+completion, ignoring an unknown packet with a long header might be more
+effective than sending a stateless reset.

equally effective?  I'm unclear about how it could be more effective?  Or maybe reword this last sentence?

> @@ -2391,13 +2391,17 @@ the packet other than the last 16 bytes for carrying data.
 
 ### Detecting a Stateless Reset
 
-An endpoint detects a potential stateless reset when a incoming packet
-with a short header either cannot be associated with a connection,
-cannot be decrypted, or is marked as a duplicate packet.  The endpoint
-then compares the last 16 bytes of the packet with the Stateless Reset
-Token provided by its peer, either in a NEW_CONNECTION_ID frame or
-the server's transport parameters.  If these values are identical,
-the endpoint MUST enter the draining period and not send any further
+An endpoint detects a potential stateless reset when an incoming packet either
+cannot be associated with a connection, cannot be decrypted, or is marked as a
+duplicate packet.  The endpoint MUST then compare the last 16 bytes of the
+packet with all Stateless Reset Tokens that are associated with connection IDs
+that are currently in use.  This includes Stateless Reset Tokens from

Should there be any constraint on the receiving IP and port opposed to all possible connections?

-- 
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/2600#pullrequestreview-224718997

---

From: Jana Iyengar <[email-masked]>
Date: Tue, 09 Apr 2019 18:11:00 -0700

janaiyengar commented on this pull request.

 

Why MUST? SHOULD seems adequate here. A strawman argument is that an endpoint might choose to not use this if there are too many connections. I don't have a strong opposition, but I'd like to hear your rationale.

 

Yeah agreed. You could say something like "candidate connections, such as those on the same IP and port as the received packet."

-- 
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/2600#pullrequestreview-224721125

---

From: Martin Thomson <[email-masked]>
Date: Tue, 09 Apr 2019 19:25:08 -0700

martinthomson commented on this pull request.

Given that these are comments I would have expected to see on the *other* PR...

Long header packets are sent during connection establishment.  If you are sending them, you are still actively connecting.  Ignoring them will mean the other side times out, whereas a stateless reset is unlikely to be usable.

"as effective" would work I guess.

Either, depending on packet loss.

 

Open an issue if you care.  I don't think that it's worth having wishy-washy SHOULDs here.

 

That's not meaningful in terms of security, but that was implied.  I'll amend the other PR.

-- 
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/2600#pullrequestreview-224734727

---

From: Kazuho Oku <[email-masked]>
Date: Tue, 09 Apr 2019 22:08:13 -0700

kazuho commented on this pull request.

 

I think that this can be a MUST, based on the understanding that processing of stateless resets sent by the peer is an option. Or are we requiring every endpoint to detect and handle stateless resets?

-- 
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/2600#discussion_r273791060

---

From: ianswett <[email-masked]>
Date: Wed, 10 Apr 2019 12:02:16 -0700

```suggestion
completion, ignoring an unknown packet with a long header might be as
```

-- 
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/2600#pullrequestreview-225160273

---

From: Martin Thomson <[email-masked]>
Date: Wed, 10 Apr 2019 18:11:27 -0700

@martinthomson pushed 1 commit.

8160b284fe668d00d0a2227a937a3e458752b8b2  as effective, not necessarily more

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/2600/files/9d83262ed55aa5b2f62d8a6af05529b1f5b63541..8160b284fe668d00d0a2227a937a3e458752b8b2

---

From: Martin Thomson <[email-masked]>
Date: Tue, 23 Apr 2019 22:16:12 +0000 (UTC)

Merged #2600 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/2600#event-2295517275