Re: Alternative ways to keeps ODCID on the server

[Marten Seemann <[e-mail]>]

Then it's not a *Retry* token, then it's a NEW_TOKEN token.
It's a kind of subtle distinction (as I noted in
https://github.com/quicwg/base-drafts/pull/3107#discussion_r349859380).

On Sat, Jan 25, 2020 at 9:18 AM Christian Huitema <[e-mail]>
wrote:

> On 1/24/2020 2:24 PM, Dmitri Tikhonov wrote:
> > Hello,
> >
> > PR 3107 introduced the following text:
> >
> >    If a server receives a client Initial that can be unprotected but
> >    contains an invalid Retry token, it knows the client will not accept
> >    another Retry token.  The server can discard such a packet and allow
> >    the client to time out to detect handshake failure, but that could
> >    impose a significant latency penalty on the client.  A server MAY
> >    proceed with the connection without verifying the token, though the
> >    server MUST NOT consider the client address validated.  If a server
> >    chooses not to proceed with the handshake, it SHOULD immediately
> >    close (Section 10.3) the connection with an INVALID_TOKEN error.
> >    Note that a server has not established any state for the connection
> >    at this point and so does not enter the closing period.
> >
> > The problem with the "server MAY proceed" part is that the server's
> > transport parameters MUST include original_connection_id.  If ODCID
> > cannot be extracted from the invalid Retry token, then the server
> > cannot let this connection proceed.
> >
> > Questions:
> >
> >     1. The Retry token seems like the obvious place for the server
> >        to store ODCID.  Is there an implementation that does something
> >        else (state on server)?
> >
> >     2. Should we spell out this caveat in the draft?  I.e. "server MAY
> >        proceed if it possesses ODCID."
>
>
> What if the Initial packet carried a token from an expired NEW TOKEN frame?
>
> -- Christian Huitema
>
>