idnits 2.17.1 draft-scheffenegger-tcpm-timestamp-negotiation-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 == Line 241 has weird spacing: '...EXP12hi and...' == Line 258 has weird spacing: '...RAC12hi and...' == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: RES - Reserved Reserved for future use. MUST not be set ("0"). If a timestamp option is received with this bit set, the receiver MUST ignore the extended options field and react as if the Flags were not set (compatibility mode). -- The document date (March 7, 2011) is 4793 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) == Unused Reference: 'Chirp' is defined on line 337, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-tcpm-tcp-security' is defined on line 341, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1323 (Obsoleted by RFC 7323) == Outdated reference: A later version (-03) exists of draft-ietf-tcpm-tcp-security-02 Summary: 1 error (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TCP Maintenance and Minor M. Kuehlewind 3 Extensions (tcpm) University of Stuttgart 4 Internet-Draft R. Scheffenegger, Ed. 5 Intended status: Standards Track NetApp, Inc. 6 Expires: September 8, 2011 March 7, 2011 8 Additional negotiation in the TCP Timestamp Option field 9 during the TCP handshake 10 draft-scheffenegger-tcpm-timestamp-negotiation-00 12 Abstract 14 RFC 1323 defines the TSecr field of a SYN packet to be not valid and 15 thus this field will always be zero. This documents specifies the 16 use of this field to signal and negotiate additional information 17 about the content of the TSopt field as well as the behavior of the 18 receiver. If the receiver understands this extension, it will use 19 the TSecr field of the SYN/ACK to reply. Otherwise the receiver will 20 ignore the TSecr field and set a timestamp in the TSecr field as 21 specified in RFC 1323. 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 8, 2011. 40 Copyright Notice 42 Copyright (c) 2011 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 1.1. Requirements Language . . . . . . . . . . . . . . . . . . . 4 59 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 60 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . 5 61 4. Signaling . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 62 4.1. Capability Flags . . . . . . . . . . . . . . . . . . . . . 5 63 5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 8 64 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 65 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 9 66 8. Security Considerations . . . . . . . . . . . . . . . . . . . . 9 67 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 68 9.1. Normative References . . . . . . . . . . . . . . . . . . . 9 69 9.2. Informative References . . . . . . . . . . . . . . . . . . 9 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 72 1. Introduction 74 The TCP Timestamps Option (TSopt) provides timestamp echoing for 75 Round-trip Time (RTT) measurments. TSopt is widely deployed and 76 activated by default in many systems. RFC 1323 [RFC1323] specifies 77 TSopt the following way: 79 Kind: 8 81 Length: 10 bytes 83 +-------+-------+---------------------+---------------------+ 84 |Kind=8 | 10 | TS Value (TSval) |TS Echo Reply (TSecr)| 85 +-------+-------+---------------------+---------------------+ 86 1 1 4 4 88 RFC1323 TSopt 90 "The Timestamps option carries two four-byte timestamp fields. 91 The Timestamp Value field (TSval) contains the current value of 92 the timestamp clock of the TCP sending the option. 94 The Timestamp Echo Reply field (TSecr) is only valid if the ACK 95 bit is set in the TCP header; if it is valid, it echos a timestamp 96 value that was sent by the remote TCP in the TSval field of a 97 Timestamps option. When TSecr is not valid, its value must be 98 zero. The TSecr value will generally be from the most recent 99 Timestamp option that was received; however, there are exceptions 100 that are explained below. 102 A TCP may send the Timestamps option (TSopt) in an initial SYN 103 segment (i.e., segment containing a SYN bit and no ACK bit), and 104 may send a TSopt in other segments only if it received a TSopt in 105 the initial SYN segment for the connection." 107 The comparison of the timestamp in the TSecr field to the current 108 time gives an estimation of the RTT. RFC 1323 [RFC1323] specifies 109 various cases when more than one timestamp is available to echo. The 110 proposed solution might not always be the best choice, e.g. when the 111 TCP Selective Acknowledgment Option (SACK) is used. Moreover, more 112 and more use cases arise where one-way delay (OWD) measurements are 113 needed. These mechanism misuse usually the TSopt to estimated the 114 variation in OWD. To enable such mechanisms the TSecr field in the 115 TCP SYN packet could be used for additional negotiation. 117 1.1. Requirements Language 119 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 120 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 121 document are to be interpreted as described in [RFC2119]. 123 2. Overview 125 3. Definitions 127 The reader is expected to be familiar with the definitions given in 128 [RFC1323]. 130 4. Signaling 132 During the initial TCP three-way handshake, timestamp options are 133 negotiated using the TSecr field. A compliant TCP receiver will XOR 134 the flags with the received TSval, when responding with the SYN+ACK. 135 Timestamp Options MAY only be present when the SYN bit is set. 137 4.1. Capability Flags 139 In order to signal the supported capabilities, the TSecr is 140 overloaded with the following flags and fields during the three-way 141 handshake. If optional capabilities such as tcp clock range are 142 presented, minimal state will be required in the host to decode the 143 returned Flags xor'ed with the TSval. 145 Kind: 8 147 Length: 10 bytes 149 +-------+-------+---------------------+---------------------+ 150 |Kind=8 | 10 | TS Value (TSval) |TS Echo Reply (TSecr)| 151 +-------+-------+---------------------+---------------------+ 152 1 1 4 | 4 | 153 / | 154 .-----------------------------------' | 155 / \ 156 | | 157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 158 |E|R|R|B|M| | EXP12hi | FRAC12hi | EXP12lo | FRAC12lo | 159 |X|E|N|I|I| MSK +-----------------------+-----------------------+ 160 |O|S|G|A|R| | RES |S| EXP16 | FRAC16 | 161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 163 timestamp option flags 165 EXO - Extended Options 166 Indicated that the sender supports extended timestamp options as 167 defined by this document, and MUST be set ("1") by compliant 168 implementations. 170 RES - Reserved 171 Reserved for future use. MUST not be set ("0"). If a timestamp 172 option is received with this bit set, the receiver MUST ignore 173 the extended options field and react as if the Flags were not set 174 (compatibility mode). 176 RNG - Range negotiation 177 Indicated that the sender is capable of adjusting the timestamp 178 clock rate within the bounds of the two 12 bit fields (see ). 179 Only the active sender of a TCP session is allowed to offer a 180 range, while the receiver MAY choose a rate within these bounds. 182 BIA - Exponent Bias 183 When set, the 16 and 12 bit floating point exponents are 184 presented with a bias of 21 instead of 15. This allows 185 negotiation of extremely fine-grained timestamp clock 186 resolutions, for example in hardware implementations and high 187 speed (>10 Gigabit/s) environments. See section for more 188 details. 190 MIR - Always Mirror Timestamp 191 To disambiguate segements and aid timing calculations even during 192 loss episodes, the timestamp will always be mirrored regardless 193 of the state of the receiver. A sender SHOULD use this option 194 only in conjunction with Selective Acknowledgements (SACK 195 [RFC2018]). 197 MSK - Mask Timestamps 198 If the timestamp is used for congestion control purposes, an 199 incentive exists for malicious receivers to reflect tampered 200 timestamps. A sender MAY choose to protect timestamps from such 201 modifications by including a fingerprint (secure hash of some 202 kind) in some of the least significant bits. However, doing so 203 would prevent a receiver from using the timestamp for other 204 purposes. The MASK field indicates how many least significant 205 nibbles should be excluded by the receiver, when processing a 206 timestamp. Note that this does not impact the reflected 207 timestamp in any way - TSecr will always be equal to a 208 appropriate TSval. Another use case would be when the sender 209 does not support a timestamp clock which can guarantee unique 210 timestamps for retransmitted segments. For unambigously 211 identifying regular from retransmitted segments, the timestamp 212 must be unique for otherwise identical segments. Reserving the 213 lowest nibble for this purpose allows senders with slow running 214 timestamp clocks to make use of this feature. 216 S - binary16 Sign 217 This is the sign bit of the IEEE 754-2008 binary16 floating point 218 representation of the timestamp clock. Timestamp clocks MUST be 219 positive, thus this bit MUST be zero. 221 EXP16 - binary16 Exponent 222 The exponent component of a binary16 floating point number 223 indicating the timestamp clock. When BIA is not set, the 224 exponent bias is 15 (identical to the binary16 definition in IEEE 225 754-2008). If OFF is set, the exponent bias is 21, allowing 226 faster timestamp clock rates. Subnormal numbers (lower 227 precision), where the exponent is zero, extend the range to 2^-24 228 and 2^-30 respectively. Infinity and NaN (all exponent bits set) 229 MUST NOT be invalid, and a timestamp option with NaN/Infinity 230 SHOULD be ignored. 232 FRAC16 - binary16 Fraction 233 The fraction component of a binary16 floating point number 234 indicating the timestamp clock. The clock rate is measured in 235 seconds between ticks. The least significant bit corresponds 236 therefore to a time interval of 59.6 ns with the default bias of 237 15, and 0.931 ns with bias set to 21. The longest time interval 238 would be 65504 sec with default bias, and 511.75 sec with bias 239 set to 21. 241 EXP12hi and 243 EXP12lo - binary12 Exponent 244 The exponent component of a truncated, 12 bit floating point 245 number indicating the possible timestamp clock ranges. Only the 246 host initiating a TCP session MAY offer a timestamp clock range, 247 while the receiver SHOULD select a timestamp clock within these 248 bounds. If the receiver can not adjust it's timestamp clock to 249 match the range, it MAY use a timestamp clock rate outside these 250 bounds. If the receiver indicated a timestamp clock rate within 251 the indicated bounds, the sender MUST set it's timestamp clock 252 rate to the negotiated rate. If the receiver uses a timestamp 253 clock rate outside the indicated bounds, it MUST NOT use 254 timestamps where knowledge of the timestamp clock rate is 255 required (ie. congesion control). The exponent bias is 15 when 256 BIA is not set, and 21 otherwise. 258 FRAC12hi and 260 FRAC12lo - binary12 Fraction 261 The fraction component of a 12 bit floating point number. 262 Subnormal numbers are allowed, while Inifinity/NaN MUST NOT be 263 used. Timestamp options with Infinity/NaN values SHOULD be 264 ignored. The smallest representable value is 238 ns with default 265 bias, and 3.73 ns with bias set to 21, while the largest values 266 would be virtually identical to the 16 bit floating point values 267 (65024 and 508 sec). 269 5. Discussion 271 One-way delay (variation) based congestion controls would benefit 272 from knowing the clock resolution on both sides. 274 RTT variance during loss episodes is not deeply researched. Current 275 heuristics (RFC1122, RFC1323, Karn's algorithm, RFC2988) explicitly 276 exclude (and prevent) the use of RTT samples when loss occurs. 277 However, solving the retransmission ambiguity problem - and the 278 related reliable ACK delivery problem - may allow the refinement of 279 these algorithms further, as well as enabling new research to 280 distinguish between corruption loss (without RTT / one-way delay 281 impact) and congestion loss (with RTT / one-way delay impact). 282 Research into this field appears to be a rather neglected, especially 283 when it comes to large scale, public internet investigations. Due to 284 the very nature of this, passive investigations without signals 285 contained within the headers are only of limited use in empirical 286 research. 288 Retransmission ambiguity detection during loss recovery would allow 289 an additional level of loss recovery control without reverting to 290 timer-based methods. As with the deployment of SACK, separating 291 "what" to send from "when" to send it could be driven one step 292 further. In particular, less conservative loss recovery schemes 293 which do not trade principles of packet conservation against 294 timeliness, require a reliable way of prompt and best possible 295 feedback from the receiver about any delivered segment and their 296 ordering. SACK alone goes quite a long way, but using Timestamp 297 information in addition could remove any ambiguity. However, the 298 current specs in RFC1323 make that use impossible, thus a modified 299 signaling (receiver behavior) is a necessity. 301 6. Acknowledgements 303 The authors would like to thank Dragana Damjanovic for some initial 304 thoughts around Timestamps and their extended potential use. 306 7. IANA Considerations 308 This memo includes no request to IANA. 310 8. Security Considerations 312 The algorithm presented in this paper shares security considerations 313 with [RFC1323]. 315 Some implementations address the vulerabilities of [RFC1323], by 316 dedicating a few low-order bits of the timestamp fields for use with 317 a (secure) hash, that protects against malicious tweaking of TSecr 318 values. A Flag-field has been provided to transparently notify the 319 receiver about that use of low-order bits, so that they can be 320 excluded in one-way delay calculations. 322 9. References 324 9.1. Normative References 326 [RFC1323] Jacobson, V., Braden, B., and D. Borman, "TCP Extensions 327 for High Performance", RFC 1323, May 1992. 329 [RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP 330 Selective Acknowledgment Options", RFC 2018, October 1996. 332 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 333 Requirement Levels", BCP 14, RFC 2119, March 1997. 335 9.2. Informative References 337 [Chirp] Kuehlewind, M. and B. Briscoe, "Chirping for Congestion 338 Control - Implementation Feasibility", Nov 2010, . 341 [I-D.ietf-tcpm-tcp-security] 342 Gont, F., "Security Assessment of the Transmission Control 343 Protocol (TCP)", draft-ietf-tcpm-tcp-security-02 (work in 344 progress), January 2011. 346 Authors' Addresses 348 Mirja Kuehlewind 349 University of Stuttgart 350 Pfaffenwaldring 47 351 Stuttgart 70569 352 Germany 354 Email: mirja.kuehlewind@ikr.uni-stuttgart.de 356 Richard Scheffenegger (editor) 357 NetApp, Inc. 358 Am Euro Platz 2 359 Vienna, 1120 360 Austria 362 Phone: +43 1 3676811 3146 363 Email: rs@netapp.com