idnits 2.17.1 draft-duke-quic-load-balancers-00.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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 13 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 12, 2018) is 2264 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) == Missing Reference: 'RFC2119' is mentioned on line 127, but not defined == Missing Reference: 'ID-ietf-quic-transport' is mentioned on line 254, but not defined == Unused Reference: 'I-D.ietf-quic-transport' is defined on line 359, but no explicit reference was found in the text == Outdated reference: A later version (-34) exists of draft-ietf-quic-transport-09 == Outdated reference: A later version (-43) exists of draft-ietf-tls-dtls13-01 ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) Summary: 2 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 QUIC WG M. Duke 2 Internet Draft F5 Networks 3 Intended status: Standards Track February 12, 2018 4 Expires: August 12, 2018 6 QUIC-LB: Using Load Balancers to Generate QUIC Connection IDs 7 draft-duke-quic-load-balancers-00.txt 9 Status of this Memo 11 This Internet-Draft is submitted in full conformance with the 12 provisions of BCP 78 and BCP 79. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six 20 months and may be updated, replaced, or obsoleted by other documents 21 at any time. It is inappropriate to use Internet-Drafts as 22 reference material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html 30 This Internet-Draft will expire on August 12, 2018. 32 Copyright Notice 34 Copyright (c) 2018 IETF Trust and the persons identified as the 35 document authors. All rights reserved. 37 This document is subject to BCP 78 and the IETF Trust's Legal 38 Provisions Relating to IETF Documents 39 (http://trustee.ietf.org/license-info) in effect on the date of 40 publication of this document. Please review these documents 41 carefully, as they describe your rights and restrictions with 42 respect to this document. Code Components extracted from this 43 document must include Simplified BSD License text as described in 44 Section 4.e of the Trust Legal Provisions and are provided without 45 warranty as described in the Simplified BSD License. 47 Abstract 49 QUIC connection IDs allow continuation of connections across 50 address/port 5-tuple changes, and can store routing information for 51 stateless or low-state layer 4 load balancers. They are also meant 52 to prevent linkability of connections across deliberate address 53 migration through the use of protected communications between client 54 and server. This creates issues for load-balancing intermediaries. 55 This specification standardizes the communication between load 56 balancers and servers to overcome these issues in a protocol called 57 QUIC-LB. 59 Table of Contents 61 1. Introduction...................................................3 62 1.1. Terminology...............................................3 63 2. Protocol Objectives............................................4 64 2.1. Simplicity................................................4 65 2.2. Security..................................................4 66 2.3. Robustness to Middleboxes.................................4 67 3. Protocol Design................................................4 68 3.1. Connection ID Generation..................................4 69 3.2. Message Exchange..........................................5 70 3.3. Load Balancer Trust.......................................6 71 3.4. Servers with Zero Stock...................................6 72 4. Message Format.................................................6 73 4.1. NEW_IDS message...........................................6 74 4.2. ID_STOCK message..........................................7 75 5. Chained Load Balancers.........................................8 76 6. Security Considerations........................................8 77 7. IANA Considerations............................................8 78 8. References.....................................................9 79 8.1. Normative References......................................9 80 8.2. Informative References....................................9 81 9. Acknowledgments................................................9 82 Appendix A. Alternate Approaches to server/load balancer 83 coordination problems............................................10 84 A.1. Terminating proxies......................................10 85 A.2. Unified control of load balancer and server..............10 86 A.3. Synchronized Algorithms..................................10 88 1. Introduction 90 Server-generated connection IDs create a potential need for out-of- 91 band communication. QUIC packets usually contain a connection ID to 92 allow endpoints to associate packets with different 93 address/port/protocol 5-tuples to the same connection context. This 94 feature makes connections robust in the event of NAT rebinding. 96 QUIC allows servers (or load balancers) to designate an initial 97 connection ID to encode useful routing information for load 98 balancers. It also encourages servers, in packets protected by 99 cryptography, to provide additional connection IDs to the client. 100 This allows clients that know they are going to change IP address or 101 port to use a separate connection ID on the new path, thus reducing 102 linkability as clients move through the world. 104 There is a tension between the requirements to provide routing 105 information and mitigate linkability. Ultimately, because new 106 connection IDs are in protected packets, they must be generated at 107 the server if the load balancer does not have access to the 108 connection keys. However, it is the load balancer that has the 109 context necessary to generate a connection ID that encodes useful 110 routing information. In the absence of any shared state between load 111 balancer and server, the load balancer must maintain a relatively 112 expensive table of server-generated connection IDs, and will not 113 route packets correctly if they use a connection ID that was 114 originally communicated in a protected NEW_CONNECTION_ID frame. 116 This specification provides a method of coordination between QUIC 117 servers and layer 4 load balancers to support connection IDs that 118 encode routing information. It describes desirable properties of a 119 solution, and then specifies a protocol that provides those 120 properties. 122 1.1. Terminology 124 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 125 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 126 document are to be interpreted as described in RFC 2119 [RFC2119]. 128 In this document, these words will appear with that interpretation 129 only when in ALL CAPS. Lower case uses of these words are not to be 130 interpreted as carrying significance described in RFC 2119. 132 In this document, "client" and "server" refer to the endpoints of a 133 QUIC connection unless otherwise indicated. A "load balancer" is an 134 intermediary for that connection that does not possess QUIC 135 connection keys, but it may rewrite IP addresses or conduct other IP 136 or UDP processing. In most respects, the load balancer behaves as a 137 client in a QUIC-LB connection, but is always referred to as a "load 138 balancer" below to avoid confusion. 140 2. Protocol Objectives 142 2.1. Simplicity 144 QUIC is intended to provide unlinkability across connection 145 migration, but servers are under no obligation to provide connection 146 IDs to enable this. If the coordination scheme is too difficult to 147 implement, servers behind load balancers using connection IDs for 148 routing will use trivially linkable connection IDs. Clients will 149 therefore be forced choose between terminating the connection during 150 migration or remaining linkable. 152 The solution should be both simple to implement and require little 153 additional infrastructure for cryptographic keys, etc. 155 2.2. Security 157 The path between load balancer and server may not be free of 158 observers from which the client wishes to avoid linkability. 159 Similarly, malicious hosts could spoof a trusted load balancer to 160 provide connection IDs that are linkable. Therefore, coordination 161 messages must be encrypted, and there must be some way for servers 162 to authenticate the load balancer's messages. 164 2.3. Robustness to Middleboxes 166 The path between load balancer and server may transit multiple 167 domains. It is therefore advantageous to make messages resemble QUIC 168 traffic as much as possible, as any viable path must obviously admit 169 QUIC traffic. 171 3. Protocol Design 173 3.1. Connection ID Generation 175 Load balancers MAY use connection IDs to encode routing information 176 to the destination server. This encoding MAY be opaque to the 177 destination server and SHOULD be opaque to all other hosts. 179 The encoding scheme MUST be able to generate enough connection IDs 180 for each server to have at least two for every QUIC connection 181 concurrently assigned to it. 183 The encoding SHOULD maximize the cryptographic distance between 184 connection IDs intended for the same server. 186 The encoding SHOULD NOT vary with the number of active servers, as 187 the connection ID remains routable even if other servers boot up or 188 suffer an outage. 190 A representative encoding that meets these requirements might 191 concatenate the server's IPv4 address and a monotonically increasing 192 sequence number, and then encrypt the result to obtain the 193 connection ID. For any incoming QUIC packet, the load balancer would 194 decrypt the connection ID to extract the server IP address. There 195 would be different routing rules for (readily identifiable) Initial 196 packets that contain an (essentially random) client-generated 197 connection ID. 199 3.2. Message Exchange 201 No message in this protocol is sent with reliability assurances. For 202 all messages the load balancer uses an ephemeral UDP port, and the 203 server uses UDP port 443. All messages are sent as encrypted records 204 in an established DTLS connection. 206 The best practice for servers is to always provide at least one 207 connection ID to clients beyond the one it is currently using. Load 208 balancers SHOULD monitor the usage of these connection IDs and the 209 number of active connections for each server. A "used" connection ID 210 is one that has been used in the Connection ID field of a QUIC 211 header, as opposed to the QUIC NEW_CONNECTION_ID frame. When the 212 stock of unused connection IDs is low, load balancers SHOULD send a 213 NEW_IDS message to that server. 215 Servers SHOULD periodically send a ID_STOCK message to the load 216 balancer to synchronize the load balancer's view of its current 217 unused connection IDs. This allows the shared state to recover from 218 lost NEW_CONN_ID messages. 220 Servers MAY increase the rate at which they send ID_STOCK messages 221 as their stocks shrink, relative to the usage rate of connection 222 IDs, to accelerate delivery of new IDs and overcome packet losses. 224 Note that the Connection IDs provided by the load balancer can be 225 used by any connection terminated at the server. There is no need 226 for the load balancer to designate specific QUIC connections for 227 each ID. As a result, load balancers cannot necessarily associate 228 packets before and after an IP address migration to the same 229 connection. 231 3.3. Load Balancer Trust 233 Message authentication and encryption is achieved using DTLS 1.2 or 234 1.3 ([RFC6347] or [I-D.ietf-tls-dtls13]). Load balancers MUST 235 initiate the handshake as the client, as some firewalls may block 236 outbound connections from the server. Servers MUST request a Client 237 Certificate to verify that the Load Balancer meets the trust 238 requirements to potentially introduce linkable Connection IDs into 239 the system. 241 Servers MUST NOT accept DTLS connections from load balancers for 242 which they do not have configured trust relationships. 244 3.4. Servers with Zero Stock 246 If the server has an active DTLS connection with a lower balancer, 247 but has zero stock, the server SHOULD use the connection ID provided 248 in the Initial packet and SHOULD NOT generate QUIC NEW_CONNECTION_ID 249 frames. Therefore, clients that knowingly change IP address or port 250 are forced to choose between terminating the connection and 251 traceably changing IP address. 253 Servers with no such trust relationship MUST behave in accordance 254 with the QUIC transport spec [ID-ietf-quic-transport], generating 255 new connection IDs at will. 257 4. Message Format 259 All messages below are encapsulated in DTLS Records. 261 The type field is not strictly necessary to resolve ambiguity, as 262 each message type is only sent by one entity in the connection. 263 However, the type byte allows future extension of the protocol. 265 4.1. NEW_IDS message 267 Load Balancers MUST ignore NEW_IDS messages. 269 0 1 2 3 270 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 271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 | Type = 0x01 | 273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 274 | | 275 + Connection ID 1 + 276 | | 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 278 | | 279 + Connection ID 2 + 280 | | 281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 282 ... 283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 284 | | 285 + Connection ID n + 286 | | 287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 288 Figure 1 NEW_IDS Message 290 Other data MUST NOT be in the DTLS Record, so the number of 291 Connection IDs present in the packet is determined by the Record 292 length. Note that connection IDs are strings, not integers that are 293 expressed in host or network order. 295 4.2. ID_STOCK message 297 Servers MUST ignore received ID_STOCK messages. 299 0 1 2 3 300 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 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 | Type = 0x02 | 303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 304 | Unused Connection IDs | 305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 306 Figure 2 ID_STOCK Message 308 This message simply reports the number of unused connection IDs in a 309 32-bit integer in Network order. Load Balancers MUST update their 310 estimate of server stock based on this message, as some connection 311 IDs may have been lost in transit. 313 5. Chained Load Balancers 315 In some deployments, there may be multiple tiers of trusted load 316 balancers in the path between client and server. All load balancers 317 using connection ID to encode routing information MUST agree on how 318 to decode connection IDs as routing instructions. Due to QUIC packet 319 authentication, connection IDs of established QUIC connections 320 cannot be rewritten in flight without access to the QUIC connection 321 keys. 323 A server configured to trust multiple load balancers MAY accept DTLS 324 connections from all of them and use provided Connection IDs 325 interchangeably. It SHOULD report its entire stock of connection IDs 326 to all trusted load balancers, rather than the number of IDs issued 327 from each source. 329 6. Security Considerations 331 QUIC-LB is intended to preserve routability and prevent linkability, 332 so attacks on the protocol would compromise at least one of these 333 objectives. 335 Injection of connection IDs could either break routability (by 336 diverting flows to a server with no QUIC connection context) or 337 allow linkability (by allowing observers to determine that two 338 connection IDs originate from the same server, and that one begins 339 at roughly the same time that the other disappears). Use of DTLS 340 authentication mechanisms, at both load balancer and server, are 341 meant to mitigate this risk. 343 Cleartext connection IDs would also allow observers to map 344 connection IDs to a specific server, potentially allowing 345 linkability. QUIC-LB utilizes DTLS-based encryption to avoid this. 347 QUIC-LB depends on DTLS, and therefore on Public Key Infrastructure. 348 Any compromise of the PKI would allow untrusted middleboxes to 349 successfully execute either of the attacks above. 351 7. IANA Considerations 353 There are no IANA requirements. 355 8. References 357 8.1. Normative References 359 [I-D.ietf-quic-transport] Iyengar, J. and M. Thomson, "QUIC: A UDP- 360 Based Multiplexed and Secure Transport", draft-ietf-quic- 361 transport-09 (work in progress), January 2018. 363 [I-D.ietf-tls-dtls13] Rescorla, E., Tschofenig, H., Modadugu, M, 364 "The Datagram Transport Layer Security (DTLS) Protocol 365 Version 1.3", draft-ietf-tls-dtls13-01 (work in progress), 366 July 2017. 368 [RFC6347] Rescorla, E., " Datagram Transport Layer Security Version 369 1.2", RFC 6347, January 2012. 371 8.2. Informative References 373 None. 375 9. Acknowledgments 377 This document was prepared using 2-Word-v2.0.template.dot. 379 Appendix A. Alternate Approaches to server/load balancer coordination 380 problems. 382 A.1. Terminating proxies 384 A load balancer that terminates the QUIC connection at the 385 application layer, with separate connections to client and server, 386 can generate new connection IDs on its own and has enough state to 387 not require connection ID to route packets. However, this approach 388 cannot work if the load balancer is not a trusted intermediary with 389 the TLS certificates required to terminate a QUIC connection. 390 Moreover, the load balancer may not have sufficient resources to 391 keep the state for every connection that traverses it. 393 A.2. Unified control of load balancer and server 395 Obviously, a vendor or network operator with access to the source 396 code of both the load balancer and the server can develop a 397 proprietary method to share the necessary state. This is difficult 398 to implement for network operators that purchase their servers and 399 load balancers from different vendors. 401 A.3. Synchronized Algorithms 403 If server understands how the load balancer encodes routing 404 information via a standard algorithm, it can generate new connection 405 IDs that preserve routability. However, if the algorithm is not 406 cryptographically secure this erodes protection against linkability. 407 Ultimately, this approach requires a key rotation scheme to remain 408 secure. 410 Authors' Addresses 412 Martin Duke 413 F5 Networks 414 401 Elliott Ave W. 415 Seattle, WA, USA 98119 417 Email: m.duke@f5.com