Diversification Nonce?

[Martin Duke]

I'm now running Version Q034, and the incoming packet from the toy client seems to deviate from the wire spec, over and above the changes listed in the email that announced Q034: 

1) Entropy is deprecated. Received entropy byte is removed from ACK FRAME, and sent entropy byte is removed from STOP_WAITING FRAME.

2) ACK FRAME now reports the largest packet number observed so far followed by received packets ranges (rather than missing packet ranges).

3) Private flags byte is removed from packet header.

Here is the bit output of the first CHLO from the toy client:

0000 : 0d12d2b2 3689078e de513033 340131bc f790dedc 9021154e e1a0a001 14054348: ....6....Q034.1......!.N......CH

0020 : 4c4f0d00 00005041 44004c04 00005645 52005004 00004343 53006004 00004d53: LO....PAD.L...VER.P...CCS.`...MS

0040 : 50436404 00005044 4d446804 00004943 534c6c04 00004354 494d7404 00004e4f: PCd...PDMDh...ICSLl...CTIMt...NO

0060 : 4e509404 00005343 4c539804 00004353 43549804 0000434f 50549c04 00004346: NP....SCLS....CSCT....COPT....CF

0080 : 4357a004 00005346 4357a404 00002d2d 2d2d2d2d 2d2d2d2d 2d2d2d2d 2d2d2d2d: CW....SFCW....------------------

It's clear from the ASCII that the stream frame begins in the first 16 bytes of the packet. Yet the opening byte is 0x0d, which includes the 32 Byte Diversification Nonce. I checked that the code still defines the nonce flag in same way, and it does.

Did something happen to the nonce or its associated flags in Q034?

[Ryan Hamilton]

Just recently, we added a command line tool for printing out quic packet contents. If you build the quic_packet_printer from the chromium source you can hand it the hex dump and it'll pretty-print it.  Can you give that a shot? I'll take a look later, if that doesn't help.  

Cheers,

Ryan

--
You received this message because you are subscribed to the Google Groups "QUIC Prototype Protocol Discussion group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to proto-quic+...@chromium.org.
To post to this group, send email to proto...@chromium.org.
For more options, visit https://groups.google.com/a/chromium.org/d/optout.

[Martin Duke]

I've got './quic_packet_printer client <hex>' but it's totally unclear to me from usage what the <hex> should look like format-wise. It keeps telling me I don't have enough arguments.

[Ryan Hamilton]

Gah! That's embarrassing. Looks like we have an bug in that tools. (Long day!)  In any case, since you're printing a packet which arrived at the server, you'll need to specify server for the first argument. (And then give it a dummy 3rd argument to make it happy :() Something like this:

% quic_packet_printer  server 0d12d2b23689078ede513033340131bcf790dedc9021154ee1a0a001140543484c4f0d000000504144004c040000564552005004000043435300600400004d5350436404000050444d44680400004943534c6c0400004354494d740400004e4f4e509404000053434c53980400004353435498040000434f50549c04000043464357a004000053464357a40400002d2d2d2d2d2d2d2d2d2d2d2d2d2d2d2d2d2d .

OnPacket

OnUnauthenticatedPublicHeader

OnUnauthenticatedHeader: { connection_id: 16036763609022517778, connection_id_length: 8, packet_number_length: 1, multipath_flag: 0, reset_flag: 0, version_flag: 1, version: 34, fec_flag: 0, entropy_flag: 0, entropy hash: 0, path_id: 0, packet_number: 1, is_in_fec_group: 0, fec_group: 0 }

[0527/152710:WARNING:quic_framer.cc(1933)] DecryptPacket failed for packet_number:1

OnError: QUIC_DECRYPTION_FAILURE detail: Unable to decrypt payload.

Decryption fails 'cause this is not the whole packet, obviously. But you'll notice that no diversification nonce is present. The diversification nonce is only present in packet from the server to the client. That being said, you're seeing the "old" 8-byte connection ID length flag. That comes from this code here:

https://code.google.com/p/chromium/codesearch#chromium/src/net/quic/quic_framer.cc&sq=package:chromium&q=QuicFramer&l=722

        if (perspective_ == Perspective::IS_CLIENT) {

          // TODO(rch): Fix this when v33 flags are supported by middle boxes.

          public_flags |= PACKET_PUBLIC_FLAGS_8BYTE_CONNECTION_ID_OLD;

        }

This code will go away eventually, but since clients can not ever send diversification nonces, the client can send the old flags format to work around some middle boxes that still need to be upgraded. This will go away soon, though. Sorry for the headache!

Cheers,

Ryan

[Alexis La Goutte]

Nice tools ! (a concurrent for Wireshark QUIC dissector !)

it is available on proto-quic Github repo ?

--

[Alyssa (Rzeszutek) Wilk]

Heh, I didn't even know it was ported to Chrome - that was something I hacked together to make some bug diagnosis easier and it's a hack -  I don't think it does well if the packet version isn't the highest version of QUIC.  Still, might as well merge it in and hopefully you all will inspire us to make it better :-)  I'll ask next week's merger to take a look.

[Aron]

I just stumbled upon the same behavior in Chrome 56.0.2924.18 dev -- diversification nonce bit is set, but the nonce is absent:

How does the server parse this packet?  It must have a fallback mechanism...

Interestingly, when the server sets the nonce bit, it also includes the actual nonce.

[Aron]

Another thread answers my questions.