Re: Alternative ways to keeps ODCID on the server

[Dmitri Tikhonov <[e-mail]>]

The server cannot pretend as if the Retry token weren't there,
because the client knows that it sent the Retry token and will
verify the subsequent Initial packet from the server according
to rules in Section 17.2.5 [1]:

   If the client received and processed a Retry packet, it MUST validate
   that the original_connection_id transport parameter is present and
   correct; otherwise, it MUST validate that the transport parameter is
   absent.  A client MUST treat a failed validation as a connection
   error of type TRANSPORT_PARAMETER_ERROR.

A conformant client will fail the connection.

  - Dmitri.

1. https://tools.ietf.org/html/draft-ietf-quic-transport-25#section-17.2.5

On Tue, Jan 28, 2020 at 07:39:48AM +0900, 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).
> 
> Maybe changing "verifying the token" to "as if there was no token being
> attached" would clarify things?
> 
> 2020年1月27日(月) 22:15 Dmitri Tikhonov <[e-mail]>:
> 
> > After considering this for a few days, I now think that the "server
> > MAY proceed" part should be removed from the draft.  This is because
> > it is impossible to get ODCID from an invalid Retry token.  There is
> > no other way reliably to associate an incoming packet with a previous
> > packet (if the server were willing to stored ODCIDs in memory
> > somewhere).
> >
> > Specifying that the server MAY proceed only makes the issue more
> > confusing.
> >
> >   - Dmitri.
> >
> > On Sat, Jan 25, 2020 at 04:36:51PM -0500, Ian Swett wrote:
> > > 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
> > > >
> > > >
> >
> >
> 
> -- 
> Kazuho Oku