Re: Fwd: New Version Notification for draft-kazuho-quic-address-bound-token-00.txt

[Christian Huitema <[e-mail]>]

I am reading the draft, and I think that the discussion of congestion
control should be removed. Senders have all latitude to coordinate
transmission control across multiple connections, including using some
form of multi-connection congestion control. I think the draft would be
easier to read if it concentrated on just one purpose, the linkage of
new tokens to server addresses instead of service identities.

We probably need a slightly larger security analysis. What if a service
part of a farm issued such a token without coordinating with the other
services that use the same address? Could that be a form of DOS?

-- Christian Huitema

On 4/3/2019 11:15 PM, Mikkel Fahnøe Jørgensen wrote:
> Nice work.
>
> Just a minor thing on priority in the appendix: what about IPv6
> priorities? That, and flow labels - are we starting to bypass much of
> the IPv6 design because it is not (yet?) sufficiently widely deployed?
> Or are there security implications, and if so, should QUIC consider
> authenticating parts of the IPv6 header?
>
> Also, on name based alternative:
> I’m wondering which non-HTTP/3 connections would really benefit as new
> designs can build in multi-purpose into the protocol whereas HTTP/3
> must follow HTTP semantics. You could argue about WebRTC/3 - but then
> - what should it co-locate with which has sufficient intelligence to
> share the congestion controller? You could argue share with HTTP/3,
> but that would probably not rule out a name based solution either.
> I’m not saying name based CG sharing is necessarily better, I’m just
> wondering.
>
> OTOH if name based sharing is used that could place some assumptions
> on a given load balancers tuple stickiness, if I understand correctly.
> That could be unfortunate. Or, if name sharing is only to target
> address validation of the client perhaps different server hosts could
> share that information successfully with a random or round robin load
> balancer?
>
> Mikkel
>
> On 4 April 2019 at 07.22.32, Kazuho Oku ([e-mail]
> <mailto:[e-mail]>) wrote:
>
>> Hi,
>>
>> I have (finally) submitted "Address-bound Token for QUIC" I-D, that
>> proposes a QUIC extension allowing tokens to be shared between
>> connections that go to the same server address, even when the value of
>> SNI is different. Having such tokens would maximize our chance of
>> skipping address validation and slow-start phase.
>>
>> The I-D and the repo can be found at the links below:
>>
>> I-D:
>> https://datatracker.ietf.org/doc/draft-kazuho-quic-address-bound-token/
>> Github repo:
>> https://github.com/kazuho/draft-kazuho-quic-address-bound-token
>>
>> Please let us know what you think.
>>
>> Rationale behind the proposal:
>>
>> The startup phase (a.k.a. slow-start) is one of the things that has
>> negative impact on user experience. QUIC, in addition to reducing the
>> connection establishment latency from TCP, provides the possibility of
>> a server skipping the startup phase when a client provides a valid
>> token.
>>
>> However, the probability of a server being able to skip the startup
>> phase relies on how frequent a user revisits a particular server,
>> identified by the value of the TLS SNI extension. To put another way,
>> there is a missed opportunity if a client is visiting a server
>> instance that it has previously visited with a different server name.
>>
>> Our proposal addresses exactly that. The proposed extension allows a
>> client to use a token for a different server name, if the server
>> address is the same. This maximizes the chance of the server skipping
>> address validation and the startup phase.
>>
>>
>> ---------- Forwarded message ---------
>> From: <[e-mail] <mailto:[e-mail]>>
>> Date: 2019年4月4日(木) 14:17
>> Subject: New Version Notification for
>> draft-kazuho-quic-address-bound-token-00.txt
>> To: Kazuho Oku <[e-mail] <mailto:[e-mail]>>
>>
>>
>>
>> A new version of I-D, draft-kazuho-quic-address-bound-token-00.txt
>> has been successfully submitted by Kazuho Oku and posted to the
>> IETF repository.
>>
>> Name: draft-kazuho-quic-address-bound-token
>> Revision: 00
>> Title: Address-bound Token for QUIC
>> Document date: 2019-04-04
>> Group: Individual Submission
>> Pages: 6
>> URL:
>> https://www.ietf.org/internet-drafts/draft-kazuho-quic-address-bound-token-00.txt
>>
>> Status:
>> https://datatracker.ietf.org/doc/draft-kazuho-quic-address-bound-token/
>> Htmlized:
>> https://tools.ietf.org/html/draft-kazuho-quic-address-bound-token-00
>> Htmlized:
>> https://datatracker.ietf.org/doc/html/draft-kazuho-quic-address-bound-token
>>
>>
>>
>> Abstract:
>> This document describes a QUIC extension for an address-bound token.
>> This token can be used for sharing address validation and congestion
>> controller state between the same two endpoints across multiple
>> connections and origins.
>>
>>
>>
>>
>> Please note that it may take a couple of minutes from the time of
>> submission
>> until the htmlized version and diff are available at tools.ietf.org
>> <http://tools.ietf.org>.
>>
>> The IETF Secretariat
>>
>>
>>
>> -- 
>> Kazuho Oku
>>