Re: Alternative ways to keeps ODCID on the server

[Christian Huitema <[e-mail]>]

On 1/24/2020 8:41 PM, Marten Seemann wrote:
> 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).


I understand that they are different. But look at the text in draft-25:

   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 <https://tools.ietf.org/html/draft-ietf-quic-transport-25#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.

Invalid is invalid. An invalid token is something that the server cannot parse.
The server does not know whether the client got the token from a retry packet
or a new token frame, or just made it up with random bytes. 

-- Christian Huitema