idnits 2.17.1 draft-hampel-mptcp-proxies-anchors-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 an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 14 instances of too long lines in the document, the longest one being 2 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 8, 2012) is 4459 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Informational RFC: RFC 6182 (ref. '1') -- Duplicate reference: RFC6182, mentioned in '2', was also mentioned in '1'. ** Downref: Normative reference to an Informational RFC: RFC 6182 (ref. '2') ** Downref: Normative reference to an Informational RFC: RFC 4225 (ref. '3') ** Downref: Normative reference to an Informational RFC: RFC 6181 (ref. '4') Summary: 7 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Multipath TCP G. Hampel 3 Internet-Draft T. Klein 4 Intended status: Standards Track Alcatel-Lucent 5 Expires: August 11, 2012 February 8, 2012 7 MPTCP Proxies and Anchors 8 draft-hampel-mptcp-proxies-anchors-00 10 Abstract 12 MPTCP proxies and anchors are network-based functions, which support 13 MPTCP connections. The MPTCP proxy provides multipath support for 14 MPTCP-capable hosts on behalf of their MPTCP-unaware peers. This 15 facilitates incremental deployment of MPTCP. The MPTCP anchor 16 permits subflow establishment for MPTCP connections when direct 17 interaction between end hosts fails. This permits tolerance to local 18 IP protocol restrictions and it provides robustness in case of break- 19 before-make mobility events. MPTCP proxies and anchors are 20 especially suited for wireless access environments. 22 Status of this Memo 24 This Internet-Draft is submitted to IETF in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on August 11, 2012. 39 Copyright Notice 41 Copyright (c) 2012 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. MPTCP Network Functions . . . . . . . . . . . . . . . . . . . 4 58 2.1. MPTCP Proxy . . . . . . . . . . . . . . . . . . . . . . . 4 59 2.2. MPTCP Anchor . . . . . . . . . . . . . . . . . . . . . . . 4 60 2.3. Implicit vs. Explicit Proxies . . . . . . . . . . . . . . 5 61 2.4. Implicit vs. Explicit Anchors . . . . . . . . . . . . . . 5 62 2.5. End-Host Authentication . . . . . . . . . . . . . . . . . 6 63 3. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . 7 64 4. Operation with MPTCP Proxies . . . . . . . . . . . . . . . . . 8 65 4.1. Introduction of Implicit Proxy . . . . . . . . . . . . . . 8 66 4.2. Subflow Management with Implicit Proxy . . . . . . . . . . 11 67 4.3. Introduction of Explicit Proxy . . . . . . . . . . . . . . 12 68 4.4. Subflow Management with Explicit Proxy . . . . . . . . . . 15 69 5. Operation with MPTCP Anchors . . . . . . . . . . . . . . . . . 16 70 5.1. Introduction of Implicit Anchor . . . . . . . . . . . . . 16 71 5.2. Subflow Management with Implicit Anchor . . . . . . . . . 17 72 5.3. Introduction of Explicit Anchor . . . . . . . . . . . . . 19 73 5.4. Subflow Management with Explicit Anchor . . . . . . . . . 21 74 5.5. Protocol Translation with Anchor . . . . . . . . . . . . . 21 75 5.6. Connection Robustness with Anchor . . . . . . . . . . . . 22 76 6. Host Configuration . . . . . . . . . . . . . . . . . . . . . . 23 77 7. New Signaling . . . . . . . . . . . . . . . . . . . . . . . . 24 78 7.1. PROXY Flag . . . . . . . . . . . . . . . . . . . . . . . . 24 79 7.2. ANCHOR Flag . . . . . . . . . . . . . . . . . . . . . . . 24 80 7.3. JOIN Flag . . . . . . . . . . . . . . . . . . . . . . . . 25 81 7.4. Anchor-Reserved Address-Id Value . . . . . . . . . . . . . 26 82 7.5. SEEK_ADDR Option . . . . . . . . . . . . . . . . . . . . . 26 83 7.6. FWD_ADDR Option . . . . . . . . . . . . . . . . . . . . . 26 84 8. Security . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 85 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28 86 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30 89 1. Introduction 91 Currently, a host can enjoy the advantages of MPTCP only if its peer 92 supports MPTCP as well [1]. This requirement creates an impediment 93 to incremental deployment since the incentive for a host to upgrade 94 to MPTCP is small as long as its potential peers have not upgraded 95 too. 97 The incremental deployment problem especially applies to wireless 98 environments, where traffic is dominated by interactions between 99 mobile clients and network-side servers. While MPTCP can be rolled 100 out rather quickly on mobile devices due to their short life cycle 101 and frequent kernel upgrades, changes on application servers are 102 usually harder to conduct. Further, the benefit of MPTCP may be more 103 obvious to mobile users than to application service providers. 105 The incremental deployment problem can be overcome through the 106 introduction of the MPTCP proxy, which resides in the network and 107 provides MPTCP support for MPTCP-capable hosts (e.g. mobile devices) 108 on behalf of their MPTCP-unaware peers (e.g. application services). 110 Since MPTCP proxies will most likely be run by network operators 111 rather than application service providers they can support a 112 multitude of application services, which makes incremental deployment 113 of MPTCP rather efficient. Further, network operators may see a 114 benefit in MPTCP deployment since it adds value to the network 115 services they provide and since they mostly support a billing 116 mechanism to reimburse themselves from MPTCP operation. 118 The MPTCP anchor is another MPTCP network function whose main purpose 119 is to support end-to-end multipath connections. It operates as a 120 subflow relay to facilitate subflow establishment between end points 121 that do not enjoy direct reachability. This may happen, for 122 instance, if the end points pertain to different IP protocols or if 123 the hosts have lost end-to-end connectivity after a break-before-make 124 mobility event. 126 The anchor function is most beneficial for peer-to-peer applications 127 such as voice/video communciations, which are run on MPTCP-enabled 128 mobile or multi-homed devices. Flexibility in IP protocol support is 129 important for this use case during the rollout of IPv6. The anchor 130 function further allows the network operator to provide 131 differentiated services for over-the-top applications. 133 This document discusses relevant features and signaling enhancements 134 needed for the support of MPTCP proxies and MPTCP anchors. 136 2. MPTCP Network Functions 138 All network-based functions that interact with MPTCP connections 139 through MPTCP signaling are referred to as "MPTCP network functions". 140 MPTCP network functions are assumed to reside on "MPTCP network 141 nodes". We consider two types of MPTCP network functions namely the 142 MPTCP proxy and the MPTCP anchor. Anchor- and proxy functions can be 143 collocated on one MPTCP network node. 145 2.1. MPTCP Proxy 147 The MPTCP proxy supports MPTCP on behalf of an MPTCP-unaware host. 148 It splits the connection between multipath-capable and multipath- 149 unaware host into a MPTCP section and a TCP section, respectively 150 (Figure 1). All subflows established by the multipath-capable host 151 terminate at the proxy. 153 Proxy operation is discussed in Section 4. 155 ______ MPTCP TCP ______ 156 | | | | 157 | |-----------\ ________ | | 158 | | \ | | | | 159 | Host |-------------+| Proxy |---------------| Host | 160 | | / |________| | | 161 | |-----------/ | | 162 |______| |______| 164 Split connection with MPTCP Proxy 166 Figure 1 168 2.2. MPTCP Anchor 170 The MPTCP anchor provides a network-based access point (i.e. IP 171 address), which a MPTCP host can use to create additional subflows to 172 the peer. The anchor relays all packets arriving from this host to 173 the peer and vice versa. This creates a split subflow consistent of 174 one section between host and anchor and the other between anchor and 175 peer (Figure 2). The anchor's operation involves address- and 176 eventually also port translation. Anchors can also insert or modify 177 MPTCP options of passing or relayed packets. 179 Anchor addresses can be introduced during connection establishment or 180 at any later point in time. Anchor functions can be invoked or 181 released during the entire lifetime of the connection. 183 An anchor function can interconnect end points using different IP 184 protocol versions with a subflow. In this case the anchor operates 185 as an IP protocol translator (Section 5.5). The anchor also serves 186 as a "meeting point" for the establishment of a new subflows when all 187 other subflows have failed and direct end-to-end subflow 188 establishment is not possible. This applies to scenarios where both 189 end hosts have simultaneously moved or when one host moves while the 190 other resides behind a firewall (Section 5.6). 192 Anchor operation is discussed in Section 5. 194 ______ ______ 195 | | SFL_0 ________ SFL_0 | | 196 | |------------\ | | /-------------| | 197 | | SFL_1 +| Anchor |+ SFL_1 | | 198 | Host |------------/ |________| \-------------| Host | 199 | | SFl_2 SFL_2 | | 200 | |---------------------------------------| | 201 |______| |______| 203 MPTCP connection with Anchor 205 Figure 2 207 2.3. Implicit vs. Explicit Proxies 209 An implicit proxy resides on the direct routing path between two 210 hosts engaging into a connection. This allows the hosts to establish 211 the connection directly with each other, while the proxy can derive 212 all information via packet inspection, insert and modify packets as 213 necessary and thereby create the MPTCP-TCP split connection. This 214 proxy is referred to as "implicit" since not explicit signaling is 215 necessary. 217 When the proxy does *not* reside on the direct routing path between 218 both hosts, explicit signaling is needed to introduce the proxy to 219 the connection. The same applies to a proxy that does not reside on 220 the path used for connection initiation. Such a proxy is referred to 221 as "explicit" proxy. 223 An implicit proxy typically resides on a central router in the access 224 network used by one of the hosts during connection establishment. An 225 explicit proxy can reside in any network. 227 2.4. Implicit vs. Explicit Anchors 229 The terms "implicit" and "explicit" can also be defined for anchors. 231 An implicit anchor resides on the routing path used by a subflow of a 232 MPTCP connection. This allows the anchor to derive all necessary 233 connection-related information via packet inspection during the 234 establishment of this subflow. Then, it can insert and modify 235 packets as necessary and thereby offer anchor services to the end 236 hosts. 238 When an implicit anchor resides on the initial subflow, it can offer 239 services to *both* end hosts. Otherwise, it can offer services only 240 to the subflow-initiating end host (see Section 5). 242 When the anchor does not reside on a direct routing path between both 243 connection end points, explicit signaling is needed to introduce the 244 anchor to the connection. Such an anchor is referred to as 245 "explicit" anchor. 247 Anchors can support connections between two hosts as well as between 248 a host and a MPTCP proxy. Usually, anchors are more beneficial in 249 the former of the two scenarios. 251 2.5. End-Host Authentication 253 MPTCP proxies and anchors should support an explicit or implicit 254 mechanism to authenticate one of the connection's end hosts. This 255 allows the proxy- or anchor operator to charge for operation of the 256 respective MPTCP network function. There are also security reasons 257 that require end-host authentication as outlined in Section 8. 259 3. Deployment Scenarios 261 The predominant use case for MPTCP proxies and MPTCP anchors is seen 262 in wireless access networks. This is motivated by the increasing 263 number of wireless devices that support multiple access technologies 264 as well as multi-homing. 266 In one deployment scenario, the MPTCP network function resides on a 267 central router of a wireless access network, e.g. a 3G/4G mobile 268 network. Especially 3G and 4G mobile network operators may see an 269 incentive for MPTCP proxy support since it allows them to dynamically 270 offload traffic from licensed to unlicensed spectrum. Further, 3G- 271 and 4G mobile networks already provide a centralized architecture, 272 security support and charging functions, which can be used for MPTCP 273 proxy or anchor operation. 275 There are also technical reasons to place MPTCP proxies inside 276 cellular networks which are related to the wide-area coverage these 277 networks typically provide. Therefore, the connection can be 278 established via the cellular interface and subsequently migrated to 279 other paths and networks. This substantially simplifies signaling 280 since an implicit proxy/anchor can be used. Further, the cellular 281 network can be used for reachability. 283 It is expected that anchor- and proxy functions are collocated. 285 For any deployment scenario, MPTCP-capable hosts need to be 286 configured appropriately so that they can take advantage of implicit 287 and explicit MPTCP network functions. Some aspects of host 288 configuration are discussed in Section 6. 290 4. Operation with MPTCP Proxies 292 Proxies must be introduced to the connection during connection 293 establishment and stay engaged during the entire lifetime of the 294 connection. 296 4.1. Introduction of Implicit Proxy 298 MPTCP TCP 299 ______ ________ ______ 300 | | | | | | 301 | Host | IP_A0 |Implicit| IP_B0 | Host | 302 | A |--|--------|--| Proxy |--|---------|--| B | 303 |______| SFL_0 |________| |______| 304 | | 305 _|_ _|_ 306 |\ IP_A1 /| IP_PROX 307 | \ / | 308 | \----------------/ | 309 | SFL_1 | 310 | | 311 \----------------------/ 312 SFL_2 314 MPTCP-TCP split connection with implicit MPTCP proxy 316 Figure 3 318 The MPTCP-capable host starts a MPTCP connection by sending a TCP SYN 319 packet with MP_CAPABLE option to its peer. The proxy inspects the 320 packet and caches the end point locators consistent of IP addresses 321 and port numbers as well as the key enclosed in the MP_CAPABLE 322 option. Based on these locators, the proxy identifies and intercepts 323 the peer's SYN-ACK response packet. The implicit proxy does not 324 change the locators contained on the packet. 326 In case the SYN-ACK response does not hold the MP_CAPABLE option, the 327 proxy initiates multipath support. It creates a key on behalf of the 328 peer, inserts a MP_CAPABLE option with this key into the SYN-ACK 329 packet, and then forwards the packet to the connection-initiating 330 host. 332 If the SYN-ACK response *does* contain an MP_CAPABLE option, the 333 proxy is not needed. In this case, the network node can provide 334 anchor functionality (see Section 5). 336 MPTCP MPTCP MPTCP TCP 337 HOST NETWORK NODE NETWORK NODE HOST 339 | | | | 340 | SYN + MP_CAPABLE | | | 341 | ----------------+--------------------+------------------->| 342 | | | | 343 | | add MP_CAPAPBLE_ | | 344 | | \| SYN-ACK | 345 |<-------------------+--------------------X--------------- | 346 | | | | 347 | | PROXY | 348 | | P | 349 | ACK + MP_CAPABLE | P | 350 | ----------------+--------------------+------------------->| 351 | | P | 352 | | P | 354 Connection initiation by MPTCP-capable host with implicit proxies on 355 initial path 357 Figure 4 359 If multiple implicit proxies reside on the initial path, the proxy 360 closest to the peer should become the MPTCP end point. Since this 361 proxy is the first to receive the peer's SYN-ACK packet, it 362 automatically assumes multipath support by inserting the MP_CAPABLE 363 option. 365 TCP MPTCP MPTCP MPTCP 366 HOST NETWORK NODE NETWORK NODE HOST 368 | | | | 369 | | _add MP_CAPABLE | | 370 | SYN |/ | | 371 | -----------------X--------------------+------------------->| 372 | | | | 373 | | | SYN-ACK+MP_CAPABLE| 374 |<-------------------+--------------------+---------------- | 375 | | | | 376 | PROXY | | 377 | P _add MP_CAPABLE | | 378 | ACK P/ | | 379 | -----------------X--------------------+------------------->| 380 | P | | 381 | P | | 383 Connection initiation by MPTCP-unaware host with implicit proxies on 384 initial path 386 Figure 5 388 The implicit proxy can also support scenarios, where the peer rather 389 than the connection-initiating host is MPTCP-capable. In this case, 390 the MPTCP proxy adds the MP_CAPABLE option with its own key to the 391 initial SYN packet. If the SYN-ACK response by the peer carries the 392 MP_CAPABLE header, the proxy assumes multipath support. 394 If multiple proxies reside on the initial path in this latter case, 395 the proxy closest to the session-initiating host should become the 396 MPTCP end point. Since this proxy is the first to receive the peer's 397 SYN packet, it automatically assumes multipath support by inserting 398 the MP_CAPABLE option into this SYN packet. 400 These signaling procedures work fine as long as at least one of the 401 end hosts supports MPTCP. A problem occurs, when multiple proxies 402 reside on the initial path but *neither* of the end hosts supports 403 MPTCP. In this case, one proxy may add MP_CAPABLE to the SYN packet 404 and the other to the SYN-ACK response packet. In this manner, both 405 proxies end up creating a TCP-MPTCP-TCP split connection with 406 multipath support between each other. Such a situation is likely to 407 occur when each of the hosts' access networks supports a proxy. 409 To avoid such a situation, the proxy inserting the MP_CAPABLE option 410 into the SYN packet has to reveal its true nature by adding a PROXY 411 flag to this option. When another proxy inspects the SYN packet and 412 finds the MP_CAPABLE option with PROXY flag set, it should not insert 413 MP_CAPABLE to the SYN-ACK response. 415 For implicit proxies, end-host authentication is implicitly provided 416 by the host's access authentication as long as the proxy resides in 417 the access network of one of the end hosts. This makes additional 418 signaling for end-host authentication unnecessary. 420 While this solution restricts operation of implicit proxies to access 421 providers and their affiliates (e.g. roaming partners), it covers the 422 most relevant deployment scenarios. 424 4.2. Subflow Management with Implicit Proxy 426 Since the proxy splits the connection into a MPTCP section and a TCP 427 section, it becomes the end point for all further subflows. These 428 subflows may be initiated by the MPTCP-capable host or by the proxy 429 itself. 431 When the proxy is implicit, it must inform the multipath-capable host 432 about its existence as well as its IP address. Otherwise, the 433 multipath-capable host may try to establish subflows with the 434 multipath-unaware peer. For this purpose, implicit proxies should 435 set the PROXY flag on those MP_CAPABLE options they insert into SYN 436 or SYN-ACK packets. This flag informs the multipath-capable host 437 that the remote end point is represented by a proxy. 439 After connection establishment, the proxy should advertise its 440 address via ADD_ADDR to the multipath-capable host. This step is 441 necessary since the host does not know the proxy's address. 443 Currently, the ADD_ADDR option also conveys the request for immediate 444 subflow establishment to the enclosed address. This request has the 445 purpose to enable subflow creation in reverse direction, i.e. when 446 the peer resides behind a firewall. 448 Obviously, immediate subflow creation is not desirable when a proxy 449 announces its IP address as an alterative end point. Therefore, the 450 ADD_ADDR option should be furnished with a JOIN flag, which allows 451 differentiating between the two purposes of ADD_ADDR. Hence subflow 452 creation is only requested when the JOIN flag is set. 454 Since MPTCP options are not delivered reliably, the ADD_ADDR option 455 may get lost. In this case, the host has no means to find out about 456 the proxy's IP address. For that reason, an additional SEEK_ADDR 457 option should be supported which allows the host to solicit address 458 advertisements by MPTCP network nodes and the peer. 460 SEEK ADDR should hold a field for the IP version requested. If this 461 field is set to zero, addresses pertaining to any IP version can be 462 advertised. 464 4.3. Introduction of Explicit Proxy 466 ________ 467 | | 468 |Explicit| 469 | Proxy | 470 MPTCP |________| TCP 471 | 472 _|_ IP_PROX 473 ______ /|\ ______ 474 | | / | \ | | 475 | Host | IP_A0 / | \ IP_B0 | Host | 476 | A |--|------------/ | \-----------|--| B | 477 |______| SFL_0 | |______| 478 | /| 479 _|_ IP_A1 / | 480 |\-------------------/ | 481 | SFL_1 | 482 | | 483 \-----------------------/ 484 SFL_2 486 MPTCP-TCP split connection with explicit MPTCP proxy 488 Figure 6 490 If the proxy does not reside on the direct routing path of the 491 intended connection the connection initiator must provide the proxy 492 with explicit information on the peer's network locator, i.e. IP 493 address and port number. Since the explicit proxy may reside in a 494 different network, additional signaling for host authentication has 495 to be supported as well. 497 In case connection establishment reveals that both end hosts support 498 MPTCP (or if the peer is supported by an implicit proxy), the 499 explicit proxy function is not needed. In this case, the MPTCP 500 network node automatically assumes explicit anchor function since it 501 splits the initial subflow. 503 For connection establishment, the following signaling approaches are 504 considered: 506 o In-band MPTCP signaling: The peer's network locator (i.e. IP 507 address and port number) and the host's authentication information 508 are sent in-band on MPTCP options. Since the amount of 509 information is too large to fit into the TCP header of the initial 510 SYN packet additional packets need to be exchanged for signaling 511 purposes. A simple handhake can be realized where the MPTCP keys 512 are used as authenticators (Figure 7): 514 MPTCP EXPL MPTCP TCP 515 HOST A NETWORK NODE HOST B 517 | | | 518 | SYN + MP_CAP(KEY_A) | | 519 | -------------------------->| | 520 | | | 521 | SYN-ACK + MP_CAP(KEY_P) | | 522 |<-------------------------- | | 523 | | | 524 | ACK + FWD_ADDR(IP_B) | | 525 | -------------------------->| SYN + MP_CAP(KEY_A) | 526 | | ----------------------------->| 527 | | | 528 | | SYN-ACK | 529 | |<----------------------------- | 530 | | | 531 | PROXY | 532 | P | 533 | ACK + MP_CAP() P ACK | 534 |<--------------------------- P ----------------------------->| 535 | P | 536 | P | 538 Connection establishment with explicit proxy and in-band MPTCP 539 signaling 541 Figure 7 543 * The connection-initiating host (host A) sends the SYN packet 544 with MP_CAPABLE containing key_A as authenticator to the 545 explicit MPTCP network node which caches key_A and host A's 546 locator. 548 * The MPTCP network node answers with SYN_ACK enclosing 549 MP_CAPABLE with key_P as its own authenticator. It should 550 *not* set the PROXY flag, since it doesn't know at this point 551 if proxy function is required. 553 * Host A sends an ACK enclosing FWD_ADDR, which holds the peer's 554 (i.e. host B's) IP address. FWD_ADDR may also hold a port 555 number if it is different from the port number used to address 556 the MPTCP network node. 558 * The MPTCP network node sends SYN with MP_CAPABLE holding key A 559 to host B using its own IPaddress. It also sets the ANCHOR 560 flag in MP_CAPABLE as discussed in Section 5. 562 * If host B is not MPTCP-capable, it responds with a simple SYN- 563 ACK packet. Otherwise, it inserts MP_CAPABLE with key B into 564 the SYN-ACK packet. If MP_CAPABLE is absent, the MPTCP network 565 node assumes proxy function. Otherwise, it assumes anchor 566 function. 568 * The proxy function sends an ACK to host A and encloses the 569 MP_CAPABLE header with the PROXY flag set. This informs host A 570 that host B does not support MPTCP and that the MPTCP network 571 node has assumed proxy function. The MP_CAPABLE option does 572 not have to hold any key at this point since all keying 573 information has already been exchanged. 575 * The proxy function also sends a simple ACK to host B. 577 o Out-of-band MPTCP signaling: MPTCP introduces a separate signaling 578 connection to exchange the necessary signaling information prior 579 to establishment of the traffic connection. Since such an out-of- 580 band solution substantially extends the present scope of MPTCP it 581 is not further considered. 583 o Independent signaling: The host and the explict MPTCP network node 584 use an independent signaling protocol, in which the host 585 authenticates itself and provides the peer's locator. This 586 protocol can be supported on session or application layer such as 587 SIP [2], for instance. In this protocol, host and MPTCP network 588 node establish the 64-bit key, which is cached by the proxy 589 together with the peer's locator and inserted by the host into 590 MP_CAPABLE when initiating the MPTCP connection. This allows the 591 network node to find the peer's locator and to forward the SYN 592 packet to the peer using its own IP address. The network node 593 should set the ANCHOR flag when relaying the MP_CAPABLE packet to 594 the peer. In case the SYN-ACK return packet arriving from the 595 peer does *not* contain an MP_CAPABLE option, the network node 596 assume proxy function. In this case, the proxy inserts MP_CAPABLE 597 into the SYN-ACK packet, sets the PROXY flag and sends the packet 598 to the connection-initiating host using its own IP address and 599 port number as the packet's source. The host responds with an ACK 600 holding its own key as well as the key contained in the SYN-ACK 601 packet. 603 Security issues related to such explicit proxy solutions are 604 discussed in Section 8. 606 It makes little sense to consider explicit-proxy scenarios where the 607 connection-initiating host is not MPTCP-capable. 609 4.4. Subflow Management with Explicit Proxy 611 Subflow establishment with an explicit proxy follows along the same 612 lines as for an implicit proxy. The explicit proxy, however, does 613 not have to send an ADD_ADDR option since the host already knows the 614 proxy's address. 616 5. Operation with MPTCP Anchors 618 The anchor function splits subflows into two subflow sections, where 619 each section interconnects an end host with one of the anchor's IP 620 addresses (Figure 8). The anchor relays all packets arriving on one 621 subflow section to the other by rewriting the IP addresses of the 622 packet headers. The anchor may also translate port numbers. Anchors 623 can also insert or modify MPTCP options of passing packets. 625 To keep end-to-end semantics in tact, the end nodes must have full 626 awareness of the anchor's presence and its operation, i.e. if 627 subflows are split and if an IP address belongs to an anchor or to 628 the peer. Further, each host must know about the address-id its peer 629 uses on the remote section of a split subflow. This ensures proper 630 subflow tear-down in case the peer announces address removal via 631 REMOVE_ADDR option. 633 Anchors can be introduced during connection establishment or at any 634 later point in time. Anchor services can be invoked or released 635 during the entire lifetime of the connection. 637 5.1. Introduction of Implicit Anchor 639 ______ ________ ______ 640 | | | | | | 641 | Host | IP_A0 |Implicit| IP_B0 | Host | 642 | A |--|--------|--| Anchor |--|---------|--| B | 643 |______| SFL_0 |________| SFL_0 / |______| 644 | | / | 645 _|_ _|_ / _|_ 646 |\ IP_A1 / \ IP_ANCH / | IP_B1 647 | \ / \ / | 648 | \----------------/ \-------/ | 649 | Split SFL_1 Split SFL_1 | 650 | | 651 \----------------------------------------------/ 652 SFL_2 654 MPTCP connection with implicit MPTCP anchor 656 Figure 8 658 When an implicit anchor resides on the initial path, it caches the 659 locators (i.e. IP addresses and port numbers) of the initial subflow 660 as well as the keys exchanged during connection establishment. This 661 allows the anchor to derive the corresponding tokens and cache them 662 together with the end hosts' locators of this subflow. 664 Then, the anchor advertises its IP address to the end hosts by 665 sending an ADD_ADDR option to one or to both end hosts. The ADD_ADDR 666 option can be inserted into a packet that is passing on the initial 667 subflow. The anchor may also insert a port number into the ADD_ADDR 668 option. 670 The anchor has to mark the ADD_ADDR option in a manner that allows 671 the host receiving the option to distinguish it from an ADD_ADDR 672 option sent by the peer. For this purpose, the anchor should set the 673 address-id in the ADD_ADDR option to an anchor-reserved value (e.g. 674 255). This does not lead to any conflict in case multiple anchors 675 advertise their addresses with the same address-id value, since 676 anchor addresses are considered invariants that need not be removed. 677 Obviously, neither end hosts nor proxies should use this anchor- 678 reserved address-id value. 680 When an implicit anchor resides on the path used by a later subflow, 681 it caches the subflows locators as well as the token used during 682 subflow establishment. Obviously, anchor support can only be 683 provided for the host that initiated this subflow (host A) but not 684 for its peer (host B) since the anchor only knows host B's token. 685 Therefore, the anchor advertises its IP address (and port number) 686 only to host A. 688 The host receiving an ADD_ADDR options from an anchor caches the 689 anchor's address and port number contained in this option. When the 690 ADD_ADDR option does not carry a port number, the remote port number 691 of the subflow, where the option arrived, is cached instead. 693 Since the delivery of ADD_ADDR is not reliable, an end host may 694 proactively seek anchor addresses via the SEEK_ADDR option introduced 695 above. Both anchor and peer should respond with an ADD_ADDR option. 696 The host can differentiate the originators of these replies by the 697 enclosed address-id value. 699 5.2. Subflow Management with Implicit Anchor 701 When a host wishes to establish a subflow via anchor, it initiates a 702 subflow to the address and port number cached for the anchor. Based 703 on the destination port number of the SYN packet and the token 704 contained in MP_JOIN, the anchor identifies the peer's locator and 705 forwards the packet to the peer using one of its own addresses and 706 port numbers as the packet's source. The peer's SYN-ACK return 707 packet and all following packets are relayed by the anchor in the 708 same manner. Since the anchor does not change the address-ids 709 contained in the MP_JOIN options of the initial handshake, each host 710 learns the peer's address-id used for this split-subflow. 712 While the host initiating the subflow (host A) is aware of the 713 anchor's presence, its peer (host B) may not know that this subflow 714 is split because the anchor has not introduced itself to the peer or 715 because the corresponding ADD_ADDR option got lost. In such a case, 716 host B may falsely assume that the anchor's IP address belongs to 717 host A and map it to the address-id contained in MP_JOIN. This may 718 lead to a conflict, in case host A has announced (or will announce) 719 this address-id for another address. Further, host B may be tempted 720 to use the anchor's IP address for further subflows without knowing 721 that this may invoke triangular routing. 723 To avoid such misunderstanding, the MP_JOIN option on the SYN packet 724 has to be marked with an ANCHOR flag. This flag tells host B, that 725 the source address on the packet header belongs to an anchor and that 726 it is not associated with the address-id carried in the MP_JOIN 727 option. The ANCHOR flag should be set by the anchor when relaying 728 the SYN packet. 730 While host B may implicitly learn the anchor's IP address in this 731 manner, it is not advised to use this anchor for new subflows unless 732 the anchor has explicitly advertised its IP address. Host B can 733 solicit such IP address advertisement via SEEK_ADDR sent on the split 734 subflow. 736 Each host should cache the peer's address-id together with the state 737 information it holds for the corresponding split subflow. In case 738 the host receives an REMOVE_ADDR option, it can identify and tear 739 down all split-subflows pertaining to the address-id held in this 740 option. 742 The establishment of split subflows via anchor may introduce address- 743 ids without the corresponding IP addresses. This is a similar 744 situation as when direct end-to-end subflows pass network address 745 translators, and it does not pose any principle problem. 747 The anchor caches the host's locators and address-ids of the split 748 subflow together with all information it holds for this connection. 749 The anchor further keeps subflow-related state information for a 750 short time frame after the subflow has been closed. The tokens and 751 address ids are held for a short time after the last subflow known by 752 this anchor has been closed. The tear-down delay permits the anchor 753 to support break-before-make mobility scenarios discussed below. 755 5.3. Introduction of Explicit Anchor 757 ________ 758 | | 759 |Explicit| 760 | Anchor | 761 |________| 762 | 763 _|_ IP_ANCH 764 ______ /|\ ______ 765 | | / | \ | | 766 | Host | IP_A0 / | \ IP_B0 | Host | 767 | A |--|------------/ | \-----------|--| B | 768 |______| Split SFL_0 | Split SFL_0 |______| 769 | / Split SFL_1 | 770 _|_ IP_A1 / (using same path) _|_ IP_B1 771 |\-------------------/ | 772 | Split SFL_1 | 773 | | 774 \----------------------------------------------/ 775 SFL_2 777 MPTCP-TCP split connection with explicit MPTCP anchor 779 Figure 9 781 If the anchor does not reside on a direct routing path it has to be 782 introduced via explicit signaling by one of the hosts. The signaling 783 has to include authentication information and the peer's locator. 784 Since these are the same conditions as for explicit proxies the same 785 solution scenarios can be applied as discussed in Section 4.3. For 786 the reasons mentioned above, only scenarios with in-band MPTCP 787 signaling and independent signaling are considered. 789 o In-band MPTCP signaling: The first four steps of the connection 790 establishment are identical to those discussed for the explicit 791 proxy (see Figure 7 and Figure 10): 793 MPTCP EXPL MPTCP MPTCP 794 HOST A NETWORK NODE HOST B 796 | | | 797 | SYN + MP_CAP(KEY_A) | | 798 | -------------------------->| | 799 | | | 800 | SYN-ACK + MP_CAP(KEY_P) | | 801 |<-------------------------- | | 802 | | | 803 | ACK + FWD_ADDR(IP_B) | | 804 | -------------------------->| SYN + MP_CAP(KEY_A) | 805 | | ----------------------------->| 806 | | | 807 | | SYN-ACK + MP_CAP(KEY_B) | 808 | |<----------------------------- | 809 | | | 810 | ANCHOR | 811 | A | 812 | ACK + MP_CAP(KEY_B) A ACK + MP_CAP(KEY_A, KEY_B) | 813 |<--------------------------- A ----------------------------->| 814 | A | 815 | A | 817 Connection establishment with explicit anchor and in-band MPTCP 818 signaling 820 Figure 10 822 * Steps 1-4 of connection establishment with explicit proxy. 824 * In case host B is MPTCP-capable, it inserts MP_CAPABLE with key 825 B into the SYN-ACK response packet. Upon reception of this 826 packet, the MPTCP network node assumes anchor function instead 827 of proxy function. 829 * The anchor function sends an ACK to host A and encloses the 830 MP_CAPABLE header with key_B and it sets the ANCHOR flag. This 831 informs host A that host B does support MPTCP and that the 832 MPTCP network node has assumed anchor function. At this point, 833 host A overwrites key_P with key_B. 835 * The anchor function also sends an ACK to host B, where it 836 inserts MP_CAPABLE with key_A and key_B and sets the ANCHOR 837 flag. This tells host B that an anchor resides on the initial 838 path. 840 o Independent signaling: The explicit MPTCP network node relays the 841 host's SYN packet holding the MP_CAPABLE option to the peer. If 842 the SYN-ACK return packet holds the MP_CAPABLE option, the MPTCP 843 network node assumes anchor function and the initial subflow 844 becomes a split subflow. When relaying the SYN-ACK packet to the 845 connection-initiating host, the anchor should set the ANCHOR flag. 846 The host responds with an ACK holding MP_CAPABLE with both keys. 848 In case host B is not multipath-aware it may be supported by an 849 implicit proxy residing on the path between host B and the explicit 850 anchor. This proxy may reside in host B's access network for 851 instance. The implicit proxy sets the PROXY flag in the MP_CAPABLE 852 option of the SYN-ACK return packet as described in section 4.1. 853 Since the explicit anchor sets the ANCHOR flag at the same time, host 854 A can infer that the PROXY flag was set by an implicit proxy. 856 A host can also introduce an explicit anchor after connection 857 establishment. This has only limited benefit since the peer won't be 858 able to proactively use this anchor. Further, it is rather 859 complicated to embed such an anchor introduction into the MP_JOIN 860 handshake. For that reason, only methods involving independent 861 signaling protocols are considered here. Such a protocol has to 862 provide authentication information, the remote end point locator and 863 the remote tokens used on this connection. 865 5.4. Subflow Management with Explicit Anchor 867 After introduction of the explicit anchor, establishment of further 868 split subflows follows the same procedure as discussed for implicit 869 anchors in Section 5.2. 871 5.5. Protocol Translation with Anchor 873 The anchor can be used for IP protocol translation on a split subflow 874 in case host A wishes to support IPv6 on a new interface while host B 875 only supports IPv4. Protocol translation further becomes necessary 876 when one host moves from an IPv4 network to an IPv6 network while the 877 peer's network only supports IPv4 (and vice versa). 879 In such scenarios, host A sends SEEK_ADDR on all subflows with the 880 IPVer field set to IPv6. In response, anchors will send their 881 respective IPv6 addresses. Then, host A initiates a new subflow to 882 one anchors' IPv6 address. Since the anchor has cached at least one 883 of host B's IPv4 addresses, it can create an IPv6/IPv4 split-subflow 884 using an IPv6 and an IPv4 address. 886 5.6. Connection Robustness with Anchor 888 The anchor can provide enhanced connection robustness in scenarios 889 where the only remaining subflow breaks and direct end-to-end subflow 890 establishment is not possible. This may happen, for instance, when 891 both hosts simultaneously move to a new address. Direct subflow 892 establishment is not possible in this case since neither host knows 893 the peer's new IP address. 895 In another scenario, a host moves to a new IP address while the peer 896 resides behind a firewall. The host cannot reach the peer since the 897 firewall blocks packets arriving from a new address. The peer cannot 898 reach the host either since it does not know the host's new IP 899 address. 901 In these scenarios, each host will try to establish a direct subflow 902 first. If this fails each host tries subflow establishment via an 903 anchor. Since the anchor recognizes the connection based on token 904 and port number contained in each host's SYN-packet, it can cache the 905 host's new address contained on the packet and use it as the 906 destination for SYN-packets sent by the peer. In this manner, a new 907 subflow can be established via the anchor. 909 For this purpose, the anchor should keep connection-related state 910 information for some time after the subflow it is residing on has 911 been torn down. 913 The procedure further requires that the anchor holds both end hosts' 914 tokens. This applies to anchors that reside on the initial path 915 during connection establishment. 917 6. Host Configuration 919 MPTCP-capable hosts should be appropriately configured to take 920 advantage of MPTCP network functions. In a deployment scenario, 921 where proxies and anchors are integrated with a central router of a 922 3G/4G cellular network, the host should initiate connections that 923 deserve MPTCP support via the cellular interface if possible. After 924 connection establishment, additional paths can be established and 925 utilized for traffic exchange. 927 In case explicit MPTCP network functions are provided, the host must 928 be configured to support the proprietary protocol that introduces 929 these nodes to the MPTCP connection. It must further be configured 930 with the IP addresses for explicit proxies. 932 The details on host configuration and the criteria on path selection 933 are beyond the scope of this document. 935 7. New Signaling 937 The following subsections discuss signaling changes necessary to 938 support MPTCP network functions. 940 7.1. PROXY Flag 942 The PROXY flag needs to be added to the MP_CAPABLE option. The PROXY 943 flag is set by MPTCP network nodes to announce that they assume proxy 944 function. 946 The PROXY flag serves two purposes. It avoids that implicit proxies 947 residing on the initial path between MPTCP-unaware hosts sustain a 948 MPTCP connection with each other. It also informs a MPTCP-capable 949 host that a proxy provides MPTCP on behalf of an MPTCP-unaware peer. 950 This avoids unnecessary attempts by this host to establish subflows 951 directly with the MPTCP-unaware peer. 953 The PROXY flag can be added into the header of the MP_CAPAPBLE option 954 (shown as "P" in Figure 11). 956 1 2 3 957 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 958 +---------------+---------------+-------+-------+-+-+-+-------+-+ 959 | Kind | Length |Subtype|Version|C|P|A|(resvd)|S| 960 +---------------+---------------+-------+-------+-+-+-+-------+-+ 961 | ... ... | 963 MP_CAPABLE header with PROXY (P) and ANCHOR (A) flags 965 Figure 11 967 7.2. ANCHOR Flag 969 The ANCHOR flag needs to be added to the MP_CAPABLE option and to the 970 MP_JOIN option. The flag informs the receiving host (or proxy) that 971 an anchor has relayed this packet. This avoids misunderstandings 972 about the source IP address of the packet and the address-id it 973 carries. 975 The ANCHOR flag can be added to the headers of MP_CAPAPBLE and 976 MP_JOIN (shown as "A" in Figure 11 and Figure 12). 978 1 2 3 979 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 980 +---------------+---------------+-------+---+-+-+---------------+ 981 | Kind | Length = 12 |Subtype| |A|B| Address ID | 982 +---------------+---------------+-------+---+-+-+---------------+ 983 | ... ... | 985 MP_JOIN header for SYN and SYN-ACK with ANCHOR flag 987 Figure 12 989 7.3. JOIN Flag 991 The ADD_ADDR option is currently overloaded with two requests: 1) 992 Cache this address and 2) initiate a subflow to this address right 993 away. While this bundling of requests makes sense for end-to-end 994 interactions, it becomes problematic for proxies and anchors, which 995 only want to inform the peers about their respective addresses. 997 The issue can be resolved by adding a JOIN flag to the ADD_ADDR 998 option. This, however, creates some issues since the option has no 999 room left for additional information. The option is further rather 1000 long, especially if IPv6 addresses and port numbers have to be 1001 carried. 1003 The following approaches can be considered: 1005 o The IPVer field is reduced from 4 to 3 bits as proposed by Olivier 1006 Bonaventure. This still leaves room for 5 future IP versions 1007 apart from IPv4 and IPv6. (Note that IP version = 0 is used by 1008 SEEK_ADDR to refer to "all IP versions"). The released bit is 1009 available for the JOIN flag. 1011 o The ADDRESS ID field is reduced by 1 bit to allocate room for JOIN 1012 as proposed by Costin Raiciu. This reduces the number of 1013 simultaneously supported addresses from 256 to 128 (or 255 and 127 1014 if the anchor-reserved address-id is included as well). 1016 o The ADD_ADDR option only provides addresses and address-ids while 1017 a new option conveys the request to create a subflow with respect 1018 to a specific address id. A similar proposal was also made by 1019 Yoshifumi Nishida. 1021 o An octet is added to the ADD_ADDR option. 1023 7.4. Anchor-Reserved Address-Id Value 1025 The anchor-reserved address-id value is used when anchors advertise 1026 their IP address via ADD_ADDR. It informs the receiving host that 1027 the address belongs to an anchor and not to the peer. 1029 The anchor reserved address-id value could be set for 255, for 1030 instance. 1032 7.5. SEEK_ADDR Option 1034 The SEEK_ADDR option is sent by a host to solicit its peer as well as 1035 proxies and anchors to advertise their addresses. This option is 1036 necessary for operation with proxies and anchors, which rely on 1037 reliable address advertising. 1039 The SEEK_ADDR option holds the IP version field. If the value of 1040 this field is set to zero, addresses to all IP versions are sought. 1042 SEEK_ADDR also permits peers and MPTCP network nodes to reduce 1043 address advertising. It is not necessary, for instance, to 1044 preemptively advertise IPv6 addresses on connections that only use 1045 IPv4 and vice versa. 1047 The SEEK_ADDR option only holds the IP version field which leads to 1048 length of 3 octets (Figure 13). 1050 1 2 1051 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 1052 +---------------+---------------+-------+-------+ 1053 | Kind | Length |Subtype| IPVer | 1054 +---------------+---------------+-------+-------+ 1056 SEEK_ADDR option 1058 Figure 13 1060 7.6. FWD_ADDR Option 1062 The FWD_ADDR option is used by a host to forward its peer's IP 1063 address and port number to an explicit MPTCP network node. 1065 The fields of the FWD_ADDR are identical to that of the ADD_ADDR 1066 option. Since both options have different semantic meanings they 1067 should also carry different subtypes. 1069 8. Security 1071 Mobility and multi-homing protocols are vulnerable to session 1072 redirection attacks such as session hijacking and distributed DoS 1073 (DDoS)[3]. For MPTCP, these matters have been discussed in [4]. The 1074 introduction of implicit proxies and anchors does not add new 1075 principal vulnerabilities. 1077 One potential weakness is seen in connections via explicit proxy (or 1078 anchor), since the proxy can be used by the adversary to disguise its 1079 true location. In a DDoS attack, the adversary establishes multiple 1080 connections with the victim host and then floods the victim with a 1081 high volume of traffic on each connection. The severity of such an 1082 attack does not change when these connections are conducted via 1083 explicit proxy. Since the proxy uses its own IP address to forward 1084 the attacker's packets to the victim, the attacker's IP address 1085 remains hidden to the victim. This makes it impossible for the 1086 victim to identify an adversary prior to accepting a connection and 1087 to trace back the traffic flood to the attacker's location. 1089 One could argue that this situation could be improved by specifying a 1090 strong authentication method to be exercised between host and proxy. 1091 This, however, is not necessarily the case since a strong 1092 authentication protocol by itself does not enforce the use of strong 1093 authenticators. 1095 Note that this situation is different for mobility protocols like 1096 Mobile IPv6. In Mobile IPv6, the home agent uses the mobile host's 1097 unique home address as the source for traffic originated by the 1098 mobile host. The home address is therefore an authenticator of the 1099 traffic originator. 1101 To support the same level of security, the explicit proxy could use a 1102 unique IP address for each host. While such an approach is feasible 1103 in IPv6 it may have limited applicability in IPv4 due to IP address 1104 exhaustion. 1106 9. Acknowledgements 1108 The authors wish to acknowledge suggestions and contributions on 1109 proxies and anchors by Olivier Bonaventure, Philip Eardley, Alan 1110 Ford, Mark Handley, Yoshifumi Nishida and Costin Raiciu. 1112 10. References 1114 [1] Ford, A., Raiciu, C., Greenhalgh, A., and M. Handley, 1115 "Architectural Guidelines for Multipath TCP Development", 1116 RFC 6182, March 2011. 1118 [2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 1119 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 1120 Session Initiation Protocol", RFC 6182, June 2002. 1122 [3] Nikander, P., Arkko, J., Auro, T., Montenegro, G., and E. 1123 Nordmark, "Mobile IP Version 6 Route Optimization Security 1124 Design Background", RFC 4225, December 2005. 1126 [4] Bangulo, M., "Threat Analysis for TCP Extensions for Multipath 1127 Operation with Multiple Addresses", RFC 6181, March 2011. 1129 Authors' Addresses 1131 Georg Hampel 1132 Alcatel-Lucent 1133 600 Mountain Ave 1134 Murray Hill, NJ 07974 1135 US 1137 Phone: +1 908 582 2377 1138 Fax: +1 908 582 8222 1139 Email: georg.hampel@alcatel-lucent.com 1141 Thierry Klein 1142 Alcatel-Lucent 1143 600 Mountain Ave 1144 Murray Hill, NJ 07974 1145 US 1147 Phone: +1 908 582 3585 1148 Fax: +1 908 582 8222 1149 Email: thierry.klein@alcatel-lucent.com