idnits 2.17.1 draft-boucadair-tcpm-capability-option-01.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 (December 8, 2016) is 2695 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) == Outdated reference: A later version (-13) exists of draft-ietf-tcpm-tcp-edo-06 == Outdated reference: A later version (-12) exists of draft-touch-tcpm-tcp-syn-ext-opt-05 -- Obsolete informational reference (is this intentional?): RFC 6824 (Obsoleted by RFC 8684) 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 Orange 5 Expires: June 11, 2017 December 8, 2016 7 TCP Capability Option 8 draft-boucadair-tcpm-capability-option-01 10 Abstract 12 This document defines an experimental TCP option that can be used to 13 negotiate a set of options that are supported by two TCP endpoints. 14 The main motivation for designing this option is the optimization of 15 the option space for SYN segments. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on June 11, 2017. 34 Copyright Notice 36 Copyright (c) 2016 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 1.1. Applicability . . . . . . . . . . . . . . . . . . . . . . 3 53 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 3 54 2. TCP Capability Option . . . . . . . . . . . . . . . . . . . . 3 55 3. Security Considerations . . . . . . . . . . . . . . . . . . . 4 56 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 57 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 5.1. Normative References . . . . . . . . . . . . . . . . . . 4 59 5.2. Informative References . . . . . . . . . . . . . . . . . 5 60 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 62 1. Introduction 64 TCP ([RFC0793]) can be extended by defining new options. Because of 65 the presence of NATs, firewalls, and other types of flow-aware 66 service functions between two TCP endpoints, means to ensure that 67 both endpoints support a given option, and that the paths used to 68 forward traffic between them do not involve nodes that strip or alter 69 the content of the options. This is actually achieved by negotiating 70 the support of a given option during the 3WHS stage. 72 Typically, an option is included in the SYN message to inform the 73 remote TCP peer that the originating TCP peer is "X"-capable (that 74 is, it supports feature "X"). Upon receipt of the SYN message, and 75 if no intermediary node has stripped that option, the remote peer 76 will echo that option in a SYN/ACK if and only if it is also "X"- 77 capable. Feature "X" can then be used if the SYN/ACK message that is 78 received by the originating peer still carries the "X"-capable; the 79 option must then be included in the ACK. 81 For example, several TCP extensions have been designed with this 82 design rationale in mind, e.g., SYN-EOS 83 [I-D.touch-tcpm-tcp-syn-ext-opt], EDO [I-D.ietf-tcpm-tcp-edo], SACK 84 Permitted [RFC2018], MP_CAPABLE [RFC6824], etc. In the meantime, and 85 given the limited TCP option space, it becomes more challenging to 86 include all options in a single SYN message. 88 Several solutions have been proposed to solve that problem (e.g., 89 [I-D.touch-tcpm-tcp-syn-ext-opt]) by means of generating a companion 90 TCP message. This document proposes a solution that aims to optimize 91 the required option space to facilitate the insertion of several "X"- 92 capable options. 94 1.1. Applicability 96 The option is primarily designed for network configurations where the 97 path between the TCP endpoints is managed (e.g., an MPTCP endpoint 98 embedded in the CPE and the remote MPTCP endpoint is located in the 99 network side; the paths between these endpoints are managed by the 100 same administrative entity such as in 101 [I-D.boucadair-mptcp-natfwfree-profile]). 103 A flow-aware device that removes the option will disable all the 104 options that were included in the TCP Capability option. This is not 105 supposed in the target deployment context for this option. 107 Some middleboxes may allow the TCP Capability option to pass through, 108 but the individual options may be blocked. This is not supposed in 109 the target deployment context for this option as those flow-aware 110 functions are managed. 112 1.2. Requirements Language 114 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 115 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 116 document are to be interpreted as described in RFC 2119 [RFC2119]. 118 2. TCP Capability Option 120 The format of the TCP Capability option is shown in Figure 1. The 121 option follows the format defined in [RFC0793]. 123 +--------+--------+--------+--------+ 124 | Kind | Length | Kind 1| Kind 2 | 125 +--------+--------+--------+--------+ 126 : .... |Kind n-1| Kind n | 127 +-------....------+--------+--------+ 129 Figure 1 131 "Kind" is to be assigned by IANA (see Section 4). 133 In order to conduct experiments with this option, a format that 134 adheres to [RFC6994] is used (see Figure 2). ExID MUST be set to 135 0x0CA0 (3232). 137 +--------+--------+--------+--------+ 138 | Kind | Length | ExID | 139 +--------+--------+--------+--------+ 140 : Kind 1 | Kind 2 | ... : 141 +-------....------+-----------------+ 143 Figure 2 145 "Kindi" carries the code point of an option that a TCP endpoint 146 supports and which it would like to negotiate with the remote peer. 147 One or multiple "Kindi" fields may be included. 149 An endpoint that wishes to enable the capabilities associated with 150 one or multiple TCP options must include the corresponding "Kind" 151 codes in a TCP Capability option, which is included in the initial 152 SYN. If the remote peer supports at least one of the options carried 153 in the TCP Capability option, it replies with a SYN/ACK that includes 154 the TCP Capability option and which only carries the code points of 155 the options it supports. These values are then echoed in the ACK 156 message the originating peer sends back to the remote peer. 158 When replying to a SYN message that includes a TCP Capability option, 159 the remote peer should preserve the same order of the "Kindi" fields 160 (of course, those that are not supported won't be included). 162 3. Security Considerations 164 The security considerations are to be completed. 166 4. IANA Considerations 168 IANA is requested to record the following identifier in the "TCP 169 Experimental Option Experiment Identifiers (TCP ExIDs)" registry: 171 Value Description Reference 172 0x0CA0 TCP Capability Option [This document] 174 5. References 176 5.1. Normative References 178 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 179 RFC 793, DOI 10.17487/RFC0793, September 1981, 180 . 182 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 183 Requirement Levels", BCP 14, RFC 2119, 184 DOI 10.17487/RFC2119, March 1997, 185 . 187 [RFC6994] Touch, J., "Shared Use of Experimental TCP Options", 188 RFC 6994, DOI 10.17487/RFC6994, August 2013, 189 . 191 5.2. Informative References 193 [I-D.boucadair-mptcp-natfwfree-profile] 194 Boucadair, M., Jacquenet, C., Seite, P., Bonaventure, O., 195 and D. Lingli, "An MPTCP Profile for NAT- and Firewall- 196 Free Networks: Network-Assisted MPTCP Deployments", draft- 197 boucadair-mptcp-natfwfree-profile-00 (work in progress), 198 July 2015. 200 [I-D.ietf-tcpm-tcp-edo] 201 Touch, J. and W. Eddy, "TCP Extended Data Offset Option", 202 draft-ietf-tcpm-tcp-edo-06 (work in progress), June 2016. 204 [I-D.touch-tcpm-tcp-syn-ext-opt] 205 Touch, J. and T. Faber, "TCP SYN Extended Option Space 206 Using an Out-of-Band Segment", draft-touch-tcpm-tcp-syn- 207 ext-opt-05 (work in progress), October 2016. 209 [RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP 210 Selective Acknowledgment Options", RFC 2018, 211 DOI 10.17487/RFC2018, October 1996, 212 . 214 [RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, 215 "TCP Extensions for Multipath Operation with Multiple 216 Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013, 217 . 219 Authors' Addresses 221 Mohamed Boucadair 222 Orange 223 Rennes 35000 224 France 226 Email: mohamed.boucadair@orange.com 227 Christian Jacquenet 228 Orange 229 Rennes 35000 230 France 232 Email: christian.jacquenet@orange.com