idnits 2.17.1 draft-duke-quic-load-balancers-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 22, 2018) is 2164 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-43) exists of draft-ietf-tls-dtls13-26 == Outdated reference: A later version (-34) exists of draft-ietf-quic-transport-12 ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 QUIC M. Duke 3 Internet-Draft F5 Networks, Inc. 4 Intended status: Standards Track May 22, 2018 5 Expires: November 23, 2018 7 QUIC-LB: Using Load Balancers to Generate QUIC Connection IDs 8 draft-duke-quic-load-balancers-01 10 Abstract 12 QUIC connection IDs allow continuation of connections across address/ 13 port 5-tuple changes, and can store routing information for stateless 14 or low-state layer 4 load balancers. They are also meant to prevent 15 linkability of connections across deliberate address migration 16 through the use of protected communications between client and 17 server. This creates issues for load-balancing intermediaries. This 18 specification standardizes the communication between load balancers 19 and servers to overcome these issues in a protocol called QUIC-LB. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on November 23, 2018. 38 Copyright Notice 40 Copyright (c) 2018 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (https://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Protocol Objectives . . . . . . . . . . . . . . . . . . . . . 3 58 2.1. Simplicity . . . . . . . . . . . . . . . . . . . . . . . 3 59 2.2. Security . . . . . . . . . . . . . . . . . . . . . . . . 4 60 2.3. Robustness to Middleboxes . . . . . . . . . . . . . . . . 4 61 3. Protocol Design . . . . . . . . . . . . . . . . . . . . . . . 4 62 3.1. Connection ID Generation . . . . . . . . . . . . . . . . 4 63 3.2. Message Exchange . . . . . . . . . . . . . . . . . . . . 5 64 3.3. Load Balancer Trust . . . . . . . . . . . . . . . . . . . 5 65 3.4. Servers with Zero Stock . . . . . . . . . . . . . . . . . 6 66 4. Message Format . . . . . . . . . . . . . . . . . . . . . . . 6 67 4.1. NEW_IDS message . . . . . . . . . . . . . . . . . . . . . 6 68 4.2. ID_STOCK message . . . . . . . . . . . . . . . . . . . . 7 69 5. Chained Load Balancers . . . . . . . . . . . . . . . . . . . 7 70 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 71 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 72 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 73 8.1. Normative References . . . . . . . . . . . . . . . . . . 8 74 8.2. Informative References . . . . . . . . . . . . . . . . . 9 75 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 9 76 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 9 77 B.1. Since draft-duke-quic-load-balancers-00 . . . . . . . . . 9 78 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 80 1. Introduction 82 Server-generated connection IDs create a potential need for out-of- 83 band communication. QUIC packets usually contain a connection ID to 84 allow endpoints to associate packets with different address/port/ 85 protocol 5-tuples to the same connection context. This feature makes 86 connections robust in the event of NAT rebinding. 88 QUIC allows servers (or load balancers) to designate an initial 89 connection ID to encode useful routing information for load 90 balancers. It also encourages servers, in packets protected by 91 cryptography, to provide additional connection IDs to the client. 92 This allows clients that know they are going to change IP address or 93 port to use a separate connection ID on the new path, thus reducing 94 linkability as clients move through the world. 96 There is a tension between the requirements to provide routing 97 information and mitigate linkability. Ultimately, because new 98 connection IDs are in protected packets, they must be generated at 99 the server if the load balancer does not have access to the 100 connection keys. However, it is the load balancer that has the 101 context necessary to generate a connection ID that encodes useful 102 routing information. In the absence of any shared state between load 103 balancer and server, the load balancer must maintain a relatively 104 expensive table of server-generated connection IDs, and will not 105 route packets correctly if they use a connection ID that was 106 originally communicated in a protected NEW_CONNECTION_ID frame. 108 This specification provides a method of coordination between QUIC 109 servers and layer 4 load balancers to support connection IDs that 110 encode routing information. It describes desirable properties of a 111 solution, and then specifies a protocol that provides those 112 properties. 114 1.1. Terminology 116 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 117 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 118 document are to be interpreted as described in RFC 2119 [RFC2119]. 120 In this document, these words will appear with that interpretation 121 only when in ALL CAPS. Lower case uses of these words are not to be 122 interpreted as carrying significance described in RFC 2119. 124 In this document, "client" and "server" refer to the endpoints of a 125 QUIC connection unless otherwise indicated. A "load balancer" is an 126 intermediary for that connection that does not possess QUIC 127 connection keys, but it may rewrite IP addresses or conduct other IP 128 or UDP processing. In most respects, the load balancer behaves as a 129 client in a QUIC-LB connection, but is always referred to as a "load 130 balancer" below to avoid confusion. 132 2. Protocol Objectives 134 2.1. Simplicity 136 QUIC is intended to provide unlinkability across connection 137 migration, but servers are under no obligation to provide connection 138 IDs to enable this. If the coordination scheme is too difficult to 139 implement, servers behind load balancers using connection IDs for 140 routing will use trivially linkable connection IDs. Clients will 141 therefore be forced choose between terminating the connection during 142 migration or remaining linkable. 144 The solution should be both simple to implement and require little 145 additional infrastructure for cryptographic keys, etc. 147 2.2. Security 149 The path between load balancer and server may not be free of 150 observers from which the client wishes to avoid linkability. 151 Similarly, malicious hosts could spoof a trusted load balancer to 152 provide connection IDs that are linkable. Therefore, coordination 153 messages must be encrypted, and there must be some way for servers to 154 authenticate the load balancer's messages. 156 2.3. Robustness to Middleboxes 158 The path between load balancer and server may transit multiple 159 domains. It is therefore advantageous to make messages resemble QUIC 160 traffic as much as possible, as any viable path must obviously admit 161 QUIC traffic. 163 3. Protocol Design 165 3.1. Connection ID Generation 167 Load balancers MAY use connection IDs to encode routing information 168 to the destination server. This encoding MAY be opaque to the 169 destination server and SHOULD be opaque to all other hosts. 171 The encoding scheme MUST be able to generate enough connection IDs 172 for each server to have at least two for every QUIC connection 173 concurrently assigned to it. 175 The encoding SHOULD maximize the cryptographic distance between 176 connection IDs intended for the same server. 178 The encoding SHOULD NOT vary with the number of active servers, as 179 the connection ID remains routable even if other servers boot up or 180 suffer an outage. 182 A representative encoding that meets these requirements might 183 concatenate the server's IPv4 address and a monotonically increasing 184 sequence number, and then encrypt the result to obtain the connection 185 ID. For any incoming QUIC packet, the load balancer would decrypt 186 the connection ID to extract the server IP address. There would be 187 different routing rules for (readily identifiable) Initial packets 188 that contain an (essentially random) client-generated connection ID. 190 3.2. Message Exchange 192 No message in this protocol is sent with reliability assurances. For 193 all messages the load balancer uses an ephemeral UDP port, and the 194 server uses UDP port 443. All messages are sent as encrypted records 195 in an established DTLS connection. 197 The best practice for servers is to always provide at least one 198 connection ID to clients beyond the one it is currently using. Load 199 balancers SHOULD monitor the usage of these connection IDs and the 200 number of active connections for each server. A "used" connection ID 201 is one that has been used in the Connection ID field of a QUIC 202 header, as opposed to the QUIC NEW_CONNECTION_ID frame. When the 203 stock of unused connection IDs is low, load balancers SHOULD send a 204 NEW_IDS message to that server. 206 Servers SHOULD periodically send a ID_STOCK message to the load 207 balancer to synchronize the load balancer's view of its current 208 unused connection IDs. This allows the shared state to recover from 209 lost NEW_CONN_ID messages. 211 Servers MAY increase the rate at which they send ID_STOCK messages as 212 their stocks shrink, relative to the usage rate of connection IDs, to 213 accelerate delivery of new IDs and overcome packet losses. 215 Note that the Connection IDs provided by the load balancer can be 216 used by any connection terminated at the server. There is no need 217 for the load balancer to designate specific QUIC connections for each 218 ID. As a result, load balancers cannot necessarily associate packets 219 before and after an IP address migration to the same connection. 221 3.3. Load Balancer Trust 223 Message authentication and encryption is achieved using DTLS 1.2 or 224 1.3 ([RFC6347] or [DTLS13]). Load balancers MUST initiate the 225 handshake as the client, as some firewalls may block outbound 226 connections from the server. Servers MUST request a Client 227 Certificate to verify that the Load Balancer meets the trust 228 requirements to potentially introduce linkable Connection IDs into 229 the system. 231 Servers MUST NOT accept DTLS connections from load balancers for 232 which they do not have configured trust relationships. 234 3.4. Servers with Zero Stock 236 If the server has an active DTLS connection with a lower balancer, 237 but has zero stock, the server SHOULD use the connection ID provided 238 in the Initial packet and SHOULD NOT generate QUIC NEW_CONNECTION_ID 239 frames. Therefore, clients that knowingly change IP address or port 240 are forced to choose between terminating the connection and traceably 241 changing IP address. 243 Servers with no such trust relationship MUST behave in accordance 244 with the QUIC transport spec [QUIC-TRANSPORT], generating new 245 connection IDs at will. 247 4. Message Format 249 All messages below are encapsulated in DTLS Records. 251 The type field is not strictly necessary to resolve ambiguity, as 252 each message type is only sent by one entity in the connection. 253 However, the type byte allows future extension of the protocol. 255 4.1. NEW_IDS message 257 Load Balancers MUST ignore NEW_IDS messages. 259 0 1 2 3 260 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 261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 262 | Type = 0x01 | CID Length | 263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 264 | | 265 + Connection ID 1 (32..144) + 266 | | 267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 268 | | 269 + Connection ID 2 (32..144) + 270 | | 271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 ... 273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 274 | | 275 + Connection ID n (32..144) + 276 | | 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 278 Figure 1 NEW_IDS Message 280 The CID length is the length, in bytes, of each Connection ID in the 281 message. All following Connection IDs must be of this length. This 282 value MUST correspond to a legal value in the QUIC long header, i.e. 283 between 4 and 18 bytes. Load balancers with a zero CID length are 284 not using connection ID for routing purposes and MUST NOT initiate a 285 QUIC-LB connection. 287 Other data MUST NOT be in the DTLS Record, so the number of 288 Connection IDs present in the packet is determined by the Record 289 length. Note that connection IDs are strings, not integers that are 290 expressed in host or network order. 292 A server that receives a NEW_IDS with a new CID length is likely 293 dealing with a change in load balancer configuration. It SHOULD 294 discard any unused Connection IDs in its stock and send a new 295 ID_STOCK message reflecting only Connection IDs with the new length. 297 4.2. ID_STOCK message 299 Servers MUST ignore received ID_STOCK messages. 301 0 1 2 3 302 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 303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 304 | Type = 0x02 | 305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 306 | Unused Connection IDs | 307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 308 Figure 2 ID_STOCK Message 310 This message simply reports the number of unused connection IDs in a 311 32-bit integer in Network order. Load Balancers MUST update their 312 estimate of server stock based on this message, as some connection 313 IDs may have been lost in transit. 315 5. Chained Load Balancers 317 In some deployments, there may be multiple tiers of trusted load 318 balancers in the path between client and server. All load balancers 319 using connection ID to encode routing information MUST agree on how 320 to decode connection IDs as routing instructions. Due to QUIC packet 321 authentication, connection IDs of established QUIC connections cannot 322 be rewritten in flight without access to the QUIC connection keys. 324 A server configured to trust multiple load balancers MAY accept DTLS 325 connections from all of them and use provided Connection IDs 326 interchangeably. It SHOULD report its entire stock of connection IDs 327 to all trusted load balancers, rather than the number of IDs issued 328 from each source. 330 6. Security Considerations 332 QUIC-LB is intended to preserve routability and prevent linkability, 333 so attacks on the protocol would compromise at least one of these 334 objectives. 336 Injection of connection IDs could either break routability (by 337 diverting flows to a server with no QUIC connection context) or allow 338 linkability (by allowing observers to determine that two connection 339 IDs originate from the same server, and that one begins at roughly 340 the same time that the other disappears). Use of DTLS authentication 341 mechanisms, at both load balancer and server, are meant to mitigate 342 this risk. 344 Cleartext connection IDs would also allow observers to map connection 345 IDs to a specific server, potentially allowing linkability. QUIC-LB 346 utilizes DTLS-based encryption to avoid this. 348 QUIC-LB depends on DTLS, and therefore on Public Key Infrastructure. 349 Any compromise of the PKI would allow untrusted middleboxes to 350 successfully execute either of the attacks above. 352 7. IANA Considerations 354 There are no IANA requirements. 356 8. References 358 8.1. Normative References 360 [DTLS13] Rescorla, E., Tschofenig, H., and N. Modadugu, "The 361 Datagram Transport Layer Security (DTLS) Protocol Version 362 1.3", draft-ietf-tls-dtls13-26 (work in progress), March 363 2018. 365 [QUIC-TRANSPORT] 366 Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed 367 and Secure Transport", draft-ietf-quic-transport-12 (work 368 in progress), May 2018. 370 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 371 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 372 January 2012, . 374 8.2. Informative References 376 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 377 Requirement Levels", BCP 14, RFC 2119, 378 DOI 10.17487/RFC2119, March 1997, 379 . 381 Appendix A. Acknowledgments 383 Appendix B. Change Log 385 *RFC Editor's Note:* Please remove this section prior to 386 publication of a final version of this document. 388 B.1. Since draft-duke-quic-load-balancers-00 390 o Converted to markdown 392 o Added variable length connection IDs 394 Author's Address 396 Martin Duke 397 F5 Networks, Inc. 399 Email: martin.h.duke@gmail.com