Re: Fast Address Validation - about

["Martin Thomson" <[e-mail]>]

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
>