Draft: draft-ietf-quic-transport

Commentary: This section had a bunch of text that was n'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 could n'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 has n't established state . We should reword that . says : Originally posted by in 
 Note that our principles here mean that we are n'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 CONNECTIONCLOSE 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 is n't critical that this get fixed right now . 
 Following a discussion on Slack ( cc ) , I feel a clarification might be needed on how / which INITIAL packets should be padded to 1200 bytes . E.g. , states : have UDP payloads of at least 1200 bytes , adding padding to packets in the datagram as necessary . Some people ( cc 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 , 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 ) . said he feels this should be removed / restated . I personally do n't know why ALL initials should be padded outside of the first flight ... 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 ... 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 , ) . 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 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 . at 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 . 
 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 ca n'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 is n'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  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 does n'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 do n'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.  injection ) . I do not think we should help them by relaxing the full - size padding requirement . 
 some editorializing
Paragraph (version A):
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.
Paragraph (version A):
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-
coalesce).  Sending a UDP datagram of this size ensures that the
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.
Paragraph (version A):
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.
Paragraph (version A):
A server MAY send a CONNECTION_CLOSE frame with error code
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.
Paragraph (version B):
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-
coalesce).  Sending a UDP datagram of this size ensures that the
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.
Paragraph (version B):
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.
Paragraph (version B):
A server MAY send a CONNECTION_CLOSE frame with error code
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.