Subject: Re: Initial TCP seq numbers - dispute w/ Microsoft

From: "Manish Patel(x67071)" <[email-masked]>
Date: Mon, 04 Jan 1999 13:21:24 -0500

Richard Berke wrote:
> 
> Bob Braden-
> 
> I have been reading RFCs 793, 1072, 1185, and 1323 expecially regarding initial TCP sequence numbers, wrapping of the sequence numbers, and session boundaries.   I ran into a dispute with Microsoft over their TCP stack behavior, and am trying to cite the RFCs.   I hope you can help, or point me in the right direction.
> 
> As I glean from the RFCs, the initial TCP sequence number of a session must be selected in a way that eliminates confusion whether subsequent packets belong to a previous session.   The old way was to use increasing sequence numbers, driven by clock cycles.   As higher transmission rates became possible, the lifetime of the TCP sequence number space decreased until it became under 3 minutes for 100 Mbps.   The maximum segment lifetime is the key factor here.   A proposed extension to the algorit
> 
> In a packet trace of a recent session with a Microsoft server and a client, I saw a TCP session finish normally with a FIN/ACK.  About a minute later, the client requested a new session, during which it pulled a data file from the server.  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.  The rest of the sequ
> 
> Microsoft asserts this behavior is okay.  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.   Microsoft asserts that there is no regard in the client for the prior session TCP once the FINish process completes successfully.  I don't find support for this position in the RFC's; I find the reverse.
> 
> Is Microsoft lucky that it works?  Are they non-compliant, but in a benign way?
> Am I misunderstanding the requirement for increasing TCP sequence numbers for new sessions?
> 
	I do not think that there is any requirement for initial sequence
number.
It could be anywhere between 0 & 4,294,967,295(2^32).

Apparently, if the connection uses the same ports and IP addresses, it
should not
matter if the sequence number is recycled because the previous control
block is
already gone and it does not remember to create any conflict.

> Thanks for your patience and sharing your understanding,
> Richard Berke
> RPM Consulting
> [email-masked]
> 
> ----- End Included Message -----

-- 
__            __
__Manish Patel__
 ____________________________________________________________________
| mailto:[email-masked] (978) 916 7071    _____            ® |
|____/|\__/|\_______/|\_______/|\___/|____/|____/|     |___/|___/|___|
    / | \/ | \     / |_\     / | \ / |   / |   /_|___ _|  / |__/ |
   /  /\/  /\/|   / |  /|   /  /\ /  /  /  /   |    /|   / |  /  /
  /  / /  / / |  /  |_/ |  /  /  /  /  /  /   _|___/ |  /  |_/  /
  | /  | /  | /  | /  | /  | /   | /   | /   |     | /  | /  | /
  |/   |/   |/   |/   |/   |/    |/    |/    |_____|/   |/   |/
 ____________________________________________________________________
| Bay Networks Inc., 600 Technology Park, Billerica, MA 01821.       |
|____________________________________________________________________|

---

From: [email-masked] (Alan Cox)
Date: Mon, 4 Jan 1999 19:54:51 +0000 (GMT)

> already gone and it does not remember to create any conflict.

Common misconception.

The 2 minute drain time means all segments from the start of the wait time
have left the network, it does not mean all control blocks are dead.

Alan

---

From: Craig Partridge <[email-masked]>
Date: Mon, 04 Jan 1999 11:14:16 -0800

>It could be anywhere between 0 & 4,294,967,295(2^32).

Yes there is -- read the Tomlinson paper and the Sunshine and Dalal
paper on sequence numbers.

The basic issue is if a segment with a sequence number from a previous
incarnation of the connection is still alive in the network when the
sequence space of the new connection overlaps that sequence number, then
there's a chance that the old segment will get delivered to the
destination and mistaken as new data.

Craig

---

From: "Manish Patel(x67071)" <[email-masked]>
Date: Mon, 04 Jan 1999 15:24:44 -0500

> have left the network, it does not mean all control blocks are dead.

	I agree that if the segments from the previous session arrives
after new connection(with same socket pair) starts can cause the
problem.
But, there should not be any duplicate control block. If the new
connection is established using the same port and IP address,
the old block must be dead, otherwise the new connection must be using
different port or should be rejected if compels to use the same port.

Please see my comments below and advise.

> Am I misunderstanding the requirement for increasing TCP sequence numbers for new sessions?

	Seems like it works because receiving FIN and closing gracefully
reflects that
there is no delayed segment from previous connection.

	How many possibilities that a segment from the old connection would
arrive?

	1. The packet is lost in the network or delayed by a great time.
		(Receiving end will not process FIN an OSS)
	2. The ack for that packet got lost.
		(Sending end will not forward window and/or send FIN)

	So, in any case the the old connection would not have closed gracefully
and the
new connection would have different socket.

	Lower sequence number could only be a problem in case of RST, where
there is a
possibility of previous session segment arrival.

	If above is not true, let me know.

Thanks,

---

From: Craig Partridge <[email-masked]>
Date: Mon, 04 Jan 1999 13:17:20 -0800

>there is no delayed segment from previous connection.

No -- it simply says that a FIN arrived (packets may arrive in any
order).

Craig

---

From: "Vijay G. Bharadwaj" <[email-masked]>
Date: Mon, 4 Jan 1999 16:53:43 -0500 (EST)

> there is no delayed segment from previous connection.

No it doesn't.

> 		(Receiving end will not process FIN an OSS)

Let's look at this scenario in some detail.

- Packet is delayed greatly in the network.
- Sender retransmits packet.
- Retransmission (or maybe original) arrives at receiver.
- Receiver ACKs.
- In due course FIN happens.
- New connection starts up.
- Now the delayed segment arrives and is accepted as valid.

Also consider a more complicated scenario:

 - ACK packet gets "greatly delayed"
 - but a later ACK covers this sequence #, so things move on
 - FIN happens, connection closes
 - new connection starts, reusing sequence space
 - happens to lose a segment with seq # just below our stale ACK
 - stale ACK arrives
 - sender moves on, receiver is still waiting for segment
 - this connection is doomed

In short, doing this is wrong and dangerous. If it works, it's because you
get lucky and the typical user doesn't know when he/she gets unlucky.
("Darn, this webpage is fouled up, let me just hit reload.")

-Vijay

---

From: Rick Jones <[email-masked]>
Date: Mon, 04 Jan 1999 14:38:34 -0800

There is also a stack out there that does not always wait TIME_WAIT
state length. It has a fixed number of TCB's (configurable through a
registry parm) and if all the TCB's are busy when a SYN arrives, it will
take one still in TIME_WAIT. The higher the connection rate, the shorter
TIME_WAIT gets.

I think the default maximum is something like 2000 TCB's.

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...