Date: Fri, 8 Jun 2001 17:56:07 -0700 From: Don Lewis <Don.Lewis@tsc.tdk.com> To: Mike Silbersack <silby@silby.com>, <freebsd-net@FreeBSD.ORG>, <freebsd-arch@FreeBSD.ORG> Subject: Re: New TCP sequence number generation algorithm; review needed Message-ID: <200106090056.RAA16800@salsa.gv.tsc.tdk.com> In-Reply-To: <20010608005234.W92206-200000@achilles.silby.com> References: <20010608005234.W92206-200000@achilles.silby.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Jun 8, 12:56am, Mike Silbersack wrote: } Subject: New TCP sequence number generation algorithm; review needed [ snip ] } Q: How does this new patch generate sequence numbers? } } A: In short, the patch provides a seperate sequence number space for each } host. These sequence spaces have no relation to the sequence spaces of } other hosts, and are re-randomized whenever a host becomes idle. } } Q: How is this done? } } A: We are able to store a 16-bit variable which corresponds to the upper } 16 bits of a host's sequence number in the cloned route entry for that } host, thanks to extra space which exists in the routing metric structure. } When we need a new sequence number for a host, we load in that value. If } it is zero, as it is when the route is first cloned, we initialize it to a } random value. Then, on this connection and every one after, we shift it } left by 16 bits and increment it by a random value of up to 2^20. } Subsequently, we store the upper 16 bits of the resulting value back in } the cloned route entry, waiting for the next sequence number. Checks are } present to make sure that the sequence number always increments by more } than 2^16-1 and that the sequence number does not go to zero and cause a } re-randomization. If a host is idle for a long period of time, the cloned } route entry will be flushed and we will start the process over. [ snip ] } Q: Ok, what's this RFC1948 sequence number generation scheme I keep } hearing about? } } A: RFC1948 suggests segementing each hostA/portA/hostB/portB pair into a } seperate sequence number space using a hash function of the form: } } ISN = timecounter + MD5(localhost, localport, remotehost, remoteport, shared secret) } } While clever, this algorithm has a major weakness. The shared secret is } used in generating the ISN for all connections to the host in question. } To ensure monotonicity for each connection, this implies that the shared } secret must remain constant for the entire uptime of a machine. As a } result, attackers may make a few connection attempts, store the IPs/ports } used and the sequence number returned. This information can then be fed } into a cracking program which will determine the shared secret. Once the } shared secret is found, the attacker can perfectly spoof a connection to } the machine from any host until the machine is rebooted and the shared } secret changed. [ snip ] Why not combine the two schemes and feed the random per-host data from the cloned route entry into the RFC1948 algorithm? This doesn't solve Terry's objection, though. Another way of strengthening the RFC1948 would be to use some of the bits of MD5(remostehost, another secret) to extract the shared secret from a larger table. This increases the difficulty of discovering the shared secret needed to spoof the host in question, but it doesn't solve the problem of needing to keep the same shared secrets for the uptime of the machine. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200106090056.RAA16800>