Draft: draft-ietf-quic-transport

Commentary: This is trickier than I had imagined . Sending CONNECTIONCLOSE is probably fine , but it 's harder to do this correctly now . You ca n't just send an unauthenticated CONNECTIONCLOSE because that might disrupt a real connection . So there are two goals in tension : ' t kill an active connection ( attempt ) unnecessarily . feedback about errors . The observation is that an attacker can disrupt connections by eliciting a CONNECTIONCLOSE , so feedback naturally leads to an exposure to a DoS attack . That 's unfortunate , but we have established that we do n't care about DoS by an on - path attacker prior to handshake completion . Anything we do here has got to be best effort . DoS prevention would say that you just discard junk , and that is probably the right answer . But we have a number of cases where the robustness of the system depends on getting feedback . Either way , we agreed to allow CONNECTIONCLOSE in Initial , so the exposure exists anyway . So this contains advice . Maybe too much advice , but I thought that I 'd see what people thought . 
 In some cases , we allow CONNECTIONCLOSE ( or immediate close ) to be used when there is no state for the associated " connection " . Most notably , this happens when a server receives a bogus Initial from a client ( see for the prime example ) . Immediate close works fine for those cases , except that it mandates the creation of state : the timer that runs for the closing period and maybe a packet . That does n't make sense , because what you want prior to establishing ANY state is to just send the signal without creating any state . So , we should allow an exception for immediate close where there is no connection state . This requires a little finesse as it touches on DoS concerns . An ( unauthenticated ) Initial packet might is handled statelessly with the resulting CONNECTIONCLOSE causing the client to kill state . If the server wanted to keep that state , that might be bad . For that , there is no perfect answer , because it trades off feedback about errors against a very narrow form of denial of service that we agreed we would n't take special steps to protect against . So we should just explain the trade - off and let the servers decide what to do . fixes this one . 
 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 . 
 LGTM modulo the editorial concerns below . A few editorial suggestions , but this looks good to me now .
Paragraph (version A):
managing the tokens.
Paragraph (version B):
managing the tokens.  A client MAY use a token from any previous
connection to that server.