RFC 6528

Defending against Sequence Number Attacks

📅 published February 2012, from ietf

RFC 6528: Defending against Sequence Number Attacks 🎀

Okay bestie, this one is the ISN glow-up you need to know about ✨ It's from the Internet Engineering Task Force (IETF) and was published in February 2012 as a Standards Track document, with ISSN 2070-1721. Its authors are F. Gont (SI6 Networks / UTN-FRH) and S. Bellovin (Columbia University). It obsoletes RFC 1948 and updates RFC 793, so it's basically the successor to 1948 and an upgrade to 793 🦋

Abstract

Okay so the vibe here is simple: this doc gives you an algorithm for generating TCP Initial Sequence Numbers (ISNs) so an off-path attacker has a much harder time guessing the sequence numbers a target connection is using 🔒 It revises (and formally obsoletes) RFC 1948, and it takes the ISN generation algorithm from that doc to Standards Track, formally updating RFC 793 💜

Status of This Memo

This is an Internet Standards Track document 🌸

This doc is a product of the Internet Engineering Task Force (IETF), so it represents the consensus of the IETF community. It went through public review and got approved for publication by the Internet Engineering Steering Group (IESG). If you want more info on Internet Standards, check Section 2 of RFC 5741 📖

For the current status of this document, any errata, and a way to send feedback, go to http://www.rfc-editor.org/info/rfc6528 ✨

Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved 🩷

This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stand on the publication date. Please read those carefully because they spell out your rights and restrictions for this doc 🧾 Any Code Components pulled out of this document must include the Simplified BSD License text described in Section 4.e of the Trust Legal Provisions, and they come without warranty as described in the Simplified BSD License 🫶

Table of Contents

1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
2.  Generation of Initial Sequence Numbers . . . . . . . . . . . .  3
3.  Proposed Initial Sequence Number Generation Algorithm  . . . .  4
4.  Security Considerations  . . . . . . . . . . . . . . . . . . .  5
5.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  6
6.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  6
  6.1.  Normative References . . . . . . . . . . . . . . . . . . .  6
  6.2.  Informative References . . . . . . . . . . . . . . . . . .  7
Appendix A.  Address-Based Trust-Relationship Exploitation
             Attacks . . . . . . . . . . . . . . . . . . . . . . . 10
  A.1.  Blind TCP Connection-Spoofing  . . . . . . . . . . . . . . 10
Appendix B.  Changes from RFC 1948 . . . . . . . . . . . . . . . . 12

1. Introduction ✨

For a long time, the Internet has dealt with a bunch of off-path attacks against TCP connections 💀 They've ranged from trust-relationship exploitation all the way to denial-of-service attacks [CPNI-TCP]. Some of these attacks go way back, at least to 1985, when Morris [Morris1985] described an attack based on guessing what sequence numbers TCP [RFC0793] would use for new connections between two known end-points 🙈

In 1996, RFC 1948 [RFC1948] proposed an algorithm for picking TCP Initial Sequence Numbers (ISNs) so the chances of an off-path attacker guessing valid sequence numbers would go down 📉 With that algorithm, attacks like this would only still be possible if the attacker already had the ability to perform "man-in-the-middle" attacks 🕵️‍♀️

This doc revises (and formally obsoletes) RFC 1948, and it takes the ISN generation algorithm from that doc onto Standards Track 🎀

Here's the roadmap 🗺️ Section 2 gives a quick rundown of what makes a good ISN generation algorithm. Section 3 specifies a good ISN selection algorithm. Appendix A talks about the trust-relationship exploitation attacks that originally motivated RFC 1948 [RFC1948]. Finally, Appendix B lists the differences between RFC 1948 and this doc 💅

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this doc are to be interpreted as described in RFC 2119 [RFC2119]. Important, bestie 👑

2. Generation of Initial Sequence Numbers 🌈

RFC 793 [RFC0793] says the choice of a connection's ISN isn't arbitrary. The goal is to lower the chances that a stale segment gets accepted by a new incarnation of an earlier connection 🧚 RFC 793 [RFC0793] also suggests a global 32-bit ISN generator that goes up by 1 roughly every 4 microseconds ⏱️

Here's the lowkey interesting part 👀 In practice, protection against stale segments from an older incarnation of a connection comes from not letting a new incarnation of that connection get created until 2*MSL has passed since a segment from the old incarnation was last seen (where "MSL" is the "Maximum Segment Lifetime" [RFC0793]). TIME-WAIT state and TCP's "quiet time" concept handle that (see Appendix B of [RFC1323]) ⌛

