idnits 2.17.1 draft-ietf-tcpm-rfc1948bis-02.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 directly say this. It does mention RFC793 though, so this could be OK. 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 (December 16, 2011) is 4514 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 Extensions F. Gont 3 (tcpm) SI6 Networks / UTN-FRH 4 Internet-Draft S. Bellovin 5 Obsoletes: 1948 (if approved) Columbia University 6 Updates: 793 (if approved) December 16, 2011 7 Intended status: Standards Track 8 Expires: June 18, 2012 10 Defending Against Sequence Number Attacks 11 draft-ietf-tcpm-rfc1948bis-02.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 guessing the sequence numbers in use by a target connection 18 are reduced. This document revises (and formally obsoletes) RFC 19 1948, and takes the ISN generation algorithm originally proposed in 20 that document to Standards Track, formally updating RFC 793. 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 June 18, 2012. 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 generation algorithm . . . . 4 59 4. Security Considerations . . . . . . . . . . . . . . . . . . . 6 60 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 61 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 62 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 63 7.1. Normative References . . . . . . . . . . . . . . . . . . . 7 64 7.2. Informative References . . . . . . . . . . . . . . . . . . 8 65 Appendix A. Address-based trust relationship exploitation 66 attacks . . . . . . . . . . . . . . . . . . . . . . . 10 67 A.1. Blind TCP connection-spoofing . . . . . . . . . . . . . . 10 68 Appendix B. Changes from RFC 1948 . . . . . . . . . . . . . . . . 12 69 Appendix C. Changes from previous versions of the document 70 (this section should be removed by the RFC Editor 71 before publication of this document as an RFC) . . . 12 72 C.1. Changes from draft-ietf-tcpm-rfc1948bis-00 . . . . . . . . 12 73 C.2. Changes from draft-gont-tcpm-rfc1948bis-00 . . . . . . . . 12 74 C.3. Changes from RFC 1948 . . . . . . . . . . . . . . . . . . 13 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 77 1. Introduction 79 For a long time, the Internet has experienced a number of off-path 80 attacks against TCP connections. These attacks have ranged from 81 trust relationships exploitation to Denial of Service attacks 82 [CPNI-TCP]. Discussion of some of these attacks dates back to at 83 least 1985, when Morris [Morris1985] described a form of attack based 84 on guessing what sequence numbers TCP [RFC0793] will use for new 85 connections between two known end-points. 87 In 1996, RFC 1948 [RFC1948] proposed an algorithm for the selection 88 of TCP Initial Sequence Numbers (ISNs), such that the chances of an 89 off-path attacker guessing valid sequence numbers are reduced. With 90 the aforementioned algorithm, such attacks would remain possible if 91 and only if the attacker already has the ability to perform "man in 92 the middle" attacks. 94 This document revises (and formally obsoletes) RFC 1948, and takes 95 the ISN generation algorithm originally proposed in that document to 96 Standards Track. 98 Section 2 provides a brief discussion of the requirements for a good 99 ISN generation algorithm. Section 3 specifies a good ISN selection 100 algorithm. Finally, Appendix A provides a discussion of the trust- 101 relationship exploitation attacks that originally motivated the 102 publication of RFC 1948 [RFC1948]. 104 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 105 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 106 document are to be interpreted as described in RFC 2119 [RFC2119]. 108 2. Generation of Initial Sequence Numbers 110 RFC 793 [RFC0793] suggests that the choice of the ISN of a connection 111 is not arbitrary, but aims to reduce the chances of a stale segment 112 from being accepted by a new incarnation of a previous connection. 113 RFC 793 [RFC0793] suggests the use of a global 32-bit ISN generator 114 that is incremented by 1 roughly every 4 microseconds. 116 It is interesting to note that, as a matter of fact, protection 117 against stale segments from a previous incarnation of the connection 118 is enforced by preventing the creation of a new incarnation of a 119 previous connection before 2*MSL have passed since a segment 120 corresponding to the old incarnation was last seen. This is 121 accomplished by the TIME-WAIT state, and TCP's "quiet time" concept 122 (see Appendix B of [RFC1323]). 124 Based on the assumption that ISNs are monotonically-increasing across 125 connections, many stacks (e.g., 4.2BSD-derived) use the ISN of an 126 incoming SYN segment to perform "heuristics" that enable the creation 127 of a new incarnation of a connection while the previous incarnation 128 is still in the TIME-WAIT state (see pp. 945 of [Wright1994]). This 129 avoids an interoperability problem that may arise when a node 130 establishes connections to a specific TCP end-point at a high rate 131 [Silbersack2005]. 133 Unfortunately, the ISN generator described in [RFC0793] makes it 134 trivial for an off-path attacker to predict the ISN that a TCP will 135 use for new connections, thus allowing a variety of attacks against 136 TCP connections [CPNI-TCP]. One of the possible attacks that takes 137 advantage of weak sequence numbers was first described in 138 [Morris1985], and its exploitation was widely publicized about 10 139 years later [Shimomura1995]. [CERT2001] and [USCERT2001] are 140 advisories about the security implications of weak ISN generators. 141 [Zalewski2001] and [Zalewski2002] contain a detailed analysis of ISN 142 generators, and a survey of the algorithms in use by popular TCP 143 implementations. 145 Simple random selection of the TCP ISNs would mitigate those attacks 146 that require an attacker to guess valid sequence numbers. However, 147 it would also break the 4.4BSD "heuristics" to accept a new incoming 148 connection when there is a previous incarnation of that connection in 149 the TIME-WAIT state [Silbersack2005]. 151 We can prevent sequence number guessing attacks by giving each 152 connection -- that is, each 4-tuple of (localip, localport, remoteip, 153 remoteport) -- a separate sequence number space. Within each space, 154 the ISN is incremented according to [RFC0793]; however, there is no 155 obvious relationship between the numbering in different spaces. 157 An obvious way to prevent sequence number guessing attacks while not 158 breaking the 4.4BSD heuristics would be to maintain state for dead 159 connections, and the easiest way to do that would be to change the 160 TCP state transition diagram so that both end-points of all 161 connections go to TIME-WAIT state. That would work, but would 162 consume system memory to store the additional state. Instead, we 163 propose an improvement to the TCP ISN generation algorithm, that does 164 not require TCP to keep state for all recently-terminated 165 connections. 167 3. Proposed Initial Sequence Number generation algorithm 169 TCP SHOULD generate its Initial Sequence Numbers with the expression: 171 ISN = M + F(localip, localport, remoteip, remoteport) 173 where M is the 4 microsecond timer, and F() is a pseudorandom 174 function (PRF) of the connection-id. F() MUST NOT be computable from 175 the outside, or an attacker could still guess at sequence numbers 176 from the ISN used for some other connection. The PRF could be 177 implemented as a cryptographic hash of the concatenation of the 178 connection-id and some secret data; MD5 [RFC1321] would be a good 179 choice for the hash function. 181 The result of F() is no more secure than the secret key. If an 182 attacker is aware of which cryptographic hash function is being used 183 by the victim (which we should expect), and the attacker can obtain 184 enough material (i.e., ISNs selected by the victim), the attacker may 185 simply search the entire secret-key space to find matches. To 186 protect against this, the secret key should be of a reasonable 187 length. Key lengths of 128 bits should be adequate. The secret key 188 can either be a true random number [RFC4086], or some per-host 189 secret. A possible mechanism for protecting the secret key would be 190 to change it on occasion. For example, the secret key could be 191 changed whenever one of the following events occur: 193 o The system is being bootstrapped (e.g., the secret key could be a 194 combination of some secret and the boot time of the machine). 196 o Some predefined/random time has expired. 198 o The secret key has been used sufficiently often that it should be 199 regarded as insecure now. 201 Note that changing the secret would change the ISN space used for 202 reincarnated connections, and thus could lead to the 4.4BSD 203 heuristics to fail; to maintain safety, either dead connection state 204 could be kept or a quiet time observed for two maximum segment 205 lifetimes before such a change. 207 It should be noted that while there have been concerns about the 208 security properties of MD5 [RFC6151], the algorithm specified in this 209 document simply aims at reducing the chances of an off-path attacker 210 guessing the ISN of a new connection, and thus in our threat model it 211 is not worth the effort for an attacker to try to learn the secret 212 key. Since MD5 is faster than other "stronger" alternatives, and is 213 used in virtually all existing implementations of this algorithm, we 214 consider that use of MD5 in the specified algorithm is acceptable. 215 However, implementations should consider the trade-offs involved in 216 using functions with stronger security properties, and employ them if 217 it is deemed appropriate. 219 4. Security Considerations 221 Good sequence numbers are not a replacement for cryptographic 222 authentication, such as that provided by IPsec [RFC4301] or TCP-AO 223 [RFC5925]. At best, they are a palliative measure. 225 If random numbers are used as the sole source of the secret, they 226 MUST be chosen in accordance with the recommendations given in 227 [RFC4086]. 229 A security consideration that should be made about the algorithm 230 proposed in this document is that it might allow an attacker to count 231 the number of systems behind a Network Address Translator (NAT) 232 [RFC3022]. Depending on the ISN generators implemented by each of 233 the systems behind the NAT, an attacker might be able to count the 234 number of systems behind a NAT by establishing a number of TCP 235 connections (using the public address of the NAT) and identifying the 236 number of different sequence number "spaces". 237 [I-D.gont-behave-nat-security] discusses how this and other 238 information leakages at NATs could be mitigated. 240 An eavesdropper who can observe the initial messages for a connection 241 can determine its sequence number state, and may still be able to 242 launch sequence number guessing attacks by impersonating that 243 connection. However, such an eavesdropper can also hijack existing 244 connections [Joncheray1995], so the incremental threat is not that 245 high. Still, since the offset between a fake connection and a given 246 real connection will be more or less constant for the lifetime of the 247 secret, it is important to ensure that attackers can never capture 248 such packets. Typical attacks that could disclose them include both 249 eavesdropping and the variety of routing attacks discussed in 250 [Bellovin1989]. 252 Off-path attacks against TCP connections require the attacker to 253 guess or know the four-tuple (localip, localport, remoteip, 254 remoteport) that identifies the target connection. TCP port number 255 randomization [RFC6056] reduces the chances of an attacker of 256 guessing such four-tuple by obfuscating the selection of TCP 257 ephemeral ports, therefore contributing to the mitigation of such 258 attacks. [RFC6056] provides advice on the selection of TCP ephemeral 259 ports, such that the overall protection of TCP connections against 260 off-path attacks is improved. 262 [CPNI-TCP] contains a discussion of all the currently-known attacks 263 that require an attacker to know or be able to guess the TCP sequence 264 numbers in use by the target connection. 266 5. IANA Considerations 268 This document has no actions for IANA. 270 6. Acknowledgements 272 Matt Blaze and Jim Ellis contributed some crucial ideas to RFC 1948, 273 on which this document is based. Frank Kastenholz contributed 274 constructive comments to that memo. 276 The authors of this document would like to thank (in chronological 277 order) Alfred Hoenes, Lloyd Wood, Lars Eggert, Joe Touch, William 278 Allen Simpson, Tim Shepard, Wesley Eddy, Anantha Ramaiah, and Ben 279 Campbell, for providing valuable comments on earlier versions of this 280 document. 282 Fernando Gont would like to thank the United Kingdom's Centre for the 283 Protection of National Infrastructure (UK CPNI) for their continued 284 support. 286 7. References 288 7.1. Normative References 290 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 291 RFC 793, September 1981. 293 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 294 April 1992. 296 [RFC1323] Jacobson, V., Braden, B., and D. Borman, "TCP Extensions 297 for High Performance", RFC 1323, May 1992. 299 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 300 Requirement Levels", BCP 14, RFC 2119, March 1997. 302 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 303 Requirements for Security", BCP 106, RFC 4086, June 2005. 305 [RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport- 306 Protocol Port Randomization", BCP 156, RFC 6056, 307 January 2011. 309 7.2. Informative References 311 [Bellovin1989] 312 Morris, R., "Security Problems in the TCP/IP Protocol 313 Suite", Computer Communications Review, vol. 19, no. 2, 314 pp. 32-48, 1989. 316 [CERT2001] 317 CERT, "CERT Advisory CA-2001-09: Statistical Weaknesses in 318 TCP/IP Initial Sequence Numbers", 319 http://www.cert.org/advisories/CA-2001-09.html, 2001. 321 [CPNI-TCP] 322 CPNI, "Security Assessment of the Transmission Control 323 Protocol (TCP)", http://www.cpni.gov.uk/Docs/ 324 tn-03-09-security-assessment-TCP.pdf, 2009. 326 [I-D.gont-behave-nat-security] 327 Gont, F. and P. Srisuresh, "Security implications of 328 Network Address Translators (NATs)", 329 draft-gont-behave-nat-security-03 (work in progress), 330 October 2009. 332 [Joncheray1995] 333 Joncheray, L., "A Simple Active Attack Against TCP", Proc. 334 Fifth Usenix UNIX Security Symposium, 1995. 336 [Morris1985] 337 Morris, R., "A Weakness in the 4.2BSD UNIX TCP/IP 338 Software", CSTR 117, AT&T Bell Laboratories, Murray Hill, 339 NJ, 1985. 341 [RFC0854] Postel, J. and J. Reynolds, "Telnet Protocol 342 Specification", STD 8, RFC 854, May 1983. 344 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 345 STD 13, RFC 1034, November 1987. 347 [RFC1948] Bellovin, S., "Defending Against Sequence Number Attacks", 348 RFC 1948, May 1996. 350 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 351 Address Translator (Traditional NAT)", RFC 3022, 352 January 2001. 354 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The 355 Kerberos Network Authentication Service (V5)", RFC 4120, 356 July 2005. 358 [RFC4251] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) 359 Protocol Architecture", RFC 4251, January 2006. 361 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 362 Internet Protocol", RFC 4301, December 2005. 364 [RFC4954] Siemborski, R. and A. Melnikov, "SMTP Service Extension 365 for Authentication", RFC 4954, July 2007. 367 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 368 October 2008. 370 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 371 Authentication Option", RFC 5925, June 2010. 373 [RFC5936] Lewis, E. and A. Hoenes, "DNS Zone Transfer Protocol 374 (AXFR)", RFC 5936, June 2010. 376 [RFC6151] Turner, S. and L. Chen, "Updated Security Considerations 377 for the MD5 Message-Digest and the HMAC-MD5 Algorithms", 378 RFC 6151, March 2011. 380 [Shimomura1995] 381 Shimomura, T., "Technical details of the attack described 382 by Markoff in NYT", 383 http://www.gont.com.ar/docs/post-shimomura-usenet.txt, 384 Message posted in USENET's comp.security.misc newsgroup, 385 Message-ID: <3g5gkl$5j1@ariel.sdsc.edu>, 1995. 387 [Silbersack2005] 388 Silbersack, M., "Improving TCP/IP security through 389 randomization without sacrificing interoperability.", 390 EuroBSDCon 2005 Conference . 392 [USCERT2001] 393 US-CERT, "US-CERT Vulnerability Note VU#498440: Multiple 394 TCP/IP implementations may use statistically predictable 395 initial sequence numbers", 396 http://www.kb.cert.org/vuls/id/498440, 2001. 398 [Wright1994] 399 Wright, G. and W. Stevens, "TCP/IP Illustrated, Volume 2: 400 The Implementation", Addison-Wesley, 1994. 402 [Zalewski2001] 403 Zalewski, M., "Strange Attractors and TCP/IP Sequence 404 Number Analysis", 405 http://lcamtuf.coredump.cx/oldtcp/tcpseq.html, 2001. 407 [Zalewski2002] 408 Zalewski, M., "Strange Attractors and TCP/IP Sequence 409 Number Analysis - One Year Later", 410 http://lcamtuf.coredump.cx/newtcp/, 2002. 412 Appendix A. Address-based trust relationship exploitation attacks 414 This section discusses the trust-relationship exploitation attack 415 that originally motivated the publication of RFC 1948 [RFC1948]. It 416 should be noted that while RFC 1948 focused its discussion of 417 address-based trust relationship exploitation attacks on Telnet 418 [RFC0854] and the various UNIX "r" commands, both Telnet and the 419 various "r" commands have since been largely replaced by secure 420 counter-parts (such as SSH [RFC4251]) for the purpose of remote login 421 and remote command execution. Nevertheless, address-based trust 422 relationships are still employed nowadays in some scenarios. For 423 example, some SMTP [RFC5321] deployments still authenticate their 424 users by means of their IP addresses, even when more appropriate 425 authentication mechanisms are available [RFC4954]. Another example 426 is the authentication of DNS secondary servers [RFC1034] by means of 427 their IP addresses for allowing DNS zone transfers [RFC5936], or any 428 other access control mechanism based on IP addresses. 430 In 1985, Morris [Morris1985] described a form of attack based on 431 guessing what sequence numbers TCP [RFC0793] will use for new 432 connections. Briefly, the attacker gags a host trusted by the 433 target, impersonates the IP address of the trusted host when talking 434 to the target, and completes the 3-way handshake based on its guess 435 at the next ISN to be used. An ordinary connection to the target is 436 used to gather sequence number state information. This entire 437 sequence, coupled with address-based authentication, allows the 438 attacker to execute commands on the target host. 440 Clearly, the proper solution for these attacks is cryptographic 441 authentication [RFC4301] [RFC4120] [RFC4251]. 443 The following subsection provides technical details for the trust 444 relationship exploitation attack described by Morris [Morris1985]. 446 A.1. Blind TCP connection-spoofing 448 In order to understand the particular case of sequence number 449 guessing, one must look at the 3-way handshake used in the TCP open 450 sequence [RFC0793]. Suppose client machine A wants to talk to rsh 451 server B. It sends the following message: 453 A->B: SYN, ISNa 455 That is, it sends a packet with the SYN ("synchronize sequence 456 number") bit set and an initial sequence number ISNa. 458 B replies with 460 B->A: SYN, ISNb, ACK(ISNa) 462 In addition to sending its own ISN, it acknowledges A's. Note that 463 the actual numeric value ISNa must appear in the message. 465 A concludes the handshake by sending 467 A->B: ACK(ISNb) 469 RFC 793 [RFC0793] specifies that the 32-bit counter be incremented by 470 1 in the low-order position about every 4 microseconds. Instead, 471 Berkeley-derived kernels traditionally incremented it by a constant 472 every second, and by another constant for each new connection. Thus, 473 if you opened a connection to a machine, you knew to a very high 474 degree of confidence what sequence number it would use for its next 475 connection. And therein lied the vulnerability. 477 The attacker X first opens a real connection to its target B -- say, 478 to the mail port or the TCP echo port. This gives ISNb. It then 479 impersonates A and sends 481 Ax->B: SYN, ISNx 483 where "Ax" denotes a packet sent by X pretending to be A. 485 B's response to X's original SYN (so to speak) 487 B->A: SYN, ISNb', ACK(ISNx) 489 goes to the legitimate A, about which more anon. X never sees that 490 message but can still send 492 Ax->B: ACK(ISNb') 494 using the predicted value for ISNb'. If the guess is right -- and 495 usually it will be, if the sequence numbers are weak -- B's rsh 496 server thinks it has a legitimate connection with A, when in fact X 497 is sending the packets. X can't see the output from this session, 498 but it can execute commands as more or less any user -- and in that 499 case, the game is over and X has won. 501 There is a minor difficulty here. If A sees B's message, it will 502 realize that B is acknowledging something it never sent, and will 503 send a RST packet in response to tear down the connection. However, 504 an attacker could send the TCP segments containing the commands to be 505 executed back-to-back with the segments required to establish the TCP 506 connection, and thus by the time the connection is reset, the 507 attacker has already won. 509 In the past, attackers exploited a common TCP implementation bug 510 to prevent the connection from being reset (see subsection "A 511 Common TCP Bug" in [RFC1948]). However, all TCP implementations 512 that used to implement this bug have been fixed for a long time. 514 Appendix B. Changes from RFC 1948 516 o This document aims at Standards Track (rather than Informational). 518 o Formal requirements ([RFC2119]) are specified. 520 o The discussion of address-based trust relationship attacks has 521 been updated and moved to an Appendix. 523 o The subsection entitled "A Common TCP Bug" (describing a common 524 bug in the BSD TCP implementation) has been removed. 526 Appendix C. Changes from previous versions of the document (this 527 section should be removed by the RFC Editor before 528 publication of this document as an RFC) 530 C.1. Changes from draft-ietf-tcpm-rfc1948bis-00 532 o Addresses WGLC feedback (posted on-list) by Wesley Eddy, and some 533 comments submitted by Anantha Ramaiah. 535 C.2. Changes from draft-gont-tcpm-rfc1948bis-00 537 o The recommended hash algorithm has been changed back to MD5 538 [RFC1321], with a note that the security implications of MD5 have 539 been carefully considered. 541 o The subsection entitled "An old BSD bug" (describing a common bug 542 in the BSD TCP implementation) has been removed. 544 o Minor editorial changes. 546 C.3. Changes from RFC 1948 548 o New document aims at Standards Track (rather than Informational). 550 o The discussion of address-based trust relationship attacks was 551 updated and moved to an Appendix. 553 o The recommended hash algorithm has been changed to SHA-256, in 554 response to the security concerns for MD5 [RFC1321]. 556 o Formal requirements ([RFC2119]) are specified. 558 Authors' Addresses 560 Fernando Gont 561 UTN-FRH / SI6 Networks 562 Evaristo Carriego 2644 563 Haedo, Provincia de Buenos Aires 1706 564 Argentina 566 Phone: +54 11 4650 8472 567 Email: fernando@gont.com.ar 568 URI: http://www.si6networks.com 570 Steven M. Bellovin 571 Columbia University 572 1214 Amsterdam Avenue 573 MC 0401 574 New York, NY 10027 575 US 577 Phone: +1 212 939 7149 578 Email: bellovin@acm.org