Subject: [quicwg/base-drafts] Stateless Reset header encoding mandates one octet sequence number length (#742)

From: Christian Huitema <[email-masked]>
Date: Mon, 21 Aug 2017 03:58:45 +0000 (UTC)

In the draft 05, the stateless reset header is defined as:
~~~
>   +-+-+-+-+-+-+-+-+
>   |0|C|K|  00001  |
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>   |                                                               |
>  +                     [Connection ID (64)]                      +
>   |                                                               |
~~~

The first 8 bits mimic the beginning of a short header, with the connection ID optional (C bit), with the key phase arbitrary (K bit), and with a type set to 0x01, which implies "encoding of sequence number on 1 octet". Why 1, instead of 2 or 4?

If the server mostly uses a 4 bytes encoding for ongoing connections, the first byte for these connections will typically be 0x42 or 0x44, maybe 0x62 or 0x64 if the key rotates. If the first byte of stateless reset is 0x41, it will stick out.

-- 
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/742

---

From: Martin Thomson <[email-masked]>
Date: Mon, 21 Aug 2017 06:41:44 +0000 (UTC)

(This really doesn't need to be an issue.  The mailing list is better for questions.)

The reason is that a shorter encoding is harder to detect as being out-of-sequence.  At worst, the recovered sequence number differs from the one on the last packet on the flow by 128.  2 or 4 octet encodings will differ by more.  If you look, the text explicitly allows a different length:

> A server MAY use a different short header type, indicating a different packet number length, but this allows for the message to be identified as a stateless reset more easily using heuristics.

The other part to this was that if the server just recovered from a crash it probably won't have sent many packets recently, so a smaller encoding is the safest in that regard.

Given the desire to not stick out, there are a bunch of bad trade-offs we can make.  We could expand the advice on the quoted text above if you think that would improve things.

-- 
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/742#issuecomment-323659195