idnits 2.17.1 draft-boucadair-mptcp-symmetric-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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (March 3, 2015) is 3343 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-00 == Outdated reference: A later version (-09) exists of draft-ietf-pcp-proxy-06 Summary: 1 error (**), 0 flaws (~~), 5 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 Intended status: Experimental France Telecom 5 Expires: September 4, 2015 March 3, 2015 7 An Extension to MPTCP for Symmetrical Sub-Flow Management 8 draft-boucadair-mptcp-symmetric-00 10 Abstract 12 This document specifies a MPTCP extension that allows to achieve 13 symmetrical subflow management. In particular, this extension allows 14 both endpoints to add new subflows whenever needed without waiting 15 for the endpoint which initiated the first subflow to add new ones. 17 Requirements Language 19 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 20 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 21 document are to be interpreted as described in RFC 2119 [RFC2119]. 23 Status of This Memo 25 This Internet-Draft is submitted 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). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 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 This Internet-Draft will expire on September 4, 2015. 40 Copyright Notice 42 Copyright (c) 2015 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Problem Space . . . . . . . . . . . . . . . . . . . . . . . . 2 59 3. Proposed Solution . . . . . . . . . . . . . . . . . . . . . . 3 60 4. Security Considerations . . . . . . . . . . . . . . . . . . . 4 61 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 62 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4 63 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 7.1. Normative References . . . . . . . . . . . . . . . . . . 4 65 7.2. Informative References . . . . . . . . . . . . . . . . . 5 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 68 1. Introduction 70 This document specifies a MPTCP [RFC6824] extension to achieve 71 symmetrical subflow management. The problem space is further 72 described in Section 2, while a proposed solution is discussed in 73 Section 3. 75 This document assumes Port Control Protocol (PCP)-enabled networks 76 [RFC6887]. But other procedures can be used to instantiate mappings 77 and discover the external lP address/port assigned by an upstream 78 flow-aware device (e.g., CGN [RFC6888], firewall, etc.). 80 2. Problem Space 82 The following is extracted from[I-D.ietf-mptcp-experience]: 84 From a subflow viewpoint, the Multipath TCP protocol is completely 85 symmetrical. Both the clients and the server have the capability 86 to create subflows. However in practice the existing Multipath 87 TCP implementations [I-D.eardley-mptcp-implementations-survey] 88 have opted for a strategy where only the client creates new 89 subflows. The main motivation for this strategy is that often the 90 client resides behind a NAT or a firewall, preventing passive 91 subflow openings on the client. 93 This means that in practice only the client (that is the TCP endpoint 94 that initiated the first subflow) can initiate new subflows. This is 95 not optimal in situations where (1) the remote endpoints want to 96 boost their sending rate or handover to a new IP address without 97 waiting for the client to add new subflows, (2) or when the traffic 98 distribution as observed by the remote endpoint does not meet its 99 local policies. Adding new subflows should be subject to both the 100 client's and server's local policies, not only those of the client. 102 3. Proposed Solution 104 This procedure can be activated upon bootstrap or when a network 105 attachment change occurs (e.g., attach to a new network); it is not 106 executed for every new MPTCP connection: 108 o Each endpoint proceeds to the discovery of upstream flow-aware 109 devices (e.g., NAT, Firewall). 111 This can be achieved by various means, e.g., using UPnP IGD 112 [IGD1][IGD2], PCP server discovery [RFC6887], PCP DHCP option 113 [RFC7225], DS-Lite AFTR [RFC6334], etc. 115 A NAT/firewall can be embedded in a CPE (Customer Premises 116 Equipment) and/or hosted in the network provider's side. 118 o Appropriate mappings are instantiated in those discovered flow- 119 aware devices. In particular, external IP address(es) and port 120 numbers are retrieved. 122 This can be achieved using PCP [RFC6887]. Note, mappings created 123 by PCP MAP requests are, by definition, endpoint-independent 124 mappings (EIMs) with endpoint-independent filtering (EIF). 125 Filters can be associated with the PCP MAP request to restrict a 126 mapping to be bound to specific remote peer(s). 128 PCP allows to dynamically control both NATs and firewalls. 129 Furthermore, PCP allows to retrieve the lifetime associated with 130 an external IP address and external port number. 132 If the host is a UPnP IGD Control Point, [RFC6970] allows to relay 133 UPnP IGD primitives into PCP messages. PCP can also be used to 134 control multi-layered NATs/firewall owing to the activation of 135 [I-D.ietf-pcp-proxy] in intermediate NATs/firewalls. 137 o When initiating an MPTCP connection, external IP addresses and 138 port numbers are communicated to the remote peer. 140 This can be achieved using ADD_ADDR together with a new option 141 that will indicate that the address/port pair (identified by 142 Address ID) enclosed in ADD_ADDR has been checked so that incoming 143 flows can be sent to this address/port. 145 Another implementation flavor is to define a new option, similar 146 to ADD_ADDR, but which will include an optional field (lifetime). 147 The lifetime can be used as an input to the traffic management 148 block at the remote side. This field can be derived from the 149 lease returned in DHCP, or in PCP requests. The use of this 150 option is an indication that appropriate actions were undertaken 151 at the remote side to receive incoming packets. A remote peer can 152 use the enclosed address/port to add a new subflow without any 153 risk to experience failures at the client side. 155 1 2 3 156 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 157 +---------------+---------------+-------+-------+---------------+ 158 | Kind | Length |TBD | IPVer | Address ID | 159 +---------------+---------------+-------+-------+---------------+ 160 | Address (IPv4 - 4 octets / IPv6 - 16 octets) | 161 +-------------------------------+-------------------------------+ 162 | Port (2 octets) |Lifetime (Optional) (4 octets) | 163 +-------------------------------+-------------------------------+ 164 | Lifetime (Optional)(continued)| 165 +-------------------------------+ 167 4. Security Considerations 169 PCP-related security considerations are discussed in [RFC6887]. 170 MPTCP-related security considerations are documented in [RFC6824] and 171 [I-D.ietf-mptcp-attacks]. 173 5. IANA Considerations 175 TBC. 177 6. Acknowledgements 179 TBC 181 7. References 183 7.1. Normative References 185 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 186 Requirement Levels", BCP 14, RFC 2119, March 1997. 188 [RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, 189 "TCP Extensions for Multipath Operation with Multiple 190 Addresses", RFC 6824, January 2013. 192 7.2. Informative References 194 [I-D.eardley-mptcp-implementations-survey] 195 Eardley, P., "Survey of MPTCP Implementations", draft- 196 eardley-mptcp-implementations-survey-02 (work in 197 progress), July 2013. 199 [I-D.ietf-mptcp-attacks] 200 Bagnulo, M., Paasch, C., Gont, F., Bonaventure, O., and C. 201 Raiciu, "Analysis of MPTCP residual threats and possible 202 fixes", draft-ietf-mptcp-attacks-03 (work in progress), 203 February 2015. 205 [I-D.ietf-mptcp-experience] 206 Bonaventure, O., Paasch, C., and G. Detal, "Experience 207 with Multipath TCP", draft-ietf-mptcp-experience-00 (work 208 in progress), September 2014. 210 [I-D.ietf-pcp-proxy] 211 Perreault, S., Boucadair, M., Penno, R., Wing, D., and S. 212 Cheshire, "Port Control Protocol (PCP) Proxy Function", 213 draft-ietf-pcp-proxy-06 (work in progress), December 2014. 215 [IGD1] UPnP Forum, , "WANIPConnection:1 Service 216 (http://www.upnp.org/specs/gw/ 217 UPnP-gw-WANIPConnection-v1-Service.pdf)", November 2001. 219 [IGD2] UPnP Forum, , "WANIPConnection:2 Service 220 (http://upnp.org/specs/gw/ 221 UPnP-gw-WANIPConnection-v2-Service.pdf)", September 2010. 223 [RFC6334] Hankins, D. and T. Mrugalski, "Dynamic Host Configuration 224 Protocol for IPv6 (DHCPv6) Option for Dual-Stack Lite", 225 RFC 6334, August 2011. 227 [RFC6887] Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. 228 Selkirk, "Port Control Protocol (PCP)", RFC 6887, April 229 2013. 231 [RFC6888] Perreault, S., Yamagata, I., Miyakawa, S., Nakagawa, A., 232 and H. Ashida, "Common Requirements for Carrier-Grade NATs 233 (CGNs)", BCP 127, RFC 6888, April 2013. 235 [RFC6970] Boucadair, M., Penno, R., and D. Wing, "Universal Plug and 236 Play (UPnP) Internet Gateway Device - Port Control 237 Protocol Interworking Function (IGD-PCP IWF)", RFC 6970, 238 July 2013. 240 [RFC7225] Boucadair, M., "Discovering NAT64 IPv6 Prefixes Using the 241 Port Control Protocol (PCP)", RFC 7225, May 2014. 243 Authors' Addresses 245 Mohamed Boucadair 246 France Telecom 247 Rennes 35000 248 France 250 Email: mohamed.boucadair@orange.com 252 Christian Jacquenet 253 France Telecom 254 Rennes 35000 255 France 257 Email: christian.jacquenet@orange.com