Many stacks (e.g., 4.2BSD-derived ones) assume ISNs keep increasing across connections, so they use the ISN of an incoming SYN segment to run "heuristics". Those heuristics let a new incarnation of a connection get created while the previous incarnation is still in the TIME-WAIT state (see p. 945 of [Wright1994]) 🫠 This avoids an interoperability problem that can show up when a node sets up connections to one specific TCP end-point at a high rate [Silbersack2005] 🚀

Unfortunately, the ISN generator described in [RFC0793] makes it super easy for an off-path attacker to predict the ISN a TCP will use for new connections. That opens the door to a bunch of attacks on TCP connections [CPNI-TCP] 😭 One of the possible attacks that takes advantage of weak sequence numbers was first described in [Morris1985], and it got widely publicized about 10 years later [Shimomura1995]. [CERT2001] and [USCERT2001] are advisories about the security implications of weak ISN generators 📢 [Zalewski2001] and [Zalewski2002] have a detailed analysis of ISN generators and a survey of the algorithms popular TCP implementations use 🔍

Simple random selection of TCP ISNs would help against the attacks that require an attacker to guess valid sequence numbers. But it would also break the 4.4BSD "heuristics" that accept a new incoming connection while a previous incarnation of that connection is in the TIME-WAIT state [Silbersack2005] 💔

Here's the plan 💡 We can stop sequence number guessing attacks by giving each connection, meaning each four-tuple of (localip, localport, remoteip, remoteport), its own sequence number space. Inside each space, the ISN is incremented according to [RFC0793]. But there's no obvious relationship between the numbering in different spaces 🧩

Another option would be to prevent sequence number guessing attacks without breaking the 4.4BSD heuristics: do simple random selection of TCP ISNs while keeping state for dead connections. For example, you could change the TCP state transition diagram so that both end-points of all connections go to TIME-WAIT state. That would work, but it would eat up system memory to store the extra state 😩 So instead, we propose an improvement to the TCP ISN generation algorithm that doesn't require TCP to keep state for all recently terminated connections 🌸

3. Proposed Initial Sequence Number Generation Algorithm 🦄

Okay this is the core of it 🔥 TCP SHOULD generate its Initial Sequence Numbers with this expression:

ISN = M + F(localip, localport, remoteip, remoteport, secretkey)

Here M is the 4 microsecond timer, and F() is a pseudorandom function (PRF) of the connection-id. F() MUST NOT be computable from the outside, or an attacker could still guess sequence numbers from the ISN used for some other connection 🙅‍♀️ The PRF could be implemented as a cryptographic hash of the concatenation of the connection-id and some secret data. MD5 [RFC1321] would be a good choice for the hash function 🍓

The result of F() is no more secure than the secret key. If an attacker knows which cryptographic hash function the victim is using (which we should expect), and can get enough material (i.e., ISNs selected by the victim), the attacker may just search the entire secret-key space to find matches. To protect against this, the secret key should be a reasonable length. Key lengths of 128 bits should be adequate. The secret key can either be a true random number [RFC4086] or some per-host secret 🔐 One possible way to protect the secret key is to change it now and then. For example, the secret key could be changed whenever one of the following events occurs:

  • The system is being bootstrapped (e.g., the secret key could be a combination of some secret and the boot time of the machine).
  • Some predefined/random time has expired.
  • The secret key has been used often enough that it should be regarded as insecure at that point.

Heads up, though 🚨 changing the secret changes the ISN space used for reincarnated connections, and that could make the 4.4BSD heuristics fail. To stay safe, either the dead connection state could be kept, or a quiet time of two maximum segment lifetimes could be observed before such a change 🫶

It should be noted that while there have been concerns about the security properties of MD5 [RFC6151], the algorithm in this doc only aims to reduce the chances of an off-path attacker guessing the ISN of a new connection. So in our threat model, it isn't worth the effort for an attacker to try to learn the secret key. MD5 is faster than other "stronger" alternatives and is used in virtually all existing implementations of this algorithm, so we consider its use in the specified algorithm acceptable 💜 Implementations should still weigh the trade-offs of using functions with stronger security properties, and use them if that's deemed appropriate ✨

