idnits 2.17.1 draft-bonaventure-mptcp-timestamp-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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC1323]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 122: '... A Multipath TCP implementation SHOULD not use the [RFC7323]...' RFC 2119 keyword, line 124: '... TCP connection SHOULD use the [RFC7323] timestamp option to protect...' RFC 2119 keyword, line 126: '... implementations SHOULD operate as fol...' RFC 2119 keyword, line 128: '...ipath TCP opener SHOULD place both the...' RFC 2119 keyword, line 135: '...tamp and the MP_CAPABLE options SHOULD...' (3 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == 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 'SHOULD not' in this paragraph: A Multipath TCP implementation SHOULD not use the [RFC7323] timestamps option on Multipath TCP connections. However, a regular TCP connection SHOULD use the [RFC7323] timestamp option to protect against wrapped sequence numbers. To achieve this objective, Multipath TCP implementations SHOULD operate as follows : -- The document date (July 02, 2015) is 3215 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 6824 (Obsoleted by RFC 8684) -- Obsolete informational reference (is this intentional?): RFC 1323 (Obsoleted by RFC 7323) Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MPTCP Working Group O. Bonaventure 3 Internet-Draft UCLouvain 4 Intended status: Experimental July 02, 2015 5 Expires: January 3, 2016 7 Multipath TCP timestamp option 8 draft-bonaventure-mptcp-timestamp-01 10 Abstract 12 The TCP timestamps defined in [RFC1323] were designed to improve 13 round-trip-time estimations and provide protection against wrapped 14 sequence numbers (PAWS). This draft clarifies the utilisation of 15 timestamps by Multipath TCP and proposes a new timestamp option that 16 better suits the needs of Multipath TCP. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on January 3, 2016. 35 Copyright Notice 37 Copyright (c) 2015 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. The TCP Timestamps option and Multipath TCP . . . . . . . . . 3 54 3. The Multipath TCP Timestamp option . . . . . . . . . . . . . 4 55 4. Security Considerations . . . . . . . . . . . . . . . . . . . 5 56 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 57 6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 5 58 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 59 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 60 8.1. Normative References . . . . . . . . . . . . . . . . . . 6 61 8.2. Informative References . . . . . . . . . . . . . . . . . 6 62 Appendix A. Changelog . . . . . . . . . . . . . . . . . . . . . 6 63 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 65 1. Introduction 67 The Timestamps option was proposed in [RFC1323]. Each Timestamps 68 option contains two timestamps. The first one corresponds to the 69 current value of the sender's clock. The second timestamp allows to 70 echo the most recent timestamp received from the remote host. The 71 utilisation of this option can be negotiated on a per-connection 72 basis during the three-way handshake. The timestamps option was 73 motivated by two usages : 75 o improve the accuracy of the round-trip-time measurements 77 o provide protection against wrapped TCP sequence numbers (PAWS) 79 Although these two usages have completely different purposes, they 80 are coupled in [RFC1323]. [RFC7323] goes further by requiring that 81 the TCP timestamps option be included in all segments once the option 82 has been negotiated in the three-way handshake. Forcing the 83 utilisation of this option in all segments is required to support 84 PAWS. However, there is no reason to force TCP hosts to include the 85 timestamp option in all segments when PAWS is not required. 87 In practice, there are two important use cases where PAWS is not 88 required. The first is when the TCP connections are so short that 89 TCP sequence numbers cannot wrap around. The second use case is when 90 Multipath TCP is used. Multipath TCP, defined in [RFC6824], is a TCP 91 extension that enables a TCP connection to exchange data over 92 multiple paths. This TCP extension uses 64 bits sequence number 93 which solves the PAWS problem in a cleaner way than [RFC7323]. Once 94 Multipath TCP has been negotiated, the PAWS part of [RFC1323] becomes 95 useless and should be disabled. 97 This document is organised as follows. We first summarize in section 98 Section 2 the issues with the TCP timestamps option defined in 99 [RFC1323]. We then propose in section Section 3 a Multipath TCP 100 Timestamp option that should be used by Multipath TCP implementations 101 instead of the regular [RFC7323] timestamps options. 103 2. The TCP Timestamps option and Multipath TCP 105 The TCP timestamps option defined in [RFC1323] is encoded as shown in 106 figure Figure 1. 108 +-------+-------+---------------------+---------------------+ 109 |Kind=8 | 10 | TS Value (TSval) |TS Echo Reply (TSecr)| 110 +-------+-------+---------------------+---------------------+ 111 1 1 4 4 113 Figure 1: Original RFC1323 Timestamps option 115 This option consummes 10 bytes. When [RFC1323] was published, 116 consumming 10 bytes in the SYN segment to negotiate the utilisation 117 of this option and later in all data segments was not a severe 118 concern given the limited number of TCP options that were used at 119 that time. This is not anymore the case today with Multipath TCP 120 [RFC6824] or the Selective Acknowledgements [RFC2018] option. 122 A Multipath TCP implementation SHOULD not use the [RFC7323] 123 timestamps option on Multipath TCP connections. However, a regular 124 TCP connection SHOULD use the [RFC7323] timestamp option to protect 125 against wrapped sequence numbers. To achieve this objective, 126 Multipath TCP implementations SHOULD operate as follows : 128 o an active Multipath TCP opener SHOULD place both the Timestamps 129 and MP_CAPABLE options in SYN segments when trying to open a TCP 130 connection unless the remote host (and the path towards this host) 131 is known to support Multipath TCP. In this case, the Timestamps 132 option can be ignored in the SYN segment. 134 o a passive Multipath TCP opener that receives a SYN segment 135 containing both the Timestamp and the MP_CAPABLE options SHOULD 136 only include the MP_CAPABLE option in the returned SYN+ACK 137 segment. This would disable the [RFC7323] timestamps on the 138 Multipath TCP connection. 140 When creating subflows, the Timestamps option SHOULD NOT be 141 associated with the MP_JOIN option in the SYN segments. Furthermore, 142 if a Multipath TCP host receives a valid SYN segment that contains 143 both the MP_JOIN option and the Timestamps option, it should not 144 include the Timestamps option in the returned SYN+ACK segment. 146 3. The Multipath TCP Timestamp option 148 The Timestamps option defined in [RFC7323] encodes two 32 bits 149 timestamps. Having two timestamps is useful when data transfer is 150 bidirectional but in practice very few TCP connections are totally 151 bidirectional. Most TCP connections send data in one directions and 152 acknowledgments in the opposite. For these connections, placing two 153 timestamps in each segment that carries data and each acknowledgement 154 is a waste of TCP options space. 156 When precise round-trip-time measurements are required on a Multipath 157 TCP connection, those measurements can be performed by using the 158 experimental Multipath TCP option shown in figure Figure 2. 160 1 2 3 161 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 162 +---------------+---------------+-------+-----------------------+ 163 | Kind | Length |Subtype| Flags | Experiment | 164 +---------------+---------------+-------+-------+---------------+ 165 | Id. (16 bits) | Timestamp (24 bits) | 166 +---------------------------------------------------------------+ 168 Figure 2: The experimental MPTCP Timestamp Option 170 The experimental MPTCP TS option contains the flags defined in 171 [I-D.bonaventure-mptcp-exp-option]. 173 The experimental MPTCP TS option may be sent in any TCP segment 174 except those having the SYN flag set. 176 When a host receives a segment containing an MPTCP TS option whose 177 'S' flag is set, it SHOULD reply immediately by echoing the received 178 timestamp in a returned MPTCP TS option whose 'S' flag is reset. 179 This MPTCP TS option can be included in either a segment that carries 180 data, if one is pending, or an acknowledgement. This implies that a 181 host does not need to maintain additional state to process the 182 received MPTCP TS option since it can reply directly to any received 183 MPTCP TS option. 185 The MPTCP TS option can be used to improve the quality of the round- 186 trip-time estimator. The discussion in section 4.2 of [RFC7323] is 187 also applicable for the Timestamp proposed in this document. 189 The MPTCP TS may also be used to verify that a subflow remains active 190 by forcing a remote host to reply to an MPTCP segment without sending 191 data. 193 4. Security Considerations 195 A middlexbox may remove the experimental MPTCP TS option. This is 196 unlikely if the Multipath TCP connection operates corectly. Since 197 the MPTCP TS option is only informational, such a behaviour would not 198 affect the reliability of the Multipath TCP connection. 200 Some of the security considerations from [RFC7323] and in particular 201 the following paragraph apply for the MPTCP TS option : 203 A naive implementation that derives the timestamp clock value 204 directly from a system uptime clock may unintentionally leak this 205 information to an attacker. This does not directly compromise any of 206 the mechanisms described in this document. However, this may be 207 valuable information to a potential attacker. It is therefore 208 RECOMMENDED to generate a random, per-Multipath TCP connection offset 209 to be used with the clock source when generating the Timestamps 210 option value. 211 By carefully choosing this random offset, further improvements as 212 described in [RFC6191] are possible. 214 5. IANA Considerations 216 This document proposes an experimental MPTCP option to carry 217 timestamps. If [I-D.bonaventure-mptcp-exp-option] is approved, then 218 an experimental identifier should be added to the IANA registry to 219 identify the timestamp option. 221 6. Conclusion 223 This document has proposed a new Timestamp option to replace the 224 [RFC7323] Timestamps option on Multipath TCP connections. The MPTCP 225 TS option can be included in MPTCP segments only when needed to 226 preserve TCP option space notably for the MPTCP and SACK options. 228 7. Acknowledgements 230 This work was partially supported by the EC within the FP7-Trilogy2 231 project. The author would like to thank Raphael Bauduin for his 232 comments and Joe Touch whose comments on the mptcp mailing list 233 encouraged the writing of this draft. 235 8. References 237 8.1. Normative References 239 [I-D.bonaventure-mptcp-exp-option] 240 Bonaventure, O., benjamin.hesmans@uclouvain.be, b., and M. 241 Boucadair, "Experimental Multipath TCP option", draft- 242 bonaventure-mptcp-exp-option-00 (work in progress), June 243 2015. 245 [RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP 246 Selective Acknowledgment Options", RFC 2018, October 1996. 248 [RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, 249 "TCP Extensions for Multipath Operation with Multiple 250 Addresses", RFC 6824, January 2013. 252 [RFC7323] Borman, D., Braden, B., Jacobson, V., and R. 253 Scheffenegger, "TCP Extensions for High Performance", RFC 254 7323, September 2014. 256 8.2. Informative References 258 [RFC1323] Jacobson, V., Braden, B., and D. Borman, "TCP Extensions 259 for High Performance", RFC 1323, May 1992. 261 [RFC6191] Gont, F., "Reducing the TIME-WAIT State Using TCP 262 Timestamps", BCP 159, RFC 6191, April 2011. 264 Appendix A. Changelog 266 This appendix should be removed before publication. 268 Changes in version 01. 270 o updated the format of the proposed option to use the encoding 271 proposed in [I-D.bonaventure-mptcp-exp-option] 273 Author's Address 275 Olivier Bonaventure 276 UCLouvain 278 Email: Olivier.Bonaventure@uclouvain.be