Re: Fast Address Validation - about

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

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 ([e-mail]) 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