About the initial sequence number (ISN) in windows XP SP2

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

For my question, the key is that the random ISNs disobey the RFC protoals
about TCP/IP for ISNs increment set. They may affect the TCP communication
between the host and the network, result the confusion in communication.

Refrence:
1,Microsoft Windows Server 2003 TCP/IP Implementation Details
http://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/networking/tcpip03.mspx
"Windows Server 2003 TCP/IP has also been strengthened against a variety of
attacks that were published over the past couple of years and has been
subject to an internal security review intended to reduce susceptibility to
future attacks. For instance, the initial sequence number (ISN) algorithm has
been modified so that ISNs increase in random increments, using an RC4-based
random number generator initialized with a 2048-bit random key upon system
startup."
2,RFC

Thanks
 
boyhill said:
For my question, the key is that the random ISNs disobey the RFC
protoals about TCP/IP for ISNs increment set. They may affect the
TCP communication between the host and the network, result the
confusion in communication.
Click to expand...

What was the actual question again?
 
I'm very curious where you find this in RFC-793.
My own implementation uses a random seed for the first ISN,
and a random increment for further ISNs. I see no place in
RFC-793 that disallows this behavior, and in fact the RFC
seems to suggest it as an optimum implementation.

Can you clarify?

--

... Hank

http://horedson.home.att.net
http://w0rli.home.att.net
 
Hank said:
I'm very curious where you find this in RFC-793.
My own implementation uses a random seed for the first ISN,
and a random increment for further ISNs. I see no place in
RFC-793 that disallows this behavior, and in fact the RFC
seems to suggest it as an optimum implementation.
Click to expand...

IIRC the only real requirement is that a ISN must be unique for the time it
is live? Anything else was just suggestions on how this might be achieved.
 
Robert Moir said:
IIRC the only real requirement is that a ISN must be unique for the time
it is live? Anything else was just suggestions on how this might be
achieved.
Click to expand...


There is a suggestion, somewhere near the end of the RFC, that
ISNs should be monotonic. Don't have the doc right in front of
me right now. As I recall it involved multiple connects to the same
port at the same host, to attempt to avoid SN clash with a lost
but still half-open connection. I recall the same requirement that
you do: must be unique for it's TTL ... with a suggested 4 or
5 minute max. I've seen many implementations that use the low
bits of some fast clock to obtain a "sort of random" ISN. Those
would not be monotonic ;-)

--

... Hank

http://horedson.home.att.net
http://w0rli.home.att.net
 
Monotonic sequence numbers make it realtively easy to predict sequence numbers
and forge connections using spoofed IP addresses. This wasn't envisioned
by the designers of the protocol way back when.

These are old resources now, but still very useful for learning about the
dangers of predictable sequence numbers. Note that we've finally got it right
in XP and 2003 :)

http://alon.wox.org/tcpseq.html
http://lcamtuf.coredump.cx/newtcp/

Steve Riley
(e-mail address removed)
 
Back
Top