Subject: [quicwg/base-drafts] Stateless reset in response to long header packets (#1348)

From: Martin Thomson <[email-masked]>
Date: Wed, 09 May 2018 23:02:06 -0700

I think that we permit these, and it seems reasonable to send one.  I don't think that there is any reason why this wouldn't work, even if it is unlikely that an endpoint would find itself in a position where it needed to send one.  For instance, a server might want to send one in response to the second client flight.  But then it might be able to wait for the packets with short headers to arrive.

We might want to tighten things up a little in a few places so that this is clearer if we intend to allow 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/issues/1348

---

From: ianswett <[email-masked]>
Date: Thu, 10 May 2018 03:37:07 -0700

Q: In what case would the sender of the long header packet have the information necessary to validate the stateless reset?  It's in the TransportParameters, which are only available at the end of the handshake.

So I'd be inclined to say don't send them because they're useless, unless there's a case I'm missing.

-- 
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/1348#issuecomment-388017884

---

From: martinduke <[email-masked]>
Date: Thu, 10 May 2018 12:36:52 -0700

If the server reboots after sending the encrypted extensions, I believe we can end up in this state. I'm not caught up on the migration stuff, but I believe this also involves long headers in mid-connection,.

It's all not a big deal how we resolve this, but at the very least we don't want to respond to a long header with a mock short header as currently defined (i.e. with a purely random destination conn ID).

-- 
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/1348#issuecomment-388161748

---

From: Mike Bishop <[email-masked]>
Date: Thu, 10 May 2018 13:03:31 -0700

No, migration is all short-header, at least as currently designed.  There was a proposal that we should (somehow) make migrations look like handshakes, but that so far hasn't gone anywhere.

-- 
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/1348#issuecomment-388168844

---

From: MikkelFJ <[email-masked]>
Date: Thu, 10 May 2018 13:06:03 -0700

Just drop the packet and log it - the case is either extremely rare - or way too frequent due to misconfiguration - or it is a DoS vector. You don't want to hide misconfiguration through random 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/issues/1348#issuecomment-388169572

---

From: Martin Thomson <[email-masked]>
Date: Thu, 10 May 2018 17:56:29 -0700

@martinduke is right, you can get a Handshake packet from a client.  A client can also find that 0-RTT packets hit the wrong server, after it receives the EncryptedExtensions (or the entire handshake).  A client can't prime the server at all with stateless reset messages, so these are the only cases I'm aware of - in this version of the protocol.

With 0-RTT in the mix, albeit in a narrow window, I think that we can probably allow stateless reset.  But we should explain the limitations and note that crashes will more than likely just cause handshakes to fail.

-- 
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/1348#issuecomment-388228186