idnits 2.17.1 draft-gont-tcpm-rfc1948bis-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 : ---------------------------------------------------------------------------- -- The draft header indicates that this document obsoletes RFC1948, but the abstract doesn't seem to directly say this. It does mention RFC1948 though, so this could be OK. -- The draft header indicates that this document updates RFC793, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC793, updated by this document, for RFC5378 checks: 1981-09-01) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 3, 2011) is 4834 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) ** Downref: Normative reference to an Informational RFC: RFC 1321 ** Obsolete normative reference: RFC 1323 (Obsoleted by RFC 7323) -- Obsolete informational reference (is this intentional?): RFC 1948 (Obsoleted by RFC 6528) Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 5 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) UTN/FRH 4 Internet-Draft S. Bellovin 5 Obsoletes: 1948 (if approved) Columbia University 6 Updates: 793 (if approved) January 3, 2011 7 Intended status: Standards Track 8 Expires: July 7, 2011 10 Defending Against Sequence Number Attacks 11 draft-gont-tcpm-rfc1948bis-00.txt 13 Abstract 15 This document specifies an algorithm for the generation of TCP 16 Initial Sequence Numbers (ISNs), such that the chances of an off-path 17 attacker of guessing the sequence numbers in use by a target 18 connection are reduced. This document is a revision of RFC 1948, and 19 takes the ISN generation algorithm originally proposed in that 20 document to Standards Track. 22 Status of this Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on July 7, 2011. 39 Copyright Notice 41 Copyright (c) 2011 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Generation of Initial Sequence Numbers . . . . . . . . . . . . 3 58 3. Proposed Initial Sequence Number (ISN) generation algorithm . 4 59 4. Security Considerations . . . . . . . . . . . . . . . . . . . 5 60 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 61 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 62 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 63 7.1. Normative References . . . . . . . . . . . . . . . . . . . 6 64 7.2. Informative References . . . . . . . . . . . . . . . . . . 7 65 Appendix A. Address-based trust relationship exploitation 66 attacks . . . . . . . . . . . . . . . . . . . . . . . 9 67 A.1. Blind TCP connection-spoofing . . . . . . . . . . . . . . 9 68 A.2. An old BSD bug . . . . . . . . . . . . . . . . . . . . . . 11 69 Appendix B. Changes from previous versions of the document . . . 12 70 B.1. Changes from RFC 1948 . . . . . . . . . . . . . . . . . . 12 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 73 1. Introduction 75 During the last 25 years, the Internet has experienced a number of 76 off-path attacks against TCP connections. These attacks have ranged 77 from trust relationships exploitation to Denial of Service attacks 78 [CPNI-TCP]. Discusion of some of these attacks dates back to at 79 least 1985, when Morris [Morris1985] described a form of attack based 80 on guessing what sequence numbers TCP [RFC0793] will use for new 81 connections. 83 In 1996, RFC 1948 [RFC1948] proposed an algorithm for the selection 84 of TCP Initial Sequence Numbers (ISNs), such that the chances of an 85 off-path attacker of guessing valid sequence numbers are reduced. 86 With the aforementioned algorithm, such attacks would remain possible 87 if and only if the Bad Guy already had the ability to launch even 88 more devastating attacks. 90 This document is a revision of RFC 1948, and takes the ISN generation 91 algorithm originally proposed in that document to Standards Track. 93 Section 2 provides a brief discussion of the requirements for a good 94 ISN generation algorithm. Section 3 specifies a good ISN 95 randomization algorithm. Finally, Appendix A provides a discussion 96 of the trust-relationship exploitation attacks that originally 97 motivated the publication of RFC 1948 [RFC1948]. 99 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 100 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 101 document are to be interpreted as described in RFC 2119 [RFC2119]. 103 2. Generation of Initial Sequence Numbers 105 RFC 793 [RFC0793] suggests that the choice of the Initial Sequence 106 Number of a connection is not arbitrary, but aims to reduce the 107 chances of a stale segment from being accepted by a new incarnation 108 of a previous connection. RFC 793 [RFC0793] suggests the use of a 109 global 32-bit ISN generator that is incremented by 1 roughly every 4 110 microseconds. 112 It is interesting to note that, as a matter of fact, protection 113 against stale segments from a previous incarnation of the connection 114 is enforced by preventing the creation of a new incarnation of a 115 previous connection before 2*MSL have passed since a segment 116 corresponding to the old incarnation was last seen. This is 117 accomplished by the TIME-WAIT state, and TCP's "quiet time" concept 118 (see Appendix B of [RFC1323]). 120 Based on the assumption that ISNs are monotonically-increasing across 121 connections, many stacks (e.g., 4.2BSD-derived) use the ISN of an 122 incomming SYN segment to perform "heuristics" that enable the 123 creation of a new incarnation of a connection while the previous 124 incarnation is still in the TIME-WAIT state (see pp. 945 of 125 [Wright1994]). This avoids an interoperability problem that may 126 arise when a systems establishes connections to a specific TCP end- 127 point at a high rate [Silbersack2005]. 129 Unfortunately, the ISN generator described in [RFC0793] makes it 130 trivial for an off-path attacker to predict the ISN that a TCP will 131 use for new connections, thus allowing a variety of attacks against 132 TCP connections [CPNI-TCP]. One of the possible attacks that took 133 advantage of weak sequence numbers was first described in 134 [Morris1985], and its exploitation was widely publicized about 10 135 years later [Shimomura1995]. [CERT2001] and [USCERT2001] are 136 advisories about the security implications of weak ISN generators. 137 [Zalewski2001] and [Zalewski2002] contain a detailed analysis of ISN 138 generators, and a survey of the algorithms in use by popular TCP 139 implementations. 141 Simple randomization of the TCP Initial Sequence Numbers would 142 mitigate those attacks that require an attacker to guess valid 143 sequence numbers. However, it would also break the 4.4BSD 144 "heuristics" to accept a new incoming connection when there is a 145 previous incarnation of that connection in the TIME-WAIT state 146 [Silbersack2005]. 148 We can prevent sequence number guessing attacks by giving each 149 connection -- that is, each 4-tuple of (localip, localport, remoteip, 150 remoteport) -- a separate sequence number space. Within each space, 151 the initial sequence number is incremented according to [RFC0793]; 152 however, there is no obvious relationship between the numbering in 153 different spaces. 155 The obvious way to do this is to maintain state for dead connections, 156 and the easiest way to do that is to change the TCP state transition 157 diagram so that both ends of all connections go to TIME-WAIT state. 158 That would work, but it's inelegant and consumes storage space. 159 Instead, we propose an improvement to the TCP ISN generation 160 algorithm. 162 3. Proposed Initial Sequence Number (ISN) generation algorithm 164 TCP SHOULD generate its Initial Sequence Numbers with the expression: 166 ISN = M + F(localip, localport, remoteip, remoteport) 168 where M is the 4 microsecond timer, and F is a pseudorandom function 169 (PRF) of the connection-id. It is vital that F not be computable 170 from the outside, or an attacker could still guess at sequence 171 numbers from the initial sequence number used for some other 172 connection. The PRF could be implemented as a cryptographic hash of 173 the concatenation of the connection-id and some secret data; SHA-256 174 [FIPS-SHS] would be a good choice for the hash function. The secret 175 data can either be a true random number [RFC4086], or it can be the 176 combination of some per-host secret and the boot time of the machine. 177 The boot time is included to ensure that the secret is changed on 178 occasion. 180 Note that the secret cannot easily be changed on a live machine. 181 Doing so would change the initial sequence numbers used for 182 reincarnated connections; to maintain safety, either dead connection 183 state must be kept or a quiet time observed for two maximum segment 184 lifetimes after such a change. 186 4. Security Considerations 188 Good sequence numbers are not a replacement for cryptographic 189 authentication, such as that provided by IPsec [RFC4301]. At best, 190 they're a palliative measure. 192 If random numbers are used as the sole source of the secret, they 193 MUST be chosen in accordance with the recommendations given in 194 [RFC4086]. 196 A security consideration that should be made about the algorithm 197 proposed in this document is that it might allow an attacker to count 198 the number of systems behind a Network Address Translator (NAT) 199 [RFC3022]. Depending on the ISN generators implemented by each of 200 the systems behind the NAT, an attacker might be able to count the 201 number of systems behind a NAT by establishing a number of TCP 202 connections (using the public address of the NAT) and indentifying 203 the number of different sequence number "spaces". 204 [I-D.gont-behave-nat-security] discusses how this and other 205 information leakages at NATs could be mitigated. 207 An eavesdropper who can observe the initial messages for a connection 208 can determine its sequence number state, and may still be able to 209 launch sequence number guessing attacks by impersonating that 210 connection. However, such an eavesdropper can also hijack existing 211 connections [Joncheray1995], so the incremental threat isn't that 212 high. Still, since the offset between a fake connection and a given 213 real connection will be more or less constant for the lifetime of the 214 secret, it is important to ensure that attackers can never capture 215 such packets. Typical attacks that could disclose them include both 216 eavesdropping and the variety of routing attacks discussed in 217 [Bellovin1989]. 219 [CPNI-TCP] contains a discussion of all the currently-known attacks 220 that require an attacker to know or be able to guess the TCP sequence 221 numbers in use by the target connection. 223 5. IANA Considerations 225 This document has no actions for IANA. 227 6. Acknowledgements 229 Matt Blaze and Jim Ellis contributed some crucial ideas to RFC 1948, 230 on which this document is based. Frank Kastenholz contributed 231 constructive comments to that memo. 233 The authors of this document woul like to thank (in chronological 234 order) Alfred Hoenes for providing valuable comments on earlier 235 versions of this document. 237 Fernando Gont would like to thank the United Kingdom's Centre for the 238 Protection of National Infrastructure (UK CPNI) for their continued 239 support. 241 7. References 243 7.1. Normative References 245 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 246 RFC 793, September 1981. 248 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 249 April 1992. 251 [RFC1323] Jacobson, V., Braden, B., and D. Borman, "TCP Extensions 252 for High Performance", RFC 1323, May 1992. 254 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 255 Requirement Levels", BCP 14, RFC 2119, March 1997. 257 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 258 Requirements for Security", BCP 106, RFC 4086, June 2005. 260 7.2. Informative References 262 [Bellovin1989] 263 Morris, R., "Security Problems in the TCP/IP Protocol 264 Suite", Computer Communications Review, vol. 19, no. 2, 265 pp. 32-48, 1989. 267 [CERT2001] 268 CERT, "CERT Advisory CA-2001-09: Statistical Weaknesses in 269 TCP/IP Initial Sequence Numbers", 270 http://www.cert.org/advisories/CA-2001-09.html, 2001. 272 [CPNI-TCP] 273 CPNI, "Security Assessment of the Transmission Control 274 Protocol (TCP)", http://www.cpni.gov.uk/Docs/ 275 tn-03-09-security-assessment-TCP.pdf, 2009. 277 [FIPS-SHS] 278 FIPS, "Secure Hash Standard (SHS)", Federal Information 279 Processing Standards Publication 180-3, 2008, available 280 at: http://csrc.nist.gov/publications/fips/fips180-3/ 281 fips180-3_final.pdf. 283 [I-D.gont-behave-nat-security] 284 Gont, F. and P. Srisuresh, "Security implications of 285 Network Address Translators (NATs)", 286 draft-gont-behave-nat-security-03 (work in progress), 287 October 2009. 289 [Joncheray1995] 290 Joncheray, L., "A Simple Active Attack Against TCP", Proc. 291 Fifth Usenix UNIX Security Symposium, 1995. 293 [Morris1985] 294 Morris, R., "A Weakness in the 4.2BSD UNIX TCP/IP 295 Software", CSTR 117, AT&T Bell Laboratories, Murray Hill, 296 NJ, 1985. 298 [RFC0854] Postel, J. and J. Reynolds, "Telnet Protocol 299 Specification", STD 8, RFC 854, May 1983. 301 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 302 STD 13, RFC 1034, November 1987. 304 [RFC1948] Bellovin, S., "Defending Against Sequence Number Attacks", 305 RFC 1948, May 1996. 307 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 308 Address Translator (Traditional NAT)", RFC 3022, 309 January 2001. 311 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The 312 Kerberos Network Authentication Service (V5)", RFC 4120, 313 July 2005. 315 [RFC4251] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) 316 Protocol Architecture", RFC 4251, January 2006. 318 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 319 Internet Protocol", RFC 4301, December 2005. 321 [RFC4954] Siemborski, R. and A. Melnikov, "SMTP Service Extension 322 for Authentication", RFC 4954, July 2007. 324 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 325 October 2008. 327 [RFC5936] Lewis, E. and A. Hoenes, "DNS Zone Transfer Protocol 328 (AXFR)", RFC 5936, June 2010. 330 [Shimomura1995] 331 Shimomura, T., "Technical details of the attack described 332 by Markoff in NYT", 333 http://www.gont.com.ar/docs/post-shimomura-usenet.txt, 334 Message posted in USENET's comp.security.misc newsgroup, 335 Message-ID: <3g5gkl$5j1@ariel.sdsc.edu>, 1995. 337 [Silbersack2005] 338 Silbersack, M., "Improving TCP/IP security through 339 randomization without sacrificing interoperability.", 340 EuroBSDCon 2005 Conference . 342 [USCERT2001] 343 US-CERT, "US-CERT Vulnerability Note VU#498440: Multiple 344 TCP/IP implementations may use statistically predictable 345 initial sequence numbers", 346 http://www.kb.cert.org/vuls/id/498440, 2001. 348 [Wright1994] 349 Wright, G. and W. Stevens, "TCP/IP Illustrated, Volume 2: 350 The Implementation", Addison-Wesley, 1994. 352 [Zalewski2001] 353 Zalewski, M., "Strange Attractors and TCP/IP Sequence 354 Number Analysis", 355 http://lcamtuf.coredump.cx/oldtcp/tcpseq.html, 2001. 357 [Zalewski2002] 358 Zalewski, M., "Strange Attractors and TCP/IP Sequence 359 Number Analysis - One Year Later", 360 http://lcamtuf.coredump.cx/newtcp/, 2002. 362 Appendix A. Address-based trust relationship exploitation attacks 364 This section discusses the trust-relationship exploitation attack 365 that originally motivated the publication of RFC 1948 [RFC1948]. It 366 should be noted that while RFC 1948 focused its discussion of 367 address-based trust relationship exploitation attacks on Telnet 368 [RFC0854] and the various UNIX "r" commands, both Telnet and the 369 various "r" commands have since been largely replaced by secure 370 counter-parts (such as SSH [RFC4251]) for the purpose of remote login 371 and remote command execution. Nevertheless, address-based trust 372 relationships are still employed nowadays in some scenarios. For 373 example, some SMTP [RFC5321] deployments still authenticate their 374 users by means of their IP addresses, even when more appropriate 375 authentication mechanisms are available [RFC4954]. Another example 376 is the authentication of DNS secondary servers [RFC1034] by means of 377 their IP addresses for allowing DNS zone transfers [RFC5936], or any 378 other access control mechanism based on IP addresses. 380 In 1985, Morris [Morris1985] described a form of attack based on 381 guessing what sequence numbers TCP [RFC0793] will use for new 382 connections. Briefly, the attacker gags a host trusted by the 383 target, impersonates the IP address of the trusted host when talking 384 to the target, and completes the 3-way handshake based on its guess 385 at the next initial sequence number to be used. An ordinary 386 connection to the target is used to gather sequence number state 387 information. This entire sequence, coupled with address-based 388 authentication, allows the attacker to execute commands on the target 389 host. 391 Clearly, the proper solution for these attacks is cryptographic 392 authentication [RFC4301] [RFC4120] [RFC4251]. 394 The following subsections provide technical details for the trust 395 relationship exploitation attack described by Morris [Morris1985]. 397 A.1. Blind TCP connection-spoofing 399 In order to understand the particular case of sequence number 400 guessing, one must look at the 3-way handshake used in the TCP open 401 sequence [RFC0793]. Suppose client machine A wants to talk to rsh 402 server B. It sends the following message: 404 A->B: SYN, ISNa 406 That is, it sends a packet with the SYN ("synchronize sequence 407 number") bit set and an initial sequence number ISNa. 409 B replies with 411 B->A: SYN, ISNb, ACK(ISNa) 413 In addition to sending its own initial sequence number, it 414 acknowledges A's. Note that the actual numeric value ISNa must 415 appear in the message. 417 A concludes the handshake by sending 419 A->B: ACK(ISNb) 421 RFC 793 [RFC0793] specifies that the 32-bit counter be incremented by 422 1 in the low-order position about every 4 microseconds. Instead, 423 Berkeley-derived kernels traditionally incremented it by a constant 424 every second, and by another constant for each new connection. Thus, 425 if you opened a connection to a machine, you knew to a very high 426 degree of confidence what sequence number it would use for its next 427 connection. And therein lied the vulnerability. 429 The attacker X first opens a real connection to its target B -- say, 430 to the mail port or the TCP echo port. This gives ISNb. It then 431 impersonates A and sends 433 Ax->B: SYN, ISNx 435 where "Ax" denotes a packet sent by X pretending to be A. 437 B's response to X's original SYN (so to speak) 439 B->A: SYN, ISNb', ACK(ISNx) 441 goes to the legitimate A, about which more anon. X never sees that 442 message but can still send 444 Ax->B: ACK(ISNb') 446 using the predicted value for ISNb'. If the guess is right -- and 447 usually it will be, if the sequence numbers are weak -- B's rsh 448 server thinks it has a legitimate connection with A, when in fact X 449 is sending the packets. X can't see the output from this session, 450 but it can execute commands as more or less any user -- and in that 451 case, the game is over and X has won. 453 There is a minor difficulty here. If A sees B's message, it will 454 realize that B is acknowledging something it never sent, and will 455 send a RST packet in response to tear down the connection. There are 456 a variety of ways to prevent this; the easiest is to wait until the 457 real A is down (possibly as a result of enemy action, of course). In 458 actual practice, X can gag A by exploiting a very common 459 implementation bug; this is described in the next subsection. 461 A.2. An old BSD bug 463 As mentioned in the previous sub-section, attackers performing a 464 trust relationship exloitation attack may want to "gag" the trusted 465 machine first. While a number of strategies are possible, most of 466 the attacks detected in the wild relied on an implementation bug. 468 When SYN packets are received for a connection, the receiving system 469 creates a new TCB in SYN-RCVD state. To avoid overconsumption of 470 resources, 4.2BSD-derived systems permit only a limited number of 471 TCBs in this state per connection. Once this limit is reached, 472 future SYN packets for new connections are discarded; it is assumed 473 that the client will retransmit them as needed. 475 When a packet is received, the first thing that must be done is a 476 search for the TCB for that connection. If no TCB is found, the 477 kernel searches for a "wild card" TCB used by servers to accept 478 connections from all clients. Unfortunately, in many kernels this 479 code was invoked for any incoming packets, not just for initial SYN 480 packets. If the SYN-RCVD queue was full for the wildcard TCB, any 481 new packets specifying just that host and port number were discarded, 482 even if they weren't SYN packets. 484 To gag a host, then, the attacker sent a few dozen SYN packets to the 485 rlogin port from different port numbers on some non-existent machine. 486 This filled up the SYN-RCVD queue, while the SYN+ACK packets went off 487 to the bit bucket. The attack on the target machine then appeared to 488 come from the rlogin port on the trusted machine. The replies -- the 489 SYN+ACKs from the target -- were perceived as packets belonging to a 490 full queue, and were dropped silently. This could have been avoided 491 if the full queue code checked for the ACK bit, which could not 492 legally be on for legitimate open requests (if it was on, an RST 493 should be sent in response). 495 Appendix B. Changes from previous versions of the document 497 B.1. Changes from RFC 1948 499 o New document aims at Standards Track (rather than Informaitonal). 501 o The discussion of address-based trust relationship attacks was 502 updated and moved to an Appendix. 504 o The recommended hash algorithm has been changed to SHA-256 505 [FIPS-SHS], in response to the security concerns for MD5 506 [RFC1321]. 508 o Formal requirements ([RFC2119]) are specified. 510 Authors' Addresses 512 Fernando Gont 513 Universidad Tecnologica Nacional / Facultad Regional Haedo 514 Evaristo Carriego 2644 515 Haedo, Provincia de Buenos Aires 1706 516 Argentina 518 Phone: +54 11 4650 8472 519 Email: fernando@gont.com.ar 520 URI: http://www.gont.com.ar 522 Steven M. Bellovin 523 Columbia University 524 1214 Amsterdam Avenue 525 MC 0401 526 New York, NY 10027 527 US 529 Phone: +1 212 939 7149 530 Email: bellovin@acm.org