Subject: Initial TCP seq numbers - dispute w/ Microsoft

From: "Richard Berke" <[email-masked]>
Date: Wed, 23 Dec 1998 15:52:48 -0500

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 algorithm incorporates a timestamp field along with the TCP sequence number field. 

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 sequence numbers in the session did increase after the initial number.  The session proceeded and completed without apparent errors to the data file.

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?

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

----- End Included Message -----

---

From: [email-masked]
Date: Mon, 4 Jan 1999 10:30:09 -0800

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

!!?? See section 4.2.2.9 of RFC-1122, and Appendix B of RFC 1323.

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

Old duplicate segments can cause erroneous data transfers.

Bob Braden