Internet DRAFT - draft-kazuho-quic-address-bound-token

draft-kazuho-quic-address-bound-token







QUIC                                                              K. Oku
Internet-Draft                                                    Fastly
Intended status: Standards Track                          April 04, 2019
Expires: October 6, 2019


                      Address-bound Token for QUIC
                draft-kazuho-quic-address-bound-token-00

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.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on October 6, 2019.

Copyright Notice

   Copyright (c) 2019 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.




Oku                      Expires October 6, 2019                [Page 1]

Internet-Draft        Address-bound Token for QUIC            April 2019


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Notational Conventions  . . . . . . . . . . . . . . . . .   2
   2.  Overview  . . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  The address_bound_token Transport Parameter . . . . . . . . .   3
   4.  Sharing the Congestion Controller . . . . . . . . . . . . . .   3
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   4
     5.1.  Reflection Attack . . . . . . . . . . . . . . . . . . . .   4
     5.2.  Plaintext Tokens  . . . . . . . . . . . . . . . . . . . .   4
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   4
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   4
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .   4
     7.2.  Informative References  . . . . . . . . . . . . . . . . .   5
   Appendix A.  Design Variations  . . . . . . . . . . . . . . . . .   5
     A.1.  Using Alt-Svc Name as the Key . . . . . . . . . . . . . .   5
     A.2.  Cross-connection Prioritization . . . . . . . . . . . . .   5
   Appendix B.  Acknowledgements . . . . . . . . . . . . . . . . . .   6
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   6

1.  Introduction

   Some, if not all of the application protocols that are built on top
   of QUIC [QUIC-TRANSPORT], including HTTP/3 [QUIC-HTTP], require or
   would require clients to establish different connections for each
   server name, even when those server names are hosted by the same
   server.  This restriction introduces several drawbacks:

   o  Address validation is required for each connection establishment
      specifying a different server name, thereby restricting the amount
      of data that a server can initially send.

   o  Distribution of network bandwidth among these connections is
      governed by the startup phase and congestion control dynamics,
      which can lead to unfair distribution for short-lived connections.

   o  It is hard if not impossible to prioritize the transmission of
      some connections among others.

   To resolve these issues, this document defines a QUIC transport
   parameter that expands the scope of the token from the server name to
   a union of the server name and the server's address tuple.

1.1.  Notational Conventions

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].



Oku                      Expires October 6, 2019                [Page 2]

Internet-Draft        Address-bound Token for QUIC            April 2019


2.  Overview

   When accepting a new connection, a server sends the
   "address_bound_token" transport parameter indicating to the client
   that the tokens it would send can be used for establishing future
   connections against the server's address tuple regardless of the
   server's name, and sends the tokens using the NEW_TOKEN frames.

   A server can embed the identifier of the congestion controller tied
   to the connection within the tokens that it sends.  Then, when
   accepting a new connection using the advertised token, the server
   tries to associate the new connection to the existing congestion
   controller by using the identifier found in the provided token.  Once
   the server succeeds in making this association, it can skip address
   validation and the startup phase for the new connection, as well as
   using the congestion controller for distributing the network
   bandwidth between the old and the new connection.

   Even when it is impossible to share a congestion controller among
   multiple connections, sharing the tokens between different server
   names raises the chance of the server receiving a token that has not
   yet expired.  That improves the odds of skipping address validation
   and reusing the information of the path, such as the estimated round-
   trip time or the network bandwidth.

3.  The address_bound_token Transport Parameter

   A server sends the "address_bound_token" transport parameter (0xTBD)
   to indicate that tokens sent using the NEW_TOKEN frame are "address-
   bound tokens".  That is, they can be used by the client for future
   connections established to the same server name or to the same server
   IP address and port.

   Only the server sends the "address_bound_token" transport parameter.
   A client MUST NOT send this transport parameter.  A server MUST treat
   receipt of a "address_bound_token" transport parameter as a
   connection error of type TRANSPORT_PARAMETER_ERROR.

   The "address_bound_token" transport parameter does not carry a value;
   the length of the value MUST be set to zero.  A client that receives
   this transport parameter not conforming to these requirements MUST
   terminate the connection with a TRANSPORT_PARAMETER_ERROR.

4.  Sharing the Congestion Controller

   When multiple QUIC connections share a single congestion controller,
   how the send window is distributed between the connections is up to
   the sender's discretion.



Oku                      Expires October 6, 2019                [Page 3]

