Draft: draft-ietf-quic-manageability

Commentary: Merged ... with the neurons I have left on 22 December , this seems broadly true . I 'm not sure we should be too prescriptive about load balancing in this doc , though -- in part because I suspect the challenge of handling DDoS attacks using QUIC traffic will lead to divergent innovation in the LB space in the near term ... 
 So if the 5 - tuple changes because of NAT , the connection ID might actually not change . So in case of DDoS you might want to look at the connection ID to at cover those cases . For DDoS you usually do n't need a hard guarantee to track all flows ( if you block a flow incorrectly , it has to reconnect ) , but where you can track the flow when the 5 - tuple changes , it might actually help . That is what this paragraph is / was about . 
 " QUIC 's linkability resistance ensures that a deliberate connection migration is accompanied by a change in the connection ID and necessitate that connection ID aware DDoS defense system must have the same information about connection IDs as the load balancer { { ? I - D.ietf - quic - load - balancers } } . This may be complicated where mitigation and load balancing environments are logically separate . " This is insufficient . Even the load balancer is only able to identify the end server , not the connection . 
 On a related note , the suggestion to use the " first 8 bytes " of a server 's connection ID is somewhat strange . Why not observe the CIDL it 's using in long headers , or just have common configuration ? 
 How about if we just remove any wording about load balancers here ? Like this maybe : 
 On the 8 bytes : I actually not sure where this comes from , however , I assume that the thinking was that using the first 8 bytes might be good enough to avoid collisions if you do n't know the connection ID length . But I guess we can remove it or add some more explanation ... any thoughts ? 
 If you read the Retry Services section of QUIC - LB , you 'll see that there is no dependence on the Connection ID encoding at all . It is a common format for   that allows servers to ( at a minimum ) extract the original CIDs necessary for verification . Certainly , no device should drop packets simply because the CID has changed , which is maybe what you 're trying to say here ? But I 'm not sure that this is a DDoS thing . 
 The point is when a DDoS attack is on - going you want to make sure that on - going connections keep running while new connections are handled more carefully . So you have to be flow aware . However , maybe it 's acceptable if connectivity breaks during a DDoS when the 5 tuple changes ... ? Otherwise you would need to be CID aware . 
 This PR removes the problems I cited in the issue . Ship it . I wonder if we should hit the point in the last sentence a little harder . If you want to support connection migration , there 's nothing you can do in this space except the Retry Service stuff in QUIC - LB , is there ?
Paragraph (version A):
Note that the use of a connection ID to support connection migration
renders 5-tuple based filtering insufficient and requires more state
to be maintained by DDoS defense systems.  For the common case of NAT
rebinding, DDoS defense systems can detect a change in the client's
endpoint address by linking flows based on the first 8 bytes of the
server's connection IDs, provided the server is using at least 8-
bytes-long connection IDs.  QUIC's linkability resistance ensures
that a deliberate connection migration is accompanied by a change in
the connection ID and necessitates that connection ID-aware DDoS
defense system must have the same information about connection IDs as
the load balancer I-D.ietf-quic-load-balancers.  This may be
complicated where mitigation and load balancing environments are
logically separate.
Paragraph (version B):
Note that the use of a connection ID to support connection migration
renders 5-tuple based filtering insufficient and requires more state
to be maintained by DDoS defense systems.  For the common case of NAT
rebinding, DDoS defense systems can detect a change in the client's
endpoint address by linking flows based on the server's connection
IDs.  QUIC's linkability resistance ensures that a deliberate
connection migration is accompanied by a change in the connection ID.