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

[Mike Bishop <[e-mail]>]

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:[e-mail]]
Sent: Friday, June 29, 2018 3:22 PM
To: quicwg/base-drafts <[e-mail]>
Cc: Subscribed <[e-mail]>
Subject: Re: [quicwg/base-drafts] Stateless Reset from clients, bis (#1505)

Hi Igor,

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


On Fri, Jun 29, 2018 at 3:12 PM, Igor Lubashev <[e-mail]>
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.)
>
> 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).
>
> 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


> 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>, 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, 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