Re: The first octet

Colin Perkins <> Wed, 08 August 2018 09:39 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D1887130E1E for <>; Wed, 8 Aug 2018 02:39:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 7wuO-GiZATBr for <>; Wed, 8 Aug 2018 02:39:07 -0700 (PDT)
Received: from ( [IPv6:2a00:1098:0:82:1000:0:2:1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4CEE8130E1D for <>; Wed, 8 Aug 2018 02:39:07 -0700 (PDT)
Received: from [] (port=36287 helo=[]) by with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <>) id 1fnKvl-0006Dt-9I; Wed, 08 Aug 2018 10:39:05 +0100
From: Colin Perkins <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_B0CD7D3F-D6C1-4E68-B2FF-30BE27E7DD11"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Subject: Re: The first octet
Date: Wed, 8 Aug 2018 10:38:58 +0100
In-Reply-To: <>
To: Martin Thomson <>
References: <>
X-Mailer: Apple Mail (2.3273)
X-BlackCat-Spam-Score: 24
Archived-At: <>
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 08 Aug 2018 09:39:11 -0000

> On 6 Aug 2018, at 06:55, Martin Thomson <> wrote:
> It appears as though we're about to get some information about how
> deployable the QUIC invariants are.  Ian tells me that Google are most
> of the way to deploying a protocol that uses QUIC invariants and
> should be able to confirm that this works by the interim.  Well,
> either that or to be able to tell us what doesn't work, which I'm
> hoping isn't a problem we have to deal with.
> I'd like to spend some time at the interim on what we do with the type
> bits in the protocol.  This email is an attempt to thoroughly cover
> the constraints that we have here and attempt to describe a process
> that I hope should get us to a conclusion shortly after Bangkok.
> Looking at open design issues, this cluster is the one that is the
> biggest threat to our schedule.
> Design Status and Constraints
> Long Header
> The long header uses the 0b1xxxxxxx pattern (128-255). The 7 bits we
> have are currently allocated to the 4 types of long header packet,
> using only 252-255.  All other values are currently unused.
> With respect to design constraints, there is only one that I'm aware
> of and that is a potential collision with RTP (and RTCP) on this octet
> (see RFC 7983), which use 0x10xxxxxx (128-191).
> The open question here is what we do with unused types.  We might
> debate creating a registry for unused values.  We might want to grease
> values.  We could even decide to encrypt these values (though the
> design of Retry makes that more difficult, because the contents of
> that packet aren't encrypted at all).
> I'm not aware of any plans to use these bits, except perhaps what
> might be done to be consistent with the short header changes, so we
> might have some latitude here.
> Short Header
> The short header uses the 0b0xxxxxxx pattern (0-127).  This is far
> more complex and we have a bunch of open questions that will make this
> difficult.
> Right now, we use the 0b0K110RRR as the pattern, with K being the key
> phase, and RRR being reserved for the spin bit experiment.
> Those fixed bits are (largely) temporary, and might be reclaimed once
> existing deployments of Google QUIC (pre-44) are phased out, so I
> think that we might want to reclaim some or all of them.
> There is a chance that the reserved bits will also become available
> (if not all, then maybe 2 of them).  That will be decided in Bangkok,
> but we might want to have a plan for those bits.
> The constraints that I am then aware of are these:
> 1. RFC 7983 has the lower half of the first octet fairly densely
> populated for demux.  Of the protocols there, my understanding of
> their relative importance puts STUN (0-4) as fairly critical, if not
> mandatory, then TLS (20-63) as optional.  ZRTP (16-19) and TURN
> channels (64-79) are both apparently unimportant, though each might be
> opportunistically accommodated.
> 2. Passive RTT measurement (spin bit) will take 0, 1, or 3 bits.  I
> suggest that we allow for this, not counting on having any more bits
> than N-3, or assuming that only that many bits will be available.
> 3. Kazuho points out that the key phase is a linkability vector.  We
> might want to consider encrypting that.  We could do that by fixing
> the packet number key and not updating it after key updates and using
> more output from that process to mask the bit (and maybe other bits in
> this field).
> 4. I realize that we don't have to put a key phase in every packet if
> we are less concerned about being able to update immediately.  If we
> adopt a scheme to what was proposed in DTLS, then a longer encoding
> can be used during the preparation and signaling phase.    I'll follow
> up with another email on this subject.
> One thing that we could use extra bits for is to move the packet
> number size back into this octet.  We could even move packet number
> bits back, depending on available space.  That might make some
> difference to the number of bytes we allocate for packet numbers.
> Process
> Given that we don't have answers to some questions we might conclude
> several ways.  I proposed that we agree on principles, starting with:
> A. What do we want to do with unused bits?  Do we want to ensure that
> they are always used?  Or can they be reserved?  If so, how would they
> be reserved (fixed values, random values, greasing, etc…)?

I suggest either random or greased somehow, but with a note that implementations that know they’ll be multiplexing another protocol on the same port will need to take care to avoid collisions with that other protocol when doing so.

> …
> E. How should we accommodate multiplexing?  For me, the big questions
> here are whether we allow for RTP to collide with the long header and
> which of the protocols we privilege by avoiding with the short header.

I think we have two demultiplexing concerns: in the longer-term how to do NAT binding discovery for peer-to-peer QUIC, and in the short term how to demux with RTP, DTLS, etc.

As a long term issue, if we want to support peer-to-peer use of QUIC, then we’ll need a NAT binding discovery protocol. STUN provides such a mechanism that we could re-use, or we could choose to re-invent a similar mechanism inside QUIC. I’d prefer not to reinvent the wheel here, but that’s a decision the group will need to make.

If we use STUN, we must ensure it can be de-multiplexed from QUIC. STUN packets have their first two bits set to 0b00 and bits 32-63 set to the magic number 0x2112A442. It’s trivial to demultiplex STUN from QUIC long header and version negotiation packets, since those packets have their first bit set to 1. 

To demultiplex STUN and QUIC short header packets, we could change the invariant for QUIC short header packets to start 0b01. This is the smallest change needed to guarantee trivial demuxing with STUN, and doesn’t significantly constrain future evolution of QUIC. Alternatively, we could specify something based on the STUN magic number and QUIC DCID, but that seems unnecessarily complex to me.

As a short term issue, we also need to consider demuxing with RTP, DTLS, and so on (I expect that media will run over QUIC in time, so demuxing with these protocols will gradually become less important). 

RTP packets have their first two bits set to 0b10, so are simple to demux with both QUIC short header packets and with the currently defined QUIC long header packet types. I think this is sufficient, and we can revisit in future versions of QUIC if we decide to change the QUIC long header packet types.

A DTLS handshake is used to key secure RTP flows, so we also need to demultiplex DTLS. The RFC 7983 heuristic for this demuxing is that packets with first octet in the range 20-63 are DTLS. That doesn’t conflict with QUIC long header packets, or short header packets as defined in the -13 QUIC drafts, but we’ll need to be careful to avoid collisions if we rearrange the bits in the short header (the above suggestion to make short header packets start 0b01 avoids conflicts).

RFC 7983 also defines demuxing with TURN and ZRTP. My opinion is that this is not important, but I accept that others may disagree.


Colin Perkins