idnits 2.17.1 draft-boucadair-mptcp-symmetric-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 : ---------------------------------------------------------------------------- ** There are 10 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 (March 9, 2015) is 3330 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 (-04) exists of draft-ietf-mptcp-attacks-03 == Outdated reference: A later version (-07) exists of draft-ietf-mptcp-experience-01 == Outdated reference: A later version (-09) exists of draft-ietf-pcp-proxy-06 Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Boucadair 3 Internet-Draft C. Jacquenet 4 Updates: 6824 (if approved) France Telecom 5 Intended status: Experimental March 9, 2015 6 Expires: September 10, 2015 8 An Extension to MPTCP for Symmetrical Sub-Flow Management 9 draft-boucadair-mptcp-symmetric-02 11 Abstract 13 This document specifies a MPTCP extension that allows to achieve 14 symmetrical subflow management. In particular, this extension allows 15 both endpoints to add new subflows whenever needed without waiting 16 for the endpoint which initiated the first subflow to add new ones. 18 This document updates RFC 6824. 20 Requirements Language 22 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 23 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 24 document are to be interpreted as described in RFC 2119 [RFC2119]. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on September 10, 2015. 43 Copyright 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 61 2. Problem Space . . . . . . . . . . . . . . . . . . . . . . . . 2 62 3. Proposed Solution . . . . . . . . . . . . . . . . . . . . . . 3 63 4. Security Considerations . . . . . . . . . . . . . . . . . . . 5 64 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 65 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 66 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 67 7.1. Normative References . . . . . . . . . . . . . . . . . . 6 68 7.2. Informative References . . . . . . . . . . . . . . . . . 6 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 71 1. Introduction 73 This document specifies a MPTCP [RFC6824] extension to achieve 74 symmetrical subflow management. The problem space is further 75 described in Section 2, while a proposed solution is discussed in 76 Section 3. 78 This document assumes Port Control Protocol (PCP)-enabled networks 79 [RFC6887]. But other procedures can be used to instantiate mappings 80 and discover the external lP address/port assigned by an upstream 81 flow-aware device (e.g., CGN [RFC6888], firewall, etc.). 83 2. Problem Space 85 The following is extracted from[I-D.ietf-mptcp-experience]: 87 From a subflow viewpoint, the Multipath TCP protocol is completely 88 symmetrical. Both the clients and the server have the capability 89 to create subflows. However in practice the existing Multipath 90 TCP implementations [I-D.eardley-mptcp-implementations-survey] 91 have opted for a strategy where only the client creates new 92 subflows. The main motivation for this strategy is that often the 93 client resides behind a NAT or a firewall, preventing passive 94 subflow openings on the client. 96 This means that in practice only the client (that is the TCP endpoint 97 that initiated the first subflow) can initiate new subflows. This is 98 not optimal in situations where (1) the remote endpoints want to 99 boost their sending rate or handover to a new IP address without 100 waiting for the client to add new subflows, (2) or when the traffic 101 distribution as observed by the remote endpoint does not meet its 102 local policies. Adding new subflows should be subject to both the 103 client's and server's local policies, not only those of the client. 105 3. Proposed Solution 107 This procedure can be activated upon bootstrap or when a network 108 attachment change occurs (e.g., attach to a new network); it is not 109 executed for every new MPTCP connection: 111 o Each endpoint proceeds to the discovery of upstream flow-aware 112 devices (e.g., NAT, Firewall). 114 This can be achieved by various means, e.g., using UPnP IGD 115 [IGD1][IGD2], PCP server discovery [RFC6887], PCP DHCP option 116 [RFC7291], DS-Lite AFTR [RFC6334], etc. 118 A NAT/firewall can be embedded in a CPE (Customer Premises 119 Equipment) and/or hosted in the network provider's side. 121 o Appropriate mappings are instantiated in those discovered flow- 122 aware devices. In particular, external IP address(es) and port 123 numbers are retrieved. 125 This can be achieved using PCP [RFC6887]. Note, mappings created 126 by PCP MAP requests are, by definition, endpoint-independent 127 mappings (EIMs) with endpoint-independent filtering (EIF). 128 Filters can be associated with the PCP MAP request to restrict a 129 mapping to be bound to specific remote peer(s). 131 PCP allows to dynamically control both NATs and firewalls. 132 Furthermore, PCP allows to retrieve the lifetime associated with 133 an external IP address and external port number. 135 If the host is a UPnP IGD Control Point, [RFC6970] allows to relay 136 UPnP IGD primitives into PCP messages. PCP can also be used to 137 control multi-layered NATs/firewall owing to the activation of 138 [I-D.ietf-pcp-proxy] in intermediate NATs/firewalls. 140 o When initiating an MPTCP connection, external IP addresses and 141 port numbers are communicated to the remote peer. 143 This can be achieved using ADD_ADDR together with a new option 144 that will indicate that the address/port pair (identified by 145 Address ID) enclosed in ADD_ADDR has been checked so that incoming 146 flows can be sent to this address/port. 148 A second implementation flavor is to define a new option, similar 149 to ADD_ADDR, but which will include an optional field (lifetime). 150 The lifetime can be used as an input to the traffic management 151 block at the remote side. This field can be derived from the 152 lease returned in DHCP, or in PCP requests. The use of this 153 option is an indication that appropriate actions were undertaken 154 at the remote side to receive incoming packets. A remote peer can 155 use the enclosed address/port to add a new subflow without any 156 risk to experience failures at the client side. Indicating the 157 lifetime associated with an IP address is seen as a limitation of 158 current APIs as discussed in Section-3.2.1 of [RFC6250]. The 159 lifetime can be used as a hint to migrate flows to another 160 subflows. 162 Another implementation flavor is to update ADD_ADDR as shown in 163 Figure 1. "IPVer" is useless since the length is sufficient to 164 determine whether the enclosed IP address is IPv4 or IPv6. 166 OLD: 167 1 2 3 168 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 169 +---------------+---------------+--------+--------+---------------+ 170 | Kind | Length |ADD_ADDR| IPVer | Address ID | 171 +---------------+---------------+--------+--------+---------------+ 172 | Address (IPv4 - 4 octets / IPv6 - 16 octets) | 173 +-------------------------------+---------------------------------+ 174 | Port (2 octets) | 175 +-------------------------------+ 177 NEW: 178 1 2 3 179 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 180 +---------------+---------------+--------+--------+---------------+ 181 | Kind | Length |ADD_ADDR| Flags | Address ID | 182 +---------------+---------------+--------+--------+---------------+ 183 | Address (IPv4 - 4 octets / IPv6 - 16 octets) | 184 +-------------------------------+---------------------------------+ 185 | Port (2 octets) | 186 +-------------------------------+ 188 +-+-+-+-+ 189 Flags is a set of 4 flags: |C|r|r|r| 190 +-+-+-+-+ 192 C flag MUST be set to 1 when the address/port are checked. 193 "rrr" are for future assignment as additional flag bits. 194 r bits MUST each be sent as zero and MUST be ignored on receipt. 196 Figure 1 198 4. Security Considerations 200 PCP-related security considerations are discussed in [RFC6887]. 201 MPTCP-related security considerations are documented in [RFC6824] and 202 [I-D.ietf-mptcp-attacks]. 204 5. IANA Considerations 206 TBC. 208 6. Acknowledgements 210 Many thank to Olivier Bonaventure who suggested the idea of updating 211 ADD_ADDR. 213 7. References 215 7.1. Normative References 217 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 218 Requirement Levels", BCP 14, RFC 2119, March 1997. 220 [RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, 221 "TCP Extensions for Multipath Operation with Multiple 222 Addresses", RFC 6824, January 2013. 224 7.2. Informative References 226 [I-D.eardley-mptcp-implementations-survey] 227 Eardley, P., "Survey of MPTCP Implementations", draft- 228 eardley-mptcp-implementations-survey-02 (work in 229 progress), July 2013. 231 [I-D.ietf-mptcp-attacks] 232 Bagnulo, M., Paasch, C., Gont, F., Bonaventure, O., and C. 233 Raiciu, "Analysis of MPTCP residual threats and possible 234 fixes", draft-ietf-mptcp-attacks-03 (work in progress), 235 February 2015. 237 [I-D.ietf-mptcp-experience] 238 Bonaventure, O., Paasch, C., and G. Detal, "Experience 239 with Multipath TCP", draft-ietf-mptcp-experience-01 (work 240 in progress), March 2015. 242 [I-D.ietf-pcp-proxy] 243 Perreault, S., Boucadair, M., Penno, R., Wing, D., and S. 244 Cheshire, "Port Control Protocol (PCP) Proxy Function", 245 draft-ietf-pcp-proxy-06 (work in progress), December 2014. 247 [IGD1] UPnP Forum, , "WANIPConnection:1 Service 248 (http://www.upnp.org/specs/gw/ 249 UPnP-gw-WANIPConnection-v1-Service.pdf)", November 2001. 251 [IGD2] UPnP Forum, , "WANIPConnection:2 Service 252 (http://upnp.org/specs/gw/ 253 UPnP-gw-WANIPConnection-v2-Service.pdf)", September 2010. 255 [RFC6250] Thaler, D., "Evolution of the IP Model", RFC 6250, May 256 2011. 258 [RFC6334] Hankins, D. and T. Mrugalski, "Dynamic Host Configuration 259 Protocol for IPv6 (DHCPv6) Option for Dual-Stack Lite", 260 RFC 6334, August 2011. 262 [RFC6887] Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. 263 Selkirk, "Port Control Protocol (PCP)", RFC 6887, April 264 2013. 266 [RFC6888] Perreault, S., Yamagata, I., Miyakawa, S., Nakagawa, A., 267 and H. Ashida, "Common Requirements for Carrier-Grade NATs 268 (CGNs)", BCP 127, RFC 6888, April 2013. 270 [RFC6970] Boucadair, M., Penno, R., and D. Wing, "Universal Plug and 271 Play (UPnP) Internet Gateway Device - Port Control 272 Protocol Interworking Function (IGD-PCP IWF)", RFC 6970, 273 July 2013. 275 [RFC7291] Boucadair, M., Penno, R., and D. Wing, "DHCP Options for 276 the Port Control Protocol (PCP)", RFC 7291, July 2014. 278 Authors' Addresses 280 Mohamed Boucadair 281 France Telecom 282 Rennes 35000 283 France 285 Email: mohamed.boucadair@orange.com 287 Christian Jacquenet 288 France Telecom 289 Rennes 35000 290 France 292 Email: christian.jacquenet@orange.com