idnits 2.17.1 draft-tarreau-extend-flow-label-balancing-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (December 5, 2012) is 4157 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 6434 (Obsoleted by RFC 8504) == Outdated reference: A later version (-02) exists of draft-carpenter-flow-label-balancing-01 -- Obsolete informational reference (is this intentional?): RFC 2629 (Obsoleted by RFC 7749) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group B. Carpenter 3 Internet-Draft Univ. of Auckland 4 Intended status: Informational S. Jiang 5 Expires: June 8, 2013 Huawei Technologies Co., Ltd 6 W. Tarreau 7 Exceliance 8 December 5, 2012 10 Extending Use of the IPv6 Flow Label for Load Balancing Persistence 11 draft-tarreau-extend-flow-label-balancing-01 13 Abstract 15 This document describes how the IPv6 flow label could be used in an 16 extended role to simplify persistence mechanisms for load 17 distribution and balancing for large server farms. 19 Status of this Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on June 8, 2013. 36 Copyright Notice 38 Copyright (c) 2012 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Server Load Balancing and the Persistence Problem . . . . . . . 3 55 3. Extended Role of Flow Label . . . . . . . . . . . . . . . . . . 4 56 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 57 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 58 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 59 7. Change log [RFC Editor: Please remove] . . . . . . . . . . . . 7 60 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 61 8.1. Normative References . . . . . . . . . . . . . . . . . . . 7 62 8.2. Informative References . . . . . . . . . . . . . . . . . . 8 63 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 65 1. Introduction 67 The IPv6 flow label has been redefined [RFC6437] and is now a 68 recommended IPv6 node requirement [RFC6434]. Its use for layer 3/4 69 server load balancing is described in 70 [I-D.carpenter-flow-label-balancing], and the reader is assumed to be 71 familiar with that document. In server load balancing, 'persistence' 72 is defined as guaranteeing that a given session will run to 73 completion on a single server. The present document describes 74 extensions to the role of the flow label to simplify and enhance 75 persistence mechanisms. 77 Note in draft: The authors recognize that this proposal is 78 incomplete, that it needs considerable thought and discussion, and 79 that other approaches might be possible. However, current approaches 80 to persistence in server load balancing are complicated and 81 pragmatic, and this new approach, even though it requires changes to 82 client applications and proxies as well as to load balancers 83 themselves, seems worth discussion. 85 2. Server Load Balancing and the Persistence Problem 87 The IPv6 flow label is a 20 bit field included in every IPv6 header 88 [RFC2460]. It is recommended to be supported in all IPv6 nodes by 89 [RFC6434] and it is defined in [RFC6437]. In 90 [I-D.carpenter-flow-label-balancing], it is explained how the flow 91 label value, set at or near the client of a server farm, may be used 92 by a layer 3/4 load balancer as part of a 2-tuple {source address, 93 flow label} to efficiently identify packets belonging to a given 94 client's application data flow and to direct them to a specific 95 server. 97 A layer 3/4 load balancer has to recognize incoming packets as 98 belonging to new or existing client sessions, and choose a target 99 server or proxy so as to ensure persistence. In a simple scenario, 100 the 2-tuple {source address, flow label} will be a sufficient label 101 for a user data flow to guarantee persistence. However, there are 102 various cases where this does not apply. Sometimes, multiple 103 independent transport connections from the same client need to be 104 handled by the same server instance. This can be an extremely 105 difficult task which often requires ugly tricks such as pattern 106 matching within a buffered stream, cookie insertion, etc, which most 107 current load balancers have to deal with every day. 109 A common example is FTP. For a load balancer, passive mode FTP 110 requires parsing the entire control stream on port 21, in order to 111 find which incoming packet will initiate a data session on a port 112 chosen by the server. This expensive process is not always useful, 113 due to the fact that sometimes clients fail to connect, or that the 114 session is finally not used, e.g., because no transfer needs to be 115 performed. 117 The same issue is even more prominent with HTTP/HTTPS. While it is 118 costly but straightforward to insert a cookie in an HTTP stream to 119 identify the server to which the user was assigned, it is very 120 difficult to do that for HTTPS, because the stream must be deciphered 121 first. Deciphering the stream requires a huge amount of centralized 122 power, since the load balancer needs to see the clear stream; this is 123 in fact the main reason for having specialised SSL proxies in load 124 balancing scenarios. 126 An additional complication that arises frequently is when a single 127 client inadvertently generates sessions that appear to originate from 128 different IP addresses. This can arise, for example, if an 129 enterprise uses a proxy farm for outgoing traffic, or in mobile 130 applications where several subsequent requests come from different 131 network cells and thus different IP addresses (for instance, 132 consulting a bank account in the train). When two consecutive client 133 requests pass through two distinct proxies, a different IP source 134 address may be presented to the server load balancer, which then 135 cannot rely on address-based persistence. 137 In some application scenarios, such an inadvertent change in the 138 client IP address may only have consequences for performance, such as 139 reloading transaction context into a new server. In other cases it 140 may be more serious and result in a transaction failure that seems 141 inexplicable to the user. A reliable and efficient solution to this 142 problem is therefore needed. 144 3. Extended Role of Flow Label 146 We propose a new model in which the client application has control 147 over the outgoing flow label, and assigns the same label to all 148 transport connections related to a single application session. It 149 would then be both possible and desirable to use the same flow label 150 value for multiple correlated transport sessions from the same 151 client. For this to work, it is also necessary for any proxies to be 152 transparent to the flow label value. Thus, modifications to the 153 network stack and the application layer code are needed in both hosts 154 and proxies. In particular, the network API needs to provide a 155 method for the application layer to set the flow label value for each 156 new outgoing transport session, and to read it for each new incoming 157 transport session. The former is needed for client applications, and 158 both features are needed for HTTP proxies in particular. 160 Such a mechanism is not the recommended default host behaviour, but 161 it is permitted by [RFC6437], which states that "a flow is not 162 necessarily 1:1 mapped to a transport connection". The assignment of 163 flow labels in this case is clearly no longer stateless, but the 164 requirement that they be drawn from a uniform distribution should be 165 retained. 167 In the case of FTP Passive mode, using a flow label, the client could 168 generate an initial flow label value when a file transfer is 169 expected, and assign the same flow label to all data connections 170 related to the same control connection. A flow label based load 171 balancer would then by definition send the data traffic to the same 172 server as the control traffic, and would thus guarantee that the 173 sessions are properly associated. 175 For a multiprotocol transaction, if a web client (browser) used the 176 same flow label for any protocol targetting a given host (or domain), 177 this could be used by load balancers to reach the same server for 178 several protocols (such as HTTP and HTTPS), without having to inspect 179 the stream payload at all nor to inspect anything beyond layer 3, 180 which is unavoidable today. 182 In the case of an inadvertent change in the client IP address, most 183 likely due to an intervening proxy, the use of the same flow label 184 for an entire application session would allow a load balancer to 185 reliably route all packets for the session to the same server without 186 any additional packet inspection or cookie insertion. This would 187 improve both efficiency and reliability for all parties concerned. 189 This proposal means that the layer 3/4 load balancer identifies a 190 session by using the flow label value alone, rather than the 2-tuple 191 {source address, flow label} as described in 192 [I-D.carpenter-flow-label-balancing]. However, it is of minor 193 importance if two independent client sessions are directed to the 194 same server because they happen to have the same flow label. They 195 will in any case be treated separately by the server, and 196 statistically there will be a negligible effect on load balancing, 197 since there are a million different possible flow labels to spread 198 traffic across the server farm. 200 Using the flow label in this way would also greatly simplify the 201 logging of user sessions. A very common task is to match logs from 202 various equipments to follow a user's activity and decide whether it 203 indicates a bug, user error or attack. Logging a flow label would of 204 course help because it's easier to find the beginning and end of a 205 session and decide whether it's legitimate or not. In the case of 206 two simultaneous application sessions using the same flow label value 207 by chance, the two logs would be intermingled, so the analysis would 208 be more complex, but still quite feasible. 210 Such extensions to the role of the flow label in load balancing are 211 theoretically very attractive, but would require a major refresh of 212 client and proxy software as well as of load balancers themselves. 213 It amounts to considering an entire application session, in a broad 214 sense, as a single flow for the purposes of RFC 6437. 216 It is worth noting that what is important to save server-side 217 resources is wide enough adoption. Most of today's load balanced 218 traffic is HTTP originating from a handful of browsers which are 219 regularly upgraded for security reasons. Thus, once a mechanism is 220 adopted, it can quickly be deployed across popular browsers, and soon 221 become the general case. 223 The difficulty of the upgrade path is then on the server side. The 224 first step would consist in having layer 7 load balancers be able to 225 consider the flow label, to avoid costly layer 7 analysis, each time 226 it is possible. This means that if a non-null flow label is seen, 227 then the load balancer would consider it, otherwise it would fall 228 back to its default behaviour. The second step would consist in 229 having front layer 3/4 load balancers bypass the layer 7 load 230 balancer farms when the flow label is found. This point would 231 greatly offload layer 7 load balancers. 233 Finally we observe that both clients and server farms would benefit 234 from this approach, in terms of performance and reliability. Thus, 235 although both parties (and proxy operators) would need to upgrade 236 software, it is in their own interest to do so. 238 4. Security Considerations 240 The security considerations of [RFC6437] and 241 [I-D.carpenter-flow-label-balancing] apply. 243 Using the flow label on its own as a session handle has limitations. 244 It has no security properties and must not be used in any way as an 245 identifier or authenticator; it does not have enough bits to be used 246 as a nonce. Its value should never be used in the application layer 247 nor where any form of resource sharing is not desired. For instance, 248 it is not acceptable that an application would identify a user 249 session by its flow label value, due to the inevitable collisions and 250 the risk of forgery. The flow label value on its own should only be 251 used where resource sharing is intended (for instance, load 252 balancing) and by components explicitly designed for this task, 253 taking into account all the risks exposed in the above security 254 references, with solid protection against mis-use, and acceptable 255 fallbacks for remaining situations where the flow label values are 256 unusable. 258 The setting of the flow label by an application is necessarily a 259 stateful process, so that the application can store the label value 260 for re-use in all transport sessions that are part of the same 261 application transaction. Therefore, any firewall that chooses to 262 rewrite the label, to avoid a perceived covert channel risk, must do 263 so in a stateful way such that a given incoming label value is always 264 rewritten to the same outgoing value. 266 5. IANA Considerations 268 This document requests no action by IANA. 270 6. Acknowledgements 272 Valuable comments and contributions were made by... 274 This document was produced using the xml2rfc tool [RFC2629]. 276 7. Change log [RFC Editor: Please remove] 278 draft-tarreau-extend-flow-label-balancing-01: small updates, 279 2012-12-05. 281 draft-tarreau-extend-flow-label-balancing-00: extended role extracted 282 after IETF83, 2012-06-12. 284 draft-carpenter-v6ops-label-balance-02: clarified after WG 285 discussions, 2012-03-06. 287 draft-carpenter-v6ops-label-balance-01: updated with community 288 comments, additional author, 2012-01-17. 290 draft-carpenter-v6ops-label-balance-00: original version, 2011-10-13. 292 8. References 294 8.1. Normative References 296 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 297 (IPv6) Specification", RFC 2460, December 1998. 299 [RFC6434] Jankiewicz, E., Loughney, J., and T. Narten, "IPv6 Node 300 Requirements", RFC 6434, December 2011. 302 [RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, 303 "IPv6 Flow Label Specification", RFC 6437, November 2011. 305 8.2. Informative References 307 [I-D.carpenter-flow-label-balancing] 308 Carpenter, B., Jiang, S., and W. Tarreau, "Using the IPv6 309 Flow Label for Server Load Balancing", 310 draft-carpenter-flow-label-balancing-01 (work in 311 progress), June 2012. 313 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 314 June 1999. 316 Authors' Addresses 318 Brian Carpenter 319 Department of Computer Science 320 University of Auckland 321 PB 92019 322 Auckland, 1142 323 New Zealand 325 Email: brian.e.carpenter@gmail.com 327 Sheng Jiang 328 Huawei Technologies Co., Ltd 329 Q14, Huawei Campus 330 No.156 Beiqing Road 331 Hai-Dian District, Beijing 100095 332 P.R. China 334 Email: jiangsheng@huawei.com 335 Willy Tarreau 336 Exceliance 337 R&D Produits reseau 338 3 rue du petit Robinson 339 78350 Jouy-en-Josas 340 France 342 Email: w@1wt.eu