Internet-Draft        Address-bound Token for QUIC            April 2019


   However, the use of the "address_bound_token" transport parameter
   MUST NOT cause any change to when the acknowledgements are sent by a
   connection endpoint.  Similarly, while connection endpoints will
   forward receipts of acknowledgements and loss signals to the shared
   congestion controller, loss recovery logic SHOULD operate
   independently for each connection.

5.  Security Considerations

5.1.  Reflection Attack

   An attacker can create a connection to obtain an address-bound token,
   warm up the connection, then initiate a new connection by using the
   token with a spoofed client address or port number.  If the server
   skips address validation and retains the congestion window as-is, the
   spoofed address might receive a large amount of unsolicited data.

   The impact of the attack is equivalent to the spoofed NAT rebinding
   attack.  A server SHOULD NOT skip path validation if the source IP
   address of an initiating connection is different from the address for
   which the address-bound token was issued.

5.2.  Plaintext Tokens

   An address-bound token MUST NOT expose linkability between
   connections, for example by including the identifier of the
   congestion controller in cleartext.  Exposing a value shared between
   multiple tokens that could be carried among different connections
   allows observers to identify the connections belonging to the same
   client.

6.  IANA Considerations

   TBD

7.  References

7.1.  Normative References

   [QUIC-TRANSPORT]
              Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
              Multiplexed and Secure Transport", draft-ietf-quic-
              transport-16 (work in progress), October 2018.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997, <https://www.rfc-
              editor.org/info/rfc2119>.



Oku                      Expires October 6, 2019                [Page 4]

Internet-Draft        Address-bound Token for QUIC            April 2019


7.2.  Informative References

   [QUIC-HTTP]
              Bishop, M., Ed., "Hypertext Transfer Protocol Version 3
              (HTTP/3)", draft-ietf-quic-http-16 (work in progress),
              October 2018.

   [RFC7838]  Nottingham, M., McManus, P., and J. Reschke, "HTTP
              Alternative Services", RFC 7838, DOI 10.17487/RFC7838,
              April 2016, <https://www.rfc-editor.org/info/rfc7838>.

Appendix A.  Design Variations

A.1.  Using Alt-Svc Name as the Key

   An alternative approach to using the server's address tuple as the
   scope of the token is to use the "host" value of the Alt-Svc
   [RFC7838] header field as the scope.

   In such an approach, a server would send one host value for all the
   origins it hosts.  Then, a client using the value of the host as the
   scope of the tokens would be able to send a token received on any of
   the connections that went to the server on any of the future
   connections that goes to the server.

   The downside of the approach is that the design works only for HTTP/3
   connections being upgraded by the Alt-Svc header field.

A.2.  Cross-connection Prioritization

   A natural extension to the proposed scheme would be to define a way
   of prioritizing the connections, so that some connections can be
   given higher precedence than others.  As an example, it would be
   sensible to prioritize a connection carrying real-time video stream
   above a connection that is transferring an update image of an
   operating system.

   A simple way of prioritizing between the connections would be to
   associate a priority value to every connection that would be
   respected by the sender when it distributes the bandwidth among the
   connections.

   The PRIORITY frame (type=0xTBD) indicates the priority.








Oku                      Expires October 6, 2019                [Page 5]

Internet-Draft        Address-bound Token for QUIC            April 2019


    0
    0 1 2 3 4 5 6 7
   +-+-+-+-+-+-+-+-+
   |  Priority (8) |
   +-+-+-+-+-+-+-+-+

   The Priority field carries the priority of the connection, subtracted
   by one.

   Each connection is assigned a priority value between 1 and 256.  The
   initial priority is 16.

   The PRIORITY frame is sent by an endpoint to encourage the receiver
   to assign bandwidth proportional to the suggested priority value for
   each connection.

   The priority value carried by the PRIORITY frame is unidirectional.
   A client advertises its preference on how the data sent by the server
   should be prioritized; a server advertises its preference on how the
   data sent by the client should be prioritized.

Appendix B.  Acknowledgements

   Thanks to Eric Kinnear, Ian Swett, Jana Iyengar, Martin Thomson,
   Lucas Pardue for their feedback and suggestions.

   A proposal exists that advocates for having a transport parameter to
   change the scope of a token to a list of server names:
   https://svs.informatik.uni-hamburg.de/publications/2019/2019-03-22-
   Sy-preprint-Surfing-the-Web-quicker-than-QUIC-via-a-shared-Address-
   Validation.pdf .  The approach described in this document is
   different from that in the following aspects:

   o  The scope of the token is the union of the server name and the
      server's address tuple.

   o  The token is used also for consolidating the congestion
      controller.

Author's Address

   Kazuho Oku
   Fastly

   Email: kazuhooku@gmail.com






Oku                      Expires October 6, 2019                [Page 6]