idnits 2.17.1 draft-zimmermann-tcpm-echo-option-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 seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- The document date (June 30, 2015) is 3223 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) == Outdated reference: A later version (-13) exists of draft-ietf-tcpm-tcp-edo-01 -- Obsolete informational reference (is this intentional?): RFC 1072 (Obsoleted by RFC 1323, RFC 2018, RFC 6247) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TCP Maintenance and Minor Extensions (tcpm) A. Zimmermann 3 Internet-Draft R. Scheffenegger 4 Intended status: Standards Track NetApp, Inc. 5 Expires: January 1, 2016 B. Briscoe 7 June 30, 2015 9 The TCP Echo and TCP Echo Reply Options 10 draft-zimmermann-tcpm-echo-option-00 12 Abstract 14 This document specifies the TCP Echo and TCP Echo Reply options. It 15 provides a single field a TCP sender can use to store any type of 16 data that a TCP receiver simply echo unmodified back. In contrast to 17 the original TCP Echo and TCP Echo Reply options defined in RFC 1072 18 the options specified in this document have slightly different 19 semantics and support a variable option length. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on January 1, 2016. 38 Copyright Notice 40 Copyright (c) 2015 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 1. Introduction 55 This document specifies the TCP Echo and TCP Echo Reply options. It 56 provides a single field a TCP sender can use to store any type of 57 data that a TCP receiver simply echo unmodified back. In contrast to 58 the original TCP Echo and TCP Echo Reply options defined in RFC 1072 59 [RFC1072] the options specified in this document have a slightly 60 different semantics and support a variable option length. 62 2. Terminology 64 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 65 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 66 document are to be interpreted as described in [RFC2119]. These 67 words only have such normative significance when in ALL CAPS, not 68 when in lower case. 70 3. The TCP Echo and TCP Echo Reply options 72 The general structure of TCP options is defined in [RFC0793]. The 73 TCP Echo option is organized as indicated in Figure 1. 75 0 1 2 76 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 ... 77 +---------------+---------------+-------- ... ------+ 78 | Kind A | Length | Data | 79 +---------------+---------------+-------- ... ------+ 81 Figure 1: The TCP Echo option 83 The codepoint value of the TCP Echo 'Kind A' is {ToDo: Value TBA}. 84 The value of the 'Length' field in octets can be any value greater 85 than 1 as long as the TCP Echo option completely fits into TCP option 86 space, which may be extended (see [RFC0793], [I-D.ietf-tcpm-tcp-edo], 87 [I-D.briscoe-tcpm-inner-space]). The optional 'Data' field is 88 available for the TCP sender to fill with any amount of any type of 89 data it wishes to be send back by the TCP receiver in a subsequent 90 TCP Echo Reply option (see Figure 2). It is only be constrained in 91 size to an integer number of octets. 93 The TCP Echo facility is determined in both directions using a single 94 exchange during the 3-way handshake [RFC0793]. A TCP seeking to use 95 TCP Echo facility includes the TCP Echo option in the initial SYN or 96 SYN/ACK. If the TCP receiver of that SYN or SYN/ACK agrees to 97 support TCP Echo facility, it MUST respond with TCP Echo Reply option 98 (see Figure 2) in its corresponding segment. 100 Both TCP endpoints MAY use the TCP Echo facility in any segment, but 101 only if the TCP Echo option was received in a segment with the SYN 102 bit set (i.e., SYN and SYN/ACK) or the TCP Echo Reply option was 103 received in response to a sent TCP Echo option. In all cases an 104 endpoint MUST NOT include more than one TCP Echo option per segment. 106 A TCP sender MAY send an empty TCP Echo option with Length=2 on the 107 SYN, to only indicate that it supports the TCP Echo facility. In 108 that case, the TCP receiver of that SYN MUST response with and empty 109 TCP Echo Reply option with Length=2 accordingly. 111 The TCP Echo Reply option is organized as indicated in Figure 2. 113 0 1 2 114 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 ... 115 +---------------+---------------+-------- ... ------+ 116 | Kind B | Length | Data | 117 +---------------+---------------+-------- ... ------+ 119 Figure 2: The TCP Echo Reply Option 121 A TCP receiver that does not implement the TCP Echo facility or 122 decides to not use the TCP Echo facility for this particular 123 connection MUST silently ignore any TCP Echo options it receives for 124 this connection. If the TCP receiver has reflected the TCP Echo 125 option in its SYN/ACK during the 3-way handshake, it MUST reply to 126 any TCP Echo option received during this connection. 128 Once enabled on a connection, a TCP receiver that receives a TCP Echo 129 option MUST return the same bytes of the Data field in a TCP Echo 130 Reply option. This TCP Echo Reply option MUST returned in the next 131 segment (e.g., an ACK segment) that is sent. If due to the delayed 132 ACK algorithm [RFC1122] more than one TCP Echo option is received 133 before a reply segment is sent, the TCP receiver MUST choose only one 134 of the options to echo, ignoring the others; specifically, it MUST 135 choose the most recently received TCP Echo option to echo back (i.e. 136 Last In, First Out - LIFO). 138 4. IANA Considerations 140 This specification requires IANA to allocate a value from the TCP 141 option kind name-space against the name 143 'Kind A' 144 'Kind B' 146 Early implementation before the IANA allocation MUST follow [RFC6994] 147 and use experimental option 254 and respective Experiment ID: 149 0xEC01 (16 bits) for the TCP Echo option; 150 0xEC02 (16 bits) for the TCP Echo Reply option; 152 The Echo option defined in RFC1072 [RFC1072] specifies different 153 semantics, which do not lend themselves for reuse. Specifically, 154 RFC1072 [RFC1072] specifies to select the TCP Echo option data from 155 the newest segment with the oldest sequence number, while herein we 156 specify to return the TCP Echo option of the most recently received 157 segment, regardless of sequence numbers. 159 {ToDo: Values TBA and register them with IANA} then migrate to the 160 assigned option after allocation.} 162 5. Security Considerations 164 An implementation should not rely on this facility for critical TCP 165 mechanisms, before ensuring that the TCP Echo option data field is 166 reflected back properly and unmodified. If the TCP Echo option is 167 considered critical, a TCP mechanism should have means to verify the 168 integrity of the data contained in the TCP Echo Reply option. 169 Additionally, a malicious receiver or network device may infer the 170 utility of the data in a TCP Echo option, and interpret it for its 171 purposes. A designer using the TCP Echo facility needs to consider 172 this, and take appropriate measures to prevent misuse of the data 173 sent. 175 Since TCP options are not delivered reliably, a TCP Echo or TCP Echo 176 Reply option may be lost or reordered at any time, a TCP mechanisms 177 MUST to deal appropriately with this occurrences. 179 If multiple TCP mechanisms want to make use of the TCP Echo facility, 180 the implementer should accommodate for that, for example by encoding 181 the multiple inputs accordingly into the data field of the TCP Echo 182 option. 184 Some middleboxes have been known to remove TCP options unknown to 185 them like those described in this document (see [Honda11]). As the 186 TCP Echo and TCP Echo Reply option use two different option numbers, 187 it is conceivable that only one or the other may get stripped from a 188 segment, in one direction, resulting in an unidirectional usability 189 of the TCP Echo facility. 191 6. Privacy Considerations 193 This document describes a new mechanism to tag individual TCP 194 segments. However, the TCP options described do not expose 195 individual user's data. In order to better maintain the 196 confidentiality of data exchanged on the wire, and to address some 197 aspects of security, it is NOT RECOMMENDED to send easily 198 decipherable data in the clear as data in the TCP Echo option. 200 7. Acknowledgements 202 Alexander Zimmermann have received funding from the European Union's 203 Horizon 2020 research and innovation program 2014-2018 under grant 204 agreement No. 644866 (SSICLOPS). This document reflects only the 205 authors' views and the European Commission is not responsible for any 206 use that may be made of the information it contains. 208 8. References 210 8.1. Normative References 212 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 213 793, September 1981. 215 [RFC1122] Braden, R., "Requirements for Internet Hosts - 216 Communication Layers", STD 3, RFC 1122, October 1989. 218 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 219 Requirement Levels", BCP 14, RFC 2119, March 1997. 221 [RFC6994] Touch, J., "Shared Use of Experimental TCP Options", RFC 222 6994, August 2013. 224 8.2. Informative References 226 [Honda11] Honda, M., Nishida, Y., Raiciu, C., Greenhalgh, A., 227 Handley, M., and H. Tokuda, "Is it still possible to 228 extend TCP?", Proc. of ACM Internet Measurement Conference 229 (IMC) '11, November 2011. 231 [I-D.briscoe-tcpm-inner-space] 232 Briscoe, B., "Inner Space for TCP Options", draft-briscoe- 233 tcpm-inner-space-01 (work in progress), October 2014. 235 [I-D.ietf-tcpm-tcp-edo] 236 Touch, J. and W. Eddy, "TCP Extended Data Offset Option", 237 draft-ietf-tcpm-tcp-edo-01 (work in progress), October 238 2014. 240 [RFC1072] Jacobson, V. and R. Braden, "TCP extensions for long-delay 241 paths", RFC 1072, October 1988. 243 Authors' Addresses 245 Alexander Zimmermann 246 NetApp, Inc. 247 Sonnenallee 1 248 Kirchheim 85551 249 Germany 251 Phone: +49 89 900594712 252 Email: alexander.zimmermann@netapp.com 254 Richard Scheffenegger 255 NetApp, Inc. 256 Am Euro Platz 2 257 Vienna 1120 258 Austria 260 Email: rs@netapp.com 262 Bob Briscoe 264 Email: ietf@bobbriscoe.net 265 URI: http://bobbriscoe.net/