Subject: [QUIC] Early implementation feedback on draft-hamilton-quic-transport-protocol-00

From: "Eggert, Lars" <[email-masked]>
Date: Fri, 23 Sep 2016 09:47:02 +0000

Hi,

I've started to do a little QUIC implementation exercise, to see if
the current set of documents is sufficient to allow independent
implementation. As can be expected, they're not, but I wanted to post
some feedback based on what I encountered at this very, very, VERY
early phase, so the documents can be improved.

I'm purposefully avoiding to rely at documentation other than the IDs.
I won't look at the Chromium code, and I'm only looking at the specs
on Google Docs or wireshark outputs in order to more accurately
describe what's currently missing in the IDs. However, I run my
implementation against the Chromium quic_server and quic_client
implementations, in order to see if they interoperate.

(I may open source this pure C implementation at some point; at the
moment, it's too embarrassing to do so.)

I began by reading draft-hamilton-quic-transport-protocol-00, in order
to implement the initial handshake. The ID is reasonably long and
complete-looking. Sections 1, 2 and 3 are reasonable in terms of
content.

Section 4 (Connection Establishment) is difficult to make sense of
without first reading Section 9 (Packet Types and Formats), because
Section 4 refers to header fields, flags and other concepts that are
only defined in Section 9. The content seems arbitrarily split between
those sections, e.g., Section 4.1 attempts to specify version
negotiation, but Section 9.2.1 describes the version negotiation
packet format. One needs to constantly flip back and forth, which is
annoying. I'd recommend reordering the content here.

One thing that threw me was that Section 9.1 states "all QUIC packets
on the wire begin with a public header" and then has a diagram of what
that header looks like, only to immediately follow it in Section 9.2
with special packets that don't fully include that public header.
That's really confusing. Is there a way to describe the public header
that would include the format of the special packets? Is there a way
to make those special packets use the public header? They're so rarely
sent that deviating to save a few bytes doesn't seem to be a smart
tradeoff.

Also, the document makes no mention of what endianness the protocol
fields are supposed to be encoded in.

The ID mentions QUIC version "Q025", so my code attempts to negotiate
this version with the Chromium quic_server, but that offers "Q036" and
indicates support for "Q035Q034Q033Q032" as well. The negotiation
response from the server does not conform to what's in the ID, since
it has the "diversification nonce" flag set (0x04), which is not
specified in Section 9.2.1. It also seems to use only 12 bytes of the
fixed 32 bytes that the nonce should occupy to indicate support for
other versions, according to Section 9.1.

Also, that "diversification nonce" is not referred to anywhere else in
the ID other than Section 9.1. It remains fully unclear what it is.

I change my code to negotiate version "Q036", and am trying to
figure out which frame types I am supposed to include in the initial
packet. The various subsections of Section 4.2 list some (and say that
some are required), but there is not enough information here for me to
determine which to include and what the initial values should be.

So I'm cheating, and am looking at a wireshark dump of the initial
packet that the Chromium quic_client sends to my server. I notice
there is a "Message Authentication Hash" following the public header
that is not mentioned at all in the ID. There is some brief text about
"AEAD data" in Section 9.3, but nothing that would let me understand
how that hash is computed. A quick glance at draft-thomson-quic-tls
doesn't resolve this either. Googling around, I find that older
versions of the spec on Google Docs have a short paragraph on "Initial
Packet Null Encryption" that talks about using a FNV1a128 hash, but
even the current version on Google Docs doesn't have that paragraph
anymore. There's clearly some content missing here.

And that's where I'm currently at, after a few hours of coding. Hope
this is useful.

Lars

---

From: Ted Hardie <[email-masked]>
Date: Fri, 23 Sep 2016 11:51:52 -0700

HI Lars,

Thanks very much for the report; it is very useful to have someone trying
to implement from the specs at such an early stage.  You mention you were
relying on the IDs--did that include the earlier draft-tsvwg-quic-protocol
draft?  It would be interesting to know if anything got dropped as that was
split into the successor drafts.

thanks,

Ted

On Fri, Sep 23, 2016 at 2:47 AM, Eggert, Lars <[email-masked]> wrote:

> _______________________________________________
> QUIC mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/quic
>

---

From: "Eggert, Lars" <[email-masked]>
Date: Fri, 23 Sep 2016 18:57:19 +0000

Hi,

On 2016-09-23, at 20:51, Ted Hardie <[email-masked]> wrote:
> Thanks very much for the report; it is very useful to have someone trying to implement from the specs at such an early stage.  You mention you were relying on the IDs--did that include the earlier draft-tsvwg-quic-protocol draft?  It would be interesting to know if anything got dropped as that was split into the successor drafts.

no, I only looked at the drafts mentioned in the current charter text.

Lars

---

From: Jana Iyengar <[email-masked]>
Date: Mon, 26 Sep 2016 12:31:17 -0700

That's awesome, Lars -- thanks for your early work and your feedback!  I'll
address them all soon before the next draft cutoff.
In the meanwhile, if you have any questions about missing details in the
draft, please feel free to ask.

- jana

On Fri, Sep 23, 2016 at 11:57 AM, Eggert, Lars <[email-masked]> wrote:

> > Thanks very much for the report; it is very useful to have someone
> trying to implement from the specs at such an early stage.  You mention you
> were relying on the IDs--did that include the earlier
> draft-tsvwg-quic-protocol draft?  It would be interesting to know if
> anything got dropped as that was split into the successor drafts.
>