Change:
The QUIC packet size includes the QUIC header and protected payload, but not the UDP or IP header. <del> Clients MUST ensure they send the first Initial packet in a single IP packet.  Similarly, the first Initial packet sent after receiving a Retry packet MUST be sent in a single IP packet. The payload of a UDP datagram carrying the first Initial packet MUST be expanded to at least 1200 bytes, by adding PADDING frames to the Initial packet and/or by coalescing the Initial packet (see packet- </del> <ins> A client MUST expand the payload of all UDP datagrams carrying Initial packets to at least 1200 bytes, by adding PADDING frames to the Initial packet or by coalescing the Initial packet (see packet- </ins> coalesce).  Sending a UDP datagram of this size ensures that the <del> network path supports a reasonable Maximum Transmission Unit (MTU), and helps reduce the amplitude of amplification attacks caused by server responses toward an unverified client address; see address- validation. </del> <ins> network path from the client to the server supports a reasonable Maximum Transmission Unit (MTU).  Padding datagrams also helps reduce the amplitude of amplification attacks caused by server responses toward an unverified client address; see address-validation. </ins> <del> The datagram containing the first Initial packet from a client MAY exceed 1200 bytes if the client believes that the Path Maximum Transmission Unit (PMTU) supports the size that it chooses. </del> <ins> Datagrams containing Initial packets MAY exceed 1200 bytes if the client believes that the Path Maximum Transmission Unit (PMTU) supports the size that it chooses. </ins> A server MAY send a CONNECTION_CLOSE frame with error code <del> PROTOCOL_VIOLATION in response to the first Initial packet it receives from a client if the UDP datagram is smaller than 1200 bytes.  It MUST NOT send any other frame type in response, or otherwise behave as if any part of the offending packet was processed as valid. </del> <ins> PROTOCOL_VIOLATION in response to an Initial packet it receives from a client if the UDP datagram is smaller than 1200 bytes.  It MUST NOT send any other frame type in response, or otherwise behave as if any part of the offending packet was processed as valid. </ins> The server MUST also limit the number of bytes it sends before validating the address of the client; see address-validation.

Discussion:
This section had a bunch of text that wasn't updated as the result of other changes elsewhere. There was a suggestion that this could reference other sections, but as this is in some ways the authoritative section on the subject, I decided to keep the requirements. That's duplicative, but I couldn't see a simple way to deal with that.
The draft requires that if an Initial packet is not padded, the server sends a CONNECTIONCLOSE. I think that the goal was to have the server drop those packets and optionally send a signal. But that only applies if the server hasn't established state. We should reword that. NAME says: Originally posted by NAME in URL
Note that our principles here mean that we aren't obligated to defend against this style of attack, but rewording here is probably a good idea.
I agree that we've decided not to try to protect against attacks in the first flight, but this seems open up an extremely trivial attack vector that we can easily shutdown. I believe we should prevent it.
Why would a server want to send a CONNECTION_CLOSE in the first place? I think dropping the packet is a perfectly valid thing to do, and in fact is preferable at such an early state in the connection.
I'm going to request that this go for a consensus call. It's borderline, but I think that it is worth running the process here. And it isn't critical that this get fixed right now.
Following a discussion on Slack (cc NAME NAME NAME ), I feel a clarification might be needed on how/which INITIAL packets should be padded to 1200 bytes. E.g., URL states: have UDP payloads of at least 1200 bytes, adding padding to packets in the datagram as necessary. Some people (cc NAME interpret this to mean ALL packets containing initials should be padded (e.g., also an initial ACK from the client to the server) and not just the first initials with crypto data from the client. However, URL somewhat contradicts/restates this: be expanded to at least 1200 bytes, by adding PADDING frames to the Initial packet and/or by coalescing the Initial packet (see Section 12.2). NAME said he feels this should be removed/restated.

I personally don't know why ALL initials should be padded outside of the first flight... NAME mentioned the stateless LB use case, where they could drop all initials < 1200 bytes, though I'm not sure why a LB would do this... NAME mentioned that padding the client's initial ACKs gives additional allowance towards the 3X amplification factor limit, but as those intitial ACKS will arrive with/close to the client's first handshake packet (which validates the path, IIUC, URL). Either way, I feel the text should be tightened to clarify the intended use. Full disclosure: we're working on some dirty stuff that spoofs/abuses QUIC initials to carry in-band metadata, so we'd really not like intermediaries dropping < 1200 byte initials by default.
"Some people (cc NAME interpret this to mean ALL packets containing initials should be padded" This matches my interpretation and sounds simple and straightforward.
Yes. We have the consensus to require every datagram containing an Initial packet to be padded. See .
To clarify, section 8.1 talks about client Initials. NAME at NAME are you saying all datagrams containing client Initial packets or all datagrams containing Initial packets? I think there are some uses for non-padded server to client Initials, such as a CONNECTION_CLOSE.
I also meant client-sent initials. Though, I assume for asymmetric PMTU reasons, the server's initials should also be 1200+ bytes? IIUC correctly from the comments above: requiring client initial ACKs to also be 1200+ is mainly out of convenience/consistency ()? In that case, the text in section 14 should indeed be updated to make that more clear? I can submit a PR for that.
NAME That is my understanding, and I think that a PR would be very welcome. To clarify, the following statement in section 8.1 is correct as I understand: 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.. The text in section 14 seems to be incorrect (likely out-of-date).
I'm pretty sure that the text in Section 14 is outdated, and should probably be removed, with a short reference to section 8.1.
That's right, that's just cruft.
Thank you for the PR Martin.

Just for my understanding: the requirement to pad client initials from the second flight onward (i.e., after receiving server packets, ACKing server initials) is purely for convenience. It is not necessary for PMTU or anti-amplification-allowance. As such, the limit should also not be enforced at intermediaries wholesale?
For the most part, yes, the second flight is generally sent with some evidence that the return address is live, however we can't guarantee that the second flight carries sufficient entropy. For instance, HelloRetryRequest causes a second flight that still requires anti-amplification. Initial packets with acknowledgments in the second flight might still require padding in the case that the client isn't able to send Handshake packets (which can happen when you have a partial server flight). In the end, this is just simpler. I would be sad if intermediaries were to "enforce" MUSTs from QUIC.
In thinking about this a bit more, I wonder if 8.1 says everything we want it to say: 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. What about INITIAL packets which contain only a CONNECTION_CLOSE frame? Should those be padded? It doesn't seem terribly necessary to do this...
For the client, I think requiring padding even a CONNECTIONCLOSE is the right thing to do, since it simplifies processing on the server side. On the server, I definitely do not want to require padding Initials that only contain CONNECTIONCLOSE.
Yeah, it should be super uncommon for a client to send a CONNECTION_CLOSE in Initial, and I don't think the cost of padding it is terribly high in that uncommon case. I think keeping it simple is probably best here.
The far most likely case of a server receiving a CONNECTION_CLOSE is a middlebox trying to disrupt the handshake (i.e. RST injection). I do not think we should help them by relaxing the full-size padding requirement.
some editorializing