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