Pad Initial datagrams outside of the packet

[flub]

This is a combination of a number of things we want that we expect to make packet build more robust. This approach was independently inspired, but was confirmed to also be used by picoquic for its packet building.

Current packet building

The current packet builder pads Initial datagrams inside the final packet of the, possibly coalesced, datagram. This means that to build the datagram it needs to know before finishing a packet whether another packet will be coalesced into the datagram.

• This is brittle, because you need to be sure a non-empty packet will be produced. E.g. there needs to be enough space for whatever will be sent, an abstract minimal amount of space is not enough.
• This is redundant, because you then actually need to build the packet as well.
• The cost of this carries on long after the handshake is completed.

Proposal

• Whenever a long-header packet is written, finish it without padding.
• Packet building always starts, no need to predict if something can be written.
• If a packet is empty, the header is removed again from the buffer.
• To expand a datagram containing an Initial packet, use random bytes outside of the last packet.

This is expected to be more robust because there is only one place, populate_packet, that needs to decide if something can be written into the packet. The checks on how to finish a next packet or start building a new one disappear. No more state is shared between those iterations.

Security

The amount of information an observer of an in-flight packet can deduce is still the same: For the very first client-initiated Initial packet an on-wire observer can always decrypt it. If the server uses this technique the random data is indistinguishable from a packet, so it will look like the coalesced Handshake or Data packet just continues to the end.

[matheus23]

This approach was independently inspired, but was confirmed to also be used by picoquic for its packet building.

But only in certain cases. I dug through picoquic code a bit, and there are multiple mechanisms for "padding" datagrams (ensuring datagrams have a certain size at least). I don't understand all of them, but here are two at least:

Client-side Initial packets are padded with random data

https://github.com/private-octopus/picoquic/blob/d6ba0415d5b2284e49413adc994560510b4c7c75/picoquic/sender.c#L4101-L4109

Also a minor note: It has a comment above that says "This is bad"...

MTU probes are padded with padding frames

Uses memset with zeroes to add padding frames.

https://github.com/private-octopus/picoquic/blob/d6ba0415d5b2284e49413adc994560510b4c7c75/picoquic/sender.c#L1630-L1647

[flub]

Only the padding of datagrams that can have coalesced packets matter here. There are indeed other places where padding happens:

• MTU probes.
• Datagrams containing PATH_CHALLENGE and PATH_RESPONSE frames, if they are meant to validate the path.

In both these cases the packets are short-header 1-RTT packets. These packets can not be coalesced with another packet in the datagram because they do not indicate when the packet ends: it ends at the datagram boundary. This also means that padding outside of the packet is impossible here. But padding inside the packet is trivial for them, because they do not need to leave space for a coalesced packet.