Padding in Initial Packets

[[e-mail]]

Hi All,

I'm fairly new to QUIC so apologies if the questions in here are dumb.

I've been going through a QUIC pcap, which I captured from a Firefox implementation of IETF draft 27 QUIC, and am a little confused about the use of padding in the first Initial packet.  According to Wireshark,  the UDP datagram contains a QUIC packet of type initial, length 272, the payload of which is a Client Hello.

The remainder of the UDP datagram is 1055 zero bytes.  According to Wireshark these zero bytes constitute a QUIC IETF Packet.

However there doesn't seem to be a valid QUIC packet header for these bytes.  AIUI according to the QUIC spec padding bytes are frames within a packet, so these zero bytes seem to be just bytes in the UDP datagram outside of the QUIC payload.  Which would be fine as far as I can see, but:

Why does Wireshark say it's QUIC IETF?
Is there anything in any of the QUIC draft RFCs mandating this behaviour, if so where?
Why is it being done - can't see the point?
If padding is to be added surely it should be as part of a QUIC packet and encrypted - here there's just a load of plaintext zero bytes.


Here is Wireshark's analysis:

"QUIC IETF
    QUIC Connection information
    [Packet Length: 302]
    1... .... = Header Form: Long Header (1)
    .1.. .... = Fixed Bit: True
    ..00 .... = Packet Type: Initial (0)
    .... 00.. = Reserved: 0
    .... ..10 = Packet Number Length: 3 bytes (2)
    Version: draft-27 (0xff00001b)
    Destination Connection ID Length: 17
    Destination Connection ID: 76f81a5588b2f25c5ab6dbd461a8d749e1
    Source Connection ID Length: 3
    Source Connection ID: c5ef02
    Token Length: 0
    Length: 272
    Packet Number: 0
    Payload: 04f535177fcbcfd5f06d24ffde66edf10df79205666b1851...
    TLSv1.3 Record Layer: Handshake Protocol: Client Hello
        Frame Type: CRYPTO (0x0000000000000006)
        Offset: 0
        Length: 249
        Crypto Data
        Handshake Protocol: Client Hello
            Handshake Type: Client Hello (1)
            Length: 245
            Version: TLS 1.2 (0x0303)
            Random: b1b76126ddab3c639cdfaa7d92d6cabe2ea9c1a19ea86b8b...
            Session ID Length: 0
            Cipher Suites Length: 4
            Cipher Suites (2 suites)
            Compression Methods Length: 1
            Compression Methods (1 method)
            Extensions Length: 200
            Extension: server_name (len=15)
            Extension: extended_master_secret (len=0)
            Extension: renegotiation_info (len=1)
            Extension: supported_groups (len=20)
            Extension: application_layer_protocol_negotiation (len=8)
            Extension: status_request (len=5)
            Extension: key_share (len=38)
            Extension: supported_versions (len=3)
            Extension: signature_algorithms (len=16)
            Extension: psk_key_exchange_modes (len=2)
            Extension: record_size_limit (len=2)
            Extension: quic_transports_parameters (len=42)
QUIC IETF
    [Packet Length: 1055]
    Remaining Payload: 000000000000000000000000000000000000000000000000..."

Any comments or explanations?

Tim