idnits 2.17.00 (12 Aug 2021) /tmp/idnits15880/draft-wei-mptcp-proxy-mechanism-02.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 == Line 134 has weird spacing: '...fferent scena...' -- The document date (July 1, 2015) is 2516 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) == Missing Reference: 'RFC2119' is mentioned on line 124, but not defined == Unused Reference: 'KEYWORDS' is defined on line 426, but no explicit reference was found in the text == Unused Reference: 'Deng' is defined on line 437, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT X.Wei 3 Intended Status: Standards Track C.Xiong 4 Expires: January 2, 2016 Huawei Technologies 5 E. Lopez 6 Fortinet 7 July 1, 2015 9 MPTCP proxy mechanisms 10 draft-wei-mptcp-proxy-mechanism-02 12 Abstract 14 Multipath TCP provides the ability to simultaneously use multiple 15 paths between peers for a TCP/IP session, and it could improve 16 resource usage within the network and, thus, improve user experience 17 through higher throughput and improved resilience to network failure. 18 This document discusses the mechanism of a new network entity, named 19 MPTCP proxy, which is aimed to assist MPTCP capable peer to use MPTCP 20 session in case of one of the peers not being MPTCP capable or to act 21 as an aggregation point for sublfows. 23 Status of this Memo 25 This Internet-Draft is submitted to IETF in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF), its areas, and its working groups. Note that 30 other groups may also distribute working documents as 31 Internet-Drafts. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 The list of current Internet-Drafts can be accessed at 39 http://www.ietf.org/1id-abstracts.html 41 The list of Internet-Draft Shadow Directories can be accessed at 42 http://www.ietf.org/shadow.html 44 Copyright and License Notice 45 Copyright (c) 2015 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 3 MPTCP Proxy models . . . . . . . . . . . . . . . . . . . . . . 4 63 4 MPTCP Proxy Solutions . . . . . . . . . . . . . . . . . . . . . 5 64 4.1 Mechanisms for on-path MPTCP proxy . . . . . . . . . . . . 5 65 4.2 Mechanisms for off-path MPTCP proxy . . . . . . . . . . . . 7 66 5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 9 67 6 Security Considerations . . . . . . . . . . . . . . . . . . . . 10 68 7 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 10 69 8 References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 70 8.1 Normative References . . . . . . . . . . . . . . . . . . . 10 71 8.2 Informative References . . . . . . . . . . . . . . . . . . 11 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 74 1 Introduction 76 Nowadays, the volume of mobile devices, e.g. smart phone, has 77 increased greatly, and most of these devices have more than one 78 interface for network communication, for example it's very common for 79 a smart phone to have a cellular network interface and a WLAN 80 interface; at the same time, multi-homing scenarios have been more 81 and more common. All these situations provide a good pre-condition 82 for the implementation of MPTCP [MPTCP Protocol]. Some network 83 operators also show interests in MPTCP, they want to utilize MPTCP's 84 multipath feature to realize optimization of their network 85 performances, such as resource pooling, network mobility etc. 87 But there are still some barriers existing for the promotion of 88 MPTCP, and one of them is that now almost all of the ICP (Internet 89 Content Provider) servers on the Internet are traditional TCP servers 90 and there seems no motivation for these traditional servers to embed 91 MPTCP into their protocol stack, this situation leads to the fact 92 that when communicating with these servers the MPTCP capable devices 93 have to fall back to traditional TCP and cannot fully utilize their 94 MPTCP capability. 96 Besides, the multipath feature of MPTCP protocol brings impacts on 97 the performances of some kinds of network middleboxes which are 98 deployed to enhance network performance or to provide traffic 99 optimization for network traffic. For example, middleboxes, such as 100 HTTP proxy, video/audio optimizer and firewall are deployed enroute 101 by network operators to provide performance enhancements, and all of 102 these middleboxes need to have knowledge about the entire content of 103 the traffic flow in order to function properly on the flow. But for 104 MPTCP traffic, it is likely that only a part of subflows traverse the 105 middlebox, and leads these middleboxes to be blind about the traffic, 106 and the result would be that the endhost could not benefit from 107 performance enhancement service or the traffic from endhost could be 108 blocked by firewall because the firewall cannot trust the traffic. A 109 more detailed description of MPTCP's impacts on middleboxes can be 110 found in [Lopez]. For all the middlebox scenarios, we can conclude a 111 basic requirement that the MPTCP traffic should be able to aggregate 112 at middlebox. 114 To support the use of MPTCP session between a MPTCP host and a TCP 115 host, and to make MPTCP traffic get benefits from network middlebox 116 that providing performance enhancement, this document defines a new 117 entity named MPTCP proxy (or proxy for abbreviation). 119 2 Terminology 121 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 122 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 123 document are to be interpreted as described in RFC 2119 [RFC2119]. 125 MPTCP proxy (proxy): An entity used to support MPTCP session between 126 MPTCP capable host and non-MPTCP capable host. 128 ICP: Internet Content Provider. 130 3 MPTCP Proxy models 132 To support the use of MPTCP session between MPTCP host and TCP host, or 133 to help to aggregate MPTCP subflows, there are mainly two models of 134 proxy for different scenarios: the first one is that the proxy is 135 deployed on the common direct routing path of traffic from different 136 access network, and this kind of proxy is referred as on-path proxy, an 137 example is shown in Figure 1; the second one is that the proxy locates 138 only on the direct routing path of traffic from one of the access 139 networks the MPTCP capable host attached to, and this kind of proxy is 140 referred as off-path proxy, an example is shown in Figure 2. 142 _.---.. 143 ,' `. 144 .' Access 145 +--| Network 1|-------+ 146 | `. ,' | 147 +--------+ | `.._,,,' | +--------+ +--------------+ 148 |Host (A)|--+ +-----|MPTCP |----|Host(B) | 149 |(MPTCP) |--+ ,--'''--. +-----|Proxy(P)| |(TCP) | 150 +--------+ | ,' Access `. | +--------+ +--------------+ 151 +-- Network 2---------+ 152 ' 153 `.._ _,,' 154 `'' 156 Figure 1: Scenario of on-path proxy deployment 158 For the scenario shown in Figure 1, the MPTCP capable host A has two 159 network interfaces and connects to two access networks simultaneously 160 through the two interfaces. In this case, the proxy is located on the 161 path shared by the two access networks' traffic, for example, the proxy 162 could be deployed by Host B (e.g. OTT server) side. 164 _.---.. 165 ,' `. 166 .' Access +--------+ +--------------+ 167 +--| Network 1|---------|MPTCP |----|Host(B) | 168 | `. ,' |Proxy(P)| | | 169 +--------+ | `.._,,,' +--|-----+ +--------------+ 170 |Host(A) |--+ | 171 | |--+ ,--'''--. | 172 +--------+ | ,' Access `. | 173 +-- Network 2. | 174 --------------+ 175 `.._ _,,' 176 `'' 178 Figure 2: Scenario of off-path proxy deployment 180 For the scenario shown in Figure 2, MPTCP proxy is located only on the 181 direct routing path of traffic from one of the access networks the MPTCP 182 capable host attached to, for example, the proxy could be located at 183 aggregation point such as firewall. As shown in Figure 2, the MPTCP 184 proxy is located on the natural routing path of traffic from access 185 network 1, but not on the natural routing path of traffic from access 186 network 2, which means when host A communicates using MPTCP with host B, 187 the subflow through access network 2 will not be naturally routed to 188 MPTCP proxy. 190 The MPTCP communication in this scenario could occur between a MPTCP 191 host and a TCP host, or two MPTCP hosts. 193 The following sections will discuss the detailed mechanisms of on-path 194 proxy and off-path proxy as introduced above. 196 4 MPTCP Proxy Solutions 198 4.1 Mechanisms for on-path MPTCP proxy 200 When the direct routing path of all the sub-flows of a MPTCP capable 201 host pass through the same proxy, the proxy will act as on-path proxy, 202 and the on-path proxy could be transparent to the end host, i.e. end 203 host itself knows nothing about the existence of the proxy. 205 +-------+ +--------------+ +--------------+ 206 |Host(A)| |MPTCP Proxy(P)| |ICP Server(B) | 207 |(MPTCP)| +--------|-----+ |(TCP) | 208 +-|-----+ | +-------|------+ 209 |-----SYN+MP_CAPABLE(Key-A)--->|--SYN+MP_CAPABLE(Key-A)-->| 210 | +---------------------------------+ | 211 | |create temp. entry for connection| | 212 | +---------------------------------+ | 213 | |<--------SYN+ACK ---------| 214 | +------------+ | 215 | |create Key-P| | 216 | +------|-----+ | 217 <--SYN+ACK+MP_CAPABLE(Key-P)---| | 218 | | | 219 -ACK+MP_CAPABLE(Key-A,Key-P)---> | 220 | |---------ACK--------------> 221 | +------------+ | 222 |<------Data----------->|Data Mapping|<----Data---------->| 223 | +------|-----+ | 224 | +--|------+ | 225 |---------SYN+MP_JOIN-------> | | 226 | | inspect | | 227 <-----SYN+ACK+MP_JOIN-------- MPTCP | | 228 | | signal | | 229 |--- -----ACK+MP_JOIN-------> and | | 230 | |establish| | 231 <---------ACK --------------|sub-flow | | 232 | +--|------+ | 233 | +------------+ | 234 |<======Data===========>|Data Mapping|<----Data---------->| 235 | +------|-----+ | 237 Figure 3: On-path proxy for connection between MPTCP Host and TCP Server 239 The function of on-path proxy could mainly be divided into three sub- 240 functions: supporting for initial MPTCP capability negotiation, 241 supporting for sub-flow establishment and data mapping. Figure 3 shows 242 an example signal flow for on-path proxy. The following clauses focus on 243 the description of each sub-function. 245 (1) Supporting for initial MPTCP capability negotiation 247 The MPTCP capable host starts a connection establishment procedure by 248 sending the first handshake packet with MP_CAPABLE option, including 249 Host's Key-A, to ICP server; proxy inspects the packet and creates a 250 temporary entry, which will be used to match SYN/ACK response from ICP 251 server, for the connection, then the proxy forwards the packet to ICP 252 server. 254 (2)Supporting for sub-flow establishment 256 After the initial MPTCP connection established, Host could choose to 257 start a new MPTCP sub-flow. Because Host is unaware of the existence of 258 proxy, so Host will start the new sub-flow with ICP server, i.e. the 259 destination IP address of SYN/MP_JOIN packet is ICP server's IP address. 261 The proxy inspects sub-flow establishment signal packet, i.e. 262 SYN/MP_JOIN, and decides whether it has provided proxy function for the 263 MPTCP session through the token included in MP_JOIN. If proxy has 264 provided proxy function for the MPTCP session, then it will provide 265 proxy function for the sub-flow; otherwise proxy will not take any 266 action on the establishment of sub-flow. 268 (3)Data mapping 270 Proxy implements two separate kinds of data mapping: forward mapping and 271 reverse mapping. Forward mapping means mapping data from MPTCP session 272 to TCP session; reverse mapping means mapping data from TCP session to 273 MPTCP session. Figure 4 shows the data mapping function of proxy. In 274 forward mapping, proxy maps data from all sub-flows belonging to MPTCP 275 session to a single TCP flow in TCP session. 277 +-----------------------+ 278 MPTCP | Mapping | TCP 279 +--+ | +-----+ +---+ | +----------+ 280 |Host|<===|>|MPTCP|<<<<>>>>|TCP|<-+-->|ICP server| 281 +--+ | +-----+ +---+ | +----------+ 282 |proxy | 283 +-----------------------+ 284 Figure 4: Data mapping function of proxy 286 4.2 Mechanisms for off-path MPTCP proxy 288 When proxy locates on the initial sub-flow's direct routing path, but 289 some other sub-flow's direct routing path might not go through the same 290 proxy, then proxy could act in off-path model. The main difference 291 between on-path model proxy and off-path model proxy is that in off-path 292 model proxy needs to steer sub-flows to proxy, and Host will start new 293 sub-flow with proxy, but not with its peer host. 295 +-------+ +--------------+ +--------------+ 296 |Host(A)| |MPTCP Proxy(P)| |ICP Server(B) | 297 |(MPTCP)| +--------|-----+ |(TCP) | 298 +-|-----+ | +-------|------+ 299 |-----SYN+MP_CAPABLE(Key-A)--->|--SYN+MP_CAPABLE(Key-A) ->| 300 | +---------------------------------+ | 301 | |create temp. entry for connection| | 302 | +---------------------------------+ | 303 | |<--------SYN+ACK ---------| 304 | +------------+ | 305 | |create Key-P| | 306 | +------|-----+ | 307 <--SYN+ACK+MP_CAPABLE(Key-P,P)-| | 308 | | | 309 -ACK+MP_CAPABLE(Key-A,Key-P)--->---------ACK--------------> 310 | +------------+ | 311 |<------Data----------->|Data Mapping|<----Data---------->| 312 | +------|-----+ | 313 |<------ADD_ADDR(proxy IP)-----| | 314 | +--|------+ | 315 |------SYN+MP_JOIN----------> | | 316 | | inspect | | 317 <-----SYN+ACK+MP_JOIN-------- MPTCP | | 318 | | signal | | 319 |------ACK+MP_JOIN----------> and | | 320 | |establish| | 321 <---------ACK --------------|sub-flow | | 322 | +--|------+ | 323 | +------------+ | 324 |<======Data===========>|Data Mapping|<----Data---------->| 325 | +------|-----+ | 327 Figure 5:Off-path proxy for connection between MPTCP Host and TCP Server 329 Similar to on-path model proxy, the function of off-path proxy could 330 also be divided into three sub-functions: supporting for initial MPTCP 331 capability negotiation, supporting for sub-flow establishment and data 332 mapping. Figure 5 shows an example signal flow for on-path proxy. 334 (1) Supporting for initial MPTCP capability negotiation 336 The MPTCP capable Host starts a connection establishment procedure by 337 sending the first handshake packet with MP_CAPABLE option, including 338 Key-A, to ICP server; proxy inspects the packet and creates a temporary 339 entry, which is used by proxy to match SYN/ACK response from ICP server, 340 then the proxy forwards the packet to ICP server. 342 Proxy inspects the second handshake SYN/ACK packet from ICP server, if 343 MP_CAPABLE option is included in SYN/ACK packet, then it means the ICP 344 server is MPTCP capable and the proxy could choose whether to act as 345 proxy or not for the connection, for example if the proxy wants to act 346 as an aggregation point for MPTCP subflow traffics then it could choose 347 to act proxy function for the MPTCP session; but if the purpose of proxy 348 is just provide MPTCP support for communication between MPTCP host and 349 legacy TCP host, then it could choose not to act proxy function; if no 350 MP_CAPABLE option is included in SYN/ACK, the proxy will generate Key-P 351 on behalf of ICP server to finish MPTCP connection with Host. 353 To avoid Host starts the establishment of sub-flow with ICP server's IP 354 address, proxy notifies Host the existence of itself through sending a P 355 flag in MP_CAPABLE option in SYN/ACK packet. When Host receives this P 356 flag it SHOULD NOT start the new sub-flow with ICP server's IP address 357 any more, but chooses to establish sub-flow with proxy after obtaining 358 proxy's IP address. 360 There are reasons why a new P flag needs to be defined for explicit 361 indication the existence of proxy, instead of implicitly inject the 362 proxy into MPTCP session using existing MPTCP signaling , e.g. using 363 ADD_ADDR/ADDR_JOIN to inform MPTCP host of proxy's IP address, and using 364 REMOVE_ADDR to disable initial subflow between MPTCP host and its peer 365 host:When a new subflow is to be established, the subflow management 366 strategy should be considered. As stated in [MPTCP Experience], "The 367 subflows are created immediately after the creation of the initial 368 subflow", so MPTCP host might have started a new subflow before a 369 REMOVE_ADDR is received, due to message delay or lost of REMOVE_ADDR, in 370 that case the new subflow might be established between MPTCP host and 371 its peer host but not between MPTCP host and proxy. 373 (2)Supporting for sub-flow establishment 375 In off-path model, after MPTCP capable Host has established the initial 376 sub-flow in MPTCP session with the assistance of proxy, proxy could 377 advertise its own IP address in ADD_ADDR option to Host, and then Host 378 could establish new sub-flow with proxy. 380 (3)Data mapping 382 The data mapping function for off-path proxy is the same as the function 383 described in on-path model. 385 5 Conclusion 387 This document provides two kinds of proxy modes, which could be used to 388 support MPTCP capable Host in two different scenarios. For the first on- 389 path MPTCP proxy, there is no need to modify the current MPTCP stack 390 implementation of the host; for the off-path MPTCP proxy, it requires 391 the MPTCP capable host needs to support a new defined P flag. 393 6 Security Considerations 395 The P flag provides a method for explicitly interpose a proxy function 396 in MPTCP session, but this does not bring more security risks than MPTCP 397 protocol itself, because even without P flag, an on-path middlebox could 398 still interpose it in MPTCP session using existing MPTCP protocol 399 signaling. 401 7 IANA Considerations 403 A new flag 'P' in MPTCP MP_CAPABLE option [MPTCP Protocol] needs to be 404 defined refer to RFC 6824, Section 3.1. This flag is used by proxy to 405 inform MPTCP capable host the existence of proxy, besides the 'P' flag 406 could also be used to inform other potential MPTCP proxy its presence. 408 1 2 3 409 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 410 +---------------+---------------+-------+-------+---------------+ 411 | Kind | Length |Subtype|Version|A|P|C|D|E|F|G|H| 412 +---------------+---------------+-------+-------+---------------+ 413 | Option Sender's Key (64 bits) | 414 | | 415 | | 416 +---------------------------------------------------------------+ 417 | Option Receiver's Key (64 bits) | 418 | (if option Length == 20) | 419 | | 420 +---------------------------------------------------------------+ 422 8 References 424 8.1 Normative References 426 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 427 Requirement Levels", BCP 14, RFC 2119, March 1997, 428 . 430 [MPTCP Protocol]Ford, A., Raiciu, C., Handley, M., and O. 431 Bonaventure, "TCP Extensions for Multipath Operation with 432 Multiple Addresses", RFC 6824, January 2013, 433 . 435 8.2 Informative References 437 [Deng] L.Deng, D.Liu, T.Sun. "draft-deng-mptcp-mobile-network-proxy- 438 01", April 18, 2014 439 [Lopez] E. Lopez. "draft-lopez-mptcp-middlebox-00", November 11, 2014 440 [MPTCP Experience] O. Bonaventure et al. "draft-ietf-mptcp- 441 experience-00". September 16, 2014 443 Authors' Addresses 445 Xinpeng Wei 446 Huawei Technoligies 447 Beijing, China 448 EMail: weixinpeng@huawei.com 450 Chunshan Xiong 451 Huawei Technoligies 452 Beijing, China 453 EMail: sam.xiongchunshan@huawei.com 455 Edward Lopez 456 Fortinet 457 899 Kifer Road 458 Sunnyvale, CA 94086 459 EMail: elopez@fortinet.com