Re: Alternative ways to keeps ODCID on the server

[Ian Swett <[e-mail]>]

This is a bit of an edge case, so spelling out what's required to proceed
seems reasonable to me.

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

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