QUIC M. Duke Internet-Draft F5 Networks, Inc. Intended status: Standards Track May 22, 2018 Expires: November 23, 2018 QUIC-LB: Using Load Balancers to Generate QUIC Connection IDs draft-duke-quic-load-balancers-01 Abstract QUIC connection IDs allow continuation of connections across address/ port 5-tuple changes, and can store routing information for stateless or low-state layer 4 load balancers. They are also meant to prevent linkability of connections across deliberate address migration through the use of protected communications between client and server. This creates issues for load-balancing intermediaries. This specification standardizes the communication between load balancers and servers to overcome these issues in a protocol called QUIC-LB. 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 https://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 November 23, 2018. Copyright Notice Copyright (c) 2018 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 (https://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 Duke Expires November 23, 2018 [Page 1] Internet-Draft QUIC-LB May 2018 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 2. Protocol Objectives . . . . . . . . . . . . . . . . . . . . . 3 2.1. Simplicity . . . . . . . . . . . . . . . . . . . . . . . 3 2.2. Security . . . . . . . . . . . . . . . . . . . . . . . . 4 2.3. Robustness to Middleboxes . . . . . . . . . . . . . . . . 4 3. Protocol Design . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Connection ID Generation . . . . . . . . . . . . . . . . 4 3.2. Message Exchange . . . . . . . . . . . . . . . . . . . . 5 3.3. Load Balancer Trust . . . . . . . . . . . . . . . . . . . 5 3.4. Servers with Zero Stock . . . . . . . . . . . . . . . . . 6 4. Message Format . . . . . . . . . . . . . . . . . . . . . . . 6 4.1. NEW_IDS message . . . . . . . . . . . . . . . . . . . . . 6 4.2. ID_STOCK message . . . . . . . . . . . . . . . . . . . . 7 5. Chained Load Balancers . . . . . . . . . . . . . . . . . . . 7 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 8.1. Normative References . . . . . . . . . . . . . . . . . . 8 8.2. Informative References . . . . . . . . . . . . . . . . . 9 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 9 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 9 B.1. Since draft-duke-quic-load-balancers-00 . . . . . . . . . 9 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 1. Introduction Server-generated connection IDs create a potential need for out-of- band communication. QUIC packets usually contain a connection ID to allow endpoints to associate packets with different address/port/ protocol 5-tuples to the same connection context. This feature makes connections robust in the event of NAT rebinding. QUIC allows servers (or load balancers) to designate an initial connection ID to encode useful routing information for load balancers. It also encourages servers, in packets protected by cryptography, to provide additional connection IDs to the client. This allows clients that know they are going to change IP address or port to use a separate connection ID on the new path, thus reducing linkability as clients move through the world. Duke Expires November 23, 2018 [Page 2] Internet-Draft QUIC-LB May 2018 There is a tension between the requirements to provide routing information and mitigate linkability. Ultimately, because new connection IDs are in protected packets, they must be generated at the server if the load balancer does not have access to the connection keys. However, it is the load balancer that has the context necessary to generate a connection ID that encodes useful routing information. In the absence of any shared state between load balancer and server, the load balancer must maintain a relatively expensive table of server-generated connection IDs, and will not route packets correctly if they use a connection ID that was originally communicated in a protected NEW_CONNECTION_ID frame. This specification provides a method of coordination between QUIC servers and layer 4 load balancers to support connection IDs that encode routing information. It describes desirable properties of a solution, and then specifies a protocol that provides those properties. 1.1. Terminology 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 RFC 2119 [RFC2119]. In this document, these words will appear with that interpretation only when in ALL CAPS. Lower case uses of these words are not to be interpreted as carrying significance described in RFC 2119. In this document, "client" and "server" refer to the endpoints of a QUIC connection unless otherwise indicated. A "load balancer" is an intermediary for that connection that does not possess QUIC connection keys, but it may rewrite IP addresses or conduct other IP or UDP processing. In most respects, the load balancer behaves as a client in a QUIC-LB connection, but is always referred to as a "load balancer" below to avoid confusion. 2. Protocol Objectives 2.1. Simplicity QUIC is intended to provide unlinkability across connection migration, but servers are under no obligation to provide connection IDs to enable this. If the coordination scheme is too difficult to implement, servers behind load balancers using connection IDs for routing will use trivially linkable connection IDs. Clients will therefore be forced choose between terminating the connection during migration or remaining linkable. Duke Expires November 23, 2018 [Page 3] Internet-Draft QUIC-LB May 2018 The solution should be both simple to implement and require little additional infrastructure for cryptographic keys, etc. 2.2. Security The path between load balancer and server may not be free of observers from which the client wishes to avoid linkability. Similarly, malicious hosts could spoof a trusted load balancer to provide connection IDs that are linkable. Therefore, coordination messages must be encrypted, and there must be some way for servers to authenticate the load balancer's messages. 2.3. Robustness to Middleboxes The path between load balancer and server may transit multiple domains. It is therefore advantageous to make messages resemble QUIC traffic as much as possible, as any viable path must obviously admit QUIC traffic. 3. Protocol Design 3.1. Connection ID Generation Load balancers MAY use connection IDs to encode routing information to the destination server. This encoding MAY be opaque to the destination server and SHOULD be opaque to all other hosts. The encoding scheme MUST be able to generate enough connection IDs for each server to have at least two for every QUIC connection concurrently assigned to it. The encoding SHOULD maximize the cryptographic distance between connection IDs intended for the same server. The encoding SHOULD NOT vary with the number of active servers, as the connection ID remains routable even if other servers boot up or suffer an outage. A representative encoding that meets these requirements might concatenate the server's IPv4 address and a monotonically increasing sequence number, and then encrypt the result to obtain the connection ID. For any incoming QUIC packet, the load balancer would decrypt the connection ID to extract the server IP address. There would be different routing rules for (readily identifiable) Initial packets that contain an (essentially random) client-generated connection ID. Duke Expires November 23, 2018 [Page 4] Internet-Draft QUIC-LB May 2018 3.2. Message Exchange No message in this protocol is sent with reliability assurances. For all messages the load balancer uses an ephemeral UDP port, and the server uses UDP port 443. All messages are sent as encrypted records in an established DTLS connection. The best practice for servers is to always provide at least one connection ID to clients beyond the one it is currently using. Load balancers SHOULD monitor the usage of these connection IDs and the number of active connections for each server. A "used" connection ID is one that has been used in the Connection ID field of a QUIC header, as opposed to the QUIC NEW_CONNECTION_ID frame. When the stock of unused connection IDs is low, load balancers SHOULD send a NEW_IDS message to that server. Servers SHOULD periodically send a ID_STOCK message to the load balancer to synchronize the load balancer's view of its current unused connection IDs. This allows the shared state to recover from lost NEW_CONN_ID messages. Servers MAY increase the rate at which they send ID_STOCK messages as their stocks shrink, relative to the usage rate of connection IDs, to accelerate delivery of new IDs and overcome packet losses. Note that the Connection IDs provided by the load balancer can be used by any connection terminated at the server. There is no need for the load balancer to designate specific QUIC connections for each ID. As a result, load balancers cannot necessarily associate packets before and after an IP address migration to the same connection. 3.3. Load Balancer Trust Message authentication and encryption is achieved using DTLS 1.2 or 1.3 ([RFC6347] or [DTLS13]). Load balancers MUST initiate the handshake as the client, as some firewalls may block outbound connections from the server. Servers MUST request a Client Certificate to verify that the Load Balancer meets the trust requirements to potentially introduce linkable Connection IDs into the system. Servers MUST NOT accept DTLS connections from load balancers for which they do not have configured trust relationships. Duke Expires November 23, 2018 [Page 5] Internet-Draft QUIC-LB May 2018 3.4. Servers with Zero Stock If the server has an active DTLS connection with a lower balancer, but has zero stock, the server SHOULD use the connection ID provided in the Initial packet and SHOULD NOT generate QUIC NEW_CONNECTION_ID frames. Therefore, clients that knowingly change IP address or port are forced to choose between terminating the connection and traceably changing IP address. Servers with no such trust relationship MUST behave in accordance with the QUIC transport spec [QUIC-TRANSPORT], generating new connection IDs at will. 4. Message Format All messages below are encapsulated in DTLS Records. The type field is not strictly necessary to resolve ambiguity, as each message type is only sent by one entity in the connection. However, the type byte allows future extension of the protocol. 4.1. NEW_IDS message Load Balancers MUST ignore NEW_IDS messages. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 0x01 | CID Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Connection ID 1 (32..144) + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Connection ID 2 (32..144) + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Connection ID n (32..144) + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1 NEW_IDS Message The CID length is the length, in bytes, of each Connection ID in the message. All following Connection IDs must be of this length. This Duke Expires November 23, 2018 [Page 6] Internet-Draft QUIC-LB May 2018 value MUST correspond to a legal value in the QUIC long header, i.e. between 4 and 18 bytes. Load balancers with a zero CID length are not using connection ID for routing purposes and MUST NOT initiate a QUIC-LB connection. Other data MUST NOT be in the DTLS Record, so the number of Connection IDs present in the packet is determined by the Record length. Note that connection IDs are strings, not integers that are expressed in host or network order. A server that receives a NEW_IDS with a new CID length is likely dealing with a change in load balancer configuration. It SHOULD discard any unused Connection IDs in its stock and send a new ID_STOCK message reflecting only Connection IDs with the new length. 4.2. ID_STOCK message Servers MUST ignore received ID_STOCK messages. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 0x02 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Unused Connection IDs | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2 ID_STOCK Message This message simply reports the number of unused connection IDs in a 32-bit integer in Network order. Load Balancers MUST update their estimate of server stock based on this message, as some connection IDs may have been lost in transit. 5. Chained Load Balancers In some deployments, there may be multiple tiers of trusted load balancers in the path between client and server. All load balancers using connection ID to encode routing information MUST agree on how to decode connection IDs as routing instructions. Due to QUIC packet authentication, connection IDs of established QUIC connections cannot be rewritten in flight without access to the QUIC connection keys. A server configured to trust multiple load balancers MAY accept DTLS connections from all of them and use provided Connection IDs interchangeably. It SHOULD report its entire stock of connection IDs to all trusted load balancers, rather than the number of IDs issued from each source. Duke Expires November 23, 2018 [Page 7] Internet-Draft QUIC-LB May 2018 6. Security Considerations QUIC-LB is intended to preserve routability and prevent linkability, so attacks on the protocol would compromise at least one of these objectives. Injection of connection IDs could either break routability (by diverting flows to a server with no QUIC connection context) or allow linkability (by allowing observers to determine that two connection IDs originate from the same server, and that one begins at roughly the same time that the other disappears). Use of DTLS authentication mechanisms, at both load balancer and server, are meant to mitigate this risk. Cleartext connection IDs would also allow observers to map connection IDs to a specific server, potentially allowing linkability. QUIC-LB utilizes DTLS-based encryption to avoid this. QUIC-LB depends on DTLS, and therefore on Public Key Infrastructure. Any compromise of the PKI would allow untrusted middleboxes to successfully execute either of the attacks above. 7. IANA Considerations There are no IANA requirements. 8. References 8.1. Normative References [DTLS13] Rescorla, E., Tschofenig, H., and N. Modadugu, "The Datagram Transport Layer Security (DTLS) Protocol Version 1.3", draft-ietf-tls-dtls13-26 (work in progress), March 2018. [QUIC-TRANSPORT] Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed and Secure Transport", draft-ietf-quic-transport-12 (work in progress), May 2018. [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, January 2012, . Duke Expires November 23, 2018 [Page 8] Internet-Draft QUIC-LB May 2018 8.2. Informative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . Appendix A. Acknowledgments Appendix B. Change Log *RFC Editor's Note:* Please remove this section prior to publication of a final version of this document. B.1. Since draft-duke-quic-load-balancers-00 o Converted to markdown o Added variable length connection IDs Author's Address Martin Duke F5 Networks, Inc. Email: martin.h.duke@gmail.com Duke Expires November 23, 2018 [Page 9]