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

From: Kazuho Oku <[email-masked]>
Date: Thu, 4 Apr 2019 14:22:04 +0900

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: <[email-masked]>
Date: 2019年4月4日(木) 14:17
Subject: New Version Notification for
draft-kazuho-quic-address-bound-token-00.txt
To: Kazuho Oku <[email-masked]>

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.

The IETF Secretariat

-- 
Kazuho Oku

---

From: Mikkel Fahnøe Jørgensen <[email-masked]>
Date: Thu, 4 Apr 2019 06:15:17 +0000

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 ([email-masked]) wrote:

Hi,

---------- Forwarded message ---------
From: <[email-masked]>
Date: 2019年4月4日(木) 14:17
Subject: New Version Notification for

Abstract:

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.

The IETF Secretariat

-- 
Kazuho Oku

---

From: Christian Huitema <[email-masked]>
Date: Wed, 3 Apr 2019 23:47:34 -0700

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?
>
> 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.
> 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 ([email-masked]
> <mailto:[email-masked]>) wrote:
>
>> Hi,
>>
>> I-D:
>> Github repo:
>> https://github.com/kazuho/draft-kazuho-quic-address-bound-token
>>
>> From: <[email-masked] <mailto:[email-masked]>>
>> Date: 2019年4月4日(木) 14:17
>> To: Kazuho Oku <[email-masked] <mailto:[email-masked]>>
>>
>>
>>
>> until the htmlized version and diff are available at tools.ietf.org
>> <http://tools.ietf.org>.
>>
>> The IETF Secretariat
>>
>>
>>
>> -- 
>> Kazuho Oku
>>

---

From: Kazuho Oku <[email-masked]>
Date: Thu, 4 Apr 2019 16:20:11 +0900

Hi Mikkel,

Thank you for your comments. My responses inline.

2019年4月4日(木) 15:15 Mikkel Fahnøe Jørgensen <[email-masked]>:
>
> 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?

I do not have an opinion on the design aspects of IPv6, but I can see
at least two use-cases where you would want to use the priority scheme
described in the I-D.

1. Prioritization between different browser tabs. A web browser can
raise the priority of a connection that is bound to the window tab
that's in the front. This is the type of signal should not be exposed
to on-path observers, though we have thought that it's beneficial
between endpoints (IIRC that was one of the use-cases when we designed
the HTTP/2 prioritization scheme).

2. End-to-end cross-connection prioritization on a connection using
VPN. Related thought: maybe we need a separate TP that allows a client
to opt-out from a server using IP precedence.

> 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.

I am not sure if I am following, but I'd argue that there are two ways
of using the token. One is to consolidate the congestion controller,
and the other is to reuse the most up-to-date path information (e.g.,
BDP, RTT). For the former, it's essential to use the IP address as the
scope, because that's what identifies a server instance within which a
state can be shared. For the latter, the scope does not matter, though
the probability of receiving a fresh taken rises as the scope gets
bigger. That's one of the reasons the scope proposed by the draft is
"union of server-name and server's address tuple" (the other reason is
to avoid sending two types of tokens).

>
> 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
>

-- 
Kazuho Oku

---

From: Kazuho Oku <[email-masked]>
Date: Thu, 4 Apr 2019 16:32:58 +0900

Hi Christian,

2019年4月4日(木) 15:48 Christian Huitema <[email-masked]>:
>
> 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.

That's a good suggestion. I agree that it does not need to be in this
document, even though I think it is beneficial to describe how you
could have a shared congestion controller. At the very least, it
should be moved to the appendix.

>
> 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?

Would you mind elaborating about the scenario a bit more? I ask this
because I am not sure if that is a practical attack. Assuming that it
is about an attacker running on the same server tuple, why can't the
attacker just send packets by itself? I might also point out that
section 8.1.3 of the transport draft [1] prevents such attacks from
being run.

[1] https://quicwg.org/base-drafts/draft-ietf-quic-transport.html#rfc.section.8.1.3

-- 
Kazuho Oku

---

From: "Martin Thomson" <[email-masked]>
Date: Sun, 07 Apr 2019 21:42:34 -0400

> section 8.1.3 of the transport draft [1] prevents such attacks from

I don't think that this is a particularly important consideration.  Servers make their own determination about whether clients present a risk of denial of service.  If, as the proposed mechanism proves, the server has recently communicated with the client on the same address, the risk of DoS exposure might reasonably be discounted.

This isn't the only consideration here though.  When we were discussing the use of resumption tickets across different connections, I pointed out that there is no harm in using a ticket with any connection.  Tokens aren't significantly different in this regard - a server still needs to treat them with suspicion.  But linkability concerns might cause clients to avoid use of a token:

1. When you use a token, you can't use it again (or you link any sessions that use the same token).
2. When you use a token, you link that use to the source of the token.

The first is what motivates having a clear signal from the server about the scope over which the token is usable.  Otherwise, the client might waste a token on a connection attempt that was never able to use the token.

Whether or not the second will determine use of the token is largely a question of client policy.  There is some advice we can offer, but ultimately clients will make their own determination.  For instance, it might be reasonable to use a token if the connection is being made in response to resolving a URL that was provided by the first server.  But there are numerous constraints on connection establishment that might alter any determination.

Anything we might consider publishing needs some treatment of these considerations.