idnits 2.17.00 (12 Aug 2021) /tmp/idnits46510/draft-nishida-tcpm-disabling-paws-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 == 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: Multipath TCP [RFC6824] can also be used for a replacement of PAWS. Multipath TCP maintains 64 bits sequence number space in the session and use DSS (Data Sequence Signal) option for this purpose in addition to the sequence number field in the TCP header. This DSS option can be served to provide the same protections as PAWS. By checking Data sequence number is DSS option, it can identify old duplicated segments. Because the data sequence number in the option should be exactly matched with the number stored in the session, MPTCP can provide stronger protection than PAWS. One way to signal disabling PAWS information is to use MP_EXPERIMENTAL option defined in [I-D.ietf-mptcp-rfc6824bis] during initial connection setup. Or, using 'B' bit in MP_CAPABLE option and extend MP_CAPABLE option to convey the info. Another requirement for disabling PAWS in an MPTCP session is that DSS mapping should be put in all data segments in the session. In case an MPTCP session falls back to TCP during SYN negotiation or either side does not support disabling PAWS, PAWS MUST not be disabled if the use of TS option is negotiated. == 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: When TLS [RFC5246] is used for a TCP connection, old duplicated segments can be identified as segments in the connection are protected by encryption algorithms. One difficulty for using TLS as a replacement of PAWS is that it will be hard for TCP layer to know whether TLS is used or not. One possible way is to presume the use of TLS from port numbers (e.g. 443). Or, providing APIs to signal TCP layer can be another way although this will require to update applications. In addition, TCP needs to check if the other end supports disabling PAWS. In order for this, we will need to define a new TCP option in order to be used during SYN exchange. Another possibility is to utilize timestamp values in SYN segments in order to encode the feature negotiation information. An example of using timestamp value in SYN segments for feature negotiation is described in [I-D.scheffenegger-tcpm-timestamp-negotiation]. When either side does not support disabling PAWS, PAWS MUST not be disabled if the use of TS option is negotiated. -- The document date (June 20, 2018) is 1424 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: draft-ietf-mptcp-rfc6824bis has been published as RFC 8684 == Outdated reference: draft-ietf-tcpinc-tcpeno has been published as RFC 8547 ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 6824 (Obsoleted by RFC 8684) Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Y. Nishida 3 Internet-Draft GE Global Research 4 Intended status: Experimental June 20, 2018 5 Expires: December 22, 2018 7 Disabling PAWS When Other Protections Are Available 8 draft-nishida-tcpm-disabling-paws-00 10 Abstract 12 PAWS provides protection against old duplicated segments caused by 13 wrapped sequence or earlier incarnated connections. One drawback of 14 PAWS is that it requires to place timestamp option in all segments, 15 which consumes 10-12 bytes in the option space of TCP. In addition, 16 since PAWS just checks if timestamps is older or not, the protection 17 logic is not very strong against malicious attacks or cannot work 18 properly in some situations. On the other hand, some other 19 technologies which can provide stronger protections than PAWS are 20 becoming available these days. In this document, we propose to 21 utilize other protection mechanisms as replacements of PAWS when they 22 are available. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on December 22, 2018. 41 Copyright Notice 43 Copyright (c) 2018 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (https://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 3 60 3. Possible Mechanisms AS Replacements of PAWS . . . . . . . . . 3 61 3.1. TCP Increased Security (tcpinc) . . . . . . . . . . . . . 3 62 3.2. Multipath TCP . . . . . . . . . . . . . . . . . . . . . . 4 63 3.3. TLS . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 4. Duplicates from Earlier Connection Incarnations . . . . . . . 5 65 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 66 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 67 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 68 7.1. Normative References . . . . . . . . . . . . . . . . . . 5 69 7.2. Informative References . . . . . . . . . . . . . . . . . 6 70 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 72 1. Introduction 74 PAWS (Protect Against Wrapped Sequences) defined in [RFC7323] is a 75 technique that can identify old duplicate segments in a TCP 76 connection or segments from earlier incarnated connections. PAWS 77 utilizes timestamp option in TCP segments. When both TCP endpoints 78 agree to use PAWS, all segments belong to this connection will have 79 the options, which consumes 10-12 bytes of 40 bytes option space. As 80 recent TCP connections use option space for other TCP extensions such 81 as [RFC2018], [RFC5925] and [RFC6824], this feature tends to be 82 considered as expensive these days. 84 Timestamp option is also used for RTTM (Round Trip Time Measurement). 85 Gathering many RTT samples from the timestamp in every TCP segment 86 may look useful approach to improve RTO estimations. However, some 87 research results shows taking a few timestamps per RTT can be 88 sufficient [MALLMAN99]. Also, some TCP implementations record the 89 transmission time of each packet. In this case, timestamp option is 90 not necessary to measure RTTs. 92 The basic idea of PAWS is that a received segment is considered as an 93 old duplicate if the timestamp in it is less than the timestamps 94 recently received on a connection. The timestamp values used in PAWS 95 is 32-bit unsigned integers. Hence, when PAWS compares two timestamp 96 values: t1, t2, it regards t2 as "newer than t1" if 0 < (t2 - t1) < 97 2^31, otherwise t2 is considered as "older than t1". This logic 98 presumes timestamp is monotonically increased across connections, 99 however, it can be confused in some cases such as where multiple 100 nodes are behind the same NAT. In addition, if malicious attackers 101 try to cheat the PAWS logic with random timestamp values, there will 102 be 50% of chance for success on each try. This basically means PAWS 103 can hardly contribute to securing TCP connections. On the other 104 hand, several technologies which can be utilized for the same purpose 105 are becoming available. 107 Based on these observations, we propose to utilize other mechanisms 108 as replacements of PAWS when it is possible. The goal of the 109 proposal in the draft is to provide stronger protections for old 110 duplicated segments while facilitating the use of TCP option space by 111 suppressing timestamp options. Another benefit of the proposal is 112 that it can contribute to facilitating recycling of TCP connections 113 in TIME_WAIT stat, which will be useful for busy servers. 115 2. Conventions and Terminology 117 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 118 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 119 document are to be interpreted as described in [RFC2119]. 121 3. Possible Mechanisms AS Replacements of PAWS 123 In this section, we present several possible mechanisms that can be 124 used as replacements of PAWS. When these mechanisms are available 125 and are activated in a TCP connection, PAWS can be disabled as it 126 will be redundant. In order to disable PAWS protection, a simple 127 signaling mechanism will be needed as this will require agreement on 128 both ends. We discuss how to utilize these mechanisms and how to 129 disable PAWS safely below. 131 3.1. TCP Increased Security (tcpinc) 133 Currently, TCP extensions that can provide unauthenticated encryption 134 and integrity protection to TCP streams have been actively discussed 135 in IETF [TCPINC]. As these proposed extensions is based on 136 encryption algorithms, old duplicated segments in the same connection 137 or segments from early connections with the same 4 tuples will easily 138 be identified. In addition, it will be harder for malicious attacks 139 to cheat this protections. To utilize this feature as a replacement 140 of PAWS, we propose to update the encryption negotiation option (TCP- 141 ENO) [I-D.ietf-tcpinc-tcpeno] by using 1 bit of global suboption in 142 initial suboption byte. This bit indicates that the end point 143 supports disabling PAWS. After endpoints confirm that both ends 144 support disabling PAWS and encryption negotiation has been 145 successful, they will disable PAWS and will use timestamp options 146 only for RTTM. However, in case TCP-ENO has failed or either side 147 does not support disabling PAWS, PAWS MUST NOT be disabled if the use 148 of TS option is negotiated. 150 3.2. Multipath TCP 152 Multipath TCP [RFC6824] can also be used for a replacement of PAWS. 153 Multipath TCP maintains 64 bits sequence number space in the session 154 and use DSS (Data Sequence Signal) option for this purpose in 155 addition to the sequence number field in the TCP header. This DSS 156 option can be served to provide the same protections as PAWS. By 157 checking Data sequence number is DSS option, it can identify old 158 duplicated segments. Because the data sequence number in the option 159 should be exactly matched with the number stored in the session, 160 MPTCP can provide stronger protection than PAWS. One way to signal 161 disabling PAWS information is to use MP_EXPERIMENTAL option defined 162 in [I-D.ietf-mptcp-rfc6824bis] during initial connection setup. Or, 163 using 'B' bit in MP_CAPABLE option and extend MP_CAPABLE option to 164 convey the info. Another requirement for disabling PAWS in an MPTCP 165 session is that DSS mapping should be put in all data segments in the 166 session. In case an MPTCP session falls back to TCP during SYN 167 negotiation or either side does not support disabling PAWS, PAWS MUST 168 not be disabled if the use of TS option is negotiated. 170 3.3. TLS 172 When TLS [RFC5246] is used for a TCP connection, old duplicated 173 segments can be identified as segments in the connection are 174 protected by encryption algorithms. One difficulty for using TLS as 175 a replacement of PAWS is that it will be hard for TCP layer to know 176 whether TLS is used or not. One possible way is to presume the use 177 of TLS from port numbers (e.g. 443). Or, providing APIs to signal 178 TCP layer can be another way although this will require to update 179 applications. In addition, TCP needs to check if the other end 180 supports disabling PAWS. In order for this, we will need to define a 181 new TCP option in order to be used during SYN exchange. Another 182 possibility is to utilize timestamp values in SYN segments in order 183 to encode the feature negotiation information. An example of using 184 timestamp value in SYN segments for feature negotiation is described 185 in [I-D.scheffenegger-tcpm-timestamp-negotiation]. When either side 186 does not support disabling PAWS, PAWS MUST not be disabled if the use 187 of TS option is negotiated. 189 4. Duplicates from Earlier Connection Incarnations 191 As described in [RFC7323], the main purpose of PAWS is to protect 192 against old duplicates from the same connection. In addition, it is 193 expected to provide additional security against old duplicates from 194 earlier connections. Although this feature is not strongly 195 encouraged in the RFC, some implementations support it. We believe 196 the protection described above can be used for this purpose as well. 197 By using encryption logics or extended sequence number space, they 198 can distinguish between the packets from the current connection and 199 the packets from earlier connections. The protections will even be 200 stronger than the protection PAWS can provide. We believe the 201 replacements of PAWS will also be able to facilitate recycling the 202 connections in TIME_WAIT. For example, it was reported some 203 implementations replaced the connections in TIME_WAIT by a new 204 incoming connection with the same 4 tuples when its timestamp is 205 newer than the one in TIME_WAIT. However, this logic will not work 206 properly when multiple clients behind NAT or when a node doesn't 207 maintain global timestamp offset across all TCP connections. On the 208 other hand, when a TCP connection can utilize the protections 209 described above, it can recycle the connection in TIME_WAIT with more 210 robust algorithms. 212 5. Security Considerations 214 TBD 216 6. IANA Considerations 218 This document may uses the Experimental Option Experiment Identifier 219 defined in [RFC6994]. In this case, an application for this 220 codepoint in the IANA TCP Experimental Option ExID registry will be 221 submitted. 223 7. References 225 7.1. Normative References 227 [I-D.ietf-mptcp-rfc6824bis] 228 Ford, A., Raiciu, C., Handley, M., Bonaventure, O., and C. 229 Paasch, "TCP Extensions for Multipath Operation with 230 Multiple Addresses", draft-ietf-mptcp-rfc6824bis-11 (work 231 in progress), May 2018. 233 [I-D.ietf-tcpinc-tcpeno] 234 Bittau, A., Giffin, D., Handley, M., Mazieres, D., and E. 235 Smith, "TCP-ENO: Encryption Negotiation Option", draft- 236 ietf-tcpinc-tcpeno-18 (work in progress), November 2017. 238 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 239 Requirement Levels", BCP 14, RFC 2119, 240 DOI 10.17487/RFC2119, March 1997, 241 . 243 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 244 (TLS) Protocol Version 1.2", RFC 5246, 245 DOI 10.17487/RFC5246, August 2008, 246 . 248 [RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, 249 "TCP Extensions for Multipath Operation with Multiple 250 Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013, 251 . 253 [RFC7323] Borman, D., Braden, B., Jacobson, V., and R. 254 Scheffenegger, Ed., "TCP Extensions for High Performance", 255 RFC 7323, DOI 10.17487/RFC7323, September 2014, 256 . 258 7.2. Informative References 260 [I-D.scheffenegger-tcpm-timestamp-negotiation] 261 Scheffenegger, R., Kuehlewind, M., and B. Trammell, 262 "Additional negotiation in the TCP Timestamp Option field 263 during the TCP handshake", draft-scheffenegger-tcpm- 264 timestamp-negotiation-05 (work in progress), October 2012. 266 [MALLMAN99] 267 Allman, M. and V. Paxson, "On Estimating End-to-End 268 Network Path Properties", Proceedings of the ACM SIGCOMM , 269 September 1999. 271 [RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP 272 Selective Acknowledgment Options", RFC 2018, 273 DOI 10.17487/RFC2018, October 1996, 274 . 276 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 277 Authentication Option", RFC 5925, DOI 10.17487/RFC5925, 278 June 2010, . 280 [RFC6994] Touch, J., "Shared Use of Experimental TCP Options", 281 RFC 6994, DOI 10.17487/RFC6994, August 2013, 282 . 284 [TCPINC] The IETF, "The TCPINC Working Group, 285 https://datatracker.ietf.org/wg/tcpinc/documents/", 2014. 287 Author's Address 289 Yoshifumi Nishida 290 GE Global Research 291 2623 Camino Ramon 292 San Ramon, CA 94583 293 USA 295 Email: nishida@wide.ad.jp