idnits 2.17.1 draft-nam-mptcp-deployment-considerations-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 (October 27, 2016) is 2737 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-10) exists of draft-boucadair-mptcp-plain-mode-08 ** Obsolete normative reference: RFC 6824 (Obsoleted by RFC 8684) == Outdated reference: A later version (-08) exists of draft-boucadair-mptcp-dhc-06 == Outdated reference: A later version (-05) exists of draft-boucadair-mptcp-radius-03 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Boucadair, Ed. 3 Internet-Draft C. Jacquenet, Ed. 4 Intended status: Informational Orange 5 Expires: April 30, 2017 O. Bonaventure, Ed. 6 Tessares 7 D. Behaghel 8 OneAccess 9 S. Secci 10 UPMC 11 W. Henderickx, Ed. 12 Nokia/Alcatel-Lucent 13 R. Skog, Ed. 14 Ericsson 15 S. Vinapamula 16 Juniper 17 S. Seo 18 Korea Telecom 19 W. Cloetens 20 SoftAtHome 21 U. Meyer 22 Vodafone 23 LM. Contreras 24 Telefonica 25 B. Peirens 26 Proximus 27 October 27, 2016 29 Network-Assisted MPTCP: Use Cases, Deployment Scenarios and Operational 30 Considerations 31 draft-nam-mptcp-deployment-considerations-00 33 Abstract 35 Network-Assisted MPTCP deployment models are designed to facilitate 36 the adoption of MPTCP for the establishment of multi-path 37 communications without making any assumption about the support of 38 MPTCP by the communicating peers. MPTCP Conversion Points (MCPs) 39 located in the network are responsible for establishing multi-path 40 communications on behalf of endpoints, thereby taking advantage of 41 MPTCP capabilities to achieve different goals that include (but are 42 not limited to) optimization of resource usage (e.g., bandwidth 43 aggregation), of resiliency (e.g., primary/backup communication 44 paths), and traffic offload management. 46 This document describes Network-Assisted MPTCP uses cases, deployment 47 scenarios, and operational considerations. 49 Requirements Language 51 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 52 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 53 document are to be interpreted as described in RFC 2119 [RFC2119]. 55 Status of This Memo 57 This Internet-Draft is submitted in full conformance with the 58 provisions of BCP 78 and BCP 79. 60 Internet-Drafts are working documents of the Internet Engineering 61 Task Force (IETF). Note that other groups may also distribute 62 working documents as Internet-Drafts. The list of current Internet- 63 Drafts is at http://datatracker.ietf.org/drafts/current/. 65 Internet-Drafts are draft documents valid for a maximum of six months 66 and may be updated, replaced, or obsoleted by other documents at any 67 time. It is inappropriate to use Internet-Drafts as reference 68 material or to cite them other than as "work in progress." 70 This Internet-Draft will expire on April 30, 2017. 72 Copyright Notice 74 Copyright (c) 2016 IETF Trust and the persons identified as the 75 document authors. All rights reserved. 77 This document is subject to BCP 78 and the IETF Trust's Legal 78 Provisions Relating to IETF Documents 79 (http://trustee.ietf.org/license-info) in effect on the date of 80 publication of this document. Please review these documents 81 carefully, as they describe your rights and restrictions with respect 82 to this document. Code Components extracted from this document must 83 include Simplified BSD License text as described in Section 4.e of 84 the Trust Legal Provisions and are provided without warranty as 85 described in the Simplified BSD License. 87 Table of Contents 89 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 90 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 91 3. Network-Assisted MPTCP Use Cases . . . . . . . . . . . . . . 5 92 4. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . 6 93 4.1. LTE/WLAN Aggregation . . . . . . . . . . . . . . . . . . 6 94 4.2. Fixed/Wireless Access Aggregation . . . . . . . . . . . . 6 95 5. Deployment & Operational Considerations . . . . . . . . . . . 7 96 5.1. MCP Location . . . . . . . . . . . . . . . . . . . . . . 7 97 5.2. MCP Insertion in a Multipath Communication . . . . . . . 7 98 5.2.1. Explicit Mode (Off-path) . . . . . . . . . . . . . . 7 99 5.2.2. Implicit Mode (On-path) . . . . . . . . . . . . . . . 8 100 5.3. Authorization . . . . . . . . . . . . . . . . . . . . . . 10 101 5.4. MCP Behaviors . . . . . . . . . . . . . . . . . . . . . . 10 102 5.4.1. Transparent MCP . . . . . . . . . . . . . . . . . . . 11 103 5.4.2. Non-Transparent MCP . . . . . . . . . . . . . . . . . 12 104 5.5. Address Family Considerations . . . . . . . . . . . . . . 14 105 5.6. Policies & Configuration Parameters . . . . . . . . . . . 14 106 5.6.1. Traffic Distribution Scheme . . . . . . . . . . . . . 14 107 5.6.2. Flows Eligible to Multipath Service . . . . . . . . . 14 108 5.6.3. TCP Fragmentation . . . . . . . . . . . . . . . . . . 15 109 5.6.4. DSCP Preservation . . . . . . . . . . . . . . . . . . 15 110 5.6.5. Supported Transport Protocols . . . . . . . . . . . . 15 111 5.6.6. Logging . . . . . . . . . . . . . . . . . . . . . . . 15 112 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 113 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 114 7.1. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 15 115 7.2. Denial-of-Service (DoS) . . . . . . . . . . . . . . . . . 16 116 7.3. Illegitimate MCP . . . . . . . . . . . . . . . . . . . . 16 117 7.4. High Rate Reassembly . . . . . . . . . . . . . . . . . . 16 118 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 119 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 120 9.1. Normative References . . . . . . . . . . . . . . . . . . 17 121 9.2. Informative References . . . . . . . . . . . . . . . . . 17 122 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 124 1. Introduction 126 The overall quality of connectivity services can be enhanced by 127 combining several access network links for various purposes - 128 resource optimization, better resiliency, etc. Some transport 129 protocols, such as Multipath TCP, can help achieve such better 130 quality, but failed to be massively deployed so far. 132 The support of multipath transport capabilities by communicating 133 hosts remains a privileged target design so that such hosts can 134 directly use the available resources provided by a variety of access 135 networks they can connect to. Nevertheless, network operators do not 136 control end hosts while the support of MPTCP by content servers 137 remains close to zero. 139 Network-Assisted MPTCP deployment models are designed to facilitate 140 the adoption of MPTCP for the establishment of multi-path 141 communications without making any assumption about the support of 142 MPTCP capabilities by communicating peers. Network-Assisted MPTCP 143 deployment models rely upon MPTCP Conversion Points (MCPs) that act 144 on behalf of hosts so that they can take advantage of establishing 145 communications over multiple paths. 147 Such MCPs can be deployed in CPEs (Customer Premises Equipment), as 148 well in the network side. MCPs are responsible for establishing 149 multi-path communications on behalf of endpoints. 151 This document describes Network-Assisted MPTCP uses cases 152 (Section 3), deployment scenarios (Section 4), and operational 153 considerations (Section 5). 155 2. Terminology 157 The reader should be familiar with the terminology defined in 158 [RFC6824]. 160 This document makes use of the following terms: 162 o Client: an endhost that initiates transport flows forwarded along 163 a single path. Such endhost is not assumed to support multipath 164 transport capabilities. 166 o Server: an endhost that communicates with a client. Such endhost 167 is not assumed to support multipath transport capabilities. 169 o Multipath Client: a Client that supports multipath transport 170 capabilities. 172 o Multipath Server: a Server that supports multipath transport 173 capabilities. Both the client and the server can be single-homed 174 or multi-homed. However, for the use cases discussed in this 175 document, the number of interfaces on the endhosts is not 176 relevant. 178 o Transport flow: a sequence of packets that belong to a 179 unidirectional transport flow and which share at least one common 180 characteristic (e.g., the same destination address). TCP and SCTP 181 flows are composed of packets that have the same source and 182 destination addresses, the same protocol number and the same 183 source and destination ports. 185 o Multipath Conversion Point (MCP): a function that terminates a 186 transport flow and relays all data received over it over another 187 transport flow. 189 MCP is a function provided by the network operator that converts a 190 multipath transport flow and relays it over a single path 191 transport flow and vice versa. 193 3. Network-Assisted MPTCP Use Cases 195 The first use case is a Multipath Client that interacts with a 196 Server. To benefit from the capabilities of its multipath transport 197 protocol, the Multipath Client will interact with a Multipath 198 Conversion Point (MCP) located in the network as illustrated in 199 Figure 1. 201 C <===========>MCP <------------> S 202 +<============>+ 204 Legend: 205 <===>: MPTCP leg 207 Figure 1: A Multipath Client interacts with a Server through a 208 Multipath Conversion Point 210 A similar approach consists of a Multipath Server that leverages its 211 multipath capabilities when interacting with a Client as shown in 212 Figure 2. 214 C <---------> MCP <===========> S 215 +<=============>+ 217 Figure 2: A Client interacts with a Multipath Server through a 218 Multipath Conversion Point 220 The third use case is when a Client interacts with a Server and the 221 corresponding communication is deemed eligible to multi-path 222 forwarding. In this case, two Multipath Conversion Points are used. 223 The upstream MCP converts the (single path) transport flow initiated 224 by the Client into a multipath transport flow towards a downstream 225 MCP (called, network-located MCP). This downstream MCP converts the 226 multipath transport flow received from the upstream MCP in a single 227 path transport flow forwarded to the destination Server. The end-to- 228 end transport flow between the Client and the Server is thus 229 decomposed into three flows as shown in Figure 3: A (single path) 230 transport flow between the Client and the upstream MCP, a multipath 231 transport flow between the upstream and the downstream MCPs, and a 232 single path transport flow between the downstream MCP and the Server. 234 Upstream Downstream 235 C <---> MCP <===========> MCP <------------> S 236 +<=============>+ 238 Figure 3: A Client interacts with a Server through two Multipath 239 Conversion Points 241 4. Deployment Scenarios 243 This section discusses some deployment scenarios related to Network- 244 Assisted MPTCP designs. 246 4.1. LTE/WLAN Aggregation 248 This deployment scenario is considered by mobile operators so that 249 they can propose their customers to aggregate LTE resources with WLAN 250 resources. 252 As depicted in Figure 4, the mobile terminal (UE, User Equipment) is 253 MPTCP-capable. The MCP function is enabled in the network to 254 terminate MPTCP connections (e.g., in the PDN Gateway, a dedicated 255 service function located at the (S)Gi interface, co-located with a 256 TCP proxy, etc.). 258 This deployment scenario is an implementation of the use case 259 depicted in Figure 1. 261 +------------+ _--------_ +----------------+ 262 | | ( LTE ) | | 263 | UE +=======+ +===+ Backbone | 264 | (MPTCP | (_ _) | Network | 265 | Client) | (_______) |+--------------+| 266 | | IP Network #1 || Concentrator ||------> Internet 267 | | || (MCP) || 268 | | |+--------------+| 269 | | IP Network #2 | | 270 | | _--------_ | | 271 | | ( ) | | 272 | +=======+ WLAN +==+ | 273 | | (_ _) | | 274 +------------+ (_______) +----------------+ 276 Figure 4: Network-Assisted MPTCP LTE/WLAN Aggregation (Host-based 277 model) 279 4.2. Fixed/Wireless Access Aggregation 281 One of the promising deployment scenarios for Multipath TCP is to 282 enable a CPE that is connected to multiple access networks (e.g., 283 DSL, LTE, WLAN) to optimize the usage of such resources. This 284 deployment scenario, called Hybrid Access, relies upon MCPs located 285 in both the CPE and the network (Figure 5). The latter plays the 286 role of an MPTCP concentrator. Such concentrator terminates the 287 MPTCP sessions established from CPEs, before redirecting traffic into 288 legacy TCP sessions. 290 This deployment scenario is an implementation of the use case 291 depicted in Figure 2. 293 +------------+ _--------_ +----------------+ 294 | | ( LTE ) | | 295 | CPE +=======+ +===+ Backbone | 296 | (MCP) | (_ _) | Network | 297 | | (_______) |+--------------+| 298 | | IP Network #1 || Concentrator ||------> Internet 299 | | || (MCP) || 300 | | |+--------------+| 301 | | IP Network #2 | | 302 | | _--------_ | | 303 | | ( DSL ) | | 304 | +=======+ +==+ | 305 | | (_ _) | | 306 +-----+------+ (_______) +----------------+ 307 | 308 ---- LAN ---- 309 | 310 end-nodes 312 Figure 5: Network-Assisted MPTCP Fixed/Wireless Access Aggregation 314 For mobile operators that provide CPE-based mobile broadband 315 services, LTE and WLAN resources can be aggregated by means of MPTCP. 316 In such deployment scenario, the MCP function is enabled in the CPE 317 and in the network. 319 5. Deployment & Operational Considerations 321 5.1. MCP Location 323 The location of MCPs is deployment-specific. Network Providers may 324 choose to adopt centralized or distributed designs. Nevertheless, in 325 order to take advantage of MPTCP, the location of an MCP should not 326 jeopardize packet forwarding performance overall. 328 5.2. MCP Insertion in a Multipath Communication 330 Two deployment scenarios can be considered for involving an MCP in 331 the communication path. These scenarios are described below. 333 5.2.1. Explicit Mode (Off-path) 335 This scenario assumes that the IP reachability information of an MCP 336 is explicitly configured on a device, e.g., by means of a specific 337 DHCP option [I-D.boucadair-mptcp-dhc]. A device can be a CPE or a 338 host. 340 MPTCP connections are established explicitly using the address(es) of 341 the MCP (Figure 6). In order to forward packets to their ultimate 342 destination, the MCP is provided during the connection establishment 343 with the destination IP address (and optionally destination port 344 numbers). Typically, this is achieved thanks to the use of the 345 MP_CONVERT option defined in [I-D.boucadair-mptcp-plain-mode]. 347 +---+ +-----+ +--+ 348 |H1 | | MCP | |RM| 349 +---+ +-----+ +--+ 350 h1@h2@ mcp@ rm@ 351 | | | | 352 | |src:Hi@ dst:mcp@| dst:rm@| 353 | |<=================MPTCP Leg=============>|<---TCP -->| 354 | | | | 356 Legend: 357 H1: A host serviced by an MCP. 358 RM: A remote machine. 360 Figure 6: Sample Connection Establishment (Explicit Mode) 362 This scenario aims to avoid any adherence of the Network-Assisted 363 MPTCP procedure and the underlying routing and forwarding policies. 364 Furthermore, this scenario allows for more flexibility in terms of 365 mounting MPTCP subflows as it does not require any specific order in 366 the establishment of subflows among available interfaces. 368 Because the MCP's reachability information is explicitly configured 369 on the device, means to guarantee successful inbound MPTCP 370 connections can be enabled in the device to instruct the MCP to 371 maintain active bindings so that incoming packets can be successfully 372 redirected towards the appropriate device. 374 5.2.2. Implicit Mode (On-path) 376 Unlike the explicit mode, the implicit mode assumes that the MCP is 377 located on a default forwarding path (primary path). As such, the 378 first subflow must always be placed over that primary path so that 379 the MCP can intercept MPTCP flows. Once intercepted, the MCP 380 advertises its reachability information by means of MPTCP signals 381 (MP_JOIN or ADD_ADDR). 383 +----+ +-----+ +--+ 384 | H1 | | MCP | |RM| 385 +----+ +-----+ +--+ 386 h1@h2@ mcp@ rm@ 387 | | | | 388 |src:h1@ dst:rm@| dst:rm@| 389 |<============Initial MPTCP subflow========>|<---TCP -->| 390 | | ... | | 391 | |src:h2@ dst:mcp@| dst:rm@| 392 | |<=========Secondary MPTCP subflow=======>|<---TCP -->| 393 | | ... | | 395 Figure 7: Sample Connection Establishment (Implicit Mode) 397 Subsequent subflows are then sent directly to the MCP (Figure 7). 398 The handling of these subsequent subflows is identical to the one of 399 the explicit mode; only the establishment of the initial subflow 400 differs. Concretely, in reference to Figure 8, once the upstream MCP 401 intercepts an initial subflow, it adds itself to the MPTCP connection 402 by sending ADD_ADDR on the primary subflow. Then, MP_JOIN is sent to 403 the IP address conveyed in ADD_ADDR to create the secondary subflow. 405 +----+ +-----+ +--+ 406 | H1 | | MCP | |RM| 407 +----+ +-----+ +--+ 408 h1@h2@ mcp@ rm@ 409 | | | | 410 |<==============ADD_ADDR====================| | 411 | | _______________________________________ | | 412 | |/ Secondary subflow \| | 413 | |================SYN+MP_JOIN=============>| | 414 | |<============SYN/ACK(MPJOIN)=============| | 415 | |============ACK(MP_JOIN)================>| | 416 | | ... | | 418 Figure 8: Secondary Subflow Creation (Implicit Mode) 420 5.2.2.1. Demux Native MPTCP Flows from Proxied MPTCP Flows 422 If no MP_CONVERT option ([I-D.boucadair-mptcp-plain-mode]) is 423 included in the initial SYN message, the MCP cannot distinguish 424 "native" MPTCP connections from "proxied" ones. The subsequent risk 425 is that native MPTCP communications will be reverted to TCP 426 connections. Such risk should be mitigated by enabling the 427 MP_CONVERT option to be included in the SYN message to create the 428 initial subflow. 430 5.3. Authorization 432 The Network Provider that manages the various network attachments 433 (including the MCPs) may enforce authentication and authorization 434 policies using appropriate mechanisms. For example, a non-exhaustive 435 list of methods to achieve authorization is provided hereafter: 437 o The network provider may enforce a policy based on the 438 International Mobile Subscriber Identity (IMSI) to verify that a 439 user is allowed to benefit from the aggregation service. If that 440 authorization fails, the Packet Data Protocol (PDP) context 441 /bearer will not be mounted. This method does not require any 442 interaction with the MCP. 444 o The network provider may enforce a policy based upon Access 445 Control Lists (ACLs), e.g., at a Broadband Network Gateway (BNG) 446 to control the CPEs that are authorized to communicate with an 447 MCP. These ACLs may be installed as a result of RADIUS exchanges, 448 for instance ([I-D.boucadair-mptcp-radius]). This method does not 449 require any interaction with the MCP. 451 o The MCP may implement an Ident interface [RFC1413] to retrieve an 452 identifier that will be used to assess whether that client is 453 entitled to make use of the aggregation service. Ident exchanges 454 will take place only when receiving the first subflow from a given 455 source IP address. 457 o The device that embeds the MCP may also host a RADIUS client that 458 will solicit an AAA server to check whether connections received 459 from a given source IP address are authorized or not 460 ([I-D.boucadair-mptcp-radius]). 462 A first safeguard against the misuse of MCP resources by illegitimate 463 users (e.g., users with access networks that are not managed by the 464 same service provider that operates the MCP) is to reject MPTCP 465 connections received on the Internet-facing interfaces. Only MPTCP 466 connections received on the customer-facing interfaces of an MCP will 467 be accepted. 469 Because only the CPE is entitled to establish MPTCP connections with 470 an MCP, ACLs may be installed on the CPE to avoid that internal 471 terminals issue MPTCP connections towards one of the MCPs. 473 5.4. MCP Behaviors 475 The MCP MUST be provided with instructions about the behavior to 476 adopt with regards to the processing of source addresses. The 477 following sub-sections elaborate on various schemes. 479 5.4.1. Transparent MCP 481 Transparent Network-Assisted MPTCP deployment is a deployment where 482 the visible source address of a packet forwarded by an MCP to a 483 remote machine located in the Internet is the IP address of the 484 endhost, not an address that is provisioned to the MCP. In order to 485 intercept incoming traffic, specific IPv4/IPv6 routes are injected so 486 that traffic is redirected towards the MCP. 488 No dedicated IP address pool is required to the MCP for the Network- 489 Assisted MPTCP service. 491 5.4.1.1. IPv4 Address Preservation 493 The MCP can be tweaked to behave in the IPv4 address preservation 494 mode. This is the IPv4 address assigned to the endhost (typically, 495 within a mobile deployment context as discussed in Section 4.1) or a 496 WAN address of the CPE for the wired case (Section 4.2). 498 5.4.1.2. Source IPv6 Prefix Preservation at Network-located MCP 500 Some IPv6 deployments may require the preservation of the source IPv6 501 prefix (Figure 9). 503 This model requires the MCP to support ALGs to accommodate 504 applications with IPv6 address referrals. 506 +--+ +-----+ +---+ +--+ 507 |H1| | MCP | |MCP| |RM| 508 +--+ +--+--+ +---+ +--+ 509 IP@s IP@1, IP@2 IP@mcf IP@d 510 | || | | 511 |src:IP@s ||src:IP@1 dst:IP@mcf|src:IP@1 | 512 |---------->||------------------------------------>|---------->| 513 | Dst:IP@d|| | dst:IP@d| 514 | || | | 515 |<--SYN/ACK-||<---------------SYN/ACK--------------|<-SYN/ACK--| 516 |---ACK---->||----------------ACK----------------->|---ACK---->| 517 | || | | 519 Legend: 520 mcf: MCP Customer-facing Interface 522 Figure 9: Example of Source IPv6 Prefix Preservation at Network- 523 located MCP (Initial subflow) 525 5.4.1.3. Source IPv6 Address Preservation at Network-located MCP 527 Some IPv6 deployments may require the preservation of the source IPv6 528 address (Figure 10). 530 This model avoids the need for the MCP to support ALGs to accommodate 531 applications with IPv6 address referrals. 533 +--+ +-----+ +---+ +--+ 534 |H1| | MCP | |MCP| |RM| 535 +--+ +--++-+ +---+ +--+ 536 IP@s IP@1, IP@2 IP@mcf IP@d 537 | || | | 538 |src:IP@s ||src:IP@1 dst:IP@mcf|src:IP@s | 539 |---------->||------------------------------------>|---------->| 540 | Dst:IP@d|| | dst:IP@d| 541 | || | | 542 |<--SYN/ACK-||<---------------SYN/ACK--------------|<-SYN/ACK--| 543 |---ACK---->||----------------ACK----------------->|---ACK---->| 544 | || | | 545 | || | | 547 Figure 10: Example of Outgoing SYN with Source Address Preservation 549 5.4.2. Non-Transparent MCP 551 Unlike the transport mode, this section focuses on deployments where 552 a dedicated IP address pool is provisioned to the MCP for the 553 Network-Assisted MPTCP service. 555 5.4.2.1. IPv4 Address Sharing at the at the Network-located MCP 557 Because of global IPv4 address depletion, optimization of the IPv4 558 address usage is mandatory. This obviously includes the IPv4 559 addresses that are assigned by the MCP at its Internet-facing 560 interfaces (Figure 11 and Figure 12). A pool of global IPv4 561 addresses is provisioned to the MCP along with possible instructions 562 about the address sharing ratio to apply (see Appendix B of 563 [RFC6269]). Adequate forwarding policies are enforced so that 564 traffic destined to an address of such pool is intercepted by the 565 appropriate MCP. 567 +--+ +---+ +--+ 568 |H1| |MCP| |RM| 569 +--+ +---+ +--+ 570 || | | 571 ||src:IP@s MP_CONVERT(D=0,IP@d) dst:IP@mcf|src:IP@mif | 572 ||-----------------------SYN--------------------->|---SYN---->| 573 || | dst:IP@d| 574 || | | 575 ||<--------------------SYN/ACK--------------------|<-SYN/ACK--| 576 ||-----------------------ACK--------------------->|---ACK---->| 577 || | | 579 Legend: 580 mcf: MCP Customer-facing Interface 581 mif: MCP Internet-facing Interface 583 Figure 11: Example of Outgoing SYN without Source Address 584 Preservation (Single-ended MCP) 586 +--+ +-----+ +---+ +--+ 587 |H1| | MCP | |MCP| |RM| 588 +--+ +--++-+ +---+ +--+ 589 | || | | 590 |src:IP@s ||src:IP@1 MP_CONVERT(D=0,IP@d) |src:IP@mif | 591 |---SYN---->||----------------SYN----------------->|---SYN---->| 592 | dst:IP@d|| dst:IP@mcf| dst:IP@d| 593 | || | | 594 |<--SYN/ACK-||<---------------SYN/ACK--------------|<-SYN/ACK--| 595 |---ACK---->||----------------ACK----------------->|---ACK---->| 596 | || | | 598 Figure 12: Example of Outgoing SYN without Source Address 599 Preservation (Dual-ended MCPs) 601 5.4.2.2. IPv4 Address 1:1 Translation at the MCP 603 For networks that do not face global IPv4 address depletion yet, the 604 MCP can be configured so that source IPv4 addresses of the CPE are 605 replaced with other (public) IPv4 addresses. A pool of global IPv4 606 addresses is then provisioned to the MCP for this purpose. Rewriting 607 source IPv4 addresses may be used as a means to redirect incoming 608 traffic towards the appropriate MCP. 610 5.4.2.3. IPv6 Prefix Sharing (NPTv6) at the Network-located MCP 612 Rewriting the source IPv6 prefix ([RFC6296]) may be needed to 613 redirect incoming traffic towards the appropriate MCP. A pool of 614 IPv6 prefixes is then provisioned to the MCP for this purpose. 616 5.5. Address Family Considerations 618 Subflows of a given MPTCP connection can be associated to the same 619 address family or may be established with different address families. 620 Also, the Network-Assisted MPTCP using MP_CONVERT option, regardless 621 of the addressing scheme enforced by each CPE network attachment. In 622 particular, the plain transport mode indifferently accommodates the 623 following combinations. 625 LAN Leg MPTCP Legs TCP Leg towards RM 626 ------- ----------- ------------------ 627 IPv4 IPv4 IPv4 628 IPv4 IPv6 IPv4 629 IPv4 IPv6 & IPv4 IPv4 630 IPv6 IPv6 IPv6 631 IPv6 IPv4 IPv6 632 IPv6 IPv6 & IPv4 IPv6 634 5.6. Policies & Configuration Parameters 636 5.6.1. Traffic Distribution Scheme 638 The logic of traffic distribution over multiple paths is deployment- 639 specific. This document does not require nor preclude any particular 640 traffic distribution scheme. Nevertheless, MCPs MUST be configurable 641 with a parameter to indicate which traffic distribution scheme to 642 enable. Indeed, policies can be enforced by an MCP instance operated 643 by the Network Provider to manage both upstream and downstream 644 traffic. These policies may be subscriber-specific, connection- 645 specific, system-wise, or else. 647 5.6.2. Flows Eligible to Multipath Service 649 The Multipath Client and MCPs may be provided with a set of 650 classification policies to help electing flows for the MPTCP service. 651 These policies may be provisioned either statically and dynamically 652 (or a combination thereof). 654 Also, multiple MCPs may serve a given end-user, as a function of the 655 nature of the service or the traffic to be forwarded over MPTCP 656 connections. For example, an MCP may be used by a service provider 657 to proceed with CPE-targeted maintenance operations, whereas another 658 MCP may be configured to service multi-path communications initiated 659 by a set of end-users. 661 5.6.3. TCP Fragmentation 663 Methods to avoid TCP fragmentation, such as rewriting the TCP Maximum 664 Segment Size (MSS) option, must be supported by MCPs. 666 5.6.4. DSCP Preservation 668 The MCP MAY be configured to preserve the same DSCP marking or 669 enforce DSCP re-marking policies. DSCP preservation MUST be enabled 670 by default. 672 5.6.5. Supported Transport Protocols 674 The MCP supports TCP by design. Additional transport protocols 675 SHOULD be supported. A configuration parameter MUST be supported by 676 the MCP to indicate which transport protocols can be relayed into an 677 MPTCP connection. 679 5.6.6. Logging 681 If the MCP is used in global IPv4 address sharing environments, the 682 logging recommendations discussed in Section 4 of [RFC6888] need to 683 be considered. Security-related issues encountered in address 684 sharing environments are documented in Section 13 of [RFC6269]. A 685 configuration parameter should be supported to enable/disable the 686 logging function. 688 6. IANA Considerations 690 This document does not request any action from IANA. 692 7. Security Considerations 694 MPTCP-related security threats are discussed in [RFC6181] and 695 [RFC6824]. Additional considerations are discussed in the following 696 sub-sections. 698 7.1. Privacy 700 The MCP may have access to privacy-related information (e.g., IMSI, 701 link identifier, subscriber credentials, etc.). The MCP MUST NOT 702 leak such sensitive information outside a local domain. 704 7.2. Denial-of-Service (DoS) 706 Means to protect the MCP against Denial-of-Service (DoS) attacks MUST 707 be enabled. Such means include the enforcement of ingress filtering 708 policies at the network boundaries [RFC2827]. 710 In order to prevent the exhaustion of MCP's resources by establishing 711 a large number of simultaneous subflows for each MPTCP connection, 712 the MCP administrator SHOULD limit the number of allowed subflows per 713 CPE for a given connection. Means to protect against SYN flooding 714 attacks MUST also be enabled ([RFC4987]). 716 Attacks that originate outside of the domain can be prevented if 717 ingress filtering policies are enforced. Nevertheless, attacks from 718 within the network between a host and an MCP instance are yet another 719 actual threat. Means to ensure that illegitimate nodes cannot 720 connect to a network should be implemented. 722 7.3. Illegitimate MCP 724 Traffic theft is a risk if an illegitimate MCP is inserted in the 725 path. Indeed, inserting an illegitimate MCP in the forwarding path 726 allows traffic intercept and can therefore provide access to 727 sensitive data issued by or destined to a host. To mitigate this 728 threat, secure means to discover an MCP should be enabled. 730 7.4. High Rate Reassembly 732 The MCP may perform packet reassembly. Some security-related issues 733 are discussed in [RFC4963][RFC1858][RFC3128]. 735 8. Acknowledgements 737 Many thanks to Chi Dung Phung, Mingui Zhang, Rao Shoaib, Yoshifumi 738 Nishida, and Christoph Paasch for the comments. 740 Thanks to Ian Farrer, Mikael Abrahamsson, Alan Ford, Dan Wing, and 741 Sri Gundavelli for the fruitful discussions held during the IETF#95 742 meeting. 744 Special thanks to Pierrick Seite, Yannick Le Goff, Fred Klamm, and 745 Xavier Grall for their valuable comments. 747 Thanks also to Olaf Schleusing, Martin Gysi, Thomas Zasowski, Andreas 748 Burkhard, Silka Simmen, Sandro Berger, Michael Melloul, Jean-Yves 749 Flahaut, Adrien Desportes, Gregory Detal, Benjamin David, Arun 750 Srinivasan, and Raghavendra Mallya for the discussion. 752 9. References 754 9.1. Normative References 756 [I-D.boucadair-mptcp-plain-mode] 757 Boucadair, M., Jacquenet, C., Behaghel, D., 758 stefano.secci@lip6.fr, s., Henderickx, W., Skog, R., 759 Bonaventure, O., Vinapamula, S., Seo, S., Cloetens, W., 760 Meyer, U., and L. Contreras, "An MPTCP Option for Network- 761 Assisted MPTCP Deployments: Plain Transport Mode", draft- 762 boucadair-mptcp-plain-mode-08 (work in progress), July 763 2016. 765 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 766 Requirement Levels", BCP 14, RFC 2119, 767 DOI 10.17487/RFC2119, March 1997, 768 . 770 [RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, 771 "TCP Extensions for Multipath Operation with Multiple 772 Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013, 773 . 775 9.2. Informative References 777 [I-D.boucadair-mptcp-dhc] 778 Boucadair, M., Jacquenet, C., and T. Reddy, "DHCP Options 779 for Network-Assisted Multipath TCP (MPTCP)", draft- 780 boucadair-mptcp-dhc-06 (work in progress), October 2016. 782 [I-D.boucadair-mptcp-radius] 783 Boucadair, M. and C. Jacquenet, "RADIUS Extensions for 784 Network-Assisted Multipath TCP (MPTCP)", draft-boucadair- 785 mptcp-radius-03 (work in progress), October 2016. 787 [RFC1413] St. Johns, M., "Identification Protocol", RFC 1413, 788 DOI 10.17487/RFC1413, February 1993, 789 . 791 [RFC1858] Ziemba, G., Reed, D., and P. Traina, "Security 792 Considerations for IP Fragment Filtering", RFC 1858, 793 DOI 10.17487/RFC1858, October 1995, 794 . 796 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 797 Defeating Denial of Service Attacks which employ IP Source 798 Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, 799 May 2000, . 801 [RFC3128] Miller, I., "Protection Against a Variant of the Tiny 802 Fragment Attack (RFC 1858)", RFC 3128, 803 DOI 10.17487/RFC3128, June 2001, 804 . 806 [RFC4963] Heffner, J., Mathis, M., and B. Chandler, "IPv4 Reassembly 807 Errors at High Data Rates", RFC 4963, 808 DOI 10.17487/RFC4963, July 2007, 809 . 811 [RFC4987] Eddy, W., "TCP SYN Flooding Attacks and Common 812 Mitigations", RFC 4987, DOI 10.17487/RFC4987, August 2007, 813 . 815 [RFC6181] Bagnulo, M., "Threat Analysis for TCP Extensions for 816 Multipath Operation with Multiple Addresses", RFC 6181, 817 DOI 10.17487/RFC6181, March 2011, 818 . 820 [RFC6269] Ford, M., Ed., Boucadair, M., Durand, A., Levis, P., and 821 P. Roberts, "Issues with IP Address Sharing", RFC 6269, 822 DOI 10.17487/RFC6269, June 2011, 823 . 825 [RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix 826 Translation", RFC 6296, DOI 10.17487/RFC6296, June 2011, 827 . 829 [RFC6888] Perreault, S., Ed., Yamagata, I., Miyakawa, S., Nakagawa, 830 A., and H. Ashida, "Common Requirements for Carrier-Grade 831 NATs (CGNs)", BCP 127, RFC 6888, DOI 10.17487/RFC6888, 832 April 2013, . 834 Authors' Addresses 836 Mohamed Boucadair (editor) 837 Orange 838 Rennes 35000 839 France 841 Email: mohamed.boucadair@orange.com 842 Christian Jacquenet (editor) 843 Orange 844 Rennes 845 France 847 Email: christian.jacquenet@orange.com 849 Olivier Bonaventure (editor) 850 Tessares 851 Belgium 853 Email: olivier.bonaventure@tessares.net 855 Denis Behaghel 856 OneAccess 858 Email: Denis.Behaghel@oneaccess-net.com 860 Stefano Secci 861 Universite Pierre et Marie Curie 862 Paris 863 France 865 Email: stefano.secci@lip6.fr 867 Wim Henderickx (editor) 868 Nokia/Alcatel-Lucent 869 Belgium 871 Email: wim.henderickx@alcatel-lucent.com 873 Robert Skog (editor) 874 Ericsson 876 Email: robert.skog@ericsson.com 877 Suresh Vinapamula 878 Juniper 879 1137 Innovation Way 880 Sunnyvale, CA 94089 881 USA 883 Email: Sureshk@juniper.net 885 SungHoon Seo 886 Korea Telecom 887 Seoul 888 Korea 890 Email: sh.seo@kt.com 892 Wouter Cloetens 893 SoftAtHome 894 Vaartdijk 3 701 895 3018 Wijgmaal 896 Belgium 898 Email: wouter.cloetens@softathome.com 900 Ullrich Meyer 901 Vodafone 902 Germany 904 Email: ullrich.meyer@vodafone.com 906 Luis M. Contreras 907 Telefonica 908 Spain 910 Email: luismiguel.contrerasmurillo@telefonica.com 912 Bart Peirens 913 Proximus 915 Email: bart.peirens@proximus.com