idnits 2.17.1 draft-duke-quic-load-balancers-02.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 (September 17, 2018) is 2048 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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 (-34) exists of draft-ietf-quic-transport-14 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). 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 September 17, 2018 5 Expires: March 21, 2019 7 QUIC-LB: Generating Routable QUIC Connection IDs 8 draft-duke-quic-load-balancers-02 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 March 21, 2019. 39 Copyright Notice 41 Copyright (c) 2018 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 . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Protocol Objectives . . . . . . . . . . . . . . . . . . . . . 4 59 2.1. Simplicity . . . . . . . . . . . . . . . . . . . . . . . 4 60 2.2. Security . . . . . . . . . . . . . . . . . . . . . . . . 4 61 2.3. Robustness to Middleboxes . . . . . . . . . . . . . . . . 5 62 2.4. Load Balancer Chains . . . . . . . . . . . . . . . . . . 5 63 3. Routing Algorithms . . . . . . . . . . . . . . . . . . . . . 5 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. Encrypted CID Algorithm . . . . . . . . . . . . . . . . . 7 68 3.2.1. Load Balancer Actions . . . . . . . . . . . . . . . . 7 69 3.2.2. Server Actions . . . . . . . . . . . . . . . . . . . 8 70 4. Protocol Description . . . . . . . . . . . . . . . . . . . . 8 71 4.1. Out of band sharing . . . . . . . . . . . . . . . . . . . 8 72 4.2. QUIC-LB Message Exchange . . . . . . . . . . . . . . . . 8 73 4.2.1. Packet Header Format . . . . . . . . . . . . . . . . 9 74 4.2.2. Ack Payload . . . . . . . . . . . . . . . . . . . . . 9 75 4.2.3. Fail Payload . . . . . . . . . . . . . . . . . . . . 10 76 4.2.4. Routing Info Payload . . . . . . . . . . . . . . . . 11 77 4.2.5. Encrypted CID Payload . . . . . . . . . . . . . . . . 11 78 4.2.6. Server ID Payload . . . . . . . . . . . . . . . . . . 12 79 4.2.7. Modulus Payload . . . . . . . . . . . . . . . . . . . 13 80 5. Configuration Requirements . . . . . . . . . . . . . . . . . 13 81 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 82 6.1. Outside attackers . . . . . . . . . . . . . . . . . . . . 14 83 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 84 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 85 8.1. Normative References . . . . . . . . . . . . . . . . . . 15 86 8.2. Informative References . . . . . . . . . . . . . . . . . 15 87 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 15 88 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 15 89 B.1. Since draft-duke-quic-load-balancers-00 . . . . . . . . . 15 90 B.2. Since draft-duke-quic-load-balancers-01 . . . . . . . . . 15 91 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 16 93 1. Introduction 95 QUIC packets usually contain a connection ID to allow endpoints to 96 associate packets with different address/port 4-tuples to the same 97 connection context. This feature makes connections robust in the 98 event of NAT rebinding. QUIC endpoints designate the connection ID 99 which peers use to address packets. Server-generated connection IDs 100 create a potential need for out-of-band communication to support 101 QUIC. 103 QUIC allows servers (or load balancers) to designate an initial 104 connection ID to encode useful routing information for load 105 balancers. It also encourages servers, in packets protected by 106 cryptography, to provide additional connection IDs to the client. 107 This allows clients that know they are going to change IP address or 108 port to use a separate connection ID on the new path, thus reducing 109 linkability as clients move through the world. 111 There is a tension between the requirements to provide routing 112 information and mitigate linkability. Ultimately, because new 113 connection IDs are in protected packets, they must be generated at 114 the server if the load balancer does not have access to the 115 connection keys. However, it is the load balancer that has the 116 context necessary to generate a connection ID that encodes useful 117 routing information. In the absence of any shared state between load 118 balancer and server, the load balancer must maintain a relatively 119 expensive table of server-generated connection IDs, and will not 120 route packets correctly if they use a connection ID that was 121 originally communicated in a protected NEW_CONNECTION_ID frame. 123 This specification provides a method of coordination between QUIC 124 servers and low-state load balancers to support connection IDs that 125 encode routing information. It describes desirable properties of a 126 solution, and then specifies a protocol that provides those 127 properties. This protocol supports multiple encoding schemes that 128 increase in complexity as they address paths between load balancer 129 and server with weaker trust dynamics. 131 1.1. Terminology 133 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 134 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 135 document are to be interpreted as described in RFC 2119 [RFC2119]. 137 In this document, these words will appear with that interpretation 138 only when in ALL CAPS. Lower case uses of these words are not to be 139 interpreted as carrying significance described in RFC 2119. 141 In this document, "client" and "server" refer to the endpoints of a 142 QUIC connection unless otherwise indicated. A "load balancer" is an 143 intermediary for that connection that does not possess QUIC 144 connection keys, but it may rewrite IP addresses or conduct other IP 145 or UDP processing. 147 Note that stateful load balancers that act as proxies, by terminating 148 a QUIC connection with the client and then retrieving data from the 149 server using QUIC or another protocol, are treated as a server with 150 respect to this specification. 152 When discussing security threats to QUIC-LB, we distinguish between 153 "inside observers" and "outside observers." The former lie on the 154 path between the load balancer and server, which often but not always 155 lies inside the server's data center or cloud deployment. Outside 156 observers are on the path between the load balancer and client. 157 "Off-path" attackers, though not on any data path, may also be 158 "inside" or "outside" depending on whether not they have network 159 access to the server without intermediation by the load balancer and/ 160 or other security devices. 162 2. Protocol Objectives 164 2.1. Simplicity 166 QUIC is intended to provide unlinkability across connection 167 migration, but servers are not required to provide additional 168 connection IDs that effectively prevent linkability. If the 169 coordination scheme is too difficult to implement, servers behind 170 load balancers using connection IDs for routing will use trivially 171 linkable connection IDs. Clients will therefore be forced choose 172 between terminating the connection during migration or remaining 173 linkable, subverting a design objective of QUIC. 175 The solution should be both simple to implement and require little 176 additional infrastructure for cryptographic keys, etc. 178 2.2. Security 180 In the limit where there are very few connections to a pool of 181 servers, no scheme can prevent the linking of two connection IDs with 182 high probability. In the opposite limit, where all servers have many 183 connections that start and end frequently, it will be difficult to 184 associate two connection IDs even if they are known to map to the 185 same server. 187 QUIC-LB is relevant in the region between these extremes: when the 188 information that two connection IDs map to the same server is helpful 189 to linking two connection IDs. Obviously, any scheme that 190 transparently communicates this mapping to outside observers 191 compromises QUIC's defenses against linkability. 193 However, concealing this mapping from inside observers is beyond the 194 scope of QUIC-LB. By simply observing Link-Layer and/or Network- 195 Layer addresses of packets containing distinct connection IDs, it is 196 trivial to determine that they map to the same server, even if 197 connection IDs are entirely random and do not encode routing 198 information. Schemes that conceal these addresses (e.g., IPsec) can 199 also conceal QUIC-LB messages. 201 Inside observers are generally able to mount Denial of Service (DoS) 202 attacks on QUIC connections regardless of Connection ID schemes. 203 However, QUIC-LB should protect against Denial of Service due to 204 inside off-path attackers in cases where such attackers are possible. 206 2.3. Robustness to Middleboxes 208 The path between load balancer and server may pass through 209 middleboxes that could drop the coordination messages in this 210 protocol. It is therefore advantageous to make messages resemble 211 QUIC traffic as much as possible, as any viable path must obviously 212 admit QUIC traffic. 214 2.4. Load Balancer Chains 216 While it is possible to construct a scheme that supports multiple 217 low-state load balancers in the path, by using different parts of the 218 connection ID to encoding routing information for each load balancer, 219 this use case is out of scope for QUIC-LB. 221 3. Routing Algorithms 223 In QUIC-LB, load balancers do not send individual connection IDs to 224 servers. Instead, they communicate the parameters of an algorithm to 225 generate routable connection IDs. 227 The algorithms differ in the complexity of configuration at both load 228 balancer and server. Increasing complexity improves obfuscation of 229 the server mapping. 231 The load balancer SHOULD route Initial and 0-RTT packets from the 232 client using an alternate algorithm. Note that the SCID in these 233 packets may not be long enough to represent all the routing bits. 234 This algorithm SHOULD generate consistent results for Initial and 235 0RTT packets that arrive with the same source and destination 236 connection ID. The load balancer algorithms below apply to all 237 incoming Handshake and 1-RTT packets. 239 3.1. Plaintext CID Algorithm 241 3.1.1. Load Balancer Actions 243 The load balancer selects an arbitrary set of bits of the server 244 connection ID (SCID) that it will use to route to a given server, 245 called the "routing bits". The number of bits MUST have enough 246 entropy to have a different code point for each server, and SHOULD 247 have enough entropy so that there are many codepoints for each 248 server. 250 The load balancer selects a divisor that MUST be larger than the 251 number of servers. It SHOULD be large enough to accommodate 252 reasonable increases in the number of servers. 254 The load balancer also assigns each server a "modulus", an integer 255 between 0 and the divisor minus 1. These MUST be unique for each 256 server. 258 The load balancer shares these three values with servers, as 259 explained in Section 4. 261 Upon receipt of a QUIC packet that is not of type Initial or 0-RTT, 262 the load balancer extracts the selected bits of the SCID and 263 expresses them as an unsigned integer of that length. The load 264 balancer then divides the result by the chosen divisor. The modulus 265 of this operation maps to the modulus for the destination server. . 266 Note that any SCID that contains a server's modulus, plus an 267 arbitrary integer multiple of the divisor, in the routing bits is 268 routable to that server regardless of the contents of the non-routing 269 bits. Outside observers that do not know the divisor or the routing 270 bits will therefore have difficulty identifying that two SCIDs route 271 to the same server. 273 Note also that not all Connection IDs are necessarily routable, as 274 the computed modulus may not match one assigned to any server. Load 275 balancers SHOULD drop these packets if not a QUIC Initial or 0-RTT 276 packet. 278 3.1.2. Server Actions 280 The server may choose any connection ID length that can represent all 281 of the routing bits. 283 When a server needs a new connection ID, it adds an arbitrary 284 nonnegative integer multiple of the divisor to its modulus, without 285 exceeding the maximum integer value implied by the number of routing 286 bits. The choice of multiple should appear random within these 287 constraints. 289 The server encodes the result in the routing bits. It MAY put any 290 other value into the non-routing bits. The non-routing bits SHOULD 291 appear random to observers. 293 3.2. Encrypted CID Algorithm 295 The Encrypted CID algorithm provides true cryptographic protection, 296 rather than mere obfuscation, at the cost of additional per-packet 297 processing at the load balancer to decrypt every incoming connection 298 ID except for Initial and 0RTT packets. 300 3.2.1. Load Balancer Actions 302 The load balancer assigns a server ID to every server in its pool, 303 and determines a server ID length (in octets) sufficiently large to 304 encode all server IDs, including potential future servers. The 305 server ID will be encoded in the first octets of the connection ID. 307 The load balancer also selects a connection ID length that all 308 servers must use, and an 16-octet AES-CTR key to use for connection 309 ID decryption. 311 The load balancer shares these three values with servers, as 312 explained in Section 4. 314 Upon receipt of a QUIC packet that is not of type Initial or 0-RTT, 315 the load balancer extracts as many of the earliest octets from the 316 destination connection ID as necessary to match the server ID length. 318 The load balancer decrypts the server ID using 128-bit AES in counter 319 (CTR) mode, much like QUIC packet number decryption. The counter 320 input to AES-CTR is the bytes of the connection ID that do not 321 constitute the encrypted server ID. 323 server_id = AES-CTR(key, non-server-id-bytes, encrypted_server_id) 325 The output of the decryption is the server ID that the load balancer 326 uses for routing. 328 3.2.2. Server Actions 330 When generating a routable connection ID, the server writes its 331 provided server ID into the server ID octets, and arbitrary bits into 332 the remaining required connection ID octets. These arbitrary bits 333 MAY encode additional information, but SHOULD appear essentially 334 random to observers. 336 The server then encrypts the server ID bytes using 128-bit AES in 337 counter (CTR) mode, much like QUIC packet number encryption. The 338 counter input to AES-CTR is the bytes of the connection ID that do 339 not constitute the encrypted server ID. 341 encrypted_server_id = AES-CTR(key, non_server_id_bytes, server-id) 343 4. Protocol Description 345 The fundamental protocol requirement is to share the choice of 346 routing algorithm, and the relevant parameters for that algorithm, 347 between load balancer and server. 349 For Plaintext CID Routing, this consists of the Routing Bits, 350 Divisor, and Modulus. The Modulus is unique to each server, but the 351 others MUST be global. 353 For Encrypted CID Routing, this consists of the Server ID, Server ID 354 Length, Key, and Connection ID Length. The Server ID is unique to 355 each server, but the others MUST be global. 357 4.1. Out of band sharing 359 When there are concerns about the integrity of the path between load 360 balancer and server, operators may share routing information using an 361 out-of-band technique, which is out of the scope of this 362 specification. 364 To simplify configuration, the global parameters can be shared out- 365 of-band, while the load balancer sends the unique server IDs via the 366 truncated message formats presented below. 368 4.2. QUIC-LB Message Exchange 370 QUIC-LB load balancers send the encoding parameters to servers as 371 they discover the servers, using a single packet to each that 372 resembles QUIC. They periodically retransmit this packet to each 373 server until that server responds with a QUIC-LB ack. Specifics of 374 this retransmission are implementation-dependent. 376 These message formats are specific to QUICv2 and experimental 377 versions leading up to QUICv2. They may require revision for future 378 versions of QUIC. 380 4.2.1. Packet Header Format 382 0 1 2 3 383 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 384 +-+-+-+-+-+-+-+-+ 385 | Type = 0xfb | 386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 387 | Version (32) | 388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 389 | 0x00 | 390 +-+-+-+-+-+-+-+-+ 392 Figure 1: QUIC-LB Header 394 QUIC-LB messages are QUIC packets with a long header and zero length 395 connection IDs. They are sent when a load balancer boots up, or 396 detects a new server in the pool. QUIC-LB packets are delivered in a 397 UDP datagram. 399 The type field is 0xfb, which is otherwise unused in QUICv2. 401 The Version field allows QUIC-LB to use the Version Negotiation 402 mechanism. All messages in this specification are specific to 403 QUICv2, as future QUIC versions may use the 0xfb packet type for 404 other purposes. Therefore, the Version field should be set as the 405 codepoint for QUICv2 as defined in [QUIC-TRANSPORT]. 407 Load balancers MUST cease sending QUIC-LB packets of this version to 408 a server when that server sends a Version Negotiation packet that 409 does not advertise the version. 411 The 0x00 byte indicates that there are no connection IDs present in 412 the header. 414 The remainder of the packet is the payload. This has multiple 415 formats. 417 4.2.2. Ack Payload 418 0 1 2 3 419 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 420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 421 | Type = 0x00 | 422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 423 | | 424 + Token (64) + 425 | | 426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 428 Figure 2: Ack Payload 430 The Ack Payload consists of nine octets. Servers send this payload 431 after receipt of any acceptable QUIC-LB packet from a load balancer. 433 The token field echoes the token field from the acknowledged packet. 435 Load balancers MUST retransmit a QUIC-LB packet if not followed by a 436 valid Ack Payload or Version Negotiation Packet from the destination 437 after a reasonable interval. 439 4.2.3. Fail Payload 441 0 1 2 3 442 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 443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 444 | Type = 0x01 | Supp. Type | Supp. Type | ... 445 +-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 446 | | 447 + Token (64) + 448 | | 449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 451 Figure 3: Fail Payload 453 Servers MUST send a Fail Payload upon receipt of a payload type which 454 they do not support, or if they do not possess all of the implied 455 out-of-band configuration to support a particular payload type. 457 After the type octet, servers append additional octets to list all 458 payload types they support. 460 The token field echoes the token field from the acknowledged packet. 462 Upon receipt of a Fail Payload, Load Balancers MUST either send a 463 QUIC-LB payload the server supports, or remove the server from the 464 server pool. 466 4.2.4. Routing Info Payload 468 0 1 2 3 469 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 470 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 471 | Type = 0x02 | 472 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 473 | | 474 + Token (64) + 475 | | 476 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 477 | | 478 + + 479 | | 480 + Routing Bit Mask (144) + 481 | | 482 + + 483 | | 484 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 485 | | Modulus (16) | 486 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 487 | Divisor (16) | 488 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 490 Figure 4: Routing Info Payload 492 The Type Octet indicates that this is a Routing Info Payload, which 493 contains all parameters for the plaintext CID algorithm. 495 The Token is an 8-octet field that both entities obtain at 496 configuration time. It is used to verify that the sender is not an 497 inside off-path attacker. Servers SHOULD silently drop QUIC-LB 498 packets with an incorrect token. 500 The Routing Bit Mask encodes a '1' at every bit position in the 501 server connection ID that will encode routing information. 503 These bits, along with the Modulus and Divisor, are chosen by the 504 load balancer as described in Section 3.1. 506 4.2.5. Encrypted CID Payload 507 0 1 2 3 508 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 509 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 510 | Type = 0x03 | CIDL (8) | SIDL (8) | 511 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 512 | | 513 + Token (64) + 514 | | 515 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 516 | Server ID (variable) | 517 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 518 | | 519 + Key (128) + 520 | | 521 + + 522 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 524 Figure 5: Encrypted CID Payload 526 The CIDL field is a one-octet unsigned integer that describes the 527 server connection ID length necessary to use this routing algorithm, 528 in octets. 530 The SIDL field is a one-octet unsigned integer that describes the 531 server ID length necessary to use this routing algorithm, in octets. 533 The server ID is the unique value assigned to the receiving server. 534 Its length is determined by the SIDL field. 536 The key is an 16-octet field that contains the key that the load 537 balancer will use to decrypt server IDs on QUIC packets. See 538 Section 6 to understand why sending keys in plaintext may be a safe 539 strategy. 541 4.2.6. Server ID Payload 543 0 1 2 3 544 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 545 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 546 | Type = 0x04 | SIDL (8) | Server ID (variable) | 547 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 548 | | 549 + Token (64) + 550 | | 551 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 553 Figure 6: Server ID Payload 555 Load balancers send the Server ID when all global values for CID 556 encryption are sent out-of-band, so that only the server-unique 557 values must be sent in-band. The fields are identical to their 558 counterparts in the Encrypted CID payload. 560 4.2.7. Modulus Payload 562 0 1 2 3 563 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 564 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 565 | Type = 0x05 | Modulus (16) | 566 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 567 | | 568 + Token (64) + 569 | | 570 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 572 Figure 7: Modulus Payload 574 Load balancers send the Modulus when all global values for Plaintext 575 CIDs are sent out-of-band, so that only the server- unique values 576 must be sent in-band. The Modulus field is identical to its 577 counterpart in the Routing Info payload. 579 5. Configuration Requirements 581 QUIC-LB strives to minimize the configuration load to enable, as much 582 as possible, a "plug-and-play" model. However, there are some 583 configuration requirements based on algorithm and protocol choices 584 above. 586 There are three levels of configuration that correspond to increasing 587 levels of concern about the security of the load balancer-server 588 path. 590 The complete information requirements are described in Section 4. 591 Load balancers MUST have configuration for all parameters of each 592 routing algorithm they support. 594 If there is any in-band communication, servers MUST be explicitly 595 configured with the token of the load balancer they expect to 596 interface with. 598 Optionally, servers MAY be configured with the global parameters of 599 supported routing algorithms. This allows load balancers to use 600 Server ID and Modulus Payloads, limiting the information sent in- 601 band. 603 Finally, servers MAY be directly configured with their unique server 604 IDs or modulus, eliminating need for in-band messaging at all. In 605 this case, servers and load balancers MUST enable only one routing 606 algorithm, as there is no explicit message to agree on one or the 607 other. 609 6. Security Considerations 611 QUIC-LB is intended to preserve routability and prevent linkability. 612 Attacks on the protocol would compromise at least one of these 613 objectives. 615 A routability attack would inject QUIC-LB messages so that load 616 balancers incorrectly route QUIC connections. 618 A linkability attack would find some means of determining that two 619 connection IDs route to the same server. As described above, there 620 is no scheme that strictly prevents linkability for all traffic 621 patterns, and therefore efforts to frustrate any analysis of server 622 ID encoding have diminishing returns. 624 6.1. Outside attackers 626 For an outside attacker to break routability, it must inject packets 627 that correctly guess the 64-bit token, and servers must be reachable 628 from these outside hosts. Load balancers SHOULD drop QUIC-LB packets 629 that arrive on its external interface. 631 Off-path outside attackers cannot observe connection IDs, and will 632 therefore struggle to link them. 634 On-path outside attackers might try to link connection IDs to the 635 same QUIC connection. The Encrypted CID algorithm provides robust 636 entropy to making any sort of linkage. The Plaintext CID obscures 637 the mapping and prevents trivial brute-force attacks to determine the 638 routing parameters, but does not provide robust protection against 639 sophisticated attacks. 641 ## Inside Attackers 643 As described above, on-path inside attackers are intrinsically able 644 to map two connection IDs to the same server. The QUIC-LB algorithms 645 do prevent the linkage of two connection IDs to the same individual 646 connection if servers make reasonable selections when generating new 647 IDs for that connection. 649 On-path inside attackers can break routability for new and migrating 650 connections by copying the token from QUIC-LB messages. From this 651 privileged position, however, there are many other attacks that can 652 break QUIC connections to the server during the handshake. 654 Off-path inside attackers cannot observe connection IDs to link them. 655 To successfully break routability, they must correctly guess the 656 token. 658 7. IANA Considerations 660 There are no IANA requirements. 662 8. References 664 8.1. Normative References 666 [QUIC-TRANSPORT] 667 Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based 668 Multiplexed and Secure Transport", draft-ietf-quic- 669 transport-14 (work in progress). 671 8.2. Informative References 673 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 674 Requirement Levels", BCP 14, RFC 2119, 675 DOI 10.17487/RFC2119, March 1997, 676 . 678 Appendix A. Acknowledgments 680 Appendix B. Change Log 682 *RFC Editor's Note:* Please remove this section prior to 683 publication of a final version of this document. 685 B.1. Since draft-duke-quic-load-balancers-00 687 o Converted to markdown 689 o Added variable length connection IDs 691 B.2. Since draft-duke-quic-load-balancers-01 693 o Complete rewrite 695 o Supports multiple security levels 697 o Lightweight messages 699 Author's Address 701 Martin Duke 702 F5 Networks, Inc. 704 Email: martin.h.duke@gmail.com