Consider three ways handshake for new paths

[huitema]

For privacy reasons, we want that communication between peers happens on path defined by a pair of addresses and identified by a pair of connection ID. For security reasons, we also want to not use paths before their continuity has been tested. Implementations end up doing that with an "ad hoc" three ways handshake:

Client API:  please test a new path between dest and srce addresses.
Client: 
picks fresh connection ID from list provided by server.
sends "probe" (path challenge) to/from selected addresses, to selected CID.
                                    Server Node:
                                    receives the path challenge
                                    picks fresh connection ID from list provided by client.
                                    sends probe response (path challenge response and path challenge) to selected CID
receives probe response.
uses address pair to correlate with one of the probes in progress.
associate server selected "client CID" with client selected "server CID".
consider path validated.
sends challenge response
                                    receives response. considers path validated.

Developers can make that work, and in fact it works in my code. But it is very brittle. It will fail if:

1. There is no fresh server CID available at the client to start the process.
2. There is no fresh client CID available at the server.
3. Somehow the client cannot correlate the incoming response with a pending probe.

The first condition is unavoidable -- the client needs a fresh ID, and the server needs accept packets through it. But the other failure modes could be avoided, and a slight redesign would make the whole process more robust. The idea would be to recognize that this is a 3-ways handshake, and treat it as such:

Client API:  please test a new path between dest and srce addresses.
Client: 
picks fresh connection ID from list provided by server.
picks new local CID.
sends "probe" towards server selected CID with three parameters: 
probe challenge, client source CID, client reset token.
                                    Server Node:
                                    receives the probe. If it is ready to accept it,
                                    sends probe response to client source CID with two parameters:
                                    probe response and server challenge
receives probe response.
uses destination CID to correlate with probe in progress.
consider path validated.
sends challenge response to server.
                                    receives response. considers path validated.

Recognizing the probes as such makes bookkeeping much easier. It also allows enforcement of privacy rules: use exactly one CID for each of the peer CID. But of course, it requires three or four new frames; PATH_PROBE, PATH_RESPONSE, PATH_CONFIRM. And maybe something like PATH_RESET.

[ianswett]

Thanks for the detailed description.

If you added a client CID and reset token in the PATH_CHALLENGE/PATH_PROBE, then you could use receipt of any packet on the new path with the newly specified connection ID as path confirmation I believe? And at that point the responder(server) could use acknowledgement of the packet it sent as confirmation? But possibly that has problems I wouldn't anticipate?

PATH_RESET or PATH_CLOSE is likely going to be useful for multipath, but I'm not sure why it needs to be added for migration? Adding it seems orthogonal to the rest of this issue as well.

[MikeBishop]

There is another issue to include CID frames in the probes, which solves part of this. You shouldn't be using the path to match the probe response -- you use the CID to identify the connection, then the value of the probe response to identify which probe is being answered. The only thing the address is used for is to validate that the response came back from the right endpoint.

[martinthomson]

Closed by #2033.