idnits 2.17.1 draft-ietf-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 == Line 889 has weird spacing: '...boolean first...' -- The document date (March 9, 2020) is 1508 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) -- Looks like a reference, but probably isn't: '16' on line 919 -- Looks like a reference, but probably isn't: '19' on line 905 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 4 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 N. Banks 5 Expires: September 10, 2020 Microsoft 6 March 9, 2020 8 QUIC-LB: Generating Routable QUIC Connection IDs 9 draft-ietf-quic-load-balancers-02 11 Abstract 13 QUIC connection IDs allow continuation of connections across address/ 14 port 4-tuple changes, and can store routing information for stateless 15 or low-state load balancers. They also can prevent linkability of 16 connections across deliberate address migration through the use of 17 protected communications between client and server. This creates 18 issues for load-balancing intermediaries. This specification 19 standardizes methods for encoding routing information given a small 20 set of configuration parameters. This framework also enables offload 21 of other QUIC functions to trusted intermediaries, given the explicit 22 cooperation of the QUIC server. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on September 10, 2020. 41 Copyright Notice 43 Copyright (c) 2020 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (https://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 59 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 60 2. Protocol Objectives . . . . . . . . . . . . . . . . . . . . . 5 61 2.1. Simplicity . . . . . . . . . . . . . . . . . . . . . . . 5 62 2.2. Security . . . . . . . . . . . . . . . . . . . . . . . . 5 63 3. First CID octet . . . . . . . . . . . . . . . . . . . . . . . 5 64 3.1. Config Rotation . . . . . . . . . . . . . . . . . . . . . 6 65 3.2. Configuration Failover . . . . . . . . . . . . . . . . . 6 66 3.3. Length Self-Description . . . . . . . . . . . . . . . . . 7 67 4. Routing Algorithms . . . . . . . . . . . . . . . . . . . . . 7 68 4.1. Plaintext CID Algorithm . . . . . . . . . . . . . . . . . 8 69 4.1.1. Configuration Agent Actions . . . . . . . . . . . . . 8 70 4.1.2. Load Balancer Actions . . . . . . . . . . . . . . . . 9 71 4.1.3. Server Actions . . . . . . . . . . . . . . . . . . . 9 72 4.2. Obfuscated CID Algorithm . . . . . . . . . . . . . . . . 9 73 4.2.1. Configuration Agent Actions . . . . . . . . . . . . . 9 74 4.2.2. Load Balancer Actions . . . . . . . . . . . . . . . . 10 75 4.2.3. Server Actions . . . . . . . . . . . . . . . . . . . 10 76 4.3. Stream Cipher CID Algorithm . . . . . . . . . . . . . . . 10 77 4.3.1. Configuration Agent Actions . . . . . . . . . . . . . 11 78 4.3.2. Load Balancer Actions . . . . . . . . . . . . . . . . 11 79 4.3.3. Server Actions . . . . . . . . . . . . . . . . . . . 12 80 4.4. Block Cipher CID Algorithm . . . . . . . . . . . . . . . 12 81 4.4.1. Configuration Agent Actions . . . . . . . . . . . . . 12 82 4.4.2. Load Balancer Actions . . . . . . . . . . . . . . . . 13 83 4.4.3. Server Actions . . . . . . . . . . . . . . . . . . . 13 84 5. Retry Service . . . . . . . . . . . . . . . . . . . . . . . . 13 85 5.1. Common Requirements . . . . . . . . . . . . . . . . . . . 14 86 5.2. No-Shared-State Retry Service . . . . . . . . . . . . . . 14 87 5.2.1. Configuration Agent Actions . . . . . . . . . . . . . 14 88 5.2.2. Service Requirements . . . . . . . . . . . . . . . . 15 89 5.2.3. Server Requirements . . . . . . . . . . . . . . . . . 16 90 5.3. Shared-State Retry Service . . . . . . . . . . . . . . . 17 91 5.3.1. Configuration Agent Actions . . . . . . . . . . . . . 18 92 5.3.2. Service Requirements . . . . . . . . . . . . . . . . 18 93 5.3.3. Server Requirements . . . . . . . . . . . . . . . . . 18 94 6. Configuration Requirements . . . . . . . . . . . . . . . . . 19 95 7. Additional Use Cases . . . . . . . . . . . . . . . . . . . . 20 96 7.1. Load balancer chains . . . . . . . . . . . . . . . . . . 20 97 7.2. Moving connections between servers . . . . . . . . . . . 21 98 8. Security Considerations . . . . . . . . . . . . . . . . . . . 21 99 8.1. Attackers not between the load balancer and server . . . 21 100 8.2. Attackers between the load balancer and server . . . . . 22 101 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 102 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 103 10.1. Normative References . . . . . . . . . . . . . . . . . . 22 104 10.2. Informative References . . . . . . . . . . . . . . . . . 22 105 Appendix A. Load Balancer Test Vectors . . . . . . . . . . . . . 22 106 A.1. Obfuscated Connection ID Algorithm . . . . . . . . . . . 23 107 A.2. Stream Cipher Connection ID Algorithm . . . . . . . . . . 24 108 A.3. Block Cipher Connection ID Algorithm . . . . . . . . . . 25 109 Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 26 110 Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 26 111 C.1. since-draft-ietf-quic-load-balancers-01 . . . . . . . . . 26 112 C.2. since-draft-ietf-quic-load-balancers-00 . . . . . . . . . 26 113 C.3. Since draft-duke-quic-load-balancers-06 . . . . . . . . . 26 114 C.4. Since draft-duke-quic-load-balancers-05 . . . . . . . . . 26 115 C.5. Since draft-duke-quic-load-balancers-04 . . . . . . . . . 26 116 C.6. Since draft-duke-quic-load-balancers-03 . . . . . . . . . 27 117 C.7. Since draft-duke-quic-load-balancers-02 . . . . . . . . . 27 118 C.8. Since draft-duke-quic-load-balancers-01 . . . . . . . . . 27 119 C.9. Since draft-duke-quic-load-balancers-00 . . . . . . . . . 27 120 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 122 1. Introduction 124 QUIC packets [QUIC-TRANSPORT] usually contain a connection ID to 125 allow endpoints to associate packets with different address/port 126 4-tuples to the same connection context. This feature makes 127 connections robust in the event of NAT rebinding. QUIC endpoints 128 usually designate the connection ID which peers use to address 129 packets. Server-generated connection IDs create a potential need for 130 out-of-band communication to support QUIC. 132 QUIC allows servers (or load balancers) to designate an initial 133 connection ID to encode useful routing information for load 134 balancers. It also encourages servers, in packets protected by 135 cryptography, to provide additional connection IDs to the client. 136 This allows clients that know they are going to change IP address or 137 port to use a separate connection ID on the new path, thus reducing 138 linkability as clients move through the world. 140 There is a tension between the requirements to provide routing 141 information and mitigate linkability. Ultimately, because new 142 connection IDs are in protected packets, they must be generated at 143 the server if the load balancer does not have access to the 144 connection keys. However, it is the load balancer that has the 145 context necessary to generate a connection ID that encodes useful 146 routing information. In the absence of any shared state between load 147 balancer and server, the load balancer must maintain a relatively 148 expensive table of server-generated connection IDs, and will not 149 route packets correctly if they use a connection ID that was 150 originally communicated in a protected NEW_CONNECTION_ID frame. 152 This specification provides common algorithms for encoding the server 153 mapping in a connection ID given some shared parameters. The mapping 154 is generally only discoverable by observers that have the parameters, 155 preserving unlinkability as much as possible. 157 Aside from load balancing, a QUIC server may also desire to offload 158 other protocol functions to trusted intermediaries. These 159 intermediaries might include hardware assist on the server host 160 itself, without access to fully decrypted QUIC packets. For example, 161 this document specifies a means of offloading stateless retry to 162 counter Denial of Service attacks. It also proposes a system for 163 self-encoding connection ID length in all packets, so that crypto 164 offload can consistently look up key information. 166 While this document describes a small set of configuration parameters 167 to make the server mapping intelligible, the means of distributing 168 these parameters between load balancers, servers, and other trusted 169 intermediaries is out of its scope. There are numerous well-known 170 infrastructures for distribution of configuration. 172 1.1. Terminology 174 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 175 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 176 document are to be interpreted as described in RFC 2119 [RFC2119]. 178 In this document, these words will appear with that interpretation 179 only when in ALL CAPS. Lower case uses of these words are not to be 180 interpreted as carrying significance described in RFC 2119. 182 In this document, "client" and "server" refer to the endpoints of a 183 QUIC connection unless otherwise indicated. A "load balancer" is an 184 intermediary for that connection that does not possess QUIC 185 connection keys, but it may rewrite IP addresses or conduct other IP 186 or UDP processing. 188 Note that stateful load balancers that act as proxies, by terminating 189 a QUIC connection with the client and then retrieving data from the 190 server using QUIC or another protocol, are treated as a server with 191 respect to this specification. 193 2. Protocol Objectives 195 2.1. Simplicity 197 QUIC is intended to provide unlinkability across connection 198 migration, but servers are not required to provide additional 199 connection IDs that effectively prevent linkability. If the 200 coordination scheme is too difficult to implement, servers behind 201 load balancers using connection IDs for routing will use trivially 202 linkable connection IDs. Clients will therefore be forced choose 203 between terminating the connection during migration or remaining 204 linkable, subverting a design objective of QUIC. 206 The solution should be both simple to implement and require little 207 additional infrastructure for cryptographic keys, etc. 209 2.2. Security 211 In the limit where there are very few connections to a pool of 212 servers, no scheme can prevent the linking of two connection IDs with 213 high probability. In the opposite limit, where all servers have many 214 connections that start and end frequently, it will be difficult to 215 associate two connection IDs even if they are known to map to the 216 same server. 218 QUIC-LB is relevant in the region between these extremes: when the 219 information that two connection IDs map to the same server is helpful 220 to linking two connection IDs. Obviously, any scheme that 221 transparently communicates this mapping to outside observers 222 compromises QUIC's defenses against linkability. 224 Though not an explicit goal of the QUIC-LB design, concealing the 225 server mapping also complicates attempts to focus attacks on a 226 specific server in the pool. 228 3. First CID octet 230 The first octet of a Connection ID is reserved for two special 231 purposes, one mandatory (config rotation) and one optional (length 232 self-description). 234 Subsequent sections of this document refer to the contents of this 235 octet as the "first octet." 237 3.1. Config Rotation 239 The first two bits of any connection-ID MUST encode the configuration 240 phase of that ID. QUIC-LB messages indicate the phase of the 241 algorithm and parameters that they encode. 243 A new configuration may change one or more parameters of the old 244 configuration, or change the algorithm used. 246 It is possible for servers to have mutually exclusive sets of 247 supported algorithms, or for a transition from one algorithm to 248 another to result in Fail Payloads. The four states encoded in these 249 two bits allow two mutually exclusive server pools to coexist, and 250 for each of them to transition to a new set of parameters. 252 When new configuration is distributed to servers, there will be a 253 transition period when connection IDs reflecting old and new 254 configuration coexist in the network. The rotation bits allow load 255 balancers to apply the correct routing algorithm and parameters to 256 incoming packets. 258 Servers MUST NOT generate new connection IDs using an old 259 configuration when it has sent an Ack payload for a new 260 configuration. 262 Load balancers SHOULD NOT use a codepoint to represent a new 263 configuration until it takes precautions to make sure that all 264 connections using IDs with an old configuration at that codepoint 265 have closed or transitioned. They MAY drop connection IDs with the 266 old configuration after a reasonable interval to accelerate this 267 process. 269 3.2. Configuration Failover 271 If a server has not received a valid QUIC-LB configuration, and 272 believes that low-state, Connection-ID aware load balancers are in 273 the path, it SHOULD generate connection IDs with the config rotation 274 bits set to '11' and SHOULD use the "disable_migration" transport 275 parameter in all new QUIC connections. It SHOULD NOT send 276 NEW_CONNECTION_ID frames with new values. 278 A load balancer that sees a connection ID with config rotation bits 279 set to '11' MUST revert to 5-tuple routing. 281 3.3. Length Self-Description 283 Local hardware cryptographic offload devices may accelerate QUIC 284 servers by receiving keys from the QUIC implementation indexed to the 285 connection ID. However, on physical devices operating multiple QUIC 286 servers, it is impractical to efficiently lookup these keys if the 287 connection ID does not self-encode its own length. 289 Note that this is a function of particular server devices and is 290 irrelevant to load balancers. As such, load balancers MAY omit this 291 from their configuration. However, the remaining 6 bits in the first 292 octet of the Connection ID are reserved to express the length of the 293 following connection ID, not including the first octet. 295 A server not using this functionality SHOULD make the six bits appear 296 to be random. 298 4. Routing Algorithms 300 In QUIC-LB, load balancers do not generate individual connection IDs 301 to servers. Instead, they communicate the parameters of an algorithm 302 to generate routable connection IDs. 304 The algorithms differ in the complexity of configuration at both load 305 balancer and server. Increasing complexity improves obfuscation of 306 the server mapping. 308 As clients sometimes generate the DCIDs in long headers, these might 309 not conform to the expectations of the routing algorithm. These are 310 called "non-compliant DCIDs": 312 o The DCID might not be long enough for the routing algorithm to 313 process. 315 o The extracted server mapping might not correspond to an active 316 server. 318 o A field that should be all zeroes after decryption may not be so. 320 Load balancers MUST forward packets with long headers with non- 321 compliant DCIDs to an active server using an algorithm of its own 322 choosing. It need not coordinate this algorithm with the servers. 323 The algorithm SHOULD be deterministic over short time scales so that 324 related packets go to the same server. For example, a non-compliant 325 DCID might be converted to an integer and divided by the number of 326 servers, with the modulus used to forward the packet. The number of 327 servers is usually consistent on the time scale of a QUIC connection 328 handshake. 330 Load balancers SHOULD drop packets with non-compliant DCIDs in a 331 short header. 333 Load balancers MUST forward packets with compliant DCIDs to a server 334 in accordance with the chosen routing algorithm. 336 The load balancer MUST NOT make the routing behavior dependent on any 337 bits in the first octet of the QUIC packet header, except the first 338 bit, which indicates a long header. All other bits are QUIC version- 339 dependent and intermediaries would cannot build their design on 340 version-specific templates. 342 There are situations where a server pool might be operating two or 343 more routing algorithms or parameter sets simultaneously. The load 344 balancer uses the first two bits of the connection ID to multiplex 345 incoming DCIDs over these schemes. 347 This section describes three participants: the configuration agent, 348 the load balancer, and the server. 350 4.1. Plaintext CID Algorithm 352 The Plaintext CID Algorithm makes no attempt to obscure the mapping 353 of connections to servers, significantly increasing linkability. The 354 format is depicted in the figure below. 356 0 1 2 3 357 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 358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 359 | First octet | Server ID (X=8..152) | 360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 361 | Any (0..152-X) | 362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 364 Figure 1: Plaintext CID Format 366 4.1.1. Configuration Agent Actions 368 The configuration agent selects a number of bytes of the server 369 connection ID (SCID) to encode individual server IDs, called the 370 "routing bytes". The number of bytes MUST have enough entropy to 371 have a different code point for each server. 373 It also assigns a server ID to each server. 375 4.1.2. Load Balancer Actions 377 On each incoming packet, the load balancer extracts consecutive 378 octets, beginning with the second octet. These bytes represent the 379 server ID. 381 4.1.3. Server Actions 383 The server chooses a connection ID length. This MUST be at least one 384 byte longer than the routing bytes. 386 When a server needs a new connection ID, it encodes its assigned 387 server ID in consecutive octets beginning with the second. All other 388 bits in the connection ID, except for the first octet, MAY be set to 389 any other value. These other bits SHOULD appear random to observers. 391 4.2. Obfuscated CID Algorithm 393 The Obfuscated CID Algorithm makes an attempt to obscure the mapping 394 of connections to servers to reduce linkability, while not requiring 395 true encryption and decryption. The format is depicted in the figure 396 below. 398 0 1 2 3 399 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 400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 401 | First octet | Mixed routing and non-routing bits (64..152) | 402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 404 Figure 2: Obfuscated CID Format 406 4.2.1. Configuration Agent Actions 408 The configuration agent selects an arbitrary set of bits of the 409 server connection ID (SCID) that it will use to route to a given 410 server, called the "routing bits". The number of bits MUST have 411 enough entropy to have a different code point for each server, and 412 SHOULD have enough entropy so that there are many codepoints for each 413 server. 415 The configuration agent MUST NOT select a routing mask with more than 416 136 routing bits set to 1, which allows for the first octet and up to 417 2 octets for server purposes in a maximum-length connection ID. 419 The configuration agent selects a divisor that MUST be larger than 420 the number of servers. It SHOULD be large enough to accommodate 421 reasonable increases in the number of servers. The divisor MUST be 422 an odd integer so certain addition operations do not always produce 423 an even number. 425 The configuration agent also assigns each server a "modulus", an 426 integer between 0 and the divisor minus 1. These MUST be unique for 427 each server, and SHOULD be distributed across the entire number space 428 between zero and the divisor. 430 4.2.2. Load Balancer Actions 432 Upon receipt of a QUIC packet, the load balancer extracts the 433 selected bits of the SCID and expresses them as an unsigned integer 434 of that length. The load balancer then divides the result by the 435 chosen divisor. The modulus of this operation maps to the modulus 436 for the destination server. 438 Note that any SCID that contains a server's modulus, plus an 439 arbitrary integer multiple of the divisor, in the routing bits is 440 routable to that server regardless of the contents of the non-routing 441 bits. Outside observers that do not know the divisor or the routing 442 bits will therefore have difficulty identifying that two SCIDs route 443 to the same server. 445 Note also that not all Connection IDs are necessarily routable, as 446 the computed modulus may not match one assigned to any server. These 447 DCIDs are non-compliant as described above. 449 4.2.3. Server Actions 451 The server chooses a connection ID length. This MUST contain all of 452 the routing bits and MUST be at least 9 octets to provide adequate 453 entropy. 455 When a server needs a new connection ID, it adds an arbitrary 456 nonnegative integer multiple of the divisor to its modulus, without 457 exceeding the maximum integer value implied by the number of routing 458 bits. The choice of multiple should appear random within these 459 constraints. 461 The server encodes the result in the routing bits. It MAY put any 462 other value into bits that used neither for routing nor config 463 rotation. These bits SHOULD appear random to observers. 465 4.3. Stream Cipher CID Algorithm 467 The Stream Cipher CID algorithm provides true cryptographic 468 protection, rather than mere obfuscation, at the cost of additional 469 per-packet processing at the load balancer to decrypt every incoming 470 connection ID. The CID format is depicted below. 472 0 1 2 3 473 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 474 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 475 | First Octet | Nonce (X=64..144) | 476 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 477 | Encrypted Server ID (Y=8..152-X) | 478 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 479 | For server use (0..152-X-Y) | 480 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 482 Figure 3: Stream Cipher CID Format 484 4.3.1. Configuration Agent Actions 486 The configuration agent assigns a server ID to every server in its 487 pool, and determines a server ID length (in octets) sufficiently 488 large to encode all server IDs, including potential future servers. 490 The configuration agent also selects a nonce length and an 16-octet 491 AES-ECB key to use for connection ID decryption. The nonce length 492 MUST be at least 8 octets and no more than 16 octets. The nonce 493 length and server ID length MUST sum to 19 or fewer octets. 495 4.3.2. Load Balancer Actions 497 Upon receipt of a QUIC packet that is not of type Initial or 0-RTT, 498 the load balancer extracts as many of the earliest octets from the 499 destination connection ID as necessary to match the nonce length. 500 The server ID immediately follows. 502 The load balancer decrypts the server ID using 128-bit AES Electronic 503 Codebook (ECB) mode, much like QUIC header protection. The nonce 504 octets are zero-padded to 16 octets. AES-ECB encrypts this nonce 505 using its key to generate a mask which it applies to the encrypted 506 server id. 508 server_id = encrypted_server_id ^ AES-ECB(key, padded-nonce) 510 For example, if the nonce length is 10 octets and the server ID 511 length is 2 octets, the connection ID can be as small as 13 octets. 512 The load balancer uses the the second through eleventh of the 513 connection ID for the nonce, zero-pads it to 16 octets using the 514 first 6 octets of the token, and uses this to decrypt the server ID 515 in the twelfth and thirteenth octet. 517 The output of the decryption is the server ID that the load balancer 518 uses for routing. 520 4.3.3. Server Actions 522 When generating a routable connection ID, the server writes arbitrary 523 bits into its nonce octets, and its provided server ID into the 524 server ID octets. Servers MAY opt to have a longer connection ID 525 beyond the nonce and server ID. The nonce and additional bits MAY 526 encode additional information, but SHOULD appear essentially random 527 to observers. 529 The server decrypts the server ID using 128-bit AES Electronic 530 Codebook (ECB) mode, much like QUIC header protection. The nonce 531 octets are zero-padded to 16 octets using the as many of the first 532 octets of the token as necessary. AES-ECB encrypts this nonce using 533 its key to generate a mask which it applies to the server id. 535 encrypted_server_id = server_id ^ AES-ECB(key, padded-nonce) 537 4.4. Block Cipher CID Algorithm 539 The Block Cipher CID Algorithm, by using a full 16 octets of 540 plaintext and a 128-bit cipher, provides higher cryptographic 541 protection and detection of non-compliant connection IDs. However, 542 it also requires connection IDs of at least 17 octets, increasing 543 overhead of client-to-server packets. 545 0 1 2 3 546 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 547 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 548 | First octet | Encrypted server ID (X=8..144) | 549 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 550 | Encrypted Zero Padding (Y=0..144-X) | 551 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 552 | Encrypted bits for server use (144-X-Y) | 553 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 554 | Unencrypted bits for server use (0..24) | 555 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 557 Figure 4: Block Cipher CID Format 559 4.4.1. Configuration Agent Actions 561 The configuration agent assigns a server ID to every server in its 562 pool, and determines a server ID length (in octets) sufficiently 563 large to encode all server IDs, including potential future servers. 565 The server ID will start in the second octet of the decrypted 566 connection ID and occupy continuous octets beyond that. 568 The configuration agent selects a zero-padding length. This SHOULD 569 be at least four octets to allow detection of non-compliant DCIDs. 570 The server ID and zero- padding length MUST sum to no more than 16 571 octets. They SHOULD sum to no more than 12 octets, to provide 572 servers adequate space to encode their own opaque data. 574 The configuration agent also selects an 16-octet AES-ECB key to use 575 for connection ID decryption. 577 4.4.2. Load Balancer Actions 579 Upon receipt of a QUIC packet, the load balancer reads the first 580 octet to obtain the config rotation bits. It then decrypts the 581 subsequent 16 octets using AES-ECB decryption and the chosen key. 583 The decrypted plaintext contains the server id, zero padding, and 584 opaque server data in that order. The load balancer uses the server 585 ID octets for routing. 587 4.4.3. Server Actions 589 When generating a routable connection ID, the server MUST choose a 590 connection ID length between 17 and 20 octets. The server writes its 591 provided server ID into the server ID octets, zeroes into the zero- 592 padding octets, and arbitrary bits into the remaining bits. These 593 arbitrary bits MAY encode additional information. Bits in the first, 594 eighteenth, nineteenth, and twentieth octets SHOULD appear 595 essentially random to observers. The first octet is reserved as 596 described in Section 3. 598 The server then encrypts the second through seventeenth octets using 599 the 128-bit AES-ECB cipher. 601 5. Retry Service 603 When a server is under load, QUICv1 allows it to defer storage of 604 connection state until the client proves it can receive packets at 605 its advertised IP address. Through the use of a Retry packet, a 606 token in subsequent client Initial packets, and the 607 original_connection_id transport parameter, servers verify address 608 ownership and clients verify that there is no "man in the middle" 609 generating Retry packets. 611 As a trusted Retry Service is literally a "man in the middle," the 612 service must communicate the original_connection_id back to the 613 server so that in can pass client verification. It also must either 614 verify the address itself (with the server trusting this 615 verification) or make sure there is common context for the server to 616 verify the address using a service-generated token. 618 There are two different mechanisms to allow offload of DoS mitigation 619 to a trusted network service. One requires no shared state; the 620 server need only be configured to trust a retry service, though this 621 imposes other operational constraints. The other requires shared 622 key, but has no such constraints. 624 Retry services MUST forward all QUIC packets that are not of type 625 Initial or 0-RTT. Other packets types might involve changed IP 626 addresses or connection IDs, so it is not practical for Retry 627 Services to identify such packets as valid or invalid. 629 5.1. Common Requirements 631 Regardless of mechanism, a retry service has an active mode, where it 632 is generating Retry packets, and an inactive mode, where it is not, 633 based on its assessment of server load and the likelihood an attack 634 is underway. The choice of mode MAY be made on a per-packet or per- 635 connection basis, through a stochastic process or based on client 636 address. 638 A retry service MUST forward all packets for a QUIC version it does 639 not understand. Note that if servers support versions the retry 640 service does not, this may increase load on the servers. However, 641 dropping these packets would introduce chokepoints to block 642 deployment of new QUIC versions. Note that future versions of QUIC 643 might not have Retry packets, require different information in Retry, 644 or use different packet type indicators. 646 5.2. No-Shared-State Retry Service 648 The no-shared-state retry service requires no coordination, except 649 that the server must be configured to accept this service and know 650 which QUIC versions the retry service supports. The scheme uses the 651 first bit of the token to distinguish between tokens from Retry 652 packets (codepoint '0') and tokens from NEW_TOKEN frames (codepoint 653 '1'). 655 5.2.1. Configuration Agent Actions 657 The configuration agent distributes a list of QUIC versions to be 658 served by the Retry Service. 660 5.2.2. Service Requirements 662 A no-shared-state retry service MUST be present on all paths from 663 potential clients to the server. These paths MUST fail to pass QUIC 664 traffic should the service fail for any reason. That is, if the 665 service is not operational, the server MUST NOT be exposed to client 666 traffic. Otherwise, servers that have already disabled their Retry 667 capability would be vulnerable to attack. 669 The path between service and server MUST be free of any potential 670 attackers. Note that this and other requirements above severely 671 restrict the operational conditions in which a no-shared-state retry 672 service can safely operate. 674 Retry tokens generated by the service MUST have the format below. 676 0 1 2 3 677 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 678 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 679 |0| ODCIL (7) | Original Destination Connection ID (0..160) | 680 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 681 | Original Destination Connection ID (...) | 682 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 683 ... 684 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 685 | Opaque Data (variable) | 686 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 688 Figure 5: Format of non-shared-state retry service tokens 690 The first bit of retry tokens generated by the service MUST be zero. 691 The token has the following additional fields: 693 ODCIL: The length of the original destination connection ID from the 694 triggering Initial packet. This is in cleartext to be readable for 695 the server, but authenticated later in the token. 697 Original Destination Connection ID: This also in cleartext and 698 authenticated later. 700 Opaque Data: This data MUST contain encrypted information that allows 701 the retry service to validate the client's IP address, in accordance 702 with the QUIC specification. It MUST also encode a secure hash of 703 the original destination connection ID field to verify that this 704 field has not been edited. 706 Upon receipt of an Initial packet with a token that begins with '0', 707 the retry service MUST validate the token in accordance with the QUIC 708 specification. It must also verify that the secure hash of the 709 Connect ID is correct. If incorrect, the token is invalid. 711 In active mode, the service MUST issue Retry packets for all Client 712 initial packets that contain no token, or a token that has the first 713 bit set to '1'. It MUST NOT forward the packet to the server. The 714 service MUST validate all tokens with the first bit set to '0'. If 715 successful, the service MUST forward the packet with the token 716 intact. If unsuccessful, it MUST drop the packet. 718 Note that this scheme has a performance drawback. When the retry 719 service is in active mode, clients with a token from a NEW_TOKEN 720 frame will suffer a 1-RTT penalty even though it has proof of address 721 with its token. 723 In inactive mode, the service MUST forward all packets that have no 724 token or a token with the first bit set to '1'. It MUST validate all 725 tokens with the first bit set to '0'. If successful, the service 726 MUST forward the packet with the token intact. If unsuccessful, it 727 MUST either drop the packet or forward it with the token removed. 728 The latter requires decryption and re-encryption of the entire 729 Initial packet to avoid authentication failure. Forwarding the 730 packet causes the server to respond without the 731 original_connection_id transport parameter, which preserves the 732 normal QUIC signal to the client that there is an unauthorized man in 733 the middle. 735 5.2.3. Server Requirements 737 A server behind a non-shared-state retry service MUST NOT send Retry 738 packets for a QUIC version the retry service understands. It MAY 739 send Retry for QUIC versions the Retry Service does not understand. 741 Tokens sent in NEW_TOKEN frames MUST have the first bit be set to 742 '1'. 744 If a server receives an Initial Packet with the first bit set to '1', 745 it could be from a server-generated NEW_TOKEN frame and should be 746 processed in accordance with the QUIC specification. If a server 747 receives an Initial Packet with the first bit to '0', it is a Retry 748 token and the server MUST NOT attempt to validate it. Instead, it 749 MUST assume the address is validated and MUST extract the Original 750 Destination Connection ID, assuming the format described in 751 Section 5.2.2. 753 5.3. Shared-State Retry Service 755 A shared-state retry service uses a shared key, so that the server 756 can decode the service's retry tokens. It does not require that all 757 traffic pass through the Retry service, so servers MAY send Retry 758 packets in response to Initial packets that don't include a valid 759 token. 761 Both server and service must have access to Universal time, though 762 tight synchronization is not necessary. 764 All tokens, generated by either the server or retry service, MUST use 765 the following format. This format is the cleartext version. On the 766 wire, these fields are encrypted using an AES-ECB cipher and the 767 token key. If the token is not a multiple of 16 octets, the last 768 block is padded with zeroes. 770 0 1 2 3 771 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 772 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 773 | ODCIL | Original Destination Connection ID (0..160) | 774 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 775 | ... | 776 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 777 | | 778 + + 779 | | 780 + Client IP Address (128) + 781 | | 782 + + 783 | | 784 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 785 | | 786 + + 787 | | 788 + + 789 | date-time (160) | 790 + + 791 | | 792 + + 793 | | 794 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 795 | Opaque Data (optional) | 796 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 798 Figure 6: Cleartext format of shared-state retry tokens 800 The tokens have the following fields: 802 ODCIL: The original destination connection ID length. Tokens in 803 NEW_TOKEN frames MUST set this field to zero. 805 Original Destination Connection ID: This is copied from the field in 806 the client Initial packet. 808 Client IP Address: The source IP address from the triggering Initial 809 packet. The client IP address is 16 octets. If an IPv4 address, the 810 last 12 octets are zeroes. 812 date-time: The date-time string is a total of 20 octets and encodes 813 the time the token was generated. The format of date-time is 814 described in Section 5.6 of [RFC3339]. This ASCII field MUST use the 815 "Z" character for time-offset. 817 Opaque Data: The server may use this field to encode additional 818 information, such as congestion window, RTT, or MTU. Opaque data 819 SHOULD also allow servers to distinguish between retry tokens (which 820 trigger use of the original_connection_id transport parameter) and 821 NEW_TOKEN frame tokens. 823 5.3.1. Configuration Agent Actions 825 The configuration agent generates and distributes a "token key." 827 5.3.2. Service Requirements 829 When in active mode, the service MUST generate Retry tokens with the 830 format described above when it receives a client Initial packet with 831 no token. 833 In active mode, the service SHOULD decrypt incoming tokens. The 834 service SHOULD drop packets with an IP address that does not match, 835 and SHOULD forward packets that do, regardless of the other fields. 837 In inactive mode, the service SHOULD forward all packets to the 838 server so that the server can issue an up-to-date token to the 839 client. 841 5.3.3. Server Requirements 843 The server MUST validate all tokens that arrive in Initial packets, 844 as they may have bypassed the Retry service. It SHOULD use the date- 845 time field to apply its expiration limits for tokens. This need not 846 be synchronized with the retry service. However, servers MAY allow 847 retry tokens marked as being a few seconds in the future, due to 848 possible clock synchronization issues. 850 A server MUST NOT send a Retry packet in response to an Initial 851 packet that contains a retry token. 853 6. Configuration Requirements 855 QUIC-LB requires common configuration to synchronize understanding of 856 encodings and guarantee explicit consent of the server. 858 The load balancer and server MUST agree on a routing algorithm and 859 the relevant parameters for that algorithm. 861 For Plaintext CID Routing, this consists of the Server ID and the 862 routing bytes. The Server ID is unique to each server, and the 863 routing bytes are global. 865 For Obfuscated CID Routing, this consists of the Routing Bits, 866 Divisor, and Modulus. The Modulus is unique to each server, but the 867 others MUST be global. 869 For Stream Cipher CID Routing, this consists of the Server ID, Server 870 ID Length, Key, and Nonce Length. The Server ID is unique to each 871 server, but the others MUST be global. The authentication token MUST 872 be distributed out of band for this algorithm to operate. 874 For Block Cipher CID Routing, this consists of the Server ID, Server 875 ID Length, Key, and Zero-Padding Length. The Server ID is unique to 876 each server, but the others MUST be global. 878 A full QUIC-LB configuration MUST also specify the information 879 content of the first CID octet and the presence and mode of any Retry 880 Service. 882 The following pseudocode depicts the data items necessary to store a 883 full QUIC-LB configuration at the server. It is meant to describe 884 the conceptual range and not specify the presentation of such 885 configuration in an internet packet. The comments signify the range 886 of acceptable values where applicable. 888 uint2 config_rotation_bits; 889 boolean first_octet_encodes_cid_length; 890 enum { none, non_shared_state, shared_state } retry_service; 891 select (retry_service) { 892 case none: null; 893 case non_shared_state: uint32 list_of_quic_versions[]; 894 case shared_state: uint8 key[16]; 895 } retry_service_config; 896 enum { none, plaintext, obfuscated, stream_cipher, block_cipher } 897 routing_algorithm; 898 select (routing_algorithm) { 899 case none: null; 900 case plaintext: struct { 901 uint8 server_id_length; /* 1..19 */ 902 uint8 server_id[server_id_length]; 903 } plaintext_config; 904 case obfuscated: struct { 905 uint8 routing_bit_mask[19]; 906 uint16 divisor; /* Must be odd */ 907 uint16 modulus; /* 0..(divisor - 1) */ 908 } obfuscated_config; 909 case stream_cipher: struct { 910 uint8 nonce_length; /* 8..16 */ 911 uint8 server_id_length; /* 1..(19 - nonce_length) */ 912 uint8 server_id[server_id_length]; 913 uint8 key[16]; 914 } stream_cipher_config; 915 case block_cipher: struct { 916 uint8 server_id_length; 917 uint8 zero_padding_length; /* 0..(16 - server_id_length) */ 918 uint8 server_id[server_id_length]; 919 uint8 key[16]; 920 } block_cipher_config; 921 } routing_algorithm_config; 923 7. Additional Use Cases 925 This section discusses considerations for some deployment scenarios 926 not implied by the specification above. 928 7.1. Load balancer chains 930 Some network architectures may have multiple tiers of low-state load 931 balancers, where a first tier of devices makes a routing decision to 932 the next tier, and so on until packets reach the server. Although 933 QUIC-LB is not explicitly designed for this use case, it is possible 934 to support it. 936 If each load balancer is assigned a range of server IDs that is a 937 subset of the range of IDs assigned to devices that are closer to the 938 client, then the first devices to process an incoming packet can 939 extract the server ID and then map it to the correct forwrading 940 address. Note that this solution is extensible to arbitrarily large 941 numbers of load-balancing tiers, as the maximum server ID space is 942 quite large. 944 7.2. Moving connections between servers 946 Some deployments may transparently move a connection from one server 947 to another. The means of transferring connection state between 948 servers is out of scope of this document. 950 To support a handover, a server involved in the transition could 951 issue CIDs that map to the new server via a NEW_CONNECTION_ID frame, 952 and retire CIDs associated with the new server using the "Retire 953 Prior To" field in that frame. 955 Alternately, if the old server is going offline, the load balancer 956 could simply map its server ID to the new server's address. 958 8. Security Considerations 960 QUIC-LB is intended to prevent linkability. Attacks would therefore 961 attempt to subvert this purpose. 963 Note that the Plaintext CID algorithm makes no attempt to obscure the 964 server mapping, and therefore does not address these concerns. It 965 exists to allow consistent CID encoding for compatibility across a 966 network infrastructure. Servers that are running the Plaintext CID 967 algorithm SHOULD only use it to generate new CIDs for the Server 968 Initial Packet and SHOULD NOT send CIDs in QUIC NEW_CONNECTION_ID 969 frames. Doing so might falsely suggest to the client that said CIDs 970 were generated in a secure fashion. 972 A linkability attack would find some means of determining that two 973 connection IDs route to the same server. As described above, there 974 is no scheme that strictly prevents linkability for all traffic 975 patterns, and therefore efforts to frustrate any analysis of server 976 ID encoding have diminishing returns. 978 8.1. Attackers not between the load balancer and server 980 Any attacker might open a connection to the server infrastructure and 981 aggressively retire connection IDs to obtain a large sample of IDs 982 that map to the same server. It could then apply analytical 983 techniques to try to obtain the server encoding. 985 The Encrypted CID algorithm provides robust entropy to making any 986 sort of linkage. The Obfuscated CID obscures the mapping and 987 prevents trivial brute-force attacks to determine the routing 988 parameters, but does not provide robust protection against 989 sophisticated attacks. 991 Were this analysis to obtain the server encoding, then on-path 992 observers might apply this analysis to correlating different client 993 IP addresses. 995 8.2. Attackers between the load balancer and server 997 Attackers in this privileged position are intrinsically able to map 998 two connection IDs to the same server. The QUIC-LB algorithms do 999 prevent the linkage of two connection IDs to the same individual 1000 connection if servers make reasonable selections when generating new 1001 IDs for that connection. 1003 9. IANA Considerations 1005 There are no IANA requirements. 1007 10. References 1009 10.1. Normative References 1011 [QUIC-TRANSPORT] 1012 Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based 1013 Multiplexed and Secure Transport", draft-ietf-quic- 1014 transport (work in progress). 1016 [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: 1017 Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, 1018 . 1020 10.2. Informative References 1022 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1023 Requirement Levels", BCP 14, RFC 2119, 1024 DOI 10.17487/RFC2119, March 1997, 1025 . 1027 Appendix A. Load Balancer Test Vectors 1029 Because any connection ID encoding in this specification includes 1030 many bits for server use without affecting extraction of the 1031 connection ID, there are many possible connection IDs for any given 1032 set of parameters. However, every connection ID should result in a 1033 unique server ID. The following connection IDs can be used to verify 1034 that a load balancer implementation extracts the correct server ID. 1036 A.1. Obfuscated Connection ID Algorithm 1038 The following section lists a set of OCID load balancer 1039 configuration, followed by five CIDs from which the load balancer can 1040 extract the server ID. 1042 cr_bits 0x0 length_self_encoding: y bitmask ddc2f17788d77e3239b4ea 1043 divisor 345 1045 cid 0b72715d4745ce26cca8c750 sid b cid 0b63a1785b6c0b0857225e96 sid 1046 3f cid 0b66474fa11329e6bb947818 sid 147 cid 0b34bd7c0882deb0252e2a58 1047 sid ca cid 0b0506ee792163bf9330dc0a sid 14d 1049 cr_bits 0x1 length_self_encoding: n bitmask 1050 4855d35f5b88ddada153af61b6707ee646 divisor 301 1052 cid 542dc4c09e2d548e508dc825bbbca991c131 sid 8 cid 1053 47988071f9f03a25c322cc6fb1d57151d26f sid 93 cid 1054 6a13e05071f74cdb7d0dc24d72687b21e1d1 sid c0 cid 1055 4323c129650c7ee66f37266044ef52e74ffa sid 60 cid 1056 5e95f77e7e66891b57c224c5781c8c5dd8ba sid 8f 1058 cr_bits 0x0 length_self_encoding: y bitmask 9f98bd3df66338c2d2c6 1059 divisor 459 1061 cid 0ad52216e7798c28340fd6 sid 125 cid 0a78f8ecbd087083639f94 sid 4b 1062 cid 0ac7e70a5fe6b353b824aa sid 12 cid 0af9612ae5ccba3ef98b81 sid d1 1063 cid 0a94ab209ea1d2e1e23751 sid 5d 1065 cr_bits 0x2 length_self_encoding: n bitmask dfba93c4f98f57103f5ae331 1066 divisor 461 1068 cid 8b70b8c69e40ef2f3f8937e817 sid d3 cid b1828830ea1789dab13a043795 1069 sid 44 cid 90604a580baa3eb0a47812e490 sid 137 cid 1070 a5b4bc309337ff73e143ff6deb sid 9f cid fce75c0a984a79d3b4af40d155 sid 1071 127 1073 cr_bits 0x0 length_self_encoding: y bitmask 8320fefc5309f7aa670476 1074 divisor 379 1076 cid 0bb110af53dca7295e7d4b7e sid 101 cid 0b0d284cdff364a634a4b93b sid 1077 e3 cid 0b82ff1555c4a95f9b198090 sid 14e cid 0b7a427d3e508ad71e98b797 1078 sid 14e cid 0b71d1d4e3e3cd54d435b3fd sid eb 1080 A.2. Stream Cipher Connection ID Algorithm 1082 Like the previous section, the text below lists a set of load 1083 balancer configuration and 5 CIDs generated with that configuration. 1085 cr_bits 0x0 length_self_encoding: y nonce_len 13 sid_len 1 key 1086 16eff325e8bf8dfebdae003543fb845f 1088 cid 0eb9eb1fc72eed820cf5658cdd7888 sid 9c cid 1089 0e6f4de5beb5aa4170f44104318c5b sid c0 cid 1090 0e78f0325a8e34a40661f51f235906 sid 1d cid 1091 0ef37923f81c32632299bceabd1d92 sid fa cid 1092 0ea30788c012daa94a83865a2c7f28 sid b3 1094 cr_bits 0x1 length_self_encoding: n nonce_len 9 sid_len 2 key 1095 906220f402ba3bd893ccc4dd9cfc04b0 1097 cid 7b33366764888138f1465352 sid b839 cid 4329458bbe6cb9befc04bdeb 1098 sid 3b27 cid 61e4e8235c4ebd5442d85bb0 sid bb5c cid 1099 4fd790d1d0cf2b50796cad12 sid 4ecd cid 725325eceaca3528d8c0314b sid 1100 54fd 1102 cr_bits 0x0 length_self_encoding: y nonce_len 8 sid_len 3 key 1103 0a9b8ccdee977a65e3519693fcd55c8c 1105 cid 0bfced0b5727be40af49102e sid 08d342 cid 0b160042b34fe728a9f05376 1106 sid 4d61e0 cid 0b933157fc8c352ee9490ae7 sid 34a912 cid 1107 0b80d1d567aafedb737ed0eb sid 4f2a92 cid 0b3133feac7ae7125b1d0702 sid 1108 1a5db3 1110 cr_bits 0x0 length_self_encoding: n nonce_len 8 sid_len 4 key 1111 66c5acdb45a40c91da8cfbbdc77c157e 1113 cid 2da078bbf87c71264879c58a5a sid 20f1e37e cid 1114 04577ce3800cf22ead7f9ba9a5 sid 29e462c4 cid 1115 1a0f6592fcd9167d0aa201e228 sid a0b0fb8a cid 1116 11e4df0eb7db00363b1721e4a4 sid 31f15006 cid 1117 3d54b24c7bd39f081f00f44295 sid 551b8c28 1119 cr_bits 0x0 length_self_encoding: y nonce_len 12 sid_len 5 key 1120 ba4909a865c19d0234e090197d61bab9 1122 cid 11325919a7205f4f5e222c2ac94ec3309c1e sid 10f115363a cid 1123 11ca85a9e5d02563ebb119acfacb3007993d sid 4108093aaf cid 1124 1196ef4f0936cb6062b5db441395ef9f3831 sid 383c14e754 cid 1125 11ce3a6611da0e75f59dc8fe3cf4cfc6a61d sid d0da150dbf cid 1126 116bd4cf085659d26b39dd5dd107ae87a694 sid b2945466df 1128 A.3. Block Cipher Connection ID Algorithm 1130 Like the previous section, the text below lists a set of load 1131 balancer configuration and 5 CIDs generated with that configuration. 1133 cr_bits 0x0 length_self_encoding: y sid_len 1 zp_len 11 key 1134 8c24cb9b9c3289b4ee63c3f3d7f93a9a 1136 cid: 1378e44f874642624fa69e7b4aec15a2a678b8b5 sid: 48 cid: 1137 13772c82fe8ce6a00813f76a211b730eb4b20363 sid: 66 cid: 1138 135ccf507b1c209457f80df0217b9a1df439c4b2 sid: 30 cid: 1139 13898459900426c073c66b1001c867f9098a7aab sid: fe cid: 1140 1397a18da00bf912f20049d9f0a007444f8b6699 sid: 30 1142 cr_bits 0x0 length_self_encoding: n sid_len 2 zp_len 10 key 1143 cc7ec42794664a8428250c12a7fb16fa 1145 cid: 0cb28bfc1f65c3de14752bc0fc734ef824ce8f78 sid: 33fa cid: 1146 2345e9fc7a7be55b4ba1ff6ffa04f3f5f8c67009 sid: ee47 cid: 1147 0d32102be441600f608c95841fd40ce978aa7a02 sid: 0c8b cid: 1148 2e6bfc53c91c275019cd809200fa8e23836565ab sid: feca cid: 1149 29b87a902ed129c26f7e4e918a68703dc71a6e0a sid: 8941 1151 cr_bits 0x1 length_self_encoding: y sid_len 3 zp_len 9 key 1152 42e657946b96b7052ab8e6eeb863ee24 1154 cid: 53c48f7884d73fd9016f63e50453bfd9bcfc637d sid: b46b68 cid: 1155 53f45532f6a4f0e1757fa15c35f9a2ab0fcce621 sid: 2147b4 cid: 1156 5361fd4bbcee881a637210f4fffc02134772cc76 sid: e4bf4b cid: 1157 53881ffde14e613ef151e50ba875769d6392809b sid: c2afee cid: 1158 53ad0d60204d88343492334e6c4c4be88d4a3add sid: ae0331 1160 cr_bits 0x0 length_self_encoding: n sid_len 4 zp_len 8 key 1161 ee2dc6a3359a94b0043ca0c82715ce71 1163 cid: 058b9da37f436868cca3cef40c7f98001797c611 sid: eaf846c7 cid: 1164 1259fc97439adaf87f61250afea059e5ddf66e44 sid: 4cc5e84a cid: 1165 202f424376f234d5f014f41cebc38de2619c6c71 sid: f94ff800 cid: 1166 146ac3e4bbb750d3bfb617ef4b0cb51a1cae5868 sid: c2071b1b cid: 1167 36dfe886538af7eb16a196935b3705c9d741479f sid: 26359dbb 1169 cr_bits 0x2 length_self_encoding: y sid_len 5 zp_len 7 key 1170 700837da8834840afe7720186ec610c9 1172 cid: 931ef3cc07e2eaf08d4c1902cd564d907cc3377c sid: 759b1d419a cid: 1173 9398c3d0203ab15f1dfeb5aa8f81e52888c32008 sid: 77cc0d3310 cid: 1174 93f4ba09ab08a9ef997db4fa37a97dbf2b4c5481 sid: f7db9dce32 cid: 1176 93744f4bedf95e04dd6607592ecf775825403093 sid: e264d714d2 cid: 1177 93256308e3d349f8839dec840b0a90c7e7a1fc20 sid: 618b07791f 1179 Appendix B. Acknowledgments 1181 Appendix C. Change Log 1183 *RFC Editor's Note:* Please remove this section prior to 1184 publication of a final version of this document. 1186 C.1. since-draft-ietf-quic-load-balancers-01 1188 o Test vectors for load balancer decoding 1190 o Deleted remnants of in-band protocol 1192 o Light edit of Retry Services section 1194 o Discussed load balancer chains 1196 C.2. since-draft-ietf-quic-load-balancers-00 1198 o Removed in-band protocol from the document 1200 C.3. Since draft-duke-quic-load-balancers-06 1202 o Switch to IETF WG draft. 1204 C.4. Since draft-duke-quic-load-balancers-05 1206 o Editorial changes 1208 o Made load balancer behavior independent of QUIC version 1210 o Got rid of token in stream cipher encoding, because server might 1211 not have it 1213 o Defined "non-compliant DCID" and specified rules for handling 1214 them. 1216 o Added psuedocode for config schema 1218 C.5. Since draft-duke-quic-load-balancers-04 1220 o Added standard for retry services 1222 C.6. Since draft-duke-quic-load-balancers-03 1224 o Renamed Plaintext CID algorithm as Obfuscated CID 1226 o Added new Plaintext CID algorithm 1228 o Updated to allow 20B CIDs 1230 o Added self-encoding of CID length 1232 C.7. Since draft-duke-quic-load-balancers-02 1234 o Added Config Rotation 1236 o Added failover mode 1238 o Tweaks to existing CID algorithms 1240 o Added Block Cipher CID algorithm 1242 o Reformatted QUIC-LB packets 1244 C.8. Since draft-duke-quic-load-balancers-01 1246 o Complete rewrite 1248 o Supports multiple security levels 1250 o Lightweight messages 1252 C.9. Since draft-duke-quic-load-balancers-00 1254 o Converted to markdown 1256 o Added variable length connection IDs 1258 Authors' Addresses 1260 Martin Duke 1261 F5 Networks, Inc. 1263 Email: martin.h.duke@gmail.com 1265 Nick Banks 1266 Microsoft 1268 Email: nibanks@microsoft.com