Draft: draft-ietf-quic-transport

Commentary: I went to and found that the offending text was already removed , so we 're most of the way there . I a note to the Security Considerations about not letting clients dictate your routing decisions . 
 In Section 7.2 , the spec makes an implicit assumption that the CID of the Initial packet is used for routing : makes this even more explicit : However , in the discussion of , part of the conclusion was that , to protect from malicious clients , load balancers can not safely permit client - chosen fields to influence the routing of their packets to a particular server . IIRC , this was also discussed in New York . Did we mean that ? If so , we have conflicting text . 
 I 'd say sometimes it 's safe and sometimes it 's not and there are pros and cons of different approaches . You mention conflicting text , can you point out the text that conflicts with the sections you quoted above in this issue ? 
 I tend to agree with  , but an Initial that follows a stateless reset would have to be routed consistently . I assume this reset driven routing can not ( trivially ) be abused due to integrity checks in the reset , but I do n't recall the details . 
 Conflicting as in , we have text ( quoted ) which contradicts my understanding of our decision . I think if we decide to go with what we 'd discussed before ( do n't trust the CID of Initial/0 - RTT ) , we should add some Security Considerations text about that . 
 I presume you mean Retry . The server can specify any CID in the Retry , but I 'd expect the routing to be achieved by IP : port consistency throughout the handshake . 
 I mean Retry , of course . You can not assume IP / port consistency because the routing will in some cases happen behind an external load balancer that exposes a single public IP and routes to a specific internal IP based on CID . 
 If a middlebox can tell the difference between and original and a Retry driven Initial packet , it would be possible configure the middlebox to a ) route randomly on first initial , or b ) route consistently on first initial , and for both a ) and b ) route consistently after a retry . In the case b ) the middlebox could force a retry when it thinks there is overload either accidentally , or through an attack . If the Retry is verified properly , it is not possible to forge a successful CID in this case . All of this should be possible , and trivial to do , but need some reading up to see what is the current state of affairs . I think middleboxes might not be able to detect a Retry driven initial but endpoints are since a Retry can only happen once . 
  , I think a retry would not make sense in the above , or least not where you end up with the same external loadbalancer and public IP . In that case the load balancer could just internally swap endpoint . So is probably right about IP / port stability . EDIT : disagreeing with myself again : if the load balancer is distributed , but has a single IP , and if is mostly stateless and depends on the CID for actual routing , it does indeed need a Retry even if the IP / port is the same . 
 My answer is that both are true and that they can co - exist . While the server ca n't rely on the randomized connection ID being good , it might choose to allow routing based on that value under normal circumstances . The recommendation that a client not tamper with fields that might alter routing is a sensible one . As is the recommendation that a server not attach too much significance to values chosen by clients . 
 : I do n't think there is any text that suggests a server " not attach too much significance to values chosen by clients " . Do folks think it might be useful to add to Security Considerations ? 
 Obviously I think we should . :-) If we think there 's a place for both , then let 's give both some airtime in the spec . 
 Discussed in Tokyo ; add Security Considerations text about an attacker 's ability to influence server selection , but do n't normatively forbid the use of the ODCID in routing decisions . 
 I think the point is making is a sensible one . The explicit text that  has quoted is implying that servers SHOULD use Client - chosen CID for routing . After all , this purpose is explicitly stated , without any caveats , right there in the spec . I would rather see that quoted text removed altogether . It is enough to state that " A client SHOULD select an initial Destination Connection ID length long enough to satisfy the minimum size requirements for every QUIC version it supports " . This is accurate and not misleading . 
 Fix suggestions and we 're good .
Paragraph (version B):
Deployments should limit the ability of an attacker to target a new
connection to a particular server instance.  This means that client-
controlled fields, such as the initial Destination Connection ID used
on Initial and 0-RTT packets SHOULD NOT be used by themselves to make
routing decisions.  Ideally, routing decisions are made independently
of client-selected values; a Source Connection ID can be selected to
route later packets to the same server.