Draft: draft-ietf-quic-transport

Commentary: I tried to be conservative about changes , but there were a few paragraphs I thought should be moved . Otherwise , the changes are minimal . is the commit that adds a paragraph to clarify the main confusion on 
 Something to look into ... 
 I was previously finding the text confusing and potentially contradictory . When I read it all at once , I believe I understand the intent , but hopefully this change makes each portion clearer and less dependent upon adjacent sections . There 's probably a bit more worth doing , but at some point I 'm willing to call it good enough . 
 We decided to only specify client - initiated connection migration in QUIC v1 . The section about Connection Migration mostly talks about endpoint and peer though , which makes it really hard to parse . I have n't implement migration yet in quic - go , and reading this section confused me at multiple places . I believe that specifying the role of the endpoint would make things a lot clearer , and could offer to come up with a PR . 
 I do n't think this is worth doing , but would look at a PR . 
 To clarify , this would only apply to connection migration , not the path validation section that immediately precedes it . 
 The idea was to keep the migration mechanisms generic , since they can be applied to either endpoint . However , this is n't adequate if we support migration at both ends , since you 'd have to deal with other situations , such as simultaneous migration . v1 simply limits the scope of where these mechanisms ought to be applied . There 's value in that , but I understand your reservations . Like I 'm not keen to follow the premise of this issue , but I 'd be open to a PR . I 'd also be open to clarifying the parts you found confusing . 
 Looking at that section again , I do n't believe I want to do anything about this issue . 
 This choice was deliberate . Maybe it 's nicer , but now is not really a good time . 
 Update : I thought simultaneous path validation was n't necessary , but it looks like I misunderstood . Changing this to an editorial issue so I can re - read this text and hopefully make it clearer . I believe this is already implied , but I could n't find it stated anywhere . I think it 'd be ideal to set expectations that servers are not expected to validate multiple paths at the same time . Validating multiple paths seems like a plausible feature for multipath , but adds undue complexity for connection migration . 
 Does that imply that a client can only probe a single path at a time ? What 's the time it has to wait after apparent unsuccessful probing of one path until it can probe the next ? 
 I 'm not sure if I agree . It has been my assumption that a server is expected to respond to clients probing multiple paths concurrently . Note that in , we the following text : 
  , I did n't think this was already implied . You 're not expected ( or allowed ) to send non - probing packets on multiple paths , but you can certainly get probes in from multiple different remote endpoints . This is somewhat necessary if we 're to be resilient to the various packet racing attacks -- if an attacker can cause you to be upset about a packet coming in from a different destination then they can really mess you up . 
 I 'm a bit confused about why a client needs to probe multiple paths simultaneously , given we have connection migration , not multipath . To me , it just adds complexity . I guess I can just give out a single CID to mitigate the issue , but do we really expect servers to correctly implement probing on multiple paths ? What if they all succeed ? A client can still only use one . can you clarify the packet racing issue a bit more or point me to text that already does ? I 'd like to draw a state transition diagram for path validation , but if we can have multiple paths being validated at once , I 'm not sure that 's practical . 
 So the scenario is that a client is using one path and has 2 or more new ones available ? I 've heard future hardware could make that possible , though I 've never seen that case myself . The short of this is now that we 're trying to move to IETF QUIC style connection migration and path validation , and I 'm finding it fairly confusing . 
 I think there 's a pretty big distinction between probing a path to establish the potential for connectivity and migrating the connection to that path . For example , I would not be at all surprised if a client were to probe all available paths and choose the " best " one to migrate to when the need arises ( often , although not always , there is some warning that conditions are worsening on the current path which provides the opportunity to evaluate alternatives ) . That said , I think a large part of the reason to allow probing on multiple paths is to avoid requiring synchronization of a shared understanding as to the state of current probes . We do n't want to add a bunch of machinery to establish failure of a probe on a different path . So even if we do n't think that a client would ever intentionally probe multiple paths , if a client probes one path and hears no response , it seems completely reasonable to think that it would switch and probe a different path if it had one available . If it turns out that there was just some delay for that initial path , say it had a 1.5s RTT , now the server is going to think the client probed two paths at the same time , when in reality the client thinks it 's just talking to one . It also does n't seem particularly harmful to allow this ? As noted , there 's some good text in there about limiting state required on the server , and of course path validation can happen at any time , so it seems completely reasonable to " forget " that any given path was validated if a client probes and then does n't end up using the path . ( Note that you 'd likely want to retire the CID used on that path , so as to replace it with a new one when you did that forgetting , which also serves as a nice heuristic for the other endpoint to say " oh , hmm , they do n't think they 're talking to me over there " , but we can dig into that later . ) The packet racing thing is a reference to and the previous section . This led us to require endpoints to validate both the current and the new path when it changes , which conveniently provokes some traffic to reconfirm the active path and makes it more difficult to disrupt a connection that 's gone idle . While technically this is only discussing one " new " path and then the old path being validated at the same time , it seems as though it would be trivial for such an attacker to convince an endpoint that it was seeing " probes " ( since we 've discussed that it 's not that difficult to identify a probing packet as an observer ) from multiple paths and therefore be quite upset if such behavior were restricted . I 'm not saying this happens all the time , but it seems pretty reasonable to have a Wi - Fi interface and then a dual SIM device with multiple cellular interfaces . Overall , it seems as though ( even if this is n't crazy common ) it 's not unreasonable to expect that this behavior might happen , and it does n't seem like there 's a big benefit to restricting it , nor harm in allowing it , beyond the existing text reminding endpoints to be careful with the amount of state they 're willing to allocate to any individual client ( which is a thing outside of any probing / migration concept anyways ) . 
 +1 to what says . The resolution of ( which ended up as PR ) was that a server has to remember state of N paths where N is the number of CIDs active at one time . As says , a client can not tell when a server thinks that it received two probes concurrently . Therefore , it is very tricky to have this kind of restriction within a specification that allows clients to retain multiple backup paths . 
 I agree with and here . If a client sends a probe on interface A , and then interface A disconnects and then interface B appears immediately , the client should be able to probe on interface B even though to the server will receive two independent probes at roughly the same time . Servers need to be able to handle multiple concurrent probes in order for migration to be reliable . 
 Note that while the server needs to respond to the probes ( so the client can validate the paths ) , I do n't think there 's any requirement that the server continue to regard all those paths as validated . When the client actually migrates , if the server wants to treat the migration as an unvalidated path and initiate validation again , that seems fine . 
 Well , the paths are n't validated until the server explicitly validates them , so it seems like the cost is pretty minimal until the server decides to engage resources for that path . The server can also respond on the old path if the client is just probing . 
 do you want to think about how you reached your conclusion here and see if there is something we can do to avoid that ? It seems to me that the cost to a server is limited by how many paths it wants to probe , not how many the client probes , so the state is well managed . It 's a little less neat if the client actively migrates multiple times . But I would say that the server can abandon probes to keep the number of active probes down to at most 2 ( one for the most recent validated path , one for the most recent active path ) . Is that something we need to explain more thoroughly ? 
 I have read this text quite a bit , but not end - to - end in quite a long time , so I believe that 's the cause of my confusion . I 'm planning to re - read all the path validation and connection migration text and I 'll send out a PR if there are points that I think I are unclear . 
 have you had a chance to do this ? 
 Unfortunately , not yet . 
 Note that man - on - the - side attacker can take a valid packet and resend it from a different address . The crypto does not protect against that . If the attacker somehow isolates probe packets , the server will end up receiving probes from a variety of endpoints . Better not do something silly in that condition . 
 Would people please take a final look at the PR ? 
 A few comments , but pretty close .
Paragraph (version B):
Path validation is used by both peers during connection migration
(see migration) to verify reachability after a change of address.  In
path validation, endpoints test reachability between a specific local
address and a specific peer address, where an address is the two-
tuple of IP address and port.
Paragraph (version B):
Path validation does not validate that a peer can send in the return
direction.  Acknowledgments cannot be used for return path validation
as they contain insufficient entropy and might be spoofed.  Endpoints
independently determine reachability on each direction of a path, and
therefore return reachability can only be established by the peer.
Paragraph (version A):
An endpoint MAY include PATH_CHALLENGE and PATH_RESPONSE frames that
are used for path validation with other frames.  In particular, an
endpoint can pad a packet carrying a PATH_CHALLENGE for Path Maximum
Transfer Unit (PMTU) discovery (see pmtud), or an endpoint can
include a PATH_RESPONSE with its own PATH_CHALLENGE.
Paragraph (version A):
When probing a new path, an endpoint might want to ensure that its
peer has an unused connection ID available for responses.  The
endpoint can send NEW_CONNECTION_ID and PATH_CHALLENGE frames in the
same packet.  This ensures that an unused connection ID will be
available to the peer when sending a response.
Paragraph (version B):
An endpoint MAY include other frames with the PATH_CHALLENGE and
PATH_RESPONSE frames used for path validation.  In particular, an
endpoint can include PADDING frames with a PATH_CHALLENGE frame for
Path Maximum Transfer Unit (PMTU) discovery (see pmtud); it can also
include a PATH_CHALLENGE frame with its own PATH_RESPONSE frame.
Paragraph (version B):
An endpoint uses a new connection ID for probes sent from a new local
address; see migration-linkability.  When probing a new path, an
endpoint expecting responses on the new path needs to ensure that its
peer has an unused connection ID.  Sending NEW_CONNECTION_ID and
PATH_CHALLENGE frames in the same packet ensures that an unused
connection ID will be available to the peer when sending a response.
Paragraph (version B):
An endpoint can choose to simultaneously probe multiple paths.  The
number of simultaneous paths used for probes is limited by the number
of extra connection IDs its peer has previously supplied, since each
new local address used for a probe requires a previously unused
connection ID.
Paragraph (version B):
An endpoint MAY send multiple PATH_CHALLENGE frames to guard against
packet loss.  However, an endpoint SHOULD NOT send multiple
PATH_CHALLENGE frames in a single packet.
Paragraph (version B):
An endpoint SHOULD NOT probe a new path with packets containing a
PATH_CHALLENGE frame more frequently than it would send an Initial
packet.  This ensures that connection migration is no more load on a
new path than establishing a new connection.
Paragraph (version A):
Path validation is necessary to verify reachability of a peer on a
new network path.  Acknowledgments cannot be used for path validation
as they contain insufficient entropy and might be spoofed.  No method
is provided to establish return reachability, as endpoints
independently determine reachability on each direction of a path.
Paragraph (version A):
In response to such a packet, an endpoint MUST start sending
subsequent packets to the new peer address and MUST initiate path
validation (migrate-validate) to verify the peer's ownership of the
unvalidated address.
Paragraph (version B):
In response to such a packet, an endpoint MUST send subsequent
packets to the new peer address and MUST initiate path validation
(migrate-validate) to verify the peer's ownership of the address if
validation is not already underway.