idnits 2.17.1 draft-peirens-mptcp-transparent-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 : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 167: '...bonding solution MUST support IPv6 and...' RFC 2119 keyword, line 169: '...bonding solution SHOULD minimize the a...' RFC 2119 keyword, line 172: '...bonding solution MUST not expose multi...' RFC 2119 keyword, line 173: '... the same address MUST be used for all...' RFC 2119 keyword, line 176: '...bonding solution MUST not use more tha...' (6 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: o Req3: the bonding solution MUST not expose multiple addresses for a given customer and the same address MUST be used for all transport protocols used by each customer == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: o Req4 : the bonding solution MUST not use more than one public IPv4 address per customer == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: o Req9: the bonding solution SHOULD not change the subscriber service attachment and authentication point in the network. -- The document date (July 05, 2016) is 2849 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 6824 (Obsoleted by RFC 8684) == Outdated reference: A later version (-08) exists of draft-boucadair-mptcp-dhc-05 == Outdated reference: A later version (-10) exists of draft-boucadair-mptcp-plain-mode-08 == Outdated reference: A later version (-05) exists of draft-boucadair-mptcp-radius-01 == Outdated reference: A later version (-03) exists of draft-zhang-banana-problem-statement-02 == Outdated reference: A later version (-05) exists of draft-zhang-gre-tunnel-bonding-03 Summary: 2 errors (**), 0 flaws (~~), 9 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MPTCP Working Group B. Peirens 3 Internet-Draft Proximus 4 Intended status: Informational G. Detal 5 Expires: January 6, 2017 S. Barre 6 O. Bonaventure 7 Tessares 8 July 05, 2016 10 Link bonding with transparent Multipath TCP 11 draft-peirens-mptcp-transparent-00 13 Abstract 15 This document describes the utilisation of the transparent Multipath 16 TCP mode to enable network operators to provide link bonding services 17 in hybrid access networks. 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 January 6, 2017. 36 Copyright Notice 38 Copyright (c) 2016 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. Reference architecture . . . . . . . . . . . . . . . . . . . . 4 55 3. Operator requirements . . . . . . . . . . . . . . . . . . . . 6 56 4. Existing solutions . . . . . . . . . . . . . . . . . . . . . . 8 57 4.1. Datalink solutions for hybrid access networks . . . . . . 8 58 4.2. Network layer solutions for hybrid access networks . . . . 8 59 4.3. Transport layer solutions . . . . . . . . . . . . . . . . 9 60 4.4. Application layer solutions . . . . . . . . . . . . . . . 9 61 5. The transparent MPTCP mode . . . . . . . . . . . . . . . . . . 11 62 6. Security considerations . . . . . . . . . . . . . . . . . . . 15 63 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 64 8. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 17 65 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 66 9.1. Normative References . . . . . . . . . . . . . . . . . . . 18 67 9.2. Informative References . . . . . . . . . . . . . . . . . . 18 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 70 1. Introduction 72 Internet Service Provider networks are composed of different parts : 73 access networks, metropolitan and wide area networks. Given the 74 growing demand for bandwidth, these networks must evolve. In the 75 metropolitan and wide area parts, bandwidth increases thanks to the 76 utilisation of optical fiber or through link aggregation. Increasing 77 bandwidth in the core is not sufficient to allow all users to benefit 78 from faster services. For many operators, the last-mile of the 79 access network remains a bottleneck that is difficult to upgrade. 81 Many service providers do not rely on a single access network 82 technology. They often have deployed different access networks that 83 were initially targeted at different types of users and customers. 84 Such access networks include xDSL, DOCSIS, FTTx and various wireless 85 technologies (3G, 4G, Wimax, satellite, 5G, ...). With these 86 different access networks, service providers have different ways to 87 reach their customers and combining two access networks would enable 88 them to deliver higher bandwidth services to their customers 89 [I-D.zhang-banana-problem-statement]. 91 In this document, we first describe in section Section 2 the hybrid 92 access networks that are being deployed by various network operators. 93 We focus on the aggregation of a fixed network (e.g. xDSL) with a 94 cellular network (e.g. LTE). Many operators wish to use the 95 bandwidth that is not consumed by the mobile devices on their 96 cellular network to deliver better services to their fixed line 97 customers. Section Section 3 lists the main requirements expressed 98 by these operators. Section Section 4 briefly evaluates whether the 99 main proposed bonding techniques meet those requirements. We then 100 describe in section Section 5 how a transparent mode of operation for 101 Multipath TCP [RFC6824] can be used to meet those operator 102 requirements. 104 2. Reference architecture 106 Our reference architecture is shown in figure Figure 1. We use a 107 similar terminology as in [WT-348] and consider the following 108 elements : 110 o a single homed end host H that is attached through one interface 111 (e.g. WiFi) to a Hybrid Customer Premisses Equipment (HCPE) 113 o a Hybrid Customer Premises Equipment (HCPE) that is connected to 114 two different access networks. The solution proposed in this 115 document support any number of access networks, but we restrict 116 our examples to two. 118 o A Hybrid Aggregation Gateway (HAG) that is reachable over both 119 access networks 121 o a regular server, S 123 ___________ 124 / \ 125 +---| access net 2 |-+ 126 | \____________/ | 127 | _____|___ 128 +-+ +--+--+ / \ +---+ +-+ 129 |H|----|HCPE | | Backbone +--|HAG|-/.../--|S| 130 +-+ +--+--+ \_________/ +---+ +-+ 131 | | 132 | ___________ | 133 | / \ | 134 +--| access net 1|---+ 135 \___________/ 137 Figure 1: Hybrid access networks 139 We assume that IP addresses are assigned according to the best 140 current practices, i.e. host H is allocated one IP address, and one 141 IP address is assigned to each interface of the HCPE. Furthermore, 142 BCP 38 [RFC2827] is used on the two access networks attached to the 143 HCPE. The solution proposed in this document is agnostic of the IP 144 version that is used. It operates equally well with both IPv4 and 145 IPv6 and can use any mix of IPv4/IPv6. When writing IP addresses, we 146 use the @ notation. For example, H@ is the IP address assigned to 147 host H, HCPE@1 is the IP address assigned to the HCPE on access 148 network 1,... For most network operators, the different access 149 networks that need to be aggregated are not equivalent. One network, 150 typically a fixed access network managed by the operator, is 151 considered to be the main access network. The other access network, 152 possibly managed by another network operator, is used to provide 153 additional capacity to cope with bandwidth limitations on the primary 154 access network. We focus on this bandwidth aggregation scenario in 155 this document. While the second access network can also be used in 156 case of failure of the primary access network we currently leave it 157 out of scope of the solution (existing solutions are already deployed 158 by operators for this). 160 3. Operator requirements 162 Many operators have expressed their interest in efficiently 163 supporting hybrid access networks. We list here some of the 164 requirements that they have identified and have guided the design of 165 the proposed solution. 167 o Req1: the bonding solution MUST support IPv6 and IPv4 169 o Req2: the bonding solution SHOULD minimize the additional delay 170 that it introduces in the network 172 o Req3: the bonding solution MUST not expose multiple addresses for 173 a given customer and the same address MUST be used for all 174 transport protocols used by each customer 176 o Req4 : the bonding solution MUST not use more than one public IPv4 177 address per customer 179 o Req5 : the bonding solution SHOULD enable the operator to trace 180 the connections created by a given customer 182 o Req6 : the bonding solution MUST monitor the quality of the 183 different links and adapt the load distribution dynamically 184 according to the load and the operator's policies 186 o Req7 : the bonding solution MUST be decoupled from the underlying 187 fixed/mobile access network 189 o Req8: the bonding solution MUST be able to efficiently load- 190 balance the packets belonging to a single TCP connection over 191 several access networks 193 o Req9: the bonding solution SHOULD not change the subscriber 194 service attachment and authentication point in the network. 196 The second requirement reflects the importance of minimising the 197 latency. Many applications, including HTTP, are affected by any 198 increased latency. The third requirement reflects operational 199 issues. Many applications expect that all the flows originated by a 200 host will have the same source address, independently of the protocol 201 used for each flow. A solution that would use different addresses 202 for different transport protocols or for flows that do not benefit 203 from hybrid access (e.g. by defined policy), would cause operational 204 problems. The fifth requirement reflects the desire of the network 205 operator to have some visibility of the flows that pass through its 206 access network in order to apply filtering rules, log flows or 207 provide QoS. The sixth requirement reflects the fact that the 208 bandwidth of the access networks that are aggregated can vary 209 quickly. This is particularly the case for cellular networks where 210 mobile devices could have priority over the bonding service. The 211 last two requirements correspond to the utilisation of large TCP 212 flows. Measurement studies in access networks show that TCP is the 213 dominant protocol in these networks and that most of the data volume 214 is carried by long TCP connections. Such connections must be load- 215 balanced on a per packet basis to achieve a good aggregation. 217 4. Existing solutions 219 In this document, we focus on solutions that can combine very 220 different access network technologies, typically a fixed line access 221 network such as xDSL and a wireless access network such as LTE. We 222 discuss only some of the proposed techniques. A complete overview of 223 all the available solutions is outside the scope of this document. 225 4.1. Datalink solutions for hybrid access networks 227 Some datalink technologies, such as Multilink PPP [RFC1990], can load 228 balance packets over different links. Unfortunately, they cannot 229 easily be used in hybrid access networks that rely on different types 230 of datalinks. 232 4.2. Network layer solutions for hybrid access networks 234 Various solutions exist in the network layer. A first possibility is 235 to assign the same address to the HCPE (and thus the hosts behind it) 236 over the different access networks. This requires a specific 237 configuration of the routing in the access network and some network 238 operators have deployed such solutions. Per-flow and per-packet load 239 balancing are possible with this approach. Unfortunately, it has a 240 number of important drawbacks : 242 o it is difficult for the HAG/HCPE to measure the performance of the 243 different access networks in to adjust their utilisation in 244 realtime (Req6) 246 o assigning the same address to the HCPE over different networks 247 requires integration on the subscriber attachment points for both 248 the fixed and mobile network (e.g. BNG & P-GW) for the bonding 249 solution which might not be desirable (Req7) 251 o if packets from a transport connection are spread over different 252 access networks, they experience different delays and different 253 levels of congestion, but the transport protocol is unaware of 254 those different networks. The net result is a lower throughput 255 since the congestion control scheme adapts the throughput to the 256 access network offering the lowest performance (Req8). 258 An alternative to assigning the same IP addresses on the different 259 access networks is to use tunnels between the HCPE and the HAG. 260 Various types of IP tunnels are possible [RFC2784] 261 [I-D.zhang-gre-tunnel-bonding]. With such tunnels, the problems 262 mentioned above remain and the tunneling protocol adds a per-packet 263 overhead which may be significant in some environments. Extensions 264 have been recently proposed to include flow control mechanisms in 265 some of these tunneling techniques 266 [I-D.zhang-banana-tcp-in-bonding-tunnels] but this increases the 267 complexity of the solution. Tunnel based solutions assign the 268 external exposed customer address within the tunnel and change the 269 subscriber service attachment point (Req9) which forces operators to 270 re-implement authentication, logging and service definitions at a 271 different location than the non-hybrid access customers. See also 272 concerns listed in the next section {#transport}. 274 4.3. Transport layer solutions 276 The Multipath TCP plain mode option [I-D.boucadair-mptcp-plain-mode] 277 was recently proposed as a solution to cope with some of the above 278 problems of the network layer solutions. This solution is an 279 extension of the TCP option proposed in [HotMiddlebox13b]. With the 280 plain mode option, the HAG maintains a pool of public addresses that 281 are used to translate the client addresses. From an addressing 282 viewpoint, this is equivalent to the deployment of a carrier-grade 283 NAT which leads to operational problems for the management of access- 284 lists that are used to provide QoS, firewalling, but also for the 285 collection of meta data about customer traffic, logs, ... With 286 [I-D.boucadair-mptcp-plain-mode], all the TCP traffic in the access 287 networks appears to be destined to the HAG. 289 While the Multipath TCP plain mode optionally allows transparency of 290 the source address by using the option a second time with D-bit set 291 to zero, it would require subscriber session information from the 292 network element that assigned the now embedded source address to 293 correctly implement BCP-38 [RFC2827] validation when restoring this 294 at the HAG. 296 4.4. Application layer solutions 298 The SOCKS protocol [RFC1928] was designed to enable clients behind a 299 firewall to establish TCP connections through a TCP proxy running on 300 the firewall. A possible deployment in hybrid access networks is to 301 use the HAG as a SOCKS server over Multipath TCP to benefit from its 302 aggregation capabilities. Since regular hosts usually do not use a 303 SOCKS client and do not support Multipath TCP, the HCPE needs to act 304 as a transparent TCP/Multipath-TCP+SOCK proxy. 306 Compared with the network layer solutions and 307 [I-D.boucadair-mptcp-plain-mode], the SOCKS approach has several 308 drawbacks from an operational viewpoint : 310 o the HAG must maintain a pool of public addresses 311 o to establish a TCP connection through a SOCKS server running on 312 the HAG, the HCPE must first perform the three-way handshake and 313 then exchange SOCKS messages to authenticate the client (the 314 number of messages is function of the SOCKS authentication scheme 315 that is used). This increases the establishment time for each TCP 316 connection by one or more additional round-trip times (Req2). 318 5. The transparent MPTCP mode 320 The transparent MPTCP mode proposed in this documented was designed 321 under the assumption that in many hybrid access networks, there is a 322 primary access network and the other access network(s) that are 323 combined are used to (virtually) increase the capacity of the primary 324 access network. In such networks, operators usually expect that the 325 secondary access networks will only be used if the primary access 326 networks does not have sufficient capacity to handle the load. 328 The solution is targeted at TCP traffic only. Non TCP traffic is 329 sent over the primary access network. Support for other transport 330 protocols over the secondary access networks is outside the scope of 331 this document. 333 ____________ _________ 334 / \ / \ +-+ 335 +---| access net 2 |----| backbone |---|S| 336 | \____________/ \_________/ +-+ 337 | | 338 +-+ +--+--+ +-+-+ 339 |H|----|HCPE | +--------|HAG| 340 +-+ +--+--+ | +---+ 341 | | 342 | ___________ | 343 | / \ | 344 +--| access net 1|---+ 345 \___________/ 347 Figure 2: Reference architecture 349 We consider the network environment shown in figure Figure 2. Access 350 net 1 is the primary network. This figure reflects the specific 351 network configuration that is required for the transparent Multipath 352 TCP mode. The HAG MUST reside on the path followed by the packets 353 sent to/from the HCPE that it serves. This can be achieved, by e.g. 354 using a specific mobile APN that has restricted routing, using 355 service chaining at BNG/BRAS, using specific BNG/BRAS domains or AAA/ 356 RADIUS triggered policy routing at BNG/BRAS. Several vendors have 357 implemented such solutions and they are deployed in various networks. 359 A HAG typically serves a group of HCPEs and several HAGs can be 360 deployed by an operator. Note that the requirement of placing the 361 HAG on the path of the HCPE that it serves only applies to the 362 primary access network. The other access networks only need to be 363 able to reach the HAG. They do not need direct Internet access. 365 The HCPE has two IP addresses (or IP prefixes in the case of IPv6 366 prefix delegation) : HCPE@1 and HCPE@2. HCPE@1 is the primary 367 address prefix assigned to the HCPE and host H uses one address from 368 this prefix as its public address when contacting remote servers (we 369 assume IPv6 in this description. With IPv4, the HCPE will assign a 370 private IPv4 address to the hosts that it serves and will perform 371 NAT). The HAG has one IP address that is reachable from the 372 secondary network, identified as HAG@2. This is illustrated by the 373 vertical link on the HAG in Figure 2. 375 Both the HCPE and the HAG include a transparent Multipath-TCP/TCP 376 proxy. Various forms of TCP proxies have been defined and are 377 deployed [RFC3135]. The HCPE uses its TCP/Multipath TCP proxy to 378 convert the regular TCP connections initiated by the client host, H, 379 into Multipath TCP connections towards the distant server. However, 380 these Multipath TCP connections do not directly reach the distant 381 server. They are converted into regular TCP connections by the 382 Multipath-TCP/TCP proxy running on the HAG. This is illustrated in 383 figure Figure 3. 385 +-+ +-----+ +---+ +-+ 386 |H| |HCPE | |HAG| |S| 387 +-+ +-----+ +---+ +-+ 388 | | | | 389 |<--TCP---->|<=======MPTCP=====>|<--TCP-->| 390 | | | | 392 Figure 3: The TCP<->Multipath TCP proxies used on the HCPE and the 393 HAG 395 H HCPE HAG S 396 @1 @2 @1 @2 397 | | | | | | 398 --SYN(1)-> 399 --------SYN+MPC(2)-----------> 400 --------SYN(3)------> 401 <------SYN+ACK(4)---- 402 <-----SYN+ACK+MPC(5)---------- 403 <-SYN+ -- 404 ACK(6) 406 Figure 4: Creation of the initial subflow with the transparent mode 408 The operation of the transparent mode is illustrated in figure 409 Figure 4. We consider the establishment of one TCP connection from 410 host H (using address H@) to a distant server, S@. The following 411 packets are exchanged : 413 o (1) H sends a SYN towards S@. 415 o (2) The HCPE intercepts the SYN of the initial handshake. It 416 creates some state for a regular TCP connection between H@ and 417 itself acting as a transparent proxy for S@ and a Multipath TCP 418 connection towards S@. These two connections are linked together 419 and any data received over one connection is forwarded over the 420 other. The HCPE then sends a SYN with the MP_CAPABLE option 421 towards S@ over its primary access network to create a Multipath 422 TCP connection to the HAG. Over the primary access network, this 423 SYN appears as originating from H@ and being sent to S@. 425 o (3) The HAG acts as a transparent proxy for S@ and intercepts the 426 SYN that contains the MP_CAPABLE option. It creates some state 427 for this Multipath TCP connection and initiates a regular TCP 428 connection towards S@. It should be noted that neither the HCPE 429 nor the HAG perform address translation. The distant server 430 receives the SYN from the client as originating from address H@. 432 o (4) The server replies with a SYN+ACK to confirm the establishment 433 of the connection. 435 o (5) The HAG intercepts the returning SYN+ACK. The HAG then sends 436 a SYN+ACK with the MP_CAPABLE option to confirm the establishment 437 of the Multipath TCP connection that is proxied by the HCPE. 439 o (6) The HCPE sends a SYN+ACK to the client host to confirm the 440 establishment of the regular TCP connection 442 At this point, the establishment of the three connections can be 443 finalised by sending a third ACK. Data can be exchanged by the 444 client and the server through the proxied connections. 446 The end-to-end connection between the client host (H) and the server 447 (S) is composed of three TCP connections : a regular TCP connection 448 between the host and the HCPE, a Multipath TCP connection between the 449 HCPE and the HAG and a regular TCP connection between the HAG and the 450 remote server. All the packets sent on these three connections 451 contain the H@ and S@ addresses in their IP header. 453 To use another access network, the HAG simply advertises its address 454 reachable through this access network (HAG@2) on the initial subflow 455 by sending an ADD_ADDR option (1). This triggers the establishment 456 of an additional subflow from the HCPE over the second access network 457 (arrows (2), (3) and (4) in figure Figure 5). The endpoints of this 458 subflow are the IP address of the HCPE on the second access network, 459 i.e. HCPE@2, and the IP address of the HAG, i.e. HAG@2. Note that 460 the ADD_ADDR option shown in figure Figure 5 is optional. If the 461 HCPE already knows, e.g. by configuration or through mechanisms such 462 as [I-D.boucadair-mptcp-radius] or [I-D.boucadair-mptcp-dhc], the IP 463 address of the HAG, it can crate the additional subflow without 464 waiting for the ADD_ADDR option. 466 H HCPE HAG S 467 @1 @2 @1 @2 468 | | | | | | 469 | | | | | | 470 <------ADD_ADDR(1)------------- 471 ------SYN+MP_JOIN(2)----------> 472 <-----SYN+ACK+MPJOIN(3)-------- 473 -------ACK+MP_JOIN(4)----------> 475 Figure 5: Creation of the second subflow by the HCPE with the 476 transparent MPTCP mode 478 At this point, any data received from the host by the HCPE or from 479 the server by the HAG can be transported over any of the established 480 subflows. Both the HAG and the HCPE select the most appropriate 481 subflow based on their policies and the current network conditions 482 that are automatically measured by Multipath TCP. 484 This is not the only way to create additional subflows. The HAG may 485 also create additional subflows. This is illustrated in figure 486 Figure 6 where we assume that the HAG already knows the IP address of 487 the HCPE and thus does not wait for the reception of an ADD_ADDR 488 option from the HCPE to create the additional subflow. 490 H HCPE HAG S 491 @1 @2 @1 @2 492 | | | | | | 493 | | | | | | 494 <------SYN+MP(1)----------------- 495 -----SYN+ACK+MPJOIN(2)----------> 496 <-------ACK+MP_JOIN(3)----------- 498 Figure 6: Creation of the second subflow by the HAG with the 499 transparent MPTCP mode 501 6. Security considerations 503 Providing a bonding service through different access networks 504 introduces new capabilities, but also new threats to the network. We 505 focus in this section on the threats that are specific to the bonding 506 service and assume that the CPE devices implement the recommendations 507 listed in [RFC6092]. For the HAG, since it operates on the path like 508 a router, many of the the security considerations for routers apply. 510 When Multipath TCP is used over different paths, the security threats 511 listed in [RFC6181] and [RFC7430] need to be considered. Some of 512 these can be mitigated through proper configuration of the HCPEs, 513 HAGs and access networks. 515 An important security threat with Multipath TCP is if an attacker 516 were able to inject data on an existing Multipath TCP by associating 517 an additional subflow. Such an attack is already covered by the 518 utilisation of keys in the Multipath TCP handshake. Thanks to the 519 utilisation of the tokens and the HMAC in the MP_JOIN option, the HAG 520 and the HCPE will refuse additional subflows created by an attacker 521 who did not observe the initial SYN packets. Note that since the 522 keys are only exchanged on the first access network, this attacker 523 would have to reside on this access network. 525 Since the HAG and the HCPE only create subflows among themselves, it 526 is possible for an operator to configure those devices to only accept 527 SYN packets with the MP_CAPABLE or MP_JOIN option to those prefixes. 528 Furthermore, the second access network does not need to be connected 529 to the Internet. This implies that an attacker would need to reside 530 on this network to send packets towards the visible address of the 531 HAG. Ingress filtering and uRPF should be deployed on the access 532 networks to prevent spoofing attacks. 534 If TCP connections originating from the Internet are accepted on the 535 HCPEs, then the HAG must be secured against denial of service attacks 536 since it will be involved in the processing of all incoming SYN 537 packets. 539 7. IANA Considerations 541 There are no IANA considerations in this document. 543 8. Conclusion 545 In this document, we have proposed the transparent mode for Multipath 546 TCP and described its utilisation in hybrid access networks where a 547 secondary access network is used to complement a primary access 548 network. Our solution leverages the flow and congestion control 549 capabilities of Multipath TCP to allow an efficient utilisation of 550 the different access networks, even if their capacity fluctuates. 552 Compared with network layer solutions such as 553 [I-D.zhang-gre-tunnel-bonding], the transparent mode does not 554 introduce any per-packet overhead and does not require any form of 555 network address translation. Compared with the plain mode Multipath 556 TCP proposed in [I-D.boucadair-mptcp-plain-mode], our solution does 557 not require any form of network address translation which has clear 558 operational benefits. 560 9. References 562 9.1. Normative References 564 [RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, 565 "TCP Extensions for Multipath Operation with Multiple 566 Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013, 567 . 569 9.2. Informative References 571 [HotMiddlebox13b] 572 Detal, G., Paasch, C., and O. Bonaventure, "Multipath in 573 the Middle(Box)", HotMiddlebox'13 , December 2013, . 576 [I-D.boucadair-mptcp-dhc] 577 Boucadair, M., Jacquenet, C., and T. Reddy, "DHCP Options 578 for Network-Assisted Multipath TCP (MPTCP)", 579 draft-boucadair-mptcp-dhc-05 (work in progress), May 2016. 581 [I-D.boucadair-mptcp-plain-mode] 582 Boucadair, M., Jacquenet, C., Behaghel, D., 583 stefano.secci@lip6.fr, s., Henderickx, W., Skog, R., 584 Bonaventure, O., Vinapamula, S., Seo, S., Cloetens, W., 585 Meyer, U., and L. Contreras, "An MPTCP Option for Network- 586 Assisted MPTCP Deployments: Plain Transport Mode", 587 draft-boucadair-mptcp-plain-mode-08 (work in progress), 588 July 2016. 590 [I-D.boucadair-mptcp-radius] 591 Boucadair, M. and C. Jacquenet, "RADIUS Extensions for 592 Network-Assisted Multipath TCP (MPTCP)", 593 draft-boucadair-mptcp-radius-01 (work in progress), 594 January 2016. 596 [I-D.zhang-banana-problem-statement] 597 Cullen, M., Leymann, N., Heidemann, C., Boucadair, M., 598 Hui, D., Zhang, M., and B. Sarikaya, "Problem Statement: 599 Bandwidth Aggregation for Internet Access", 600 draft-zhang-banana-problem-statement-02 (work in 601 progress), July 2016. 603 [I-D.zhang-banana-tcp-in-bonding-tunnels] 604 Zhang, M., Leymann, N., Heidemann, C., and M. Cullen, 605 "Flow Control for Bonding Tunnels", 606 draft-zhang-banana-tcp-in-bonding-tunnels-00 (work in 607 progress), March 2016. 609 [I-D.zhang-gre-tunnel-bonding] 610 Leymann, N., Heidemann, C., Zhang, M., Sarikaya, B., and 611 M. Cullen, "Huawei's GRE Tunnel Bonding Protocol", 612 draft-zhang-gre-tunnel-bonding-03 (work in progress), 613 May 2016. 615 [RFC1928] Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D., and 616 L. Jones, "SOCKS Protocol Version 5", RFC 1928, 617 DOI 10.17487/RFC1928, March 1996, 618 . 620 [RFC1990] Sklower, K., Lloyd, B., McGregor, G., Carr, D., and T. 621 Coradetti, "The PPP Multilink Protocol (MP)", RFC 1990, 622 DOI 10.17487/RFC1990, August 1996, 623 . 625 [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. 626 Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, 627 DOI 10.17487/RFC2784, March 2000, 628 . 630 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 631 Defeating Denial of Service Attacks which employ IP Source 632 Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, 633 May 2000, . 635 [RFC3135] Border, J., Kojo, M., Griner, J., Montenegro, G., and Z. 636 Shelby, "Performance Enhancing Proxies Intended to 637 Mitigate Link-Related Degradations", RFC 3135, 638 DOI 10.17487/RFC3135, June 2001, 639 . 641 [RFC6092] Woodyatt, J., Ed., "Recommended Simple Security 642 Capabilities in Customer Premises Equipment (CPE) for 643 Providing Residential IPv6 Internet Service", RFC 6092, 644 DOI 10.17487/RFC6092, January 2011, 645 . 647 [RFC6181] Bagnulo, M., "Threat Analysis for TCP Extensions for 648 Multipath Operation with Multiple Addresses", RFC 6181, 649 DOI 10.17487/RFC6181, March 2011, 650 . 652 [RFC7430] Bagnulo, M., Paasch, C., Gont, F., Bonaventure, O., and C. 653 Raiciu, "Analysis of Residual Threats and Possible Fixes 654 for Multipath TCP (MPTCP)", RFC 7430, DOI 10.17487/ 655 RFC7430, July 2015, 656 . 658 [WT-348] Broadband Forum, ., "Hybrid Access for Broadband Network", 659 2014, . 661 Authors' Addresses 663 Bart Peirens 664 Proximus 666 Email: bart.peirens@proximus.com 668 Gregory Detal 669 Tessares 671 Email: Gregory.Detal@tessares.net 673 Sebastien Barre 674 Tessares 676 Email: Sebastien.Barre@tessares.net 678 Olivier Bonaventure 679 Tessares 681 Email: Olivier.Bonaventure@tessares.net