idnits 2.17.1 draft-boucadair-mptcp-natfwfree-profile-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 : ---------------------------------------------------------------------------- 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 (July 3, 2015) is 3212 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 6824 (Obsoleted by RFC 8684) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Boucadair 3 Internet-Draft C. Jacquenet 4 Intended status: Experimental P. Seite 5 Expires: January 4, 2016 France Telecom 6 O. Bonaventure 7 Tessares 8 L. Deng 9 China Mobile 10 July 3, 2015 12 An MPTCP Profile for NAT- and Firewall-Free Networks: Network-Assisted 13 MPTCP Deployments 14 draft-boucadair-mptcp-natfwfree-profile-00 16 Abstract 18 One of the promising deployment scenarios for Multipath TCP (MPTCP) 19 is to enable a Customer Premises Equipment (CPE) that is connected to 20 multiple networks (e.g., DSL, LTE, WLAN) to optimize the usage of 21 such resources, thereby providing better serviceability overall 22 (including whenever the CPE fails to connect to one of the access 23 networks). This document specifies a MPTCP profile for such 24 deployments in network regions that are firewall- and NAT-free. 26 Requirements Language 28 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 29 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 30 document are to be interpreted as described in RFC 2119 [RFC2119]. 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at http://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on January 4, 2016. 49 Copyright Notice 51 Copyright (c) 2015 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 67 2. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 3. Target Use Cases . . . . . . . . . . . . . . . . . . . . . . 5 69 4. Relaxing Some Base MPTCP Features . . . . . . . . . . . . . . 5 70 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 71 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 72 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 73 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 74 8.1. Normative References . . . . . . . . . . . . . . . . . . 9 75 8.2. Informative References . . . . . . . . . . . . . . . . . 9 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 78 1. Introduction 80 One of the promising deployment scenarios for Multipath TCP (MPTCP, 81 [RFC6824]) is to enable a Customer Premises Equipment (CPE) that is 82 connected to multiple networks (e.g., DSL, LTE, WLAN) to optimize the 83 usage of such resources, see for example [I-D.deng-mptcp-proxy] or 84 [RFC4908]. This deployment scenario relies on MPTCP proxies on both 85 the CPE and the network sides (Figure 1). The latter plays the role 86 of traffic concentrator. A concentrator terminates the MPTCP 87 sessions, from a CPE, before relaying it into a legacy TCP session. 89 IP Network #1 90 +------------+ _--------_ +------------+ 91 | | (e.g., LTE ) | | 92 | CPE +======================+ | 93 | (MPTCP | (_ _) |Concentrator| 94 | Proxy) | (_______) | (MPTCP | 95 | | | Proxy) |------> Internet 96 | | | | 97 | | IP Network #2 | | 98 | | _--------_ | | 99 | | ( e.g., DSL ) | | 100 | +======================+ | 101 | | (_ _) | | 102 +-----+------+ (_______) +------------+ 103 | 104 ----CPE network---- 105 | 106 end-nodes 108 Figure 1: "Network-Assisted" MPTCP Design 110 Because the paths between the CPE and the concentrator are firewall- 111 and NAT-free, the complexity of the MPTCP specification that was 112 initially induced by the need to handle the presence of firewalls as 113 well as routing asymmetry effects, is not justified anymore. 114 Concretely, in the situations where the paths between the CPE and the 115 concentrator are firewall- and NAT-free, the MPTCP stack is not 116 required to support the dedicated features required to handle the 117 presence of firewalls as well as routing asymmetry effects. 119 Such context encourages the specification of a dedicated MPTCP 120 profile that would in turn foster the adoption of MPTCP. This 121 document specifies such MPTCP profile that is adapted to network 122 regions that are firewall- and NAT-free. 124 The constraint discussed in [RFC6824] does not apply for such 125 deployments: 127 "External Constraints: The protocol must function through the vast 128 majority of existing middleboxes such as NATs, firewalls, and 129 proxies, and as such must resemble existing TCP as far as possible 130 on the wire. Furthermore, the protocol must not assume the 131 segments it sends on the wire arrive unmodified at the 132 destination: they may be split or coalesced; TCP options may be 133 removed or duplicated." 135 NAT is used through this document to refer to any function that 136 rewrites a source IP address/prefix to another IP address/prefix 137 within the same or distinct address family. NAT is also to refer to 138 any function that rewrites port numbers. Typical examples are 139 traditional IPv4-IPv4 NAT ([RFC3022]), NPTv6 ([RFC6296]), NAT64 140 ([RFC6146]), DS-Lite AFTR ([RFC6333]), or Carrier Grade NAT (CGN, 141 [RFC6888]). 143 Lawful intercept and data retention implications due to the use of 144 MPTCP are out of the scope of this document. 146 2. Assumptions 148 The following assumptions are made: 150 o One or multiple concentrators are deployed on the network side to 151 assist MPTCP-enabled hosts to establish MPTCP connections via 152 available network attachments. 153 o On the uplink path, the concentrator terminates the MPTCP 154 connections received from its customer-facing interfaces and 155 transforms these connections into legacy TCP connections towards 156 upstream servers. On the downlink path, the concentrator turns 157 the legacy server's TCP connection into MPTCP connections towards 158 its customer-facing interfaces. 159 o Various network attachments are provided to an MPTCP-enabled host/ 160 CPE; all these network attachments are managed by the same 161 administrative entity. 162 o The CPE implements an MPTCP proxy as well. This MPTCP proxy acts 163 as a traffic concentrator from the end-nodes (i.e., hosts attached 164 to the CPE) standpoint. 165 o The network legs between the hosts and a concentrator instance are 166 NAT- and firewall-free. 167 o The logic for mounting network attachments by a host is 168 deployment- and implementation-specific that are out of scope of 169 this document . 170 o The Network Provider that manages the various network attachments 171 (including the concentrators) can enforce authentication and 172 authorization policies using appropriate mechanisms that are out 173 of scope of this document. 174 o Policies can be enforced by a concentrator instance operated by 175 the Network Provider to manage both upstream and downstream 176 traffic. These policies may be subscriber-specific, connection- 177 specific or system-wide. 178 o The concentrator may be notified about the results of monitoring 179 (including probing) the various network legs to service a 180 customer, a group of customers, a given region, etc. No 181 assumption is made by this document about how these probing 182 operations are executed. 183 o Ingress filtering ([RFC2827]) is implemented at the boundaries of 184 the networks to provide anti-spoofing. 186 o An MPTCP-enabled multiple Interfaces host, that is directly 187 connected to one or multiple access networks obtains address/ 188 prefixes via legacy mechanisms of the various available network 189 attachments. The host may be assigned the same or distinct IP 190 address/prefixes via the various available network attachments. 191 o The CPE does not alter or strip MPTCP signals received from end- 192 nodes. 193 o The concentrator may behave in a transparent mode (that is, hosts 194 are unaware of the presence of the concentrator in the 195 communication path(s)) or in a non-transparent mode (i.e., the 196 identity of the concentrator is explicitly configured to the 197 hosts). 198 o A mechanism should be used to make sure the same IP address is 199 assigned to the host when transforming an MPTCP connection into a 200 TCP connection. No assumption is made about how such mechanism is 201 implemented. Network Providers should be aware of the 202 complications that may arise if a same IP address/prefix is shared 203 among multiple hosts (see [RFC6967]). Whether these complications 204 apply or not is deployment-specific. 205 o The location of the concentrator(s) is deployment-specific. 206 Network Providers may choose to adopt centralized or distributed 207 (even if they may not be present on the different network 208 accesses) designs, etc. Nevertheless, in order to take advantage 209 of MPTCP, the location of the concentrator should not jeopardize 210 packet forwarding performance for traffic sent from or directed to 211 connected hosts. 213 3. Target Use Cases 215 Two main use cases are targeted by this profile: 217 1. Multi-homed CPEs (e.g., [RFC4908]). 219 2. MPTCP within core networks to achieve load-balancing or bandwidth 220 aggregation. This use case assumes that MPTCP connections are 221 established between nodes that are managed by the same 222 administrative entity. 224 4. Relaxing Some Base MPTCP Features 226 The following list is a set of items of the MPTCP specification that 227 can be relaxed to facilitate and improve MPTCP operation in firewall- 228 and NAT-free regions of the network. A technical justification is 229 provided to relax each of these items. The rest of the MPTCP 230 specifications that are not mentioned in this section MUST be 231 followed even in firewall and NAT-free networks. 233 Item 1: Checksum SHOULD be disabled. This behavior implies in 234 particular that "A" flag bit must always be set to 0. 236 Justification: This is a direct consequence of the absence 237 of NATs and firewalls in the network leg between the host 238 and a concentrator. 240 Item 2: Section 3.6 of [RFC6824] does not apply. 242 Justification: The target deployments assume that all paths 243 are MPTCP-compliant; once the first subflow is established, 244 it is safe to assume that any additional subflow will be 245 successfully established over an MPTCP-compliant path. 246 There is no need to envision a TCP fallback mechanism except 247 for the first subflow. 249 Operators may run tests to assess whether available paths 250 are MPTCP-compliant. For example, Operators can perform 251 tests with tools like tracebox to validate the absence of 252 middleboxes on the network legs that are used. It is out of 253 scope of this document to define those tests. 255 Item 3: Endpoints may rely on the source address of a sub-flow 256 established by an initiating peer to establish new subflows 257 or enforce policies (e.g., rate-limit at the concentrator 258 side). 260 Justification: The point about private IP addresses 261 discussed in Section of [RFC6824] does not apply, since 262 there is no NAT in the path between the involved MPTCP 263 endpoints. 265 Item 4: Given that the network legs that are used are trusted, there 266 is no need to authenticate the establishment of the 267 additional subflows with a HMAC in the MP_JOIN. MP_JOIN 268 options are still used, but they neither contain random 269 numbers nor truncated HMACs. The MP_JOIN option in the SYN 270 has a length of 8 bytes and contains the receiver's token. 271 In the SYN+ACK and the third ACK, the MP_JOIN options have a 272 length of 4 bytes. 274 Justification: The network leg between the directly- 275 connected host and a concentrator instance is trusted. 276 There is thus no risk of attack on this part of the network. 278 Item 5: If the concentrator's reachability information is explicitly 279 configured on the MPTCP host, and the concentrator is aware 280 of addresses assigned to the MPTCP host, then the ADD_ADDR 281 option SHOULD NOT be supported. In such case, the host MUST 282 rely upon the provided configuration information to manage 283 an MPTCP connection. 285 Justification: A host that is configured with the addresses 286 of a concentrator can use these addresses to establish one 287 or multiple subflows for a given connection; each connection 288 is then bound to an IP address of the concentrator that has 289 been "assigned" to the host, as per the concentrator's 290 reachability information (a name, an IP address, etc.) 291 provided to the host. The locators of the concentrators are 292 likely to be stable. A locator can be a name, IPv4/v6 293 addresses, etc. 295 Item 6: If the MPTCP endpoint is explicitly configured so that it 296 behaves in a network-assisted mode, subflows can be created 297 to the remote MPTCP concentrator, using a locally configured 298 set of addresses, without advertising the available set of 299 addresses. Triggers to decide how many sub-flows are to be 300 initiated or when to establish additional ones are 301 application-specific. 303 Justification: Multiple addresses are configured out of band 304 (e.g., using DHCP [I-D.boucadair-mptcp-dhc], TR-69, etc.). 305 The use of out-of-band configuration mechanism is justified 306 in some deployments for engineering purpose (e.g., assign 307 the concentrator to service a host based on criteria such as 308 the load of the concentrator, geo-proximity, etc.). 310 Item 7: If the concentrator has access to the information about 311 address(es) assigned to a directly-connected host and their 312 associated leases (e.g., because the concentrator is 313 collocated with a DHCP relay or acquires such information by 314 means of an out-of-band mechanism), the concentrator SHOULD 315 undertake actions for a better quality of experience of 316 MPTCP connections such as: add a new sub-flow even if the 317 concentrator is not the initiator of the MPTCP connection, 318 migrate flows to another alternate address if the remote 319 address is not valid anymore or because its validity timeout 320 will expire soon, etc. 322 Justification: This approach is meant to anticipate 323 retransmissions that may be induced by the invalidity of an 324 IP address. Also, this allows to reduce the delay from 325 waiting for a notification from a remote peer. The 326 concentrator can also decide to add new subflows for better 327 quality of experience based, for example, on local policies. 329 Item 8: Address management MAY not be specific to each active MPTCP 330 connection, but MAY be on a per host basis. 332 Justification: This is because all the MPTCP connections 333 initiated by a host (resp. a concentrator) involve the same 334 MPTCP endpoint (concentrator). 336 How such address management is actually achieved is 337 implementation-specific. Nevertheless, for illustration 338 purposes, a dedicated session can be enabled between an 339 MPTCP-enabled host and a concentrator for control purposes. 340 This information exchanged in this dedicated connection will 341 be used to adjust other (data) connections. 343 Item 9: The maximum number of subflows for a given connection SHOULD 344 be set by default to 4. 346 Justification: For dimensioning purposes, an operator needs 347 to control the number of flows to be handled by a 348 concentrator. 350 4 corresponds to a dual-homed host that is assigned both an 351 IPv4 address and an IPv6 prefix for each network attachment. 353 An MPTCP endpoint that is dimensioned to maintain a maximum 354 number of subflows per MPTCP connection may accept to 355 maintain more subflows for some connections. 357 5. IANA Considerations 359 This document makes no request of IANA. 361 6. Security Considerations 363 The concentrator may have access to privacy-related information 364 (e.g., IMSI, link identifier, subscriber credentials, etc.). The 365 concentrator must not leak such sensitive information outside a local 366 domain. 368 Means to protect the MPTCP concentrator against Denial-of-Service 369 (DoS) attacks must be enabled. Such means include the enforcement of 370 ingress filtering policies at the boundaries of the network. In 371 order to prevent exhausting the resources of the concentrator by 372 creating an aggressive number of simultaneous subflows for each MPTCP 373 connection, the administrator should limit the number of allowed 374 subflows per host for a given connection. This profile recommends 375 this value to be set to 4. 377 Attacks outside the domain can be prevented if ingress filtering is 378 enforced. Nevertheless, attacks from within the network between a 379 host and a concentrator instance are another yet actual threat. 380 Means to ensure that illegitimate nodes cannot connect to a network 381 should be implemented. 383 Traffic theft can be achieved if an illegitimate concentrator is 384 inserted in the path. Indeed, inserting an illegitimate concentrator 385 in the forwarding path allows to intercept traffic and therefore have 386 access to sensitive data issued by or destined to a host. To 387 mitigate this threat, secure means to discover a concentrator (for 388 non-transparent modes) should be enabled. 390 This document relax checksum validations (Item (1), Section 4) and 391 MP_JOIN authentication constraints (Item (4), Section 4) because the 392 networks between two MPTCP endpoints is trusted. Furthermore, 393 ingress filtering is enforced at these networks for source address 394 validation. 396 7. Acknowledgements 398 TBC. 400 8. References 402 8.1. Normative References 404 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 405 Requirement Levels", BCP 14, RFC 2119, March 1997. 407 [RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, 408 "TCP Extensions for Multipath Operation with Multiple 409 Addresses", RFC 6824, January 2013. 411 8.2. Informative References 413 [I-D.boucadair-mptcp-dhc] 414 Boucadair, M., Jacquenet, C., and T. Reddy, "IP Flow 415 Information Export (IPFIX) Entities", July 2015, 416 . 419 [I-D.deng-mptcp-proxy] 420 Lingli, D., Liu, D., Sun, T., Boucadair, M., and G. 421 Cauchie, "Use-cases and Requirements for MPTCP Proxy in 422 ISP Networks", draft-deng-mptcp-proxy-01 (work in 423 progress), October 2014. 425 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 426 Defeating Denial of Service Attacks which employ IP Source 427 Address Spoofing", BCP 38, RFC 2827, May 2000. 429 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 430 Address Translator (Traditional NAT)", RFC 3022, January 431 2001. 433 [RFC4908] Nagami, K., Uda, S., Ogashiwa, N., Esaki, H., Wakikawa, 434 R., and H. Ohnishi, "Multi-homing for small scale fixed 435 network Using Mobile IP and NEMO", RFC 4908, June 2007. 437 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 438 NAT64: Network Address and Protocol Translation from IPv6 439 Clients to IPv4 Servers", RFC 6146, April 2011. 441 [RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix 442 Translation", RFC 6296, June 2011. 444 [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 445 Stack Lite Broadband Deployments Following IPv4 446 Exhaustion", RFC 6333, August 2011. 448 [RFC6888] Perreault, S., Yamagata, I., Miyakawa, S., Nakagawa, A., 449 and H. Ashida, "Common Requirements for Carrier-Grade NATs 450 (CGNs)", BCP 127, RFC 6888, April 2013. 452 [RFC6967] Boucadair, M., Touch, J., Levis, P., and R. Penno, 453 "Analysis of Potential Solutions for Revealing a Host 454 Identifier (HOST_ID) in Shared Address Deployments", RFC 455 6967, June 2013. 457 Authors' Addresses 459 Mohamed Boucadair 460 France Telecom 461 Rennes 35000 462 France 464 Email: mohamed.boucadair@orange.com 466 Christian Jacquenet 467 France Telecom 468 Rennes 469 France 471 Email: christian.jacquenet@orange.com 472 Pierrick Seite 473 France Telecom 474 Rennes 475 France 477 Email: pierrick.seite@orange.com 479 Olivier Bonaventure 480 Tessares 482 Email: Olivier.Bonaventure@tessares.net 483 URI: http://www.tessares.net 485 Lingli Deng 486 China Mobile 488 Email: denglingli@chinamobile.com