Draft: draft-ietf-quic-transport

Commentary: I 'm not sure this changes anything in practice , since the client ca n't rely on it and the server could already do this , but explicitly saying it seems preferable . 
 LGTM 
 Suppose you have a large SH , for instance due to PQ crypto , in which case it will have to span multiple packets . If it exceeds three packets , then it will not be able to fit into a single flight . Ideally this would look something like this : However , as I read the text , the server is actually only permitted to send three packets in response to the ACK . The good news is that because the client is required to send fully padded packets , so you at least get to send 3600 octets or so per RT , but if the SH is 7 K this is pretty annoying . I believe that there is a straightforward compatible change that would allow relaxing this restriction : if the server uses a reasonably long SCID , then when the client responds with an initial with DCID set to that SCID ( which it is supposed to do anyway by my reading of S 7.2 ) , then it is implicitly a proof of reachability , and the server could ignore the amplification limit . 
 This would be conditional on the server choosing a connection ID that has enough entropy ( we seem to have decided that 64 bits is the benchmark ) . has made the same comment on occasion . 
 Yes , agreed . 
 How would a client know how what algorithm the server used to generate the connection ID ? As this seems to be a design issue anyway , here 's another proposal : The server could send a token in the Initial packet , and the client would then use this token on subsequent Initial packets ( replacing the token it might have used on the packet containing the ClientHello ) . This way , we 'd be using a field that 's intended to carry a high - entropy value , and not rely on a field that the server might not even have control over . 
 The client does n't need to know , because it 's the server 's amplification limit that is at hand . And right now , the handshake would complete if the client does n't do anything , it 's just not optimal . I agree that this would work , but it seems like a significantly more invasive change , especially given the somewhat edge - casey nature of the issue . 
 We could also allow PATH_CHALLENGE in Initial packets , but that too has more disruptive effects on the design . Of course , this is almost something that implementations could do without permission . But if we want that , then it is better to capture it . 
 Yah , that was my thinking . 
 That 's probably easier than using the Token field . The only change required for this would be to allow those two frames in Initial packets . 
 I agree that the change makes sense . The picoquic server already does that : if the client responds with the proper CID , then the connection is validated . The protocol police has not caught me yet , and that makes sense because the specifics of amplification response are pretty much a server implementation choice -- and yes , sticking a path challenge in the server 's Initial packet would be another valid choice . The main problem is not on the server side , but rather on the client side . The last interop issue I saw came when a client was coalescing an Initial ACK with an Handshake ACK . The exchange went something like : For DCID I 'm sending you an Initial ACK + Handshake but picoquic is rejecting it as too short ( error code 408 ) . My reading of the spec is this is legal , as it 's a coalesced packet Answer : The text log says that the Initial packet was accepted , but after that you are sending an initial packet that is just 95 bytes long , and then an handshake packet . ... discussion showing that the coalesced datagram was just 95 bytes long , when the spec says that all initial packets should be padded to 1200 bytes . So basically the question is , should clients be authorized to NOT pad an Initial packet to 1200 bytes if the DCID of the Initial packet is set to the SCID received by the server ? I would love to say that , but I am concerned about making disruptive changes during WGLC . And so my reluctant advice is to not do anything about this issue now . Developers of servers can make their own decisions , using either long CID or path challenges . 
 Yes , the Initial padding was discussed , and I think that as it depends on the client making an assessment of the entropy present in the connection ID , it is a non - starter . 
 The server could also inject entropy by selecting a large sequence number for the Initial packet . In theory nothing would break if the server picked a random 61 bit number for the first Initial packet instead of zero . If the client acks that and repeats the proper CID , then the server can legitimately assume that the client 's address is validated . 
 You can only get 32 bits of entropy in the packet number , and you might limit your ability to send more packets if you picked a number that is too large , but yeah , there are options . 
 Is there a reason we would want to prohibit PATHCHALLENGE / PATHRESPONSE in Initial packets ? That seems like a straightforward way to use existing mechanisms , if we want to take this design change . 
 I 'm a bit surprised we 're having this conversation at this stage in the process , but I 'll throw my 2 cents in . I 'm not particularly opposed to allowing PATHCHALLENGE / PATHRESPONSE , but it seems more invasive than explicitly saying something like " Servers MAY treat the receipt of a server generated connection ID with at least 64 bits of entropy as address validation . " 
 This is my take as well . What 's the disadvantage of the text  proposes 
 I like  's proposal and I dislike the idea of allowing the Path Challenge in Initial packets . I think allowing Path Challenge would just make things more complicated , while providing very little advantage over the Retry process . We might have debated that longer 2 years ago , but now is not the time -- better leave the spec as is . 
  's suggestion seems fine . It 's an addition to the spec , and I 'm not really hearing any strong dissensions . 
 This is sounding like a design change , is that accurate ? 
 Yes , this is a design change being proposed . 
 Is there a proposed resolution here ? 
 there is now . 
 Thanks , Do folks agree with the proposed resolution ? 
 -- the PR needs some work , but I 've only heard agreement on the resolution itself . 
 : I think this is as well . 
 I see this concern , but consider a use case where it is expensive to send a large initial packet but the client has an a - priory key to generate trusted initial CIDs . In that case the client knows that entropy is sufficient and the server can validate the DCID . This can be done , for example , and deployment dependent , by using a blake-2b hash . For battery powered low - power radio devices , sending large initials can be prohibitive . 
 In most cases , the only reason a client will need to send another large Initial is if there is loss . In low - power conditions , coalescing of Initial and Handshake by the server can be used , at which point the client never has to send an Initial again . Unless there is loss , the client in this case only ever sends one 1200 byte packet . ( And it probably never ever has to receive a packet that big ever again , assuming that the server does n't decide to drop a 10k certificate on it . ) 
 I can see that you might want to forego an a - priory key and pay 1200 bytes once to get a 0 - RTT token . But the 1200 initial bytes still holds for 0 - RTT , no ? A low power device will frequently go to sleep , and might exceed to the idle timeout of the server ( although the server might want to reconsider its timeout in that case ) . I could also see a client generating its own 0 - RTT token based on a - priory keys and this way get around the 1200 bytes if 0 - RTT permitted that . 
 QUIC still requires that the datagram be 1200 bytes , but most of that 1200 can be 0 - RTT payload ( after you include a token , session ticket , TLS key share , transport parameters , etc .. ) . A new protocol specialized to this can define a different minimum packet size . That can be QUIC - compatible if it wants to be . For such a constrained deployment , that might be a good choice . 
 LGTM . My weak preference goes to adding a word or a phrase that indicates that this is an alternative to the strategy being described in the previous sentence ( like below).I think this is a useful improvement . Thanks , !
Paragraph (version B):
Additionally, a server MAY consider the client address valididated if
the client uses a connection ID chosen by the server and the
connection ID contains at least 64 bits of entropy.