【正文】 these should not occur often, and should be logged. After many years of thinking about it, I finally came up with a a solution to classical sequence number attacks. The scheme, described in RFC 1948 [10], used a cryptographic hash function to create a separate sequence number space for each “connection”, a connection being defined per RFC 791 [81] as the unique 4tuple localhost, localport, remotehost, remoteport. This scheme has not been adopted as widely as I would like。 if, say, only the loworder 8 bits were picked randomly, and the granularity of the increment was coarse, the intruder’s work factor is only multiplied by 256. A 2 At the moment, the Inter may not have such stability even over the shortterm, especially on longhaul connections. It is not forting to know that the security of a work relies on its low quality of service. bination of a finegranularity increment and a small random number generator, or just a 32bit generator, is better. Note, though, that many pseudorandom number generators are easily invertible [13]. In fact, given that most such generators work via feedback of their output, the enemy could simply pute the next “random” number to be picked. Some hybrid techniques have promise—using a 32bit generator, for example, but only emitting 16 bits of it—but bruteforce attacks could succeed at determining the seed. One would need at least 16 bits of random data in each increment, and perhaps more, to defeat probes from the work, but that might leave too few bits to guard against a search for the seed. More research or simulations are needed to determine the proper parameters. Rather than go to such lengths, it is simpler to use a cryptographic algorithm (or device) for ISNS generation. The Data Encryption Standard [73] in electronic codebook mode [74] is an attractive choice as the ISNS source, with a simple counter as input. Alternatively, DES could be used in output feedback mode without an additional counter. Either way, great care must be taken to select the key used. The timeofday at boot time is not adequate。 those systems had a vulnerable stat, a fact I refrained from mentioning for fear of pointing attackers at targets. Actual output is shown in Figure 1. There are several salient points here. The first, of course, which I stressed at the time, is that addressbased authentication is very vulnerable to attack. I will return to this point later. A second point is a threat I mention later, but not in this context: if you know the sequence numbers of an active session, you can hijack it. This attack was implemented a few years later by Joncheray [53]. A more important point (and this is one made in [54]) is that the rutilities are implicitly relying on TCP sequence numbers—and hence on TCP session correctness—for security properties. However, TCP was never designed to be a secure protocol, nor were there ever any guarantees about the properties of the sequence number. The underlying issue is this: what properties of a layer are “exported” to a higher layer? Assuming too much at any higher later is a mistake。 I did not make that distinction clear. It is indeed a bad way to do authentication, but it was not blessed by any official standard. 2. TCP Sequence Number Prediction One of the more fascinating security holes was first described byMorris [70]. Briefly, he used TCP sequence number prediction to construct a TCP packet sequence without ever receiving any responses from the server. This allowed him to spoof a trusted host on a local work. The normal TCP connection establishment sequence involves a 3way handshake. The client selects and transmits an initial sequence number ISNC, the server acknowledges it and sends its own sequence number ISNS, and the client acknowledges that. Following those three messages, data transmission may take place. The exchange may be shown schematically as follows: C ! S : SYN(ISNC) S ! C : SYN(ISNS), ACK(ISNC) C ! S : ACK(ISNS) C ! S : data and/or S ! C : data That is, for a conversation to take place, C must first hear ISNS, a more or less random number. Suppose, though, that there was a way for an intruder X to predict ISNS. In that case, it could send the following sequence to impersonate trusted host T: X ! S : SYN(ISNX), SRC = T S ! T : SYN(ISNS), ACK(ISNX) X ! S : ACK(ISNS), SRC = T X ! S : ACK(ISNS), SRC = T, nasty ? data Even though the message S ! T does not go to X, X was able to know its contents, and hence could send data. If X were to perform this attack on a connection that allows mand execution (., the Berkeley rsh server), malicious mands could be executed. How, then, to predict the random ISN? In Berkeley systems, the initial sequence number variable is incremented by a constant amount once per second, and by half that amount each time a connection is initiated. Thus, if one initiates a legitimate connection and observes the ISNS used, one can calculate, with a high degree of confidence, ISN′ S used on the next connection attempt. Morris points out that the reply message S ! T : SYN(ISNS), ACK(ISNX) does not in fact vanish down a black hole。 some, in my opinion, were not. At the time, I chose not to publish a detailed rebuttal。T puters [2]. He was detected when he tried to use uucp to grab password files from various Research machines。 we generally stuck a second Ether board into a VAX or a Sun and used it to do the routing. This mean that the routing software (we used Berkeley’s routed) was accessible to system administrators. And when things broke, we often discovered that it was a routing problem: someone had misconfigured their machine. Once, we found that someone had plugged a new workstation into