Re: KEYS_READY

[Christian Huitema <[e-mail]>]

On 2/13/2019 4:33 PM, Martin Thomson wrote:

> PATH_CHALLENGE/PATH_RESPONSE have baggage, so I don't want to use those.  A new challenge/response could work, but it doesn't offer much over a simple assertion (which is what the proposed frame is).  If the assertion is wrong, then the consequence is a broken connection, so there isn't much incentive to get this wrong.  PATH_CHALLENGE/PATH_RESPONSE contain a field that protects against lying, because there are scenarios in which lying provides advantage (that is, the "DoS this IP please" case).

Yes, I can see the logic behind that. I like the challenge/response
because it has a clean state machine behind hit: send a challenge,
expect a response, if the response does not come, repeat the challenge,
if it still does not come, give up the path. The combination of the
phase change and the KEY ACTIVE frame is not so clean. The phase change
plays the same role as the challenge and the frame plays the same role
as the response, but there is no way to repeat the challenge if the
response is not received: the peer has to wait for the diligence and
good will of the other peer.

Of course, if the KEY ACTIVE frame requires an acknowledgement, it
should arrive eventually. But what if it doesn't? What if the peer did
not send it, or did not correctly retransmit it? Should the endpoint
just abort the connection if some number of RTO pass after the phase
change, and the KEY ACTIVE frame has not been received yet? Does the
behavior change if some traffic encrypted with the new phase has been
acknowledged?

-- Christian Huitema