idnits 2.17.1 draft-boucadair-mptcp-probe-subflow-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 (July 6, 2015) is 3216 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 6824 (Obsoleted by RFC 8684) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 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 July 6, 2015 6 Expires: January 7, 2016 8 Probing MPTCP Subflows 9 draft-boucadair-mptcp-probe-subflow-00 11 Abstract 13 This document specifies an extension to Multipath TCP (MPTCP) that is 14 meant to assess whether a path used to establish a given subflow is 15 MPTCP-friendly, i.e., intermediate nodes involved in that path do not 16 alter nor strip MPTCP options, which would prevent the establishment 17 of MPTCP communications along that path. A new flag bit, called 18 Probe Flag (P-flag) is defined for this purpose. 20 This document updates RFC6824. 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 January 7, 2016. 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. The Problem . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 3. Probe Flag (P-flag) . . . . . . . . . . . . . . . . . . . . . 3 65 4. Security Considerations . . . . . . . . . . . . . . . . . . . 6 66 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 67 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 68 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 69 7.1. Normative References . . . . . . . . . . . . . . . . . . 6 70 7.2. Informative References . . . . . . . . . . . . . . . . . 6 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 73 1. Introduction 75 This document specifies an extension to Multipath TCP (MPTCP, 76 [RFC6824]) that is meant to assess whether a path used to establish a 77 given subflow is MPTCP-friendly. That is, intermediate nodes 78 involved in that path do not alter nor strip MPTCP options, which 79 would prevent the establishment of MPTCP communications along that 80 path. 82 The problem is summarized briefly in Section 2 while the probe flag 83 is defined in Section 3. 85 The solution proposed in this document allows to anticipate failures 86 due to the presence of MPTCP-unfriendly devices in the communication 87 paths. 89 2. The Problem 91 MPTCP supports a backup mode that relies on a dedicated flag, called 92 backup flag carried in the MP_JOIN option: when set, this flag 93 informs the remote peer that this is a backup subflow. Several 94 problems may be arise such as. For example: 96 o A peer decides to use a backup subflow but MPTCP cannot be used 97 for that subflow because an intermediate function removes DSS 98 options, for example. This failure will have a negative impact on 99 the quality of experience. 101 o Several subflows can be candidate to be used as backup but the 102 participating nodes do not know in advance whether associated 103 forwarding paths are MPTCP-friendly, i.e., they can actually 104 support MPTCP subflows. The participating nodes need some "hints" 105 to decide which subflows are to be used as regular ones and those 106 as backup. This lack of information may also affect the perceived 107 quality of experience. 109 3. Probe Flag (P-flag) 111 As a solution to the problem described in Section 2, a meaning is 112 associated with one of the reserved bits in MP_JOIN. This new flag 113 bit is called: Probe Flag (P-flag). This flag bit is used to 114 explicitly inform the remote peer that a probing procedure is 115 associated with the corresponding subflow. 117 Figure 1 and Figure 2 show the required update to the MP_JOIN option 118 format in SYN and SYN/ACK. 120 OLD: 122 1 2 3 123 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 124 +---------------+---------------+-------+-----+-+---------------+ 125 | Kind | Length = 12 |Subtype| |B| Address ID | 126 +---------------+---------------+-------+-----+-+---------------+ 127 | Receiver's Token (32 bits) | 128 +---------------------------------------------------------------+ 129 | Sender's Random Number (32 bits) | 130 +---------------------------------------------------------------+ 132 NEW: 133 1 2 3 134 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 135 +---------------+---------------+-------+-+-+-+-+---------------+ 136 | Kind | Length = 12 |Subtype|r|r|P|B| Address ID | 137 +---------------+---------------+-------+-+-+-+-+---------------+ 138 | Receiver's Token (32 bits) | 139 +---------------------------------------------------------------+ 140 | Sender's Random Number (32 bits) | 141 +---------------------------------------------------------------+ 143 where "rr" are reserved bits for future assignment as 144 additional flag bits. r bits MUST each be sent as zero and MUST be 145 ignored on receipt. 147 Figure 1: Join Connection (MP_JOIN) Option (for Initial SYN) 149 OLD: 150 1 2 3 151 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 152 +---------------+---------------+-------+-----+-+---------------+ 153 | Kind | Length = 16 |Subtype| |B| Address ID | 154 +---------------+---------------+-------+-----+-+---------------+ 155 | | 156 | Sender's Truncated HMAC (64 bits) | 157 | | 158 +---------------------------------------------------------------+ 159 | Sender's Random Number (32 bits) | 160 +---------------------------------------------------------------+ 162 NEW: 163 1 2 3 164 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 165 +---------------+---------------+-------+-+-+-+-+---------------+ 166 | Kind | Length = 16 |Subtype|r|r|P|B| Address ID | 167 +---------------+---------------+-------+-+-+-+-+---------------+ 168 | | 169 | Sender's Truncated HMAC (64 bits) | 170 | | 171 +---------------------------------------------------------------+ 172 | Sender's Random Number (32 bits) | 173 +---------------------------------------------------------------+ 175 where "rr" are reserved bits for future assignment as 176 additional flag bits. r bits MUST each be sent as zero and MUST be 177 ignored on receipt. 179 Figure 2: Join Connection (MP_JOIN) Option (for Responding SYN/ACK) 181 When set, the P-Flag bit indicates to the remote peer that a probing 182 is associated with this subflow. The probing logic is to be further 183 defined in future versions of this specification. Only probing data 184 MUST be sent over a subflow that is tagged to be under probing. 185 Probing MUST NOT interfere with data exchange over regular subflows, 186 if any. 188 An MPTCP endpoint that receives an MP_JOIN with a P-flag set, MUST 189 echo the P-flag in the SYN/ACK if it supports the probing mechanism. 190 If not, the P-flag MUST be ignored (i.e., the P-flag of the MP_JOIN 191 included in the SYN/ACK must be set to 0). 193 P-flag can be set independently of the backup flag. 195 The handling of the B flag when P-flag is also set, is not altered by 196 this specification. 198 4. Security Considerations 200 MPTCP-related security considerations are documented in [RFC6824] and 201 [I-D.ietf-mptcp-attacks]. 203 5. IANA Considerations 205 This document does not require any action from IANA. 207 6. Acknowledgements 209 TBC 211 7. References 213 7.1. Normative References 215 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 216 Requirement Levels", BCP 14, RFC 2119, March 1997. 218 [RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, 219 "TCP Extensions for Multipath Operation with Multiple 220 Addresses", RFC 6824, January 2013. 222 7.2. Informative References 224 [I-D.ietf-mptcp-attacks] 225 Bagnulo, M., Paasch, C., Gont, F., Bonaventure, O., and C. 226 Raiciu, "Analysis of MPTCP residual threats and possible 227 fixes", draft-ietf-mptcp-attacks-04 (work in progress), 228 March 2015. 230 Authors' Addresses 232 Mohamed Boucadair 233 France Telecom 234 Rennes 35000 235 France 237 Email: mohamed.boucadair@orange.com 238 Christian Jacquenet 239 France Telecom 240 Rennes 35000 241 France 243 Email: christian.jacquenet@orange.com