Subject: Padding in Initial Packets

From: <[email-masked]>
Date: Tue, 30 Jun 2020 10:15:52 +0000

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

---

From: Mike Bishop <[email-masked]>
Date: Tue, 30 Jun 2020 16:16:47 +0000

I can see where that output would be confusing.  This is mandated by the spec in Section 8.1, which says:

Clients MUST ensure that UDP datagrams containing Initial packets have UDP payloads of at least 1200 bytes, adding padding to packets in the datagram as necessary. A client that sends padded datagrams allows the server to send more data prior to completing address validation.

Because the client's address has not been validated when the server sends its initial response, there's an obvious risk of an amplification attack if the server's response is large.  To mitigate this, QUIC requires that clients send large Initial packets and restricts the bytes servers send to unverified addresses to a fixed multiple of the bytes received from the client.  Only UDP datagrams containing Initial packets have this requirement, because once you've moved to other packet types, the address has been validated.

From: QUIC <[email-masked]> On Behalf Of [email-masked]
Sent: Tuesday, June 30, 2020 6:16 AM
To: [email-masked]
Subject: Padding in Initial Packets

Hi All,

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

"QUIC IETF

Tim

---

From: "Martin Thomson" <[email-masked]>
Date: Wed, 01 Jul 2020 11:18:05 +1000

Hi Tim,

That's a little curveball that Firefox throws.  Other implementations pad with PADDING frames inside Initial packets.  Our first implementation found that inconvenient and so we padded outside the packet.  The resulting "packets" are clearly not valid, but neither server nor spec cannot require that they be legitimate. QUIC doesn't authenticate the composition of QUIC packets into UDP datagrams.  So the overall result is valid, even if the individual bits are not.

The number of bugs this behaviour has exposed is so great that we ultimately decided to keep it.  Fixing it would make our code more complicated anyway.

We might change the value we use for padding from 0 to something else at some point, just to keep things fresh.

Cheers,
Martin

On Tue, Jun 30, 2020, at 20:15, [email-masked] wrote:
>  
> 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?
> 
> 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
> 
>  Payload: 04f535177fcbcfd5f06d24ffde66edf10df79205666b1851…
> 
>  Random: b1b76126ddab3c639cdfaa7d92d6cabe2ea9c1a19ea86b8b…
> 
>  Session ID Length: 0
> 
>  Cipher Suites Length: 4
> 
>  Cipher Suites (2 suites)
> 
>  Remaining Payload: 000000000000000000000000000000000000000000000000…”
> 
>

---

From: Lars Eggert <[email-masked]>
Date: Wed, 1 Jul 2020 05:16:50 +0300

Quant similarly pads by coalescing random data (with the first byte massaged to be of short-header type).

-- 
Sent from a mobile device; please excuse typos.

> On Jul 1, 2020, at 04:19, Martin Thomson <[email-masked]> wrote:
> 
> Hi Tim,
>

---

From: Mikkel Fahnøe Jørgensen <[email-masked]>
Date: Tue, 30 Jun 2020 21:12:34 -0700

Maybe an an amplification attack is possible by sending all zeroes, if it
happens over a compressed link as opposed to sending random data. Maybe a
sat uplink of sorts.

This could (mostly) be avoided be having all initial data inside a QUIC
packet, although a really aggressive compressor could figure this out for
the initial packet.

Mikkel

On 1 July 2020 at 04.17.24, Lars Eggert ([email-masked]) wrote:

Quant similarly pads by coalescing random data (with the first byte
massaged to be of short-header type).

> That's a little curveball that Firefox throws. Other implementations pad
with PADDING frames inside Initial packets. Our first implementation found
that inconvenient and so we padded outside the packet. The resulting
"packets" are clearly not valid, but neither server nor spec cannot require
that they be legitimate. QUIC doesn't authenticate the composition of QUIC
packets into UDP datagrams. So the overall result is valid, even if the
individual bits are not.
>
> The number of bugs this behaviour has exposed is so great that we
ultimately decided to keep it. Fixing it would make our code more
complicated anyway.