Re: Fast Address Validation - about

[Mikkel Fahnøe Jørgensen <[e-mail]>]

You only save a roundtrip because you do not send a Retry.

If you choose not to send a Retry, the client eventually gets validated
anyway because otherwise the handshake could not complete. Therefore a
Retry token is not needed if you go down that path. In this case the RTT
overhead with fast address validation is the same as ordinary QUIC 1-RTT
handshake.

On the other hand, in the case where Retry is needed, the fast address
validation approach does not solve the problem which is one of 1) defer
handshake processing and server state until after the address is verified,
or 2) redirect the client to another server through a change in
ConnectionID.



On 1 November 2019 at 14.26.24, Qing An ([e-mail]) wrote:


I believe this can save 1-RTT.

As for the privacy risk, new_token frame can be delivered via handshake


------------------------------------------------------------------
From:Marten Seemann <[e-mail]>
Send Time:2019年11月1日(星期五) 20:54
To:安勍(莳逸) <[e-mail]>
Cc:QUIC <[e-mail]>; quic <[e-mail]>; jri.ietf <
[e-mail]>; mt <[e-mail]>; mikkelfj <[e-mail]>;
刘大鹏(鹏成) <[e-mail]>
Subject:Re: Fast Address Validation - about

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
>