4. Security Considerations 🔐

Okay bestie, real talk: good sequence numbers are not a replacement for real cryptographic authentication 🙅‍♀️. Stuff like IPsec [RFC4301] or the TCP Authentication Option (TCP-AO) [RFC5925] is the actual main character here ✨. At best, sequence numbers are a palliative measure 🩹.

If random numbers are the only source of the secret, they MUST be chosen following the recommendations in [RFC4086]. No shortcuts, periodt 💅.

A security thing worth flagging about the algorithm in this document is that it might let an attacker count how many systems sit behind a Network Address Translator (NAT) [RFC3022] 👀. It depends on which ISN generators each system behind the NAT is running. The attacker opens a bunch of TCP connections through the NAT's public address and counts how many different sequence number "spaces" show up 🔍. [Gont2009] talks about how this and other information leaks at NATs could be mitigated 🛡️.

An eavesdropper who can see the initial messages of a connection can figure out its sequence number state, and could still try sequence number guessing attacks by impersonating that connection 😬. But honestly, that eavesdropper can also just hijack existing connections [Joncheray1995], so the extra threat isn't that huge 🤷‍♀️. Still, the offset between a fake connection and a real one stays more or less constant for the lifetime of the secret. So it's super important that attackers can never capture those packets 🚫. Typical attacks that could expose them include eavesdropping and the whole variety of routing attacks covered in [Bellovin1989] 🙈.

Off-path attacks against TCP connections need the attacker to guess or know the four-tuple (localip, localport, remoteip, remoteport) that identifies the target connection. Bestie, this is the key detail 🔑.

TCP port number randomization [RFC6056] makes it harder for an attacker to guess that four-tuple, because it hides how TCP ephemeral ports get picked 🎲. So it helps mitigate these attacks 🫶. [RFC6056] also gives advice on picking TCP ephemeral ports, which improves overall protection of TCP connections against off-path attacks 💜.

[CPNI-TCP] has a discussion of all the currently known attacks that need an attacker to know or guess the TCP sequence numbers a target connection is using 📚.

5. Acknowledgements 🌸

Matt Blaze and Jim Ellis brought some crucial ideas to RFC 1948, which this document is based on 🙌. Frank Kastenholz gave constructive comments on that memo too 💕.

The authors of this document want to thank (in chronological order) Alfred Hoenes, Lloyd Wood, Lars Eggert, Joe Touch, William Allen Simpson, Tim Shepard, Wesley Eddy, Anantha Ramaiah, and Ben Campbell for their valuable comments on draft versions of this document 🥹✨.

Fernando Gont wants to thank Jorge Oscar Gont, Nelida Garcia, and Guillermo Gont for their love and support 🫶, and Daniel Bellomo and Christian O'Flaherty for supporting his Internet engineering activities 🌈.

Fernando Gont's attendance at IETF meetings was supported by ISOC's "Fellowship to the IETF" program 🎀.

6. References 📖

6.1. Normative References

[RFC0793]         Postel, J., "Transmission Control Protocol", STD 7,
                  RFC 793, September 1981.

[RFC1321]         Rivest, R., "The MD5 Message-Digest Algorithm",
                  RFC 1321, April 1992.

[RFC1323]         Jacobson, V., Braden, B., and D. Borman, "TCP
                  Extensions for High Performance", RFC 1323,
                  May 1992.

[RFC2119]         Bradner, S., "Key words for use in RFCs to Indicate
                  Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC4086]         Eastlake, D., Schiller, J., and S. Crocker,
                  "Randomness Requirements for Security", BCP 106,
                  RFC 4086, June 2005.

[RFC6056]         Larsen, M. and F. Gont, "Recommendations for
                  Transport-Protocol Port Randomization", BCP 156,
                  RFC 6056, January 2011.

6.2. Informative References

[Bellovin1989]    Morris, R., "Security Problems in the TCP/IP
                  Protocol Suite", Computer Communications Review,
                  vol. 19, no. 2, pp. 32-48, 1989.

[CERT2001]        CERT, "CERT Advisory CA-2001-09: Statistical
                  Weaknesses in TCP/IP Initial Sequence Numbers",
                  http://www.cert.org/advisories/CA-2001-09.html,
                  2001.

[CPNI-TCP]        CPNI, "Security Assessment of the Transmission
                  Control Protocol (TCP)",  http://www.gont.com.ar/
                  papers/tn-03-09-security-assessment-TCP.pdf, 2009.

