Draft: draft-ietf-quic-transport

Commentary: by adding generic " MUST NOT close , MAY discard packets " rule . 
 ? 
 Merging this , since the plan is to do consensus as part of LC . 
 In , we the following sentence , but I think it does not make sense . Generally speaking , a receiver of a datagram can not verify if the sender sent a full - sized datagram . That is because a datagram as a whole is not authenticated . Instead , we authenticate each of the QUIC packets that constitute the datagram . Therefore , if the sender sends a datagram consisting of multiple QUIC packets , it is ( almost always ) possible for a MOTS to take one of the QUIC packets , coalesce that with a few octets , and forward that datagram . That forwarded datagram _ would be smaller than the original datagram . Note also that a sender can send coalesced packet after the handshake too ; see . 
 As a step forward , I think we should do the following : Regarding the sentence we in , we should either a ) change the rule to " MAY discard UDP datagrams less than 1200 bytes that carry ACK - eliciting Initial apckets " , or b ) delete the sentence , and Considering the fact that there could be other occasions in which we might want to require padding , either within the base drafts , or in some of the extensions , add a note to or somewhere that datagram size is not authenticated and can not be enforced by the peer . 
 I hate to make more changes , but I think your point is a good one . If a receiver does the enforcement that we in -- of enforcing the datagram size -- that makes us vulnerable to this MOTS attack . The newly text in has n't shipped yet in a draft , so if we can get agreement , I 'd like to take this in before we ship the next draft . 
 A timely reminder that making changes always results in making more changes and no matter how careful or small , there are almost always problems . This seems like a good proposed tweak , but this has to stop . 
 Let us discuss what purpose that " MAY discard " rule has and compare it to the issue . What is important for an endpoint is to ensure that its path to the peer is possible to forward packets and supporting at least minimal MTU to make QUIC work . I think that requirement lies on each endpoint to ensure that . Does the client need to enforce the server behavior for that verification ? Is that a risk in itself that is greater , equal or less than the MOTS risk the enforcement has ? 
 I totally agree that this has to stop . I 'm sorry to have missed this point when working on ; I realized the problem when I was wondering about the MUST vs. SHOULD discussion in . That said , I do think that it would be a good idea to adopt the proposal in this issue . Let me go through the facts first . They are : An encrypted transport has to discard unauthenticated signals to prevent MOTS attackers from disrupting the connection . The size of the datagram is an unauthenticated signal throughout the lifetime of the connection . As noted above , this is the case for 1 - RTT packets after handshake confirmation too . Due to these facts , " MUST NOT close , can discard " is a principle that we 've always had . The reason we had n't written it down is because we used to have only one requirement regarding datagram length , that correctly follow the principle , stating that " servers MUST discard non - full - sized datagrams containing Initial packets . " But now that we have emerging consensus that datagrams carrying PATHCHALLENGE / PATHRESPONSE MUST be padded to full size ( ) , we need to write down that the receiver can not enforce that . Realizing that , I started to wonder if the " MAY close " rule that we in has been correct . As points out , is a change that has not shipped yet . It 's a recent change due to an issue discovered during this IETF last call . I do not think we have official consensus yet . Therefore , I tend to think there would be less confusion if the next draft would contain : servers  pad datagrams carrying ack - eleciting Initial packets ( the basis of ) endpoints MUST pad datagrams carrying PATHCHALLENGE / PATHRESPONSE frames ( ) endpoints MUST NOT close a connection when receiving datagrams with size requirements ( ) rather than having two different of rules for handling small - sized datagrams , of which one does not follow the principle . 
 Given we explicitly allow coalesced packets for PathMTU , I agree that closing the connection seems like the wrong thing to do . The PR looks sensible . 
 Agree with  . My plea for stopping was not about the fix ( the fix here is good ) , but the original change . We would not have had this problem if we were able to accept that the protocol was n't absolutely perfect . 
 has described a way forward on the mailing list for this issue - are we good with that ? If so , let 's merge , close and do the consensus establishment during IETF LC . 
 This seems sensible .
Paragraph (version B):
Datagrams are required to be of a minimum size under some conditions.
However, the size of the datagram is not authenticated.  Therefore,
an endpoint MUST NOT close a connection when it receives a datagram
that does not meet size constraints, though the endpoint MAY discard
such datagrams.
Paragraph (version A):
A server MUST discard an Initial packet that is carried in a UDP
datagram with a payload that is smaller than the smallest allowed
maximum datagram size of 1200 bytes.  A server MAY also immediately
close the connection by sending a CONNECTION_CLOSE frame with an
error code of PROTOCOL_VIOLATION; see immediate-close-hs.  When a
client receives an ack-eliciting Initial packet that is carried in a
UDP datagram with a payload that is less than 1200 bytes, that client
MAY close the connection by sending a CONNECTION_CLOSE frame.
Paragraph (version B):
A server MUST discard an Initial packet that is carried in a UDP
datagram with a payload that is smaller than the smallest allowed
maximum datagram size of 1200 bytes.  A server MAY also immediately
close the connection by sending a CONNECTION_CLOSE frame with an
error code of PROTOCOL_VIOLATION; see immediate-close-hs.