Re: Alternative ways to keeps ODCID on the server

[Marten Seemann <[e-mail]>]

> 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.




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

> On 1/27/2020 2:39 PM, Kazuho Oku wrote:
>
> > I am not sure if I agree with dropping the sentence.
> >
> > IIRC, this sentence (i.e. "server MAY proceed with the connection
> > without verifying the token, though the server MUST NOT consider the
> > client address validated.") suggests that a server might proceed the
> > handshake as if it did not receive the token when that token cannot be
> > used.
> >
> > I think that is not an unreasonable thing to do along with the other
> > two stated option (i.e. discard packet, send CONNECTION_CLOSE without
> > creating state).
>
> 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.
>
> -- Christian huitema
>
>