idnits 2.17.1 draft-duke-quic-load-balancers-04.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 10, 2019) is 1810 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) == Unused Reference: 'QUIC-TRANSPORT' is defined on line 908, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 2 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 10, 2019 5 Expires: November 11, 2019 7 QUIC-LB: Generating Routable QUIC Connection IDs 8 draft-duke-quic-load-balancers-04 10 Abstract 12 QUIC connection IDs allow continuation of connections across address/ 13 port 4-tuple changes, and can store routing information for stateless 14 or low-state load balancers. They also can prevent linkability of 15 connections across deliberate address migration through the use of 16 protected communications between client and server. This creates 17 issues for load-balancing intermediaries. This specification 18 standardizes methods for encoding routing information and proposes an 19 optional protocol called QUIC-LB to exchange the parameters of that 20 encoding. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on November 11, 2019. 39 Copyright Notice 41 Copyright (c) 2019 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (https://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 57 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 58 2. Protocol Objectives . . . . . . . . . . . . . . . . . . . . . 4 59 2.1. Simplicity . . . . . . . . . . . . . . . . . . . . . . . 4 60 2.2. Security . . . . . . . . . . . . . . . . . . . . . . . . 5 61 2.3. Robustness to Middleboxes . . . . . . . . . . . . . . . . 5 62 2.4. Load Balancer Chains . . . . . . . . . . . . . . . . . . 5 63 3. Routing Algorithms . . . . . . . . . . . . . . . . . . . . . 6 64 3.1. Plaintext CID Algorithm . . . . . . . . . . . . . . . . . 6 65 3.1.1. Load Balancer Actions . . . . . . . . . . . . . . . . 6 66 3.1.2. Server Actions . . . . . . . . . . . . . . . . . . . 6 67 3.2. Obfuscated CID Algorithm . . . . . . . . . . . . . . . . 7 68 3.2.1. Load Balancer Actions . . . . . . . . . . . . . . . . 7 69 3.2.2. Server Actions . . . . . . . . . . . . . . . . . . . 8 70 3.3. Stream Cipher CID Algorithm . . . . . . . . . . . . . . . 8 71 3.3.1. Load Balancer Actions . . . . . . . . . . . . . . . . 9 72 3.3.2. Server Actions . . . . . . . . . . . . . . . . . . . 9 73 3.4. Block Cipher CID Algorithm . . . . . . . . . . . . . . . 10 74 3.4.1. Load Balancer Actions . . . . . . . . . . . . . . . . 10 75 3.4.2. Server Actions . . . . . . . . . . . . . . . . . . . 11 76 4. Protocol Description . . . . . . . . . . . . . . . . . . . . 11 77 4.1. Out of band sharing . . . . . . . . . . . . . . . . . . . 11 78 4.2. QUIC-LB Message Exchange . . . . . . . . . . . . . . . . 12 79 4.3. QUIC-LB Packet . . . . . . . . . . . . . . . . . . . . . 12 80 4.4. Message Types and Formats . . . . . . . . . . . . . . . . 13 81 4.4.1. ACK_LB Message . . . . . . . . . . . . . . . . . . . 13 82 4.4.2. FAIL Message . . . . . . . . . . . . . . . . . . . . 13 83 4.4.3. ROUTING_INFO Message . . . . . . . . . . . . . . . . 14 84 4.4.4. STREAM_CID Message . . . . . . . . . . . . . . . . . 14 85 4.4.5. BLOCK_CID Message . . . . . . . . . . . . . . . . . . 15 86 4.4.6. SERVER_ID Message . . . . . . . . . . . . . . . . . . 16 87 4.4.7. MODULUS Message . . . . . . . . . . . . . . . . . . . 16 88 4.4.8. PLAINTEXT Message . . . . . . . . . . . . . . . . . . 16 89 5. Config Rotation . . . . . . . . . . . . . . . . . . . . . . . 17 90 5.1. Configuration Failover . . . . . . . . . . . . . . . . . 18 91 6. Configuration Requirements . . . . . . . . . . . . . . . . . 18 92 7. Security Considerations . . . . . . . . . . . . . . . . . . . 18 93 7.1. Outside attackers . . . . . . . . . . . . . . . . . . . . 19 94 7.2. Inside Attackers . . . . . . . . . . . . . . . . . . . . 19 95 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 96 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 97 9.1. Normative References . . . . . . . . . . . . . . . . . . 20 98 9.2. Informative References . . . . . . . . . . . . . . . . . 20 99 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 20 100 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 20 101 B.1. Since draft-duke-quic-load-balancers-03 . . . . . . . . . 20 102 B.2. Since draft-duke-quic-load-balancers-02 . . . . . . . . . 20 103 B.3. Since draft-duke-quic-load-balancers-01 . . . . . . . . . 21 104 B.4. Since draft-duke-quic-load-balancers-00 . . . . . . . . . 21 105 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 21 107 1. Introduction 109 QUIC packets usually contain a connection ID to allow endpoints to 110 associate packets with different address/port 4-tuples to the same 111 connection context. This feature makes connections robust in the 112 event of NAT rebinding. QUIC endpoints designate the connection ID 113 which peers use to address packets. Server-generated connection IDs 114 create a potential need for out-of-band communication to support 115 QUIC. 117 QUIC allows servers (or load balancers) to designate an initial 118 connection ID to encode useful routing information for load 119 balancers. It also encourages servers, in packets protected by 120 cryptography, to provide additional connection IDs to the client. 121 This allows clients that know they are going to change IP address or 122 port to use a separate connection ID on the new path, thus reducing 123 linkability as clients move through the world. 125 There is a tension between the requirements to provide routing 126 information and mitigate linkability. Ultimately, because new 127 connection IDs are in protected packets, they must be generated at 128 the server if the load balancer does not have access to the 129 connection keys. However, it is the load balancer that has the 130 context necessary to generate a connection ID that encodes useful 131 routing information. In the absence of any shared state between load 132 balancer and server, the load balancer must maintain a relatively 133 expensive table of server-generated connection IDs, and will not 134 route packets correctly if they use a connection ID that was 135 originally communicated in a protected NEW_CONNECTION_ID frame. 137 This specification provides a method of coordination between QUIC 138 servers and low-state load balancers to support connection IDs that 139 encode routing information. It describes desirable properties of a 140 solution, and then specifies a protocol that provides those 141 properties. This protocol supports multiple encoding schemes that 142 increase in complexity as they address paths between load balancer 143 and server with weaker trust dynamics. 145 1.1. Terminology 147 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 148 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 149 document are to be interpreted as described in RFC 2119 [RFC2119]. 151 In this document, these words will appear with that interpretation 152 only when in ALL CAPS. Lower case uses of these words are not to be 153 interpreted as carrying significance described in RFC 2119. 155 In this document, "client" and "server" refer to the endpoints of a 156 QUIC connection unless otherwise indicated. A "load balancer" is an 157 intermediary for that connection that does not possess QUIC 158 connection keys, but it may rewrite IP addresses or conduct other IP 159 or UDP processing. 161 Note that stateful load balancers that act as proxies, by terminating 162 a QUIC connection with the client and then retrieving data from the 163 server using QUIC or another protocol, are treated as a server with 164 respect to this specification. 166 When discussing security threats to QUIC-LB, we distinguish between 167 "inside observers" and "outside observers." The former lie on the 168 path between the load balancer and server, which often but not always 169 lies inside the server's data center or cloud deployment. Outside 170 observers are on the path between the load balancer and client. 171 "Off-path" attackers, though not on any data path, may also be 172 "inside" or "outside" depending on whether not they have network 173 access to the server without intermediation by the load balancer and/ 174 or other security devices. 176 2. Protocol Objectives 178 2.1. Simplicity 180 QUIC is intended to provide unlinkability across connection 181 migration, but servers are not required to provide additional 182 connection IDs that effectively prevent linkability. If the 183 coordination scheme is too difficult to implement, servers behind 184 load balancers using connection IDs for routing will use trivially 185 linkable connection IDs. Clients will therefore be forced choose 186 between terminating the connection during migration or remaining 187 linkable, subverting a design objective of QUIC. 189 The solution should be both simple to implement and require little 190 additional infrastructure for cryptographic keys, etc. 192 2.2. Security 194 In the limit where there are very few connections to a pool of 195 servers, no scheme can prevent the linking of two connection IDs with 196 high probability. In the opposite limit, where all servers have many 197 connections that start and end frequently, it will be difficult to 198 associate two connection IDs even if they are known to map to the 199 same server. 201 QUIC-LB is relevant in the region between these extremes: when the 202 information that two connection IDs map to the same server is helpful 203 to linking two connection IDs. Obviously, any scheme that 204 transparently communicates this mapping to outside observers 205 compromises QUIC's defenses against linkability. 207 However, concealing this mapping from inside observers is beyond the 208 scope of QUIC-LB. By simply observing Link-Layer and/or Network- 209 Layer addresses of packets containing distinct connection IDs, it is 210 trivial to determine that they map to the same server, even if 211 connection IDs are entirely random and do not encode routing 212 information. Schemes that conceal these addresses (e.g., IPsec) can 213 also conceal QUIC-LB messages. 215 Inside observers are generally able to mount Denial of Service (DoS) 216 attacks on QUIC connections regardless of Connection ID schemes. 217 However, QUIC-LB should protect against Denial of Service due to 218 inside off-path attackers in cases where such attackers are possible. 220 Though not an explicit goal of the QUIC-LB design, concealing the 221 server mapping also complicates attempts to focus attacks on a 222 specific server in the pool. 224 2.3. Robustness to Middleboxes 226 The path between load balancer and server may pass through 227 middleboxes that could drop the coordination messages in this 228 protocol. It is therefore advantageous to make messages resemble 229 QUIC traffic as much as possible, as any viable path must obviously 230 admit QUIC traffic. 232 2.4. Load Balancer Chains 234 While it is possible to construct a scheme that supports multiple 235 low-state load balancers in the path, by using different parts of the 236 connection ID to encoding routing information for each load balancer, 237 this use case is out of scope for QUIC-LB. 239 3. Routing Algorithms 241 In QUIC-LB, load balancers do not send individual connection IDs to 242 servers. Instead, they communicate the parameters of an algorithm to 243 generate routable connection IDs. 245 The algorithms differ in the complexity of configuration at both load 246 balancer and server. Increasing complexity improves obfuscation of 247 the server mapping. 249 The load balancer SHOULD route Initial and 0-RTT packets from the 250 client using an alternate algorithm. Note that the SCID in these 251 packets may not be long enough to represent all the routing bits. 252 This algorithm SHOULD generate consistent results for Initial and 253 0RTT packets that arrive with the same source and destination 254 connection ID. The load balancer algorithms below apply to all 255 incoming Handshake and 1-RTT packets. 257 There are situations where a server pool might be operating two or 258 more routing algorithms or parameter sets simultaneously. The load 259 balancer uses the first two bits of the connection ID to multiplex 260 incoming SCIDs over these schemes. 262 3.1. Plaintext CID Algorithm 264 3.1.1. Load Balancer Actions 266 The load balancer selects a number of bytes of the server connection 267 ID (SCID) that it will use to route to a given server, called the 268 "routing bytes". The number of bytes MUST have enough entropy to 269 have a different code point for each server. 271 The load balancer shares this value with servers, as explained in 272 Section 4, along with the value that represents that server. 274 On each incoming packet, the load balancer extracts consecutive 275 octets, beginning with the second byte. These bytes represent the 276 server ID. 278 3.1.2. Server Actions 280 The server chooses a connection ID length. This MUST be at least one 281 byte longer than the routing bytes. 283 When a server needs a new connection ID, it encodes its assigned 284 server ID in consecutive octets beginning with the second. All other 285 bits in the connection ID, except for the config rotation bits, MAY 286 be set to any other value. These other bits SHOULD appear random to 287 observers. 289 The figure below clarifies the format. The first two bits are 290 reserved for config rotation. The server can assign the next 6 bits 291 to any value. The specified number of bytes encodes the server ID, 292 and the server may decide how many trailing octets of information to 293 include up to the QUIC limit of 18-octet CIDs. 295 0 1 2 3 296 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 297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 298 |C R| Any | Server ID (variable) | 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 | Any (variable) | 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 303 Figure 1: Plaintext CID Format 305 3.2. Obfuscated CID Algorithm 307 3.2.1. Load Balancer Actions 309 The load balancer selects an arbitrary set of bits of the server 310 connection ID (SCID) that it will use to route to a given server, 311 called the "routing bits". The number of bits MUST have enough 312 entropy to have a different code point for each server, and SHOULD 313 have enough entropy so that there are many codepoints for each 314 server. 316 The load balancer MUST NOT select a routing mask that with more than 317 126 routing bits set to 1, which allows at least 2 bits for config 318 rotation (see Section 5) and 16 for server purposes in a maximum- 319 length connection ID. 321 The first two bits of an SCID MUST NOT be routing bits; these are 322 reserved for config rotation. 324 The load balancer selects a divisor that MUST be larger than the 325 number of servers. It SHOULD be large enough to accommodate 326 reasonable increases in the number of servers. The divisor MUST be 327 an odd integer so certain addition operations do not always produce 328 an even number. 330 The load balancer also assigns each server a "modulus", an integer 331 between 0 and the divisor minus 1. These MUST be unique for each 332 server, and SHOULD be distributed across the entire number space 333 between zero and the divisor. 335 The load balancer shares these three values with servers, as 336 explained in Section 4. 338 Upon receipt of a QUIC packet that is not of type Initial or 0-RTT, 339 the load balancer extracts the selected bits of the SCID and 340 expresses them as an unsigned integer of that length. The load 341 balancer then divides the result by the chosen divisor. The modulus 342 of this operation maps to the modulus for the destination server. 344 Note that any SCID that contains a server's modulus, plus an 345 arbitrary integer multiple of the divisor, in the routing bits is 346 routable to that server regardless of the contents of the non-routing 347 bits. Outside observers that do not know the divisor or the routing 348 bits will therefore have difficulty identifying that two SCIDs route 349 to the same server. 351 Note also that not all Connection IDs are necessarily routable, as 352 the computed modulus may not match one assigned to any server. Load 353 balancers SHOULD drop these packets if not a QUIC Initial or 0-RTT 354 packet. 356 3.2.2. Server Actions 358 The server chooses a connection ID length. This MUST contain all of 359 the routing bits and MUST be at least 8 octets to provide adequate 360 entropy. 362 When a server needs a new connection ID, it adds an arbitrary 363 nonnegative integer multiple of the divisor to its modulus, without 364 exceeding the maximum integer value implied by the number of routing 365 bits. The choice of multiple should appear random within these 366 constraints. 368 The server encodes the result in the routing bits. It MAY put any 369 other value into the non-routing bits except the config rotation 370 bits. The non-routing bits SHOULD appear random to observers. 372 3.3. Stream Cipher CID Algorithm 374 The Encrypted CID algorithm provides true cryptographic protection, 375 rather than mere obfuscation, at the cost of additional per-packet 376 processing at the load balancer to decrypt every incoming connection 377 ID except for Initial and 0RTT packets. 379 3.3.1. Load Balancer Actions 381 The load balancer assigns a server ID to every server in its pool, 382 and determines a server ID length (in octets) sufficiently large to 383 encode all server IDs, including potential future servers. 385 The load balancer also selects a nonce length and an 16-octet AES-ECB 386 key to use for connection ID decryption. The nonce length MUST be at 387 least eight octets and no more than 16 octets. The nonce length and 388 server ID length MUST sum to 18 or fewer octets. 390 The load balancer shares these three values with servers, as 391 explained in Section 4. 393 Upon receipt of a QUIC packet that is not of type Initial or 0-RTT, 394 the load balancer extracts as many of the earliest octets from the 395 destination connection ID as necessary to match the nonce length. 396 The server ID immediately follows. 398 The load balancer decrypts the server ID using 128-bit AES Electronic 399 Codebook (ECB) mode, much like QUIC header protection. The nonce 400 octets are padded to 16 octets using the as many of the first octets 401 of the token as necessary. AES-ECB encrypts this nonce using its key 402 to generate a mask which it applies to the encrypted server id. 404 server_id = encrypted_server_id ^ AES-ECB(key, padded-nonce) 406 For example, if the nonce length is 10 octets and the server ID 407 length is 2 octets, the connection ID can be as small as 12 octets. 408 The load balancer uses the first 10 octets (including the config 409 rotation bits) of the connection ID for the nonce, pads it to 16 410 octets using the first 6 octets of the token, and uses this to 411 decrypt the server ID in the eleventh and twelfth octet. 413 The output of the decryption is the server ID that the load balancer 414 uses for routing. 416 3.3.2. Server Actions 418 When generating a routable connection ID, the server writes arbitrary 419 bits into its nonce octets, and its provided server ID into the 420 server ID octets. Servers MAY opt to have a longer connection ID 421 beyond the nonce and server ID. The nonce and additional bits MAY 422 encode additional information, but SHOULD appear essentially random 423 to observers. The first two bits of the first octet are reserved for 424 config rotation Section 5, but form part of the nonce. 426 The server decrypts the server ID using 128-bit AES Electronic 427 Codebook (ECB) mode, much like QUIC header protection. The nonce 428 octets are padded to 16 octets using the as many of the first octets 429 of the token as necessary. AES-ECB encrypts this nonce using its key 430 to generate a mask which it applies to the server id. 432 encrypted_server_id = server_id ^ AES-ECB(key, padded-nonce) 434 3.4. Block Cipher CID Algorithm 436 The Block Cipher CID Algorithm, by using a full 16 octets of 437 Plaintext and a 128-bit cipher, provides higher cryptographic 438 protection and detection of spurious connection IDs. However, it 439 also requires connection IDs of at least 17 octets, increasing 440 overhead of client-to-server packets. 442 3.4.1. Load Balancer Actions 444 The load balancer assigns a server ID to every server in its pool, 445 and determines a server ID length (in octets) sufficiently large to 446 encode all server IDs, including potential future servers. The 447 server ID will start in the second octet of the decrypted connection 448 ID and occupy continuous octets beyond that. 450 The load balancer selects a zero-padding length. This SHOULD be at 451 least four octets to allow detection of spurious connection IDs. The 452 server ID and zero- padding length MUST sum to no more than 16 453 octets. They SHOULD sum to no more than 12 octets, to provide 454 servers adequate space to encode their own opaque data. 456 The load balancer also selects an 16-octet AES-ECB key to use for 457 connection ID decryption. 459 The load balancer shares these four values with servers, as explained 460 in Section 4. 462 Upon receipt of a QUIC packet that is not of type Initial or 0-RTT, 463 the load balancer reads the first octet to obtain the config rotation 464 bits. It then decrypts the subsequent 16 octets using AES-ECB 465 decryption and the chosen key. 467 The decrypted plaintext contains the server id, zero padding, and 468 opaque server data in that order. If the zero padding octets are not 469 zero, the load balancer MUST drop the packet. The load balancer uses 470 the server ID octets for routing. 472 3.4.2. Server Actions 474 When generating a routable connection ID, the server MUST choose a 475 connection ID length of 17 or 18 octets. The server writes its 476 provided server ID into the server ID octets, zeroes into the zero- 477 padding octets, and arbitrary bits into the remaining bits. These 478 arbitrary bits MAY encode additional information. Bits in the first 479 and eighteenth octets SHOULD appear essentially random to observers. 480 The first two bits of the first octet are reserved for config 481 rotation Section 5. 483 The server then encrypts the second through seventeenth octets using 484 the 128-bit AES-ECB cipher. 486 4. Protocol Description 488 The fundamental protocol requirement is to share the choice of 489 routing algorithm, and the relevant parameters for that algorithm, 490 between load balancer and server. 492 For Obfuscated CID Routing, this consists of the Routing Bits, 493 Divisor, and Modulus. The Modulus is unique to each server, but the 494 others MUST be global. 496 For Stream Cipher CID Routing, this consists of the Server ID, Server 497 ID Length, Key, and Nonce Length. The Server ID is unique to each 498 server, but the others MUST be global. The authentication token MUST 499 be distributed out of band for this algorithm to operate. 501 For Block Cipher CID Routing, this consists of the Server ID, Server 502 ID Length, Key, and Zero-Padding Length. The Server ID is unique to 503 each server, but the others MUST be global. 505 Each routing configuration also requires a unique two-bit config 506 rotation codepoint (see Section 5) to identify it. 508 4.1. Out of band sharing 510 When there are concerns about the integrity of the path between load 511 balancer and server, operators MAY share routing information using an 512 out-of-band technique, which is out of the scope of this 513 specification. 515 To simplify configuration, the global parameters can be shared out- 516 of-band, while the load balancer sends the unique server IDs via the 517 truncated message formats presented below. 519 4.2. QUIC-LB Message Exchange 521 QUIC-LB load balancers and servers exchange messages via the QUIC- 522 LBv1 protocol, which uses the QUIC invariants with version number 523 0xF1000000. The QUIC-LB load balancers send the encoding parameters 524 to servers and periodically retransmit until that server responds 525 with an acknowledgement. Specifics of this retransmission are 526 implementation-dependent. 528 4.3. QUIC-LB Packet 530 A QUIC-LB packet uses a long header. It carries configuration 531 information from the load balancer and acknowledgements from the 532 servers. They are sent when a load balancer boots up, detects a new 533 server in the pool or needs to update the server configuration. 535 0 1 2 3 536 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 537 +-+-+-+-+-+-+-+-+ 538 |1|C R| Reserved| 539 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 540 | Version (32) | 541 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 542 | 0x00 | 0x00 | 543 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 544 | | 545 + Authentication Token (64) + 546 | | 547 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 548 | Message Type | 549 +-+-+-+-+-+-+-+-+ 551 Figure 2: QUIC-LB Packet Format 553 The Version field allows QUIC-LB to use the Version Negotiation 554 mechanism. All messages in this specification are specific to QUIC- 555 LBv1. It should be set to 0xF1000000. 557 Load balancers MUST cease sending QUIC-LB packets of this version to 558 a server when that server sends a Version Negotiation packet that 559 does not advertise the version. 561 The length of the DCIL and SCIL fields are 0x00. 563 CR The 2-bit. CR field indicates the Config Rotation described in 564 Section 5. 566 Authentication Token The Authentication Token is an 8-byte field 567 that both entities obtain at configuration time. It is used to 568 verify that the sender is not an inside off-path attacker. 569 Servers and load balancers SHOULD silently discard QUIC-LB packets 570 with an incorrect token. 572 Message Type The Message Type indicates the type of message payload 573 that follows the QUIC-LB header. 575 4.4. Message Types and Formats 577 As described in Section 4.3, QUIC-LB packets contain a single 578 message. This section describes the format and semantics of the 579 QUIC-LB message types. 581 4.4.1. ACK_LB Message 583 A server uses the ACK_LB message (type=0x00) to acknowledge a QUIC-LB 584 packet received from the load balancer. The ACK-LB message has no 585 additional payload beyond the QUIC-LB packet header. 587 Load balancers SHOULD continue to retransmit a QUIC-LB packet until a 588 valid ACK_LB message, FAIL message or Version Negotiation Packet is 589 received from the server. 591 4.4.2. FAIL Message 593 A server uses the FAIL message (type=0x01) to indicate the 594 configuration received from the load balancer is unsupported. 596 0 1 2 3 597 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 598 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 599 | Supp. Type | Supp. Type | ... 600 +-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 602 Servers MUST send a FAIL message upon receipt of a message type which 603 they do not support, or if they do not possess all of the implied 604 out-of-band configuration to support a particular message type. 606 The payload of the FAIL message consists of a list of all the message 607 types supported by the server. 609 Upon receipt of a FAIL message, Load Balancers MUST either send a 610 QUIC-LB message the server supports or remove the server from the 611 server pool. 613 4.4.3. ROUTING_INFO Message 615 A load balancer uses the ROUTING_INFO message (type=0x02) to exchange 616 all the parameters for the Obfuscated CID algorithm. 618 0 1 2 3 619 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 620 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 621 | | 622 + + 623 | | 624 + Routing Bit Mask (144) + 625 | | 626 + + 627 | | 628 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 629 | | Modulus (16) | 630 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 631 | Divisor (16) | 632 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 634 Routing Bit Mask The Routing Bit Mask encodes a '1' at every bit 635 position in the server connection ID that will encode routing 636 information. 638 These bits, along with the Modulus and Divisor, are chosen by the 639 load balancer as described in Section 3.2. 641 4.4.4. STREAM_CID Message 643 A load balancer uses the STREAM_CID message (type=0x03) to exchange 644 all the parameters for using Stream Cipher CIDs. 646 0 1 2 3 647 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 648 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 649 | Nonce Len (8) | SIDL (8) | 650 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 651 | Server ID (variable) | 652 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 653 | | 654 + Key (128) + 655 | | 656 + + 657 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 659 Figure 3: Stream CID Payload 661 Nonce Len The Nonce Len field is a one-octet unsigned integer that 662 describes the nonce length necessary to use this routing 663 algorithm, in octets. 665 SIDL The SIDL field is a one-octet unsigned integer that describes 666 the server ID length necessary to use this routing algorithm, in 667 octets. 669 Server ID The Server ID is the unique value assigned to the 670 receiving server. Its length is determined by the SIDL field. 672 Key The Key is an 16-octet field that contains the key that the load 673 balancer will use to decrypt server IDs on QUIC packets. See 674 Section 7 to understand why sending keys in plaintext may be a 675 safe strategy. 677 4.4.5. BLOCK_CID Message 679 A load balancer uses the BLOCK_CID message (type=0x04) to exchange 680 all the parameters for using Stream Cipher CIDs. 682 0 1 2 3 683 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 684 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 685 | ZP Len (8) | SIDL (8) | 686 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 687 | Server ID (variable) | 688 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 689 | | 690 + Key (128) + 691 | | 692 + + 693 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 695 Figure 4: Block CID Payload 697 ZP Len The ZP Len field is a one-octet unsigned integer that 698 describes the zero-padding length necessary to use this routing 699 algorithm, in octets. 701 SIDL The SIDL field is a one-octet unsigned integer that describes 702 the server ID length necessary to use this routing algorithm, in 703 octets. 705 Server ID The Server ID is the unique value assigned to the 706 receiving server. Its length is determined by the SIDL field. 708 Key The Key is an 16-octet field that contains the key that the load 709 balancer will use to decrypt server IDs on QUIC packets. See 710 Section 7 to understand why sending keys in plaintext may be a 711 safe strategy. 713 4.4.6. SERVER_ID Message 715 A load balancer uses the SERVER_ID message (type=0x05) to exchange 716 explicit server IDs. 718 0 1 2 3 719 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 720 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 721 | SIDL (8) | Server ID (variable) | 722 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 724 Load balancers send the SERVER_ID message when all global values for 725 Stream or Block CIDs are sent out-of-band, so that only the server- 726 unique values must be sent in-band. The fields are identical to 727 their counterparts in the Section 4.4.4 payload. 729 4.4.7. MODULUS Message 731 A load balancer uses the MODULUS message (type=0x06) to exchange just 732 the modulus used in the Obfuscated CID algorithm. 734 0 1 2 3 735 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 736 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 737 | Modulus (16) | 738 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 739 | | 740 + Token (64) + 741 | | 742 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 744 Load balancers send the MODULUS when all global values for Obfuscated 745 CIDs are sent out-of-band, so that only the server-unique values must 746 be sent in-band. The Modulus field is identical to its counterpart 747 in the ROUTING_INFO message. 749 4.4.8. PLAINTEXT Message 751 A load balancer uses the PLAINTEXT message (type=0x07) to exchange 752 all parameters needed for the Plaintext CID algorithm. 754 0 1 2 3 755 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 756 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 757 | SIDL (8) | 758 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 759 | | 760 + Server ID (variable) + 761 | | 762 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 764 The SIDL field indicates the length of the server ID field. The 765 Server ID field indicates the encoding that represents the 766 destination server. 768 5. Config Rotation 770 The first two bits of any connection-ID MUST encode the configuration 771 phase of that ID. QUIC-LB messages indicate the phase of the 772 algorithm and parameters that they encode. 774 A new configuration may change one or more parameters of the old 775 configuration, or change the algorithm used. 777 It is possible for servers to have mutually exclusive sets of 778 supported algorithms, or for a transition from one algorithm to 779 another to result in Fail Payloads. The four states encoded in these 780 two bits allow two mutually exclusive server pools to coexist, and 781 for each of them to transition to a new set of parameters. 783 When new configuration is distributed to servers, there will be a 784 transition period when connection IDs reflecting old and new 785 configuration coexist in the network. The rotation bits allow load 786 balancers to apply the correct routing algorithm and parameters to 787 incoming packets. 789 Servers MUST NOT generate new connection IDs using an old 790 configuration when it has sent an Ack payload for a new 791 configuration. 793 Load balancers SHOULD NOT use a codepoint to represent a new 794 configuration until it takes precautions to make sure that all 795 connections using IDs with an old configuration at that codepoint 796 have closed or transitioned. They MAY drop connection IDs with the 797 old configuration after a reasonable interval to accelerate this 798 process. 800 5.1. Configuration Failover 802 If a server is configured to expect QUIC-LB messages, and it has not 803 received these, it MUST generate connection IDs with the config 804 rotation bits set to '0b11' and MUST use the "disable_migration" 805 transport parameter in all new QUIC connections. It MUST NOT send 806 NEW_CONNECTION_ID frames with new values. 808 A load balancer that sees a connection ID with config rotation bits 809 set to '0b11' MUST revert to 5-tuple routing. 811 6. Configuration Requirements 813 QUIC-LB strives to minimize the configuration load to enable, as much 814 as possible, a "plug-and-play" model. However, there are some 815 configuration requirements based on algorithm and protocol choices 816 above. 818 There are three levels of configuration that correspond to increasing 819 levels of concern about the security of the load balancer-server 820 path. 822 The complete information requirements are described in Section 4. 823 Load balancers MUST have configuration for all parameters of each 824 routing algorithm they support. 826 If there is any in-band communication, servers MUST be explicitly 827 configured with the token of the load balancer they expect to 828 interface with. Endpoints that use Stream Cipher CIDs MUST have this 829 token regardless of the configuration method. 831 Optionally, servers MAY be configured with the global parameters of 832 supported routing algorithms. This allows load balancers to use 833 Server ID and Modulus Payloads, limiting the information sent in- 834 band. 836 Finally, servers MAY be directly configured with their unique server 837 IDs or modulus, eliminating need for in-band messaging at all. In 838 this case, servers and load balancers MUST enable only one routing 839 algorithm, as there is no explicit message to agree on one or the 840 other. 842 7. Security Considerations 844 QUIC-LB is intended to preserve routability and prevent linkability. 845 Attacks on the protocol would compromise at least one of these 846 objectives. 848 Note that the Plaintext CID algorithm makes no attempt to obscure the 849 server mapping, and therefore does not address these concerns. It 850 exists to allow consistent CID encoding for compatibility across a 851 network infrastructure. Servers that are running the Plaintext CID 852 algorithm SHOULD only use it to generate new CIDs for the Server 853 Initial Packet, and SHOULD NOT send CIDs in QUIC NEW_CONNECTION_ID 854 frames. Doing so might falsely suggest to the client that said CIDs 855 were generated in a secure fashion. 857 A routability attack would inject QUIC-LB messages so that load 858 balancers incorrectly route QUIC connections. 860 A linkability attack would find some means of determining that two 861 connection IDs route to the same server. As described above, there 862 is no scheme that strictly prevents linkability for all traffic 863 patterns, and therefore efforts to frustrate any analysis of server 864 ID encoding have diminishing returns. 866 7.1. Outside attackers 868 For an outside attacker to break routability, it must inject packets 869 that correctly guess the 64-bit token, and servers must be reachable 870 from these outside hosts. Load balancers SHOULD drop QUIC-LB packets 871 that arrive on its external interface. 873 Off-path outside attackers cannot observe connection IDs, and will 874 therefore struggle to link them. 876 On-path outside attackers might try to link connection IDs to the 877 same QUIC connection. The Encrypted CID algorithm provides robust 878 entropy to making any sort of linkage. The Obfuscated CID obscures 879 the mapping and prevents trivial brute-force attacks to determine the 880 routing parameters, but does not provide robust protection against 881 sophisticated attacks. 883 7.2. Inside Attackers 885 As described above, on-path inside attackers are intrinsically able 886 to map two connection IDs to the same server. The QUIC-LB algorithms 887 do prevent the linkage of two connection IDs to the same individual 888 connection if servers make reasonable selections when generating new 889 IDs for that connection. 891 On-path inside attackers can break routability for new and migrating 892 connections by copying the token from QUIC-LB messages. From this 893 privileged position, however, there are many other attacks that can 894 break QUIC connections to the server during the handshake. 896 Off-path inside attackers cannot observe connection IDs to link them. 897 To successfully break routability, they must correctly guess the 898 token. 900 8. IANA Considerations 902 There are no IANA requirements. 904 9. References 906 9.1. Normative References 908 [QUIC-TRANSPORT] 909 Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based 910 Multiplexed and Secure Transport", draft-ietf-quic- 911 transport (work in progress). 913 9.2. Informative References 915 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 916 Requirement Levels", BCP 14, RFC 2119, 917 DOI 10.17487/RFC2119, March 1997, 918 . 920 Appendix A. Acknowledgments 922 Appendix B. Change Log 924 *RFC Editor's Note:* Please remove this section prior to 925 publication of a final version of this document. 927 B.1. Since draft-duke-quic-load-balancers-03 929 o Renamed Plaintext CID algorithm as Obfuscated CID 931 o Added new Plaintext CID algorithm 933 B.2. Since draft-duke-quic-load-balancers-02 935 o Added Config Rotation 937 o Added failover mode 939 o Tweaks to existing CID algorithms 941 o Added Block Cipher CID algorithm 943 o Reformatted QUIC-LB packets 945 B.3. Since draft-duke-quic-load-balancers-01 947 o Complete rewrite 949 o Supports multiple security levels 951 o Lightweight messages 953 B.4. Since draft-duke-quic-load-balancers-00 955 o Converted to markdown 957 o Added variable length connection IDs 959 Author's Address 961 Martin Duke 962 F5 Networks, Inc. 964 Email: martin.h.duke@gmail.com