[Gont2009]        Gont, F. and P. Srisuresh, "Security implications
                  of Network Address Translators (NATs)", Work
                  in Progress, October 2009.

[Joncheray1995]   Joncheray, L., "A Simple Active Attack Against
                  TCP", Proc. Fifth Usenix UNIX Security Symposium,
                  1995.

[Morris1985]      Morris, R., "A Weakness in the 4.2BSD UNIX TCP/IP
                  Software", CSTR 117, AT&T Bell Laboratories, Murray
                  Hill, NJ, 1985.

[RFC0854]         Postel, J. and J. Reynolds, "Telnet Protocol
                  Specification", STD 8, RFC 854, May 1983.

[RFC1034]         Mockapetris, P., "Domain names - concepts and
                  facilities", STD 13, RFC 1034, November 1987.

[RFC1948]         Bellovin, S., "Defending Against Sequence Number
                  Attacks", RFC 1948, May 1996.

[RFC3022]         Srisuresh, P. and K. Egevang, "Traditional IP
                  Network Address Translator (Traditional NAT)",
                  RFC 3022, January 2001.

[RFC4120]         Neuman, C., Yu, T., Hartman, S., and K. Raeburn,
                  "The Kerberos Network Authentication Service (V5)",
                  RFC 4120, July 2005.

[RFC4251]         Ylonen, T. and C. Lonvick, "The Secure Shell (SSH)
                  Protocol Architecture", RFC 4251, January 2006.

[RFC4301]         Kent, S. and K. Seo, "Security Architecture for the
                  Internet Protocol", RFC 4301, December 2005.

[RFC4954]         Siemborski, R. and A. Melnikov, "SMTP Service
                  Extension for Authentication", RFC 4954, July 2007.

[RFC5321]         Klensin, J., "Simple Mail Transfer Protocol",
                  RFC 5321, October 2008.

[RFC5925]         Touch, J., Mankin, A., and R. Bonica, "The TCP
                  Authentication Option", RFC 5925, June 2010.

[RFC5936]         Lewis, E. and A. Hoenes, "DNS Zone Transfer
                  Protocol (AXFR)", RFC 5936, June 2010.

[RFC6151]         Turner, S. and L. Chen, "Updated Security
                  Considerations for the MD5 Message-Digest and the
                  HMAC-MD5 Algorithms", RFC 6151, March 2011.

[Shimomura1995]   Shimomura, T., "Technical details of the attack
                  described by Markoff in NYT",
                  http://www.gont.com.ar/docs/post-shimomura-
                  usenet.txt, Message posted in USENET's
                  comp.security.misc newsgroup, Message-ID:
                  <3g5gkl$5j1@ariel.sdsc.edu>, 1995.

[Silbersack2005]  Silbersack, M., "Improving TCP/IP security through
                  randomization without sacrificing
                  interoperability", EuroBSDCon 2005 Conference.

[USCERT2001]      US-CERT, "US-CERT Vulnerability Note VU#498440:
                  Multiple TCP/IP implementations may use
                  statistically predictable initial sequence
                  numbers",  http://www.kb.cert.org/vuls/id/498440,
                  2001.

[Wright1994]      Wright, G. and W. Stevens, "TCP/IP Illustrated,
                  Volume 2: The Implementation", Addison-Wesley,
                  1994.

[Zalewski2001]    Zalewski, M., "Strange Attractors and TCP/IP
                  Sequence Number Analysis",
                  http://lcamtuf.coredump.cx/oldtcp/tcpseq.html,
                  2001.

[Zalewski2002]    Zalewski, M., "Strange Attractors and TCP/IP
                  Sequence Number Analysis - One Year Later",
                  http://lcamtuf.coredump.cx/newtcp/, 2002.

Appendix A. Address-Based Trust-Relationship Exploitation Attacks 🦋

This section talks about the trust-relationship exploitation attack that originally motivated RFC 1948 [RFC1948] 🕵️‍♀️. RFC 1948 focused its discussion of address-based trust-relationship exploitation attacks on Telnet [RFC0854] and the various UNIX "r" commands. Both Telnet and the "r" commands have since been mostly replaced by secure counterparts, like SSH [RFC4251], for remote login and remote command execution 🔒. Still, address-based trust relationships are employed in some scenarios today 😤. For example, some SMTP [RFC5321] deployments still authenticate their users by IP address, even when better authentication mechanisms are available [RFC4954] 🙃. Another example is authenticating DNS secondary servers [RFC1034] by their IP addresses so they can do DNS zone transfers [RFC5936], or any other access control mechanism based on IP addresses 🌐.

