Draft: draft-ietf-quic-transport

Commentary: It 's not that great that this text never said this so directly before . 
 points out that the obvious solution to is for the node to respond to the attempted probe with a stateless reset . Clients would see a Stateless Reset while attempting to probe and not use the new path . That was , in fact , part of the original design IIRC . However , the reason we removed that was that doing so opens up an attack . An attacker can take a packet , rewrite the source address to an IP range the server always rejects , and get back a valid SRT for that CID . It can then inject the SRT toward the client to destroy the connection at any time , albeit only until the CID is rotated out . As far as I can tell , this attack is n't documented anywhere . The right fix is to note that if servers receive packets that would be associated with an existing connection but would not permit migration , they SHOULD drop the packet and MUST NOT generate a stateless reset . 
 I think that we do have this text . A in fact : The subtle distinction here is not that you are unable to respond , but instead unwilling . Why would you send a stateless reset when you are pretending that the route does n't work ? ( Sorry , this just seems like self - inflicted harm . ) 
 Yeah , but this is specifically not a different instance . The defense in that case is to use different keys , so the generated stateless reset is n't valid for the original connection . The section in question could perhaps be augmented to talk about behavior when an instance receives a packet associated with an active connection , but from a source that it considers unacceptable for that connection . 
 In the case of unsupported migration , the thinking is that a stateless reset would cause the path validation to fail in one round trip(opposed to a timeout ) , which is very useful if it 's the only path the client can use . I think it 's worth saying something about this case , but I 'd I 'm not sure we need normative language . If a server thinks the best course of action is to terminate the connection in this case , then sending a stateless reset is still the right thing to do . 
 So stateless reset is a wrong mechanism , but you seem to be asking why refuse to serve traffic to a set of CIDRs if they seem to be reachable . The answer could be ( a ) contractual / legal reasons , ( b ) performance reasons ( you know it will be poor ) . 
 I think the normative language is that a valid Stateless Reset MUST NOT be sent , while a connection with that CID could still be active . This covers both far - away - server Stateless   text quoted by and the same - server Stateless Reset Oracle mentioned by here . I am happy to provide a PR for this . 
 That 's a good addition . 
 If the packet arrives at the right connection , there 's no need to send a stateless reset at all . If a server wants to close the connection , it should just send a connection close , which is likely to be smaller and does n't have any Stateless Reset Oracle issues . 
 The client could still have its original network attachment intact and could be just probing of it can migrate to the second attachment . Sending a PATHRESPONCE with CONNECTIONCLOSE will kill the connection instead of telling the client " do n't migrate " . 
 Agreed , I had in mind the case when disable migration was also sent . I think there are a number of use cases and options here , and the key thing is to ensure servers understand the implications of their choices . 
 I 'm a bit confused in this discussion . Stateless Resets have had connection - level scope so far , and using that signal for invalid paths would be an overload . Not that I 'm opposed to this on the face of it , I am just noting that as a significant departure . FWIW , I 'm on board with the change to saying " a valid Stateless Reset MUST NOT be sent , while a connection with that CID could still be active " . That is the right response I think . 
 I took a swing at this .
Paragraph (version A):
In the case of a cluster that uses dynamic load balancing, it's
possible that a change in load balancer configuration could happen
while an active instance retains connection state; even if an
instance retains connection state, the change in routing and
resulting stateless reset will result in the connection being
terminated.  If there is no chance in the packet being routed to the
correct instance, it is better to send a stateless reset than wait
for connections to time out.  However, this is acceptable only if the
routing cannot be influenced by an attacker.
Paragraph (version B):
More generally, servers MUST NOT generate a stateless reset if a
connection with the corresponding connection ID could be active on
any endpoint using the same static key.
Paragraph (version B):
In the case of a cluster that uses dynamic load balancing, it's
possible that a change in load balancer configuration could occur
while an active instance retains connection state.  Even if an
instance retains connection state, the change in routing and
resulting stateless reset will result in the connection being
terminated.  If there is no chance in the packet being routed to the
correct instance in this new configuration, it is better to send a
stateless reset than wait for connections to time out.  However, this
is acceptable only if the routing cannot be influenced by an
attacker.