Subject: Re: [quicwg/base-drafts] Add normative language for stateless reset (#2574)

From: Ryan Hamilton <[email-masked]>
Date: Mon, 01 Apr 2019 10:57:07 -0700

RyanAtGoogle commented on this pull request.

> @@ -2428,17 +2428,17 @@ This design relies on the peer always sending a connection ID in its packets so
 that the endpoint can use the connection ID from a packet to reset the
 connection.  An endpoint that uses this design MUST either use the same
 connection ID length for all connections or encode the length of the connection
-ID such that it can be recovered without state.  In addition, it cannot
-provide a zero-length connection ID.
+ID such that it can be recovered without state.  In addition, it cannot provide

Should this be MUST NOT instead of cannot?

-- 
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/2574#pullrequestreview-221259079

---

From: martinduke <[email-masked]>
Date: Mon, 01 Apr 2019 21:30:12 -0700

martinduke commented on this pull request.

Looks good, but I'd like two more normative statements about sending Stateless Reset in the first place. If I receive a packet for which I have no context, MUST I send a Stateless Reset or SHOULD I, assuming I might have sent the token?

Furthermore, SHOULD I do some sort of rate control to avoid sending 1 SR per 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/2574#pullrequestreview-221445300

---

From: Martin Thomson <[email-masked]>
Date: Thu, 04 Apr 2019 00:09:57 -0700

martinthomson commented on this pull request.

> If I receive a packet for which I have no context, MUST I send a Stateless Reset or SHOULD I, assuming I might have sent the token?

It isn't the place of this specification to tell endpoints when a stateless reset is appropriate.  Describing the consequences should suffice.

> Furthermore, SHOULD I do some sort of rate control to avoid sending 1 SR per packet?

I thought we had that already.  But I think that we intentionally removed it.  I'm still looking for the PR that did that (tracking removed code is hard).

I didn't want to repeat a requirement from elsewhere in that migration cannot be initiated if the connection ID is zero length.

-- 
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/2574#pullrequestreview-222222739

---

From: MikkelFJ <[email-masked]>
Date: Thu, 04 Apr 2019 08:21:08 +0000 (UTC)

> I thought we had that already. But I think that we intentionally removed it. I'm still looking for the PR that did that (tracking removed code is hard).

I was also wondering about the rate limit in SR - I too thought it was there.

But now, after thinking a bit, the rate limit was probably removed because it is a DoS vector. It can force state to maintained where it is not wanted.

-- 
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/2574#issuecomment-479799402

---

From: Jana Iyengar <[email-masked]>
Date: Thu, 04 Apr 2019 17:29:32 -0700

janaiyengar commented on this pull request.

> @@ -2350,11 +2344,13 @@ valid QUIC packets.  With the set of AEAD functions defined in {{QUIC-TLS}},
 packets that are smaller than 21 bytes are never valid.
 
 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 and MAY send a stateless reset that is formatted to appear as a packet
+with a long header.  Sending a stateless reset is not effective prior to the

This is odd. Why do we allow stateless reset to be sent as a long header if the peer is only looking for it in short header packets?

> @@ -2350,11 +2344,13 @@ valid QUIC packets.  With the set of AEAD functions defined in {{QUIC-TLS}},
 packets that are smaller than 21 bytes are never valid.
 
 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 and MAY send a stateless reset that is formatted to appear as a packet
+with a long 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.

```suggestion
be more effective than sending a stateless reset in response to it.
```

-- 
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/2574#pullrequestreview-223059429

---

From: martinduke <[email-masked]>
Date: Thu, 04 Apr 2019 21:05:36 -0700

> It isn't the place of this specification to tell endpoints when a stateless reset is appropriate. Describing the consequences should suffice.

This is a weird statement to make. It is absolutely the place of the spec to do that! If what you mean is that this is entirely optional, then I'm happy to make it a MAY. My concern is not so much what level of force the spec uses, just that the level of force is clear.

-- 
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/2574#issuecomment-480141483

---

From: Martin Thomson <[email-masked]>
Date: Tue, 09 Apr 2019 15:36:44 -0700

@martinthomson pushed 1 commit.

9b60422d7f1bcfe6e55b9bedf3610cd97a9d70c4  Review comments

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/2574/files/4367e0f6213cd877d9b165d7cfb057b9367438a8..9b60422d7f1bcfe6e55b9bedf3610cd97a9d70c4

---

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

dd121afa26088dd473e2dcf04c62d4a163bdc49c  Be more precise

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/2574/files/9b60422d7f1bcfe6e55b9bedf3610cd97a9d70c4..dd121afa26088dd473e2dcf04c62d4a163bdc49c