In 1985, Morris [Morris1985] described an attack based on guessing what sequence numbers TCP [RFC0793] will use for new connections 🎭. The basic idea: the attacker silences a host trusted by the target, impersonates that trusted host's IP address when talking to the target, and completes the three-way handshake based on its guess at the next ISN 😱. An ordinary connection to the target is used to gather sequence number state information 🧩. This whole sequence, combined with address-based authentication, lets the attacker run commands on the target host 💀.

Clearly, the proper solution for these attacks is cryptographic authentication [RFC4301] [RFC4120] [RFC4251] 🔐✨.

The following subsection provides technical details for the trust-relationship exploitation attack described by Morris [Morris1985] 🧠.

A.1. Blind TCP Connection-Spoofing 🦋

okay so to get why guessing sequence numbers is such a big deal, we have to look at the three-way handshake used to open a TCP connection [RFC0793] 💅. Say client machine A wants to talk to rsh server B. It starts by sending this:

A->B: SYN, ISNa

That's a packet with the SYN ("synchronize sequence number") bit set and an initial sequence number ISNa ✨.

B replies with:

B->A: SYN, ISNb, ACK(ISNa)

So B sends its own ISN and also acknowledges A's. Note that the actual numeric value ISNa has to show up in the message 🫶.

A finishes the handshake by sending:

A->B: ACK(ISNb)

RFC 793 [RFC0793] says the 32-bit counter should go up by 1 in the low-order position about every 4 microseconds. But Berkeley-derived kernels were traditionally doing something way different: they bumped it by a constant every second, and by another constant for each new connection 🙈. So if you opened a connection to a machine, you could know with a super high degree of confidence what sequence number it would use for its next connection. And therein lay the vulnerability 💀.

Here's how the attacker X runs the play. X first opens a real connection to its target B, like to the mail port or the TCP echo port 🧚. That gives X ISNb. Then X impersonates A and sends:

Ax->B: SYN, ISNx

where "Ax" denotes a packet sent by X pretending to be A.

B's response to X's original SYN (so to speak):

B->A: SYN, ISNb', ACK(ISNx)

goes to the legit A, about which more anon 👀. X never sees that message, but X can still send:

Ax->B: ACK(ISNb')

using the predicted value for ISNb'. If the guess is right (and usually it will be, if the sequence numbers are weak 😭), B's rsh server thinks it has a legit connection with A, when in fact X is the one sending the packets. X can't see the output from this session, but X can execute commands as more or less any user, and in that case, the game is over and X has won 👑🔥.

There's a minor difficulty here, though 🙃. If A sees B's message, A will realize B is acknowledging something it never sent, and will send a RST packet in response to tear down the connection. However, an attacker could send the TCP segments containing the commands to be executed back-to-back with the segments needed to establish the TCP connection. So by the time the connection gets reset, the attacker has already won 🏆.

In the past, attackers exploited a common TCP implementation bug to prevent the connection from being reset (see subsection "A Common TCP Bug" in [RFC1948]). However, all TCP implementations that used to implement this bug have been fixed for a long time.

Appendix B. Changes from RFC 1948 🎀

okay here's the tea on what changed from RFC 1948 ☕:

  • This document is Standards Track (rather than Informational) 📜.
  • Formal requirements [RFC2119] are specified 💅.
  • The discussion of address-based trust-relationship attacks has been updated and moved to an appendix 🦋.
  • The subsection entitled "A Common TCP Bug" (describing a common bug in the BSD TCP implementation) has been removed 🗑️ bye bye bug 🌸.

Authors' Addresses 💌

Fernando Gont
SI6 Networks / UTN-FRH
Evaristo Carriego 2644
Haedo, Provincia de Buenos Aires  1706
Argentina

Phone: +54 11 4650 8472
EMail: fgont@si6networks.com
URI:   http://www.si6networks.com


Steven M. Bellovin
Columbia University
1214 Amsterdam Avenue
MC 0401
New York, NY  10027
US

Phone: +1 212 939 7149
EMail: bellovin@acm.org
📦 where this page comes from