Subject: Re: Question on initial sequence numbers

From: der Mouse <[email-masked]>
Date: Mon, 4 Jan 1999 14:08:21 -0500 (EST)

Well, I'm hardly a TCP guru, but here's my take on this.  I'm sure that
if I've botched it, someone who *does* know will correct me.

With that caveat...*charrrrge!* :)

> In a packet trace [] I saw a TCP session finish normally with a
> FIN/ACK.  About a minute later, the client requested a new session,
> [].  The client and server used the same TCP ports as in the previous
> session.  The server indicated in its SYN ACK a TCP sequence number
> of 2+million LOWER than the sequence number it had used to send data
> at the end of the previous session.

> Microsoft asserts this behavior is okay.

In theory, they are wrong; in practice, they're probably right.

> In fact, they tell me that in the near future they will be selecting
> initial TCP sequence numbers at random as a technique to thwart
> hijacking of TCP sessions.

The person who told you this is either incompetent or confused.  Random
ISNs does not thwart session *hijacking*.  What it does thwart is
session *forging*, where host A pretends to be host B when speaking to
host C, and manages to carry out a complete session without seeing any
of C's response packets (which go to B, who may be dead or inaccessible
or even nonexistent).  In order to do this, A has to guess the ISN C
chooses for the connection.

> Microsoft asserts that there is no regard in the client for the prior
> session TCP once the FINish process completes successfully.

As I said above, this is a case where practice and theory diverge
widely.

IP packet TTLs are theoretically times in seconds.  In practice,
nowadays, they are hop counts (how many routers, even those that can
have >1sec queues, actually bother to decrement the TTL for every
second a packet spends waiting?).

The theoretical reason for the holddown is that a data packet may fall
into a routing warp and get stuck in a very high-delay path; a
retransmission succeeds and the conneciton completes.  Later, the stuck
packet can emerge and hit the new session.  This is possible whether or
not the client has FINned the first connection, and if the sequence
numbers are reasonable, it will be accepted as valid data.  The
requirement is intended to ensure that by the time the second
connection's sequence numbers have made it around to where they overlap
the first connection, the MSL will have caused any old segments to
expire if they're still bouncing around the network somewhere.

In practice, this happens rarely enough to be ignored, especially by
the likes of "so what's rebooting twice a day?" Microsoft.  Perhaps
they'll change their tune when some big customer gets hit by a
once-in-a-blue-moon event like this; more likely, since it won't be
easily reproducible, they'll just write it off.

					der Mouse

			       [email-masked]
		     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

---

From: Vernon Schryver <[email-masked]>
Date: Mon, 4 Jan 1999 16:33:12 -0700 (MST)

> From: [email-masked] (Alan Cox)

> > collision is small enough.  Incrementing with a clock is one way to get
> > "far apart," but there are plenty of other permutations of the natural

> Its not as simple as it first looks because BSD also allowed the shortcut
> from timewait for sequence spaces subject to certain range rules. That means
> you either have to ignore the shortcuts or for a given src,dst,ports pair
> keep incrementing sanely

Or keep asking your crypto random number generator until it gives you a
number far enough away on the down side that it looks "larger."  That's
at most only another factor of two in the hammering on your random number
generator.  One MD5 is tolerable for RFC 1948 least significant bits on
modern hardware, but the worst case number of MD5 (or other) cyclings to
guarantee far apart fully random ISS's sounds large enough that a mere
factor of two wouldn't matter.

Again, I personally wouldn't bother, and doubt anyone with a clue about
ISS's would.  It's too easy to fiddle the less significant bits as
suggested by RFC 1948 or other mechanisms (e.g. usec resolution clocks).
I also suspect that any real random ISS implementation would not worry
about getting far apart ISS, but would be be something "kick ass" and
bogus like ISS=rand(3).

Vernon Schryver    [email-masked]

P.S.  I apologize for not combining this point with my previous message.

P.P.S.  I've been told that the official doctrine of a certain large
   software outfit is that all of their programmers are "kick ass."

---

From: Sankar Ramamoorthi <[email-masked]>
Date: Tue, 5 Jan 1999 09:44:26 -0800

I agree with you what you say ie: the 2*MSL should not be broken.
My concern was whether all devices with fast reboot times or failover
capabilites observe this rule or even know about it. Some examples of
such devices are proxy servers, packet shapers, transparent proxy servers...

-- sankar --

-----Original Message-----
From: Joe Touch [mailto:[email-masked]]
Sent: Tuesday, January 05, 1999 4:34 PM
To: Sankar Ramamoorthi
Cc: 'Kacheong Poon'; Vernon Schryver; [email-masked];
[email-masked]
Subject: Re: Question on initial sequence numbers

Sankar Ramamoorthi wrote:
> 
> The problem becomes more significant with devices like network appliances,
> becoming more common. These have characterstics like High Availability,
fast
> reboot
> times etc. It is likely all TIME-WAIT is lost across reboots/failover.

The 2*MSL is supposed to be ensured; this is accomplished by either:

	- a reboot that takes 2*MSL anyway

	- prohibiting new connections for 2*MSL after a reboot

Accepting new connections immediately after a quick reboot
would be 'breaking' that rule.

Joe

---

From: Rodney Van Meter <[email-masked]>
Date: Tue, 5 Jan 1999 14:58:57 -0800

Okay, time for me to show my ignorance :-).

I'm on the side of the conservatives here (stick to the rules as spec'ed in
order to be right), but I have a few questions:

1) How does DHCP deal with the possibility of giving out the same IP address
resulting in corruption?  Does it simply refuse to give out a specific
address until TIME_WAIT after the prior lease expires?

2) How does IPv6 automatic address configuration (or any other distributed
address selection mechanism) avoid this?  What if host A picks address
1.2.3.4(.x.y.z...), then it dies mid-stream, host B comes up and, using the
same algorithm, picks 1.2.3.4, since as far as it can tell, it's not in use?
Or will, with IPv6, no two hosts ever pick the same address?

3) If we're using non-routable addresses, traffic guaranteed to be on this
LAN only, is it possible to relax the TIME_WAIT constraint?

4) Getting off the list topic a bit, but, are XTP and other transport
protocols vulnerable to the same problem?

			--Rod

P.S.  I'll go with whatever Bob Braden says ;-).

> From:	Rick Jones [SMTP:[email-masked]]
> Sent:	Tuesday, January 05, 1999 12:23 PM
> To:	[email-masked]
> All it really takes is switching an IP address from one system to
> another in the event of failure. Then instead of being a question of how
> long it takes for a system to reboot, it becomes a question of how long
> it takes for the system failure to be detected and the IP address
> (identity) be assumed by the back-up system (and of course, whether or
> not the backup system was being kept up-to-date wrt TIME_WAIT.
> 
> Given the pressures on HA in certain markets, I think there is pressure
> to have this detection and failover happen in << TIME_WAIT. I am
> reasonably confident that modulo icky things like DB recovery the
> switchovers are happening < 60 seconds today on a number of platforms.
> Probably much less.
> 
> rick jones
> -- 
> these opinions are mine, all mine; HP might not want them anyway... :)
> feel free to email, or post, but please do not do both...
> my email address is raj in the cup.hp.com domain...