Re: [quicwg/base-drafts] QUIC header format/demultiplexing (#426)

[Colin Perkins <[e-mail]>]

I was misreading the packet formats, which perhaps wasn't helping... But, to summarise, a STUN packet header is formatted as:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |0 0|     STUN Message Type     |         Message Length        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                   Magic Cookie  = 0x2112A442                  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    |                     Transaction ID (96 bits)                  |
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

This is straight-forward to demux with QUIC long header packets, since they have the initial bit set to 1 and STUN has it set to zero. 

QUIC short header packets are:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |0|C|K|   Type  |     [Connection ID (64)]                      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                     [Connection ID (64)]                      |
    +               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |               |X X X X X X X X X X X X X X X X X X X X X X X X 
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X...
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

I assume the common case is that the Connection ID is not present. If we define C=1 to mean that the Connection ID is not present, then the first two bits of the QUIC short header packet will be 01. This is straight-forward to demux from STUN, since those bits are 00 in STUN packets.

If the Connection ID is present, then the QUIC short header packet will have C=0 and so start with the first two bits equal to 00, which matches the first two bits of a STUN packet. We also see that the 64-bit QUIC Connection ID occupies the same space as the last 8 bits of the STUN Message Type, the 16-bit Message Length, the Magic Cookie, and the first 8-bits of the Transaction ID. To demultiplex such a QUIC packet from STUN, we need to either (1) use the STUN FINGERPRINT; (2) redefine the QUIC Connection ID to be 63-bit value that encoded into a 64 bits for both long- and short-header packets, with the encoding chosen so that one of the middle bits is set to avoid collisions with the STUN magic cookie when sent in short header packets; or (3) choose the QUIC short header type values to avoid conflicts with STUN message types (which is what #956 does). None of these are pleasant, but I tend to think (3) is best, since it also allows demux of WebRTC traffic.

-- 
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/426#issuecomment-350113232