[quicwg/base-drafts] Consider three ways handshake for new paths (#1749)

[Christian Huitema <[e-mail]>]

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.

          


-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/1749