Re: Fast Address Validation - about

[Marten Seemann <[e-mail]>]

I don't see any enhanced client experience, since the handshake takes
exactly the same number of round trips with your proposal as with the
current version of the QUIC draft.
Sending NEW_TOKEN in Initial packets provides no benefit over sending it in
1-RTT packets, but comes with worse privacy properties, since Initial
packets are not encrypted and can therefore be read by on-path observers.

On Fri, Nov 1, 2019 at 7:37 PM Qing An <[e-mail]> wrote:

>
> If so, for the first connection between client and server, server can
> choose to eliminate the use of Retry packet for token delivery, and
> rely on handshake encryption layer to prove return routability.
> In addition, New_Token frame is used by
> server, via i.e. the Initial packet, to provide the client with an
> address validation token that can be used to validate future connections.
>
> It can enhance the experience in client side for the first connection
> establishment.
>
> I submitted the draft,
> https://datatracker.ietf.org/doc/draft-an-fast-address-validation/
>
> Qing
>
>
>
> ------------------------------------------------------------------
> From:Mike Bishop <[e-mail]>
> Send Time:2019年11月1日(星期五) 00:06
> To:安勍(莳逸) <[e-mail]>; quic <[e-mail]>; jri.ietf <
> [e-mail]>; mt <[e-mail]>; mikkelfj <[e-mail]>
> Subject:RE: Fast Address Validation - about
>
> As Martin pointed out in the e-mail you replied to, if the server is
> willing to maintain state, any packet at the Handshake encryption layer
> proves return routability.  There seems to be no need for a separate
> address validation mechanism if the server is willing to proceed with the
> handshake.
>
>
>
> *From:* QUIC <[e-mail]> *On Behalf Of * Qing An
> *Sent:* Thursday, October 31, 2019 8:56 AM
> *To:* quic <[e-mail]>; jri.ietf <[e-mail]>; mt <
> [e-mail]>; mikkelfj <[e-mail]>
> *Subject:* Re: Fast Address Validation - about
>
>
>
>
>
>
>
> To clarify, the proposal is not to replace the existing Retry-based
> validation, but to provide another option for server to do the client
> validation.
>
>
>
> I understand that in server side, exchanging the token at the Handshake encryption level
> will make the server start to maintain handshake states. But in client
> side, it can accelerate the connection establishment from client to server.
>
>
>
> And it is the server's decision whether to exchange token in Retry or in
> Handshake. If server chooses to accept the cost brought by token exchanging
> in Handshake, it will bring more enhanced experience in client side.
>
>
>
>
>
> BR,
>
> Qing
>
>
>
>
>
> ------------------------------------------------------------------
>
> From:Martin Thomson <[e-mail]>
>
> Send Time:2019年10月31日(星期四) 06:07
>
> To:quic <[e-mail]>
>
> Subject:Re: Fast Address Validation - about
>
>
>
>
> Also note that exchange of Handshake packets provides proof of return routeability via the use of the encryption keys, so there is no need to exchange tokens at that level.
>
> On Thu, Oct 31, 2019, at 03:29, Mike Bishop wrote:
> >
> > The advantage of using Retry, however, is that the server is able to
> > keep minimal (if any) state about the client. Exchanging the token at
> > the Handshake encryption level means the server is already doing work
> > and maintaining state in order to process the handshake, which is
> > exactly what the server is trying to avoid.
> >
> >
> > *From:* QUIC <[e-mail]> *On Behalf Of * Qing An
> > *Sent:* Wednesday, October 30, 2019 9:41 AM
> > *To:* quic <[e-mail]>; jri.ietf <[e-mail]>; mt
> > <[e-mail]>
> > *Cc:* 刘大鹏(鹏成) <[e-mail]>
> > *Subject:* Fast Address Validation - about
> >
> >
> >
> >
> > Hi Martin, Jana,
> >
> > I read through https://www.ietf.org/id/draft-ietf-quic-transport-23.txt
> > and have a few comments and ideas to discuss.
> >
> >
> > [QUIC-Trans] defines a token based scheme to facilitate address
> > validation of a client. The token MUST be covered by integrity
> > protection against modification or falsification by clients. The server
> > remembers the value it sends to clients and validates the token sent
> > back from a client. In its design, Retry packet is used to deliver the
> > token to a client which address has not yet been validated. It voids
> > the first transmission of the Initial packet sent by the client, and
> > triggers a second Initial packet to be sent with the token. The
> > exchange of token will cause longer connection establishment delay for
> > a client.
> >
> >
> > To improve the efficiency of address validation during handshake, one
> > idea is that the same token can be exchanged via a different container
> > i.e. the Handshake packet, that eliminates the use of Retry packet for
> > token delivery.
> >
> >
> > I am working on the complete draft and will submit it by Friday. Before
> > that, hope this can be discussed in email first.
> >
> >
> > BR,
> >
> > Qing An
> >
>
>
>
>
>