Subject: Fast Address Validation - about

From: "Qing An" <[email-masked]>
Date: Wed, 30 Oct 2019 21:41:10 +0800

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

---

From: Mikkel Fahnøe Jørgensen <[email-masked]>
Date: Wed, 30 Oct 2019 13:56:03 +0000

Please keep in mind that Retry can be used by a server that does not want
to spend resources on the handshake and to redirect traffic elsewhere, it
is not just for validation. And when it is not a redirect, the server might
want the roundtrip to make sure the client is really interested and able
before committing resources to process the handshake.

Thus, trying to optimise this step might work against the idea, at least
for some use cases.

Mikkel

On 30 October 2019 at 14.41.29, Qing An ([email-masked]) wrote:

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

---

From: Mike Bishop <[email-masked]>
Date: Wed, 30 Oct 2019 16:29:11 +0000

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 <[email-masked]> On Behalf Of Qing An
Sent: Wednesday, October 30, 2019 9:41 AM
To: quic <[email-masked]>; jri.ietf <[email-masked]>; mt <[email-masked]>
Cc: 刘大鹏(鹏成) <[email-masked]>
Subject: Fast Address Validation - about

Hi Martin, Jana,

BR,
Qing An

---

From: "Martin Thomson" <[email-masked]>
Date: Thu, 31 Oct 2019 09:07:19 +1100

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 <[email-masked]> *On Behalf Of * Qing An
> *Sent:* Wednesday, October 30, 2019 9:41 AM
> *To:* quic <[email-masked]>; jri.ietf <[email-masked]>; mt 
> <[email-masked]>
> *Cc:* 刘大鹏(鹏成) <[email-masked]>
> *Subject:* Fast Address Validation - about
> 
> 
> 
> 
> Hi Martin, Jana, 
> 
> 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. 
> 
>

---

From: "Qing An" <[email-masked]>
Date: Thu, 31 Oct 2019 20:55:56 +0800

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 <[email-masked]>
Send Time:2019年10月31日(星期四) 06:07
To:quic <[email-masked]>
Subject:Re: Fast Address Validation - about

---

From: Mike Bishop <[email-masked]>
Date: Thu, 31 Oct 2019 16:05:16 +0000

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 <[email-masked]> On Behalf Of Qing An
Sent: Thursday, October 31, 2019 8:56 AM
To: quic <[email-masked]>; jri.ietf <[email-masked]>; mt <[email-masked]>; mikkelfj <[email-masked]>
Subject: Re: Fast Address Validation - about

BR,
Qing

------------------------------------------------------------------
From:Martin Thomson <[email-masked]<mailto:[email-masked]>>
Send Time:2019年10月31日(星期四) 06:07
To:quic <[email-masked]<mailto:[email-masked]>>
Subject:Re: Fast Address Validation - about

On Thu, Oct 31, 2019, at 03:29, Mike Bishop wrote:
> *From:* QUIC <[email-masked]<mailto:[email-masked]>> *On Behalf Of * Qing An
> *To:* quic <[email-masked]<mailto:[email-masked]>>; jri.ietf <[email-masked]<mailto:[email-masked]>>; mt
> <[email-masked]<mailto:[email-masked]>>
> *Cc:* 刘大鹏(鹏成) <[email-masked]<mailto:[email-masked]>>