idnits 2.17.1 draft-gont-timestamps-generation-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- -- The document has an IETF Trust Provisions (28 Dec 2009) Section 6.c(ii) Publication Limitation clause. If this document is intended for submission to the IESG for publication, this constitutes an error. 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 (June 22, 2010) is 5056 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC0793' is defined on line 242, but no explicit reference was found in the text == Unused Reference: 'RFC1122' is defined on line 245, but no explicit reference was found in the text == Unused Reference: 'RFC1337' is defined on line 251, but no explicit reference was found in the text == Unused Reference: 'FreeBSD-impl' is defined on line 264, but no explicit reference was found in the text == Unused Reference: 'Linux' is defined on line 275, but no explicit reference was found in the text == Unused Reference: 'Linux-impl' is defined on line 277, but no explicit reference was found in the text ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 1323 (Obsoleted by RFC 7323) ** Downref: Normative reference to an Informational RFC: RFC 1337 -- Obsolete informational reference (is this intentional?): RFC 1948 (Obsoleted by RFC 6528) Summary: 3 errors (**), 0 flaws (~~), 7 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TCP Maintenance and Minor F. Gont 3 Extensions (tcpm) UK CPNI 4 Internet-Draft A. Oppermann 5 Intended status: BCP FreeBSD 6 Expires: December 24, 2010 June 22, 2010 8 On the generation of TCP timestamps 9 draft-gont-timestamps-generation-00.txt 11 Abstract 13 This document discusses the generation of TCP timestamps. In 14 particular, it discusses a number of algorithms for producing 15 monotonically-increasing timestamps such that timestamps can be used 16 to reduce the TIME-WAIT state, and an algorithm for generating 17 timestamps that allows for extended SYN-cookies. 19 Status of this Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. This document may not be modified, 23 and derivative works of it may not be created, and it may not be 24 published except as an Internet-Draft. 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 December 24, 2010. 38 Copyright Notice 40 Copyright (c) 2010 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 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Timestamps generation for TCPs that perform the active open . . 3 57 3. Timestamps generation for TCPs that perform the passive 58 open . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 3.1. Extended SYN cookies . . . . . . . . . . . . . . . . . . . 4 60 3.2. Potential problems with SYN-cookies . . . . . . . . . . . . 5 61 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 62 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 63 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 64 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 65 7.1. Normative References . . . . . . . . . . . . . . . . . . . 6 66 7.2. Informative References . . . . . . . . . . . . . . . . . . 7 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 69 1. Introduction 71 The Timestamps option, specified in RFC 1323 [RFC1323], allows a TCP 72 to include a timestamp value in its segments, that can be used used 73 to perform two functions: Round-Trip Time Measurement (RTTM), and 74 Protection Against Wrapped Sequences (PAWS). 76 For the purpose of PAWS, the timestamps sent on a connection are 77 required to be monotonically increasing. RFC 1323 does not include 78 any further requirements for the TCP timestamps (such as the initial 79 timestamp value or the relationship between timestamps that 80 correspond to different connections). 82 [I-D.gont-tcpm-tcp-timestamps] discusses an algorithm that employs 83 TCP timestamps to reduce the TIME-WAIT state. The aforementioned 84 algorithm benefits from timestamps that are monotonically-increasing 85 across connections. 87 Some TCP implementations have employed TCP timestamps to implement 88 extended SYN-Cookies [RFC4987]. These implementations encode part of 89 the information received in an incomming SYN segment in the TCP 90 timestamps sent in the SYN/ACK. 92 It should be noted that a TCP implementation could benefit from the 93 benefits of both timestamps generation approaches. Monotonically- 94 increasing timestamps could be generated for TCPs that perform the 95 active open, while timestamps for TCPs that perform the passive open 96 could be generated according to [Opperman]. 98 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 99 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 100 document are to be interpreted as described in RFC 2119 [RFC2119]. 102 2. Timestamps generation for TCPs that perform the active open 104 While there is no requirement that timestamps are monotonically 105 increasing across TCP connections, the generation of timestamps such 106 that they are monotonically increasing across connections between the 107 same two endpoints allows the use of timestamps for improving the 108 handling of SYN segments that are received while the corresponding 109 four-tuple is in the TIME-WAIT state. That is, the timestamp option 110 could be used to perform heuristics to determine whether to allow the 111 creation of a new incarnation of a connection that is in the TIME- 112 WAIT state. 114 It is RECOMMENDED that timestamps are generated with a similar 115 algorithm to that introduced by RFC 1948 [RFC1948] for the generation 116 of Initial Sequence Numbers (ISNs). That is, 118 timestamp = T() + F(localhost, localport, remotehost, remoteport, 119 secret_key) 121 where the result of T() is a global system clock that complies with 122 the requirements of Section 4.2.2 of RFC 1323 [RFC1323], and F() is a 123 function that should not be computable from the outside without 124 knowledge of the secret key (secret_key). Therefore, we suggest F() 125 to be a cryptographic hash function of the connection-id and some 126 secret data (which could be chosen randomly). 128 F() provides an offset that will be the same for all incarnations of 129 a connection between the same two endpoints, while T() provides the 130 monotonically increasing values that are needed for PAWS. 132 3. Timestamps generation for TCPs that perform the passive open 134 3.1. Extended SYN cookies 136 The purpose of SYN cookies is to avoid keeping track of all SYN's we 137 receive and to be able to handle SYN floods from bogus source 138 addresses (where we will never receive any reply). SYN floods try to 139 exhaust all our memory and available slots in the SYN cache table to 140 cause a denial of service to legitimate users of the local host. 142 The idea of SYN cookies is to encode and include all necessary 143 information about the connection setup state within the SYN-ACK we 144 send back and thus to get along without keeping any local state until 145 the ACK to the SYN-ACK arrives (if ever). Everything we need to know 146 should be available from the information we encoded in the SYN-ACK. 148 This implementation extends the orginal idea and first implementation 149 of FreeBSD by using not only the initial sequence number field to 150 store information but also the timestamp field if present. This way 151 we can keep track of the entire state we need to know to recreate the 152 session in its original form. Almost all TCP speakers implement 153 RFC1323 timestamps these days. For those that do not we still have 154 to live with the known shortcomings of the ISN-only SYN cookies. 156 Initial Sequence Number (ISN) we send: 158 31|................................|0 159 DDDDDDDDDDDDDDDDDDDDDDDDDMMMRRRP 161 D = MD5 Digest (first dword) 162 M = MSS index 163 R = Rotation of secret 164 P = Odd or Even secret 166 Figure 1 168 The MD5 Digest is computed with over following parameters: 170 o randomly rotated secret 172 o struct in_conninfo containing the remote/local ip/port (IPv4&IPv6) 174 o the received initial sequence number from remote host 176 o the rotation offset and odd/even bit 178 Timestamp we send: 180 31|................................|0 181 DDDDDDDDDDDDDDDDDDDDDDSSSSRRRRA5 183 D = MD5 Digest (third dword) (only as filler) 184 S = Requested send window scale 185 R = Requested receive window scale 186 A = SACK allowed 187 5 = TCP-MD5 enabled (not implemented yet) 189 XORed with MD5 Digest (forth dword) 191 Figure 2 193 The timestamp isn't cryptographically secure and doesn't need to be. 194 The double use of the MD5 digest dwords ties it to a specific remote/ 195 local host/port, remote initial sequence number and our local time 196 limited secret. A received timestamp is reverted (XORed) and then 197 the contained MD5 dword is compared to the computed one to ensure the 198 timestamp belongs to the SYN-ACK we sent. The other parameters may 199 have been tampered with but this isn't different from supplying bogus 200 values in the SYN in the first place. 202 3.2. Potential problems with SYN-cookies 204 Some of the problems of ISN-only SYN cookies remain, nevertheless. 205 Consider the problem of a recreated (and retransmitted) cookie. If 206 the original SYN was accepted, the connection is established. The 207 second SYN is inflight, and if it arrives with an ISN that falls 208 within the receive window, the connection is killed. 210 A heuristic to determine when to accept syn cookies is not necessary. 211 An ACK flood would cause the syncookie verification to be attempted, 212 but a SYN flood causes syncookies to be generated. Both are of equal 213 cost, so there's no point in trying to optimize the ACK flood case. 215 Also, if you don't process certain ACKs for some reason, then all 216 someone would have to do is launch a SYN and ACK flood at the same 217 time, which would stop cookie verification and defeat the entire 218 purpose of syncookies. 220 4. Security Considerations 222 This document describes a number of algorithms for generating TCP 223 timestamps. 225 [CPNI-TCP] provides a thorough discussion of the security 226 implications of TCP timestamps. 228 5. IANA Considerations 230 This document has no actions for IANA. 232 6. Acknowledgements 234 Fernando Gont would like to thank the United Kingdom's Centre for the 235 Protection of National Infrastructure (UK CPNI) for their continued 236 support. 238 7. References 240 7.1. Normative References 242 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 243 RFC 793, September 1981. 245 [RFC1122] Braden, R., "Requirements for Internet Hosts - 246 Communication Layers", STD 3, RFC 1122, October 1989. 248 [RFC1323] Jacobson, V., Braden, B., and D. Borman, "TCP Extensions 249 for High Performance", RFC 1323, May 1992. 251 [RFC1337] Braden, B., "TIME-WAIT Assassination Hazards in TCP", 252 RFC 1337, May 1992. 254 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 255 Requirement Levels", BCP 14, RFC 2119, March 1997. 257 7.2. Informative References 259 [CPNI-TCP] 260 CPNI, "Security Assessment of the Transmission Control 261 Protocol (TCP)", http://www.cpni.gov.uk/Docs/ 262 tn-03-09-security-assessment-TCP.pdf, 2009. 264 [FreeBSD-impl] 265 FreeBSD, "FreeBSD", http://www.freebsd.org/cgi/ 266 cvsweb.cgi/src/sys/netinet/ 267 tcp_syncache.c?rev=1.99&content-type=text/x-cvsweb-markup, 268 2008. 270 [I-D.gont-tcpm-tcp-timestamps] 271 Gont, F., "Reducing the TIME-WAIT state using TCP 272 timestamps", draft-gont-tcpm-tcp-timestamps-04 (work in 273 progress), March 2010. 275 [Linux] The Linux Project, "http://www.kernel.org". 277 [Linux-impl] 278 Westphal, F., "Add support for TCP-options via 279 timestamps", http://lwn.net/Articles/277219/, 2008. 281 [Opperman] 282 Oppermann, A., "FYI: Extended TCP syncookies in FreeBSD- 283 current", Post to the tcpm mailing-list. Available at: ht 284 tp://www.ietf.org/mail-archive/web/tcpm/current/ 285 msg02251.html, 2006. 287 [RFC1948] Bellovin, S., "Defending Against Sequence Number Attacks", 288 RFC 1948, May 1996. 290 [RFC4987] Eddy, W., "TCP SYN Flooding Attacks and Common 291 Mitigations", RFC 4987, August 2007. 293 Authors' Addresses 295 Fernando Gont 296 UK Centre for the Protection of National Infrastructure 298 Email: fernando@gont.com.ar 299 URI: http://www.cpni.gov.uk 301 Andre Oppermann 302 FreeBSD 304 Email: andre@freebsd.org