Draft: draft-ietf-quic-transport

Commentary: This covers a few issues and attempts to clean up the normative text , further editorial rearranging is for a future PR , since we need to agree on some changes to the requirements first . This removes the requirement that the remote address match between PATHCHALLENGE / PATHRESPONSE . As said in : With PATHCHALLENGE going out on both paths , these duplicate packets create four outcomes depending on which packets arrive first : both paths appear to be valid , the right path only is valid , the wrong path only is valid , or neither path is valid . The current requirement that the source address of PATHRESPONSE matches the destination of the PATH_CHALLENGE can cause validation of the correct path to fail . In , there was some thought around performing path validation as a MUST " unless the endpoint has other means validate the validate the new path " . This text is a little stronger , saying that you MUST validate unless you have already done so and remembered --some of the mitigations to attacks being described rely on a guarantee that validation occurs ( and on both the old and the new paths ) . If folks wanted to have a completely separate mechanism for validating paths and considered their server / client to " know better " , I 'm not saying we should prohibit that , but such a mechanism would need to be analyzed in terms of the possible attacks . So far , I think this closes out the changes to actual requirements that are necessary , and can be followed with an editorial pass to group the requirements in a way that 's less confusing to first time readers ( and thanks to and others who gave this a close read in Prague ! ) . 
 One other section , can we leave this as - is ? Section 8.4 
 Latest text looks great , thanks 
 and I think we ’re good to go on this one , pending validating consensus on the list . 
 There are a few DoS vectors in migration that are n't well addressed in the draft . will follow soon with a short PR to address this issue . The current draft presents a specific case of a general attack . The generalized form of the attack is that the attacker observes both paths . He clones all packets from the client so that they appear to be from both addresses , and makes sure that all packets the server sends to each address both arrive at the client . He has the capability to out - race packets he observes . The attacker might fabricate a NAT rebinding that did n't happen , or spoof the old address during a rebinding . With PATHCHALLENGE going out on both paths , these duplicate packets create four outcomes depending on which packets arrive first : both paths appear to be valid , the right path only is valid , the wrong path only is valid , or neither path is valid . The current requirement that the source address of PATHRESPONSE matches the destination of the PATH_CHALLENGE can cause validation of the correct path to fail . 
 Waiting for to land this PR so a discussion can happen . 
 Is coming , apologies for the delay , been caught up in a few things immediately post - Prague . 
 The biggest change here to what ’s already in the draft is the perspective that the “ old ” path may not always be the desired one . That being said , I think we ’re still pretty well covered by the existing text describing the properties that already existed around new traffic from the client triggering it to go back to where it was previously , etc . such that an attacker would find it difficult to substantially interrupt a connection . 
 I think the attacker 's ability to do this argues for ignoring PATHRESPONSE frames that mismatch rather than actively considering the validation to have failed ; we that text already : This text perhaps needs to be broadened to talk about both source and destination address rather than simply " local address . " 
 Thanks for pulling up that text ! I think you 're correct in that we need to stop requiring remote address to match as well . That 's essentially removal of this paragraph talking about what a successful validation is : 
 I think the summary in the context of new information to do with these attacks is that an attacker can attack the NAT to effectively " take over " your port . Therefore , using the remote address is n't super useful . So far , we 've got some language that says you have to validate both the old and new path on any migration and use the old one if the new path fails to validate . Even if the old path is n't necessarily correct , an off - path attacker should not be able to cause validation of a path to fail -- it can either win the race with the packets and cause it to succeed over a different path , or it can lose that race and it validates on original path . That text is in { { on - path - spoofing } } : At the end of the day , the concern with an attacker migrating from off - path to on - path is pretty well covered by the existing text in { { off - path - forward } } : In all cases here , either the attacker continues to forward your packets faster than before ( they could always view them , so that 's not a new privilege for them ) , or they stop being faster / drop all the packets . As long as we 've induced traffic onto the connection such that it will " migrate " back to the correct / working path , then it 's not perfect , but we 're okay . All that to say , I think the requirements that are currently in the text are pretty much right , even taking into account the additional cases outlined in this issue . The few minor tweaks necessary should be covered by PR . 
 Any objection to just calling this editorial ? 
 Yeah , we got ta go full design here . This is a major change to the path validation logic . There 's a good case here for the change : path validation is currently unnecessarily symmetric . The decision to consider a path valid is a decision each peer makes unilaterally . That is , for the path to be used , both peers need to independently validate that packets sent on that path reach the other side . We do n't need the PATHRESPONSE to follow the path because we expect the peer to also send a PATHCHALLENGE down that path . The requirement that PATH_RESPONSE follow the path is a case of trying to attain or enforce behaviour from a peer unnecessarily . An endpoint does n't need to be assured that its peer has also validated the path , but that is what the existing text attempts to assure . If a peer decides not to validate a path , then that is on them . The fix here prevents an attacker from using the fact that duplicate packets are dropped to prevent path validation . And I ca n't see a down side . 
 Section 9 ( Connection Migration ) says : Section 9.2 ( Responding to   ) says : So : performing path validation ( Section 8.2 ) a SHOULD or a MUST ? I would prefer " a MUST , unless the endpoint has other means validate the validate the new path " sending subsequent packets immediately a MUST ? Not even a " MUST after validation " ? 
 This is almost an editorial issue , except that we need to agree on  vs. SHOULD . Please comment , folks . 
 I think Igor 's suggestion of " a MUST , unless the endpoint has other means validate the validate the new path " seems sensible , but either way this needs a PR . 
 I like 's suggestion , but I suspect upcoming PR that addresses ( and ) will cover this too . Let 's wait for that one first , since it should have more context and rationale . 
 I intuitively like MUST , but what would the implications be of SHOULD ? Would it broaden the attack surface ? Probably . Implications of MUST ? could an attacker force validation work by injection ? How bad could that get ? 
 I think elsewhere we had a " MUST , unless " for some of this , so sticking with that would be great ( to second Igor and  's comments ) . Re : SHOULD , agreed that it would potentially broaden the attack surface , since some of the mitigations ( the reason for the MUST in 9.2 ) rely on validation being performed . The attacker can cause you to generate validation packets by injection , but I think the discussion in should attempt to consider the implications of what happens when you end up validating on every incoming packet ( the worst possible case here , and definitely a good thing to think about ) . My intent here is to put the non - editorial changes in a small PR to get the normative language right and then potentially follow with a larger PR that 's ( hopefully ) purely editorial that rearranges these to get rid of some of the confusion around having requirements split across the sections . 
 FWIW , a " MUST , unless " is exactly what a SHOULD is 
 SHOULD is a lot weaker than " MUST , unless " because SHOULD allows skipping the behavior even if the " unless " part is not performed . " MUST A , unless B " is a syntactic sugar for " MUST A or B " . 
 From 2119 : And those circumstances should be discussed , which is the " unless " part . 
 I think is could be taking us a bit on a tangent , but my understanding of the quoted description of SHOULD is that it is used when " valid reasons [ .. ] to ignore " may exist but are not enumerated in the draft . In " MUST A , unless B " , B is explicitly named and hence this becomes " MUST A or B " . 
 Section 9 ( Connection migration ) says : If the server does not perform path validation upon a port change and no ip address change , this becomes a possible DoS vector for an attacker behind the same NAT as the client . The attacker must just capture and replay the packet from its own address , securing a new outgoing port on the NAT . 
 In my opinion , NAT rebinding should be treated like connection migration . I do n't see why we have to treat it differently . 
 The difference is that when performing connection migration , the client MUST change connection ID . On the other hand , when the NAT rebinds , the client is not immediately aware of it and there will be packets with the old connection ID coming from the new NAT binding . 
 the question is whether there is a difference from the server 's pov . I am saying that server 's response to any change in client source addresses / port SHOULD / MUST be path validation . 
 I have a branch out ( PR coming soon ) that removes this -- this part of the attack is something I think was looking at a bit . To point , the change of CID is a really strong signal that the client intends to migrate , but we may want to move that into a note along with the section we have for " server should use heuristics / be smart about what to choose " , since the definition in the text above does n't really change the requirements on the server 's behavior and that may confuse people . Whether or not we define it as migration really does n't change a whole lot , since we say ( or should say ) that the server has to validate the new path anyways . In other words , always validate everything , unless it 's something that 's previously passed path validation and not the one you 're migrating away from . note that the attack also relies on the attacker being able to race and beat the original client 's packet to the server , but there 's a whole section for that sort of attack ( although I think we need to add to it a bit , or make a variant for the attacker overloading the NAT ) . 
 I agree with and points 
 Nevermind , I did it . Looks great , and thanks for working through this Thanks , this seems sensible to me .
Paragraph (version A):
A stateless reset will be interpreted by a recipient as a packet with
a short header.  For the packet to appear as valid, the Unpredictable
Bits field needs to include at least 182 bits of data (or 23 bytes,
less the two fixed bits).  This is intended to allow for a
Destination Connection ID of the maximum length permitted, with a
minimal packet number, and payload.  The Stateless Reset Token
corresponds to the minimum expansion of the packet protection AEAD.
More unpredictable bytes might be necessary if the endpoint could
have negotiated a packet protection scheme with a larger minimum AEAD
expansion.
Paragraph (version B):
To entities other than its intended recipient, a stateless reset will
be appear to be a packet with a short header.  For the packet to
appear as valid, the Unpredictable Bits field needs to include at
least 182 bits of data (or 23 bytes, less the two fixed bits).  This
is intended to allow for a Destination Connection ID of the maximum
length permitted, with a minimal packet number, and payload.  The
Stateless Reset Token corresponds to the minimum expansion of the
packet protection AEAD.  More unpredictable bytes might be necessary
if the endpoint could have negotiated a packet protection scheme with
a larger minimum AEAD expansion.