Subject: [quicwg/base-drafts] Stateless Reset from clients, bis (#1505)

From: Igor Lubashev <[email-masked]>
Date: Fri, 29 Jun 2018 15:12:42 -0700

In #466, we left it as the client cannot use Stateless Reset, until the server starts to use to a CID provided by the client's NEW_CONNECTION_ID.  (Something that is actually not stated explicitly in the draft.)

This is certainly not great, hence this issue.

To fix this, I can think of a few alternatives:
1. A new frame that provides the initial Stateless Reset Token from the client. It only applies to the initial CID (important to note, since you do not want it to override the token from a subsequent NEW_CONNECTION_ID in case of reordering).
2. If NEW_CONNECTION_ID frame is received from the client with Seq=0 and Length=0, it provides the initial Stateless Reset Token (and is considered to be Seq=-1, so the next NEW_CONNECTION_ID would actually be Seq=0).  I do not love this and would prefer just a new frame.

-- 
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/issues/1505

---

From: hardie <[email-masked]>
Date: Fri, 29 Jun 2018 15:22:17 -0700

Hi Igor,

I think I'm a little confused.  Some questions in-line.

On Fri, Jun 29, 2018 at 3:12 PM, Igor Lubashev <[email-masked]>
wrote:

> In #466 <https://github.com/quicwg/base-drafts/issues/466>, we left it as
> the client cannot use Stateless Reset, until the server starts to use to a
> CID provided by the client's NEW_CONNECTION_ID. (Something that is actually
> not stated explicitly in the draft.)
>
>    1. A new frame that provides the initial Stateless Reset Token from
>    the client. It only applies to the initial CID (important to note, since
>    you do not want it to override the token from a subsequent
>    NEW_CONNECTION_ID in case of reordering).
>
> If the purpose of Stateless Reset is to abruptly tear down a connection,
I'm not sure what the re-ordering issue is.  Sending a Stateless Reset and
then sending more traffic on that connection seems odd.  Similarly, if the
client needs to know whether data already sent has been received, it seems
like it either has to wait until that data is acknowledged and/or use a
graceful shutdown.  I don't seen how a reset matches this--what am I
missing?

>
>    1. If NEW_CONNECTION_ID frame is received from the client with Seq=0
>    and Length=0, it provides the initial Stateless Reset Token (and is
>    considered to be Seq=-1, so the next NEW_CONNECTION_ID would actually be
>    Seq=0). I do not love this and would prefer just a new frame.
>
> —
>
I agree that this is not very lovable.

Ted

> Reply to this email directly, view it on GitHub
> <https://github.com/quicwg/base-drafts/issues/1505>, or mute the thread
> <https://github.com/notifications/unsubscribe-auth/ABVb5BUeQGYOCQ9iZVNLKtp0Y_w-WFZNks5uBqZZgaJpZM4U9sIC>
> .
>

-- 
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/issues/1505#issuecomment-401488385

---

From: Igor Lubashev <[email-masked]>
Date: Fri, 29 Jun 2018 15:32:44 -0700

Ted, take a look at #466 (closer to the end of the thread).

The problem we have right now is that client cannot supply a stateless reset token during handshake, because client's part of the handshake (unlike the server's) is not protected.  So the situation we have right now is that clients _cannot_ send a Stateless Reset any time later, until the server has switched to using a new CID from the client, provided by the client in NEW_CONNECTION_ID.  (And switching CIDs may never happen.)

So the "idea" I am proposing is very simple -- since the client cannot not send its stateless reset token associated with its CID during handshake, let it send that token later (as soon as it starts to send protected packets).

-- 
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/issues/1505#issuecomment-401490090

---

From: Mike Bishop <[email-masked]>
Date: Fri, 29 Jun 2018 16:16:02 -0700

The reordering isn’t with the Stateless Reset itself.  The server doesn’t know, during the handshake, what SRT goes with the client’s chosen CID.  Igor is looking for a way the server could acquire this information, so that a Stateless Reset subsequently sent by the client can be recognized.

The first option is a separate frame type that supplies the SRT for a CID that the server already has.  But due to reordering, that might no longer be the CID in use when the server receives it, so the server needs to be careful not to overwrite the SRT it already possesses for the new CID.  Frankly, this just seems like a bug on the server implementer’s part, albeit one it might be worth cautioning them against.

The second becomes more palatable if the outcome of #1484 is that you can express the sequence number of the initial handshake CID in a NEW_CONNECTION_ID frame; the client could simply re-send that CID as if it were new, but including the SRT this time.

From: hardie [mailto:[email-masked]]
Sent: Friday, June 29, 2018 3:22 PM
To: quicwg/base-drafts <[email-masked]>
Cc: Subscribed <[email-masked]>
Subject: Re: [quicwg/base-drafts] Stateless Reset from clients, bis (#1505)

Hi Igor,

Ted

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub<https://github.com/quicwg/base-drafts/issues/1505#issuecomment-401488385>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AEE2hSnrCgDe_HW-qY5pKgf5D6dc4T3qks5uBqiYgaJpZM4U9sIC>.

-- 
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/issues/1505#issuecomment-401496309

---

From: Igor Lubashev <[email-masked]>
Date: Fri, 29 Jun 2018 16:28:44 -0700

Yes, if #1484 assigns number 0 to the client's initial CID, then the simplest way to implement this is to just repeat CID 0 in NEW_CONNECTION_ID frame.  Some care would be needed to decide whether CID 0 in NEW_CONNECTION_ID can be different from the client's initial CID, or that's an error.  (Len=0 there could be an optimization or be considered an unnecessary complication).

-- 
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/issues/1505#issuecomment-401497887