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

[Kazuho Oku <[e-mail]>]

Hi Christian,

Thank you for your comments. My responses inline.

2019年4月4日(木) 15:48 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.

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

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


-- 
Kazuho Oku