Re: Alternative ways to keeps ODCID on the server

[Marten Seemann <[e-mail]>]

The client knows if it used a NEW_TOKEN token. More specifically, the
client knows if it received and responded to a Retry packet.

On Tue, Jan 28, 2020 at 11:21 AM Christian Huitema <[e-mail]>
wrote:

>
> On 1/27/2020 7:11 PM, Marten Seemann wrote:
>
> > That's actually what I implemented. If the token can be verified, accept
> > the connection, treat it as validated. If it cannot be verified, check
> > whether the token is necessary, e.g., would any incoming connection
> > trigger retry. If it is necessary, drop the connection; if not
> > necessary, continue as if no token was there.
>
> Doesn't that defeat the purpose of the original_connection_id transport
> parameter? We introduced it to prevent middleboxes from performing a Retry.
> With this logic, a middlebox could perform a Retry, and then corrupt the
> token on the second Initial to trick the server into accepting the
> connection.
> Furthermore, client implementation will check for the
> original_connection_id TP, and fail the connection if this TP is missing.
>
> The spec also has language that I'd interpret as forbidding this:
> If the server sends a Retry packet, it MUST include the Destination
> Connection ID field from the client's first Initial packet in the transport
> parameter.
>
> How do you reconcile that requirement with the "NEW TOKEN" mechanism? If
> the Initial packet carries a NEW TOKEN, it will be accepted and there won't
> be any ODCID transport parameter.
>
> -- Christian Huitema
>