idnits 2.17.00 (12 Aug 2021) /tmp/idnits13022/draft-boucadair-mptcp-connectivity-checks-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 4, 2015) is 2628 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 6824 (Obsoleted by RFC 8684) == Outdated reference: A later version (-02) exists of draft-boucadair-mptcp-symmetric-01 == Outdated reference: draft-ietf-mptcp-attacks has been published as RFC 7430 -- Obsolete informational reference (is this intentional?): RFC 5389 (Obsoleted by RFC 8489) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Boucadair 3 Internet-Draft C. Jacquenet 4 Intended status: Experimental France Telecom 5 Expires: September 5, 2015 March 4, 2015 7 MPTCP Connectivity Checks 8 draft-boucadair-mptcp-connectivity-checks-00 10 Abstract 12 This document specifies an extension to minimize the delay induced by 13 the presence of MPTCP-unfriendly nodes in some of the paths selected 14 by a MPTCP endpoint, and which may support the establishment of MPTCP 15 subflows. Concretely, this procedure allows a MPTCP endpoint to 16 assess whether the networks the endpoint connects to are compliant 17 with MPTCP signals or not. The procedure is not enabled for every 18 new MPTCP connection; it is activated upon bootstrap or when a 19 network attachment change occurs (e.g., attach to a new network, 20 discover a new external IP address, etc.). 22 Requirements Language 24 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 25 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 26 document are to be interpreted as described in RFC 2119 [RFC2119]. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on September 5, 2015. 45 Copyright Notice 47 Copyright (c) 2015 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 63 2. Problem Space . . . . . . . . . . . . . . . . . . . . . . . . 2 64 3. Proposed Solution . . . . . . . . . . . . . . . . . . . . . . 4 65 4. Security Considerations . . . . . . . . . . . . . . . . . . . 7 66 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 67 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 68 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 69 7.1. Normative References . . . . . . . . . . . . . . . . . . 7 70 7.2. Informative References . . . . . . . . . . . . . . . . . 7 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 73 1. Introduction 75 This document specifies an extension that minimizes the delay induced 76 by the presence of MPTCP-unfriendly nodes in the some of the paths 77 selected by a MPTCP endpoint, and which may support the establishment 78 of MPTCP subflows. 80 The problem space is further described in Section 2, while a proposed 81 solution is discussed in Section 3. 83 2. Problem Space 85 Advanced flow-aware service functions (e.g., Performance Enhancement 86 Proxies ([RFC3135]), NATs [RFC3022], CGNs [RFC6888], DS-Lite AFTR 87 [RFC6333], NAT64 [RFC6146], NPTv6 [RFC6296], firewalls, etc.) are 88 required to achieve various objectives such as IP address sharing, 89 firewalling, avoid covert channels, detect and protect against ever 90 increasing DDoS attacks, etc. 92 Removing those functions is not an option because they are used to 93 address constraints that are often typical of the current yet protean 94 Internet situation (global IPv4 address depletion comes to mind, but 95 also the plethora of services with different QoS/security/robustness 96 requirements, etc.), and this is even exacerbated by environment- 97 specific designs (e.g., the nature and the number of service 98 functions that need to be invoked at the Gi interface of a mobile 99 infrastructure). Moreover, these sophisticated service functions are 100 located in the network but also in service platforms, or intermediate 101 entities (e.g., CDNs). A flow-aware device can be embedded in a CPE 102 (Customer Premises Equipment) and/or hosted in the network provider's 103 side. 105 In the meantime, the presence of these flow-aware functions 106 complicates the introduction of new protocols or the introduction of 107 additional features for existing ones. Also, because some of these 108 flow-aware functions do not expose a deterministic behavior, 109 additional complications are encountered even if the protocol design 110 includes built-in features to detect (and possibly accommodate) the 111 presence of such functions. This document focuses on MPTCP 112 [RFC6824]. 114 MPTCP supports a mechanism to fallback to TCP when a flow-aware 115 function interferes with MPTCP signals. Figure 1 and Figure 2 show 116 two typical examples of the fallback behavior. It is out of scope of 117 this document to list all the possible fallback scenarios. Refer to 118 [RFC6824] for more details about the exact fallback behavior. 120 Host T1 Host T2 121 ------------------------ ------------------------ 122 Address A1 Address A2 Address B1 Address B2 123 ---------- ---------- ---------- ---------- 124 | | | | 125 | (initial MPTCP setup) | | 126 T0 |----------------------------------->| | 127 |<-----------------------------------| | 128 | | | | 129 | Fall Back to TCP | | 130 T0+t |----------------------------------->| | 131 |<-----------------------------------| | 132 | | | | 134 Figure 1: Fallback Case 1 136 Host T1 Host T2 137 ------------------------ ------------------------ 138 Address A1 Address A2 Address B1 Address B2 139 ---------- ---------- ---------- ---------- 140 | | | | 141 | (initial MPTCP setup) | | 142 T0 |----------------------------------->| | 143 |<-----------------------------------| | 144 | | | | 145 | | | | 146 |<------- Wrong DSS------ | | 147 | | | | 148 | Fall Back to TCP | | 149 T0+t |----------------------------------->| | 150 |<-----------------------------------| | 151 | | | | 153 Figure 2: Fallback Case 2 155 This behavior, if adopted for every new connection, will have 156 negative impacts on the quality of experience as perceived by a user. 157 This is not desirable. 159 3. Proposed Solution 161 The problem in Section 2 can be originated by MPTCP-unfriendly 162 service function(s) located at the initiator side, the receiver side, 163 or the network in between. In order to avoid increasing the delay to 164 establish a TCP-based connection involving an MPTCP-enabled endpoint, 165 this document suggests the use of connectivity checks to assess 166 whether available paths as perceived by an MPTCP-enabled endpoint can 167 safely convey MPTCP signals. Doing so, the results of such 168 connectivty checks allow an MPTCP-enabled endpoint to decide whether 169 MPTCP needs to be disabled for all or part of its available network 170 attachments. This also allows the endpoint to identify which paths 171 cannot be used to establish the first subflow. Network attachments 172 that aren't MPTCP-friendly are tagged as such. 174 A dedicated functional element (referred to as MPTCP Connectivity 175 Check Server (MCCS)) is proposed to assess the MPTCP friendliness of 176 its network attachments. MCCS is attached to a network that does not 177 involve any MPTCP-unfriendly service function. If any MPTCP problem 178 is encountered when establishing a connection with an MCCS, it is an 179 indication that the issue is located at the remote MPTCP-enabled 180 endpoint. 182 This procedure is activated upon bootstrap or when a network 183 attachment change occurs (e.g., attach to a new network, discover a 184 new external IP address, etc.); it is not executed for every new 185 MPTCP connection: 187 o An MPTCP-enabled endpoint is configured with one or a list of MCCS 188 servers. 190 A well-known name can be used for this purpose. The name is then 191 passed to the name resolution library (e.g., Section 6.1.1 of 192 [RFC1123]) to retrieve the corresponding IP address(es) (IPv4, 193 IPv6 or both). 195 o The MPTCP-enabled terminal then establishes MPTCP connections 196 based upon all the IP addresses that have been retrieved (or a 197 subset thereof). Executing the procedure with more than one MCCS 198 (if available) is RECOMMENDED. 200 These MPTCP connections are meant to assess for each available 201 network attachment, interface, discovered external IP address, 202 etc., that the path that will be solicited when issuing packets 203 does not break MPTCP connections. 205 The tests are executed both from the MPTCP-enabled endpoint and 206 also the MCCS. The extension defined 207 [I-D.boucadair-mptcp-symmetric] is RECOMMENDED so that the MCCS 208 can initiate MPTCP connections, add new subflows to an active 209 MPTCP connection, etc. 211 The tests are performed to cover all failure cases (e.g., strip 212 MPTCP signals, alter some options, corrupted DSS, etc.). An 213 example is depicted in Figure 3 for illustration purposes. 215 Host T1 MCCS 216 ------------------------ ---------- 217 Address A1 Address An Address 1 218 ---------- --------- ---------- 219 | | | 220 | (initial MPTCP setup 1) | 221 |---------------------------------->-| 222 |<-----------------------------------| 223 | .... | 224 | |(initial MPTCP setup n)| 225 | |---------------------->| 226 | |<----------------------| 227 | | | 228 | .... | 229 | | MPTCP setup m | 230 | |<----------------------| 231 | |---------------------->| 232 | | | 234 Figure 3: An example of connectivity checks 236 o As an outcome of the previous step, the MPTCP-enabled endpoint can 237 conclude whether all or some of its available network attachments 238 can "safely" be used when establishing MPTCP connections. 240 Interfaces/address/networks that are MPTCP-unfriendly are tagged 241 accordingly; those are not used when establishing a new MPTCP 242 connection with a remote peer or to add a new subflow to an 243 existing MPTCP connection. 245 In particular, an MPTCP-enabled endpoint will not use MPTCP when 246 all its network attachments are MPTCP-unfriendly. This covers in 247 particular the situation where the endpoint initialed the 248 connection or when the MPTCP device receives an MPTCP connection 249 (e.g., user-generated content context). 251 o This procedure is executed whenever network conditions change, as 252 perceived by an MPTCP-enabled endpoint. 254 In the context of [I-D.deng-mptcp-proxy], this procedure can be 255 implemented at the CPE side on behalf of the MPTCP-enabled terminals 256 the CPE is connected to in the user premises. An MPTCP-enabled 257 terminal localed behind a CPE assumes by default that its default 258 gateway is its MCCS. Doing so, this design allows to avoid re-using 259 the same connectivity checks for all the terminals located behind a 260 CPE. 262 A deployment option would consist in integrating connectivity check 263 capabilities in STUN servers [RFC5389]; an extension would be needed 264 for that purpose, though. 266 4. Security Considerations 268 MPTCP-related security considerations are documented in [RFC6824] and 269 [I-D.ietf-mptcp-attacks]. 271 Security-consideration specific to MCCS will be discussed. 273 5. IANA Considerations 275 This document does not require any action from IANA. 277 6. Acknowledgements 279 TBC 281 7. References 283 7.1. Normative References 285 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 286 Requirement Levels", BCP 14, RFC 2119, March 1997. 288 [RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, 289 "TCP Extensions for Multipath Operation with Multiple 290 Addresses", RFC 6824, January 2013. 292 7.2. Informative References 294 [I-D.boucadair-mptcp-symmetric] 295 Boucadair, M. and C. Jacquenet, "An Extension to MPTCP for 296 Symmetrical Sub-Flow Management", March 2015, 297 . 300 [I-D.deng-mptcp-proxy] 301 Lingli, D., Liu, D., Sun, T., Boucadair, M., and G. 302 Cauchie, "Use-cases and Requirements for MPTCP Proxy in 303 ISP Networks", draft-deng-mptcp-proxy-01 (work in 304 progress), October 2014. 306 [I-D.ietf-mptcp-attacks] 307 Bagnulo, M., Paasch, C., Gont, F., Bonaventure, O., and C. 308 Raiciu, "Analysis of MPTCP residual threats and possible 309 fixes", draft-ietf-mptcp-attacks-03 (work in progress), 310 February 2015. 312 [RFC1123] Braden, R., "Requirements for Internet Hosts - Application 313 and Support", STD 3, RFC 1123, October 1989. 315 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 316 Address Translator (Traditional NAT)", RFC 3022, January 317 2001. 319 [RFC3135] Border, J., Kojo, M., Griner, J., Montenegro, G., and Z. 320 Shelby, "Performance Enhancing Proxies Intended to 321 Mitigate Link-Related Degradations", RFC 3135, June 2001. 323 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 324 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 325 October 2008. 327 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 328 NAT64: Network Address and Protocol Translation from IPv6 329 Clients to IPv4 Servers", RFC 6146, April 2011. 331 [RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix 332 Translation", RFC 6296, June 2011. 334 [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 335 Stack Lite Broadband Deployments Following IPv4 336 Exhaustion", RFC 6333, August 2011. 338 [RFC6888] Perreault, S., Yamagata, I., Miyakawa, S., Nakagawa, A., 339 and H. Ashida, "Common Requirements for Carrier-Grade NATs 340 (CGNs)", BCP 127, RFC 6888, April 2013. 342 Authors' Addresses 344 Mohamed Boucadair 345 France Telecom 346 Rennes 35000 347 France 349 Email: mohamed.boucadair@orange.com 350 Christian Jacquenet 351 France Telecom 352 Rennes 35000 353 France 355 Email: christian.jacquenet@orange.com