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

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/pro...g/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 wrote:
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.

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
"boyhill" wrote in message
...
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/pro...g/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

Hank Oredson wrote:
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.

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" wrote in message
...
Hank Oredson wrote:
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.

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.


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




"Robert Moir" wrote in message
...

Hank Oredson wrote:

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

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 ;-)
http://horedson.home.att.net
http://w0rli.home.att.net

Exactly so.

--

... Hank

http://horedson.home.att.net
http://w0rli.home.att.net
"Steve Riley [MSFT]" wrote in message
...
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




"Robert Moir" wrote in message
...

Hank Oredson wrote:

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

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 ;-)
http://horedson.home.att.net
http://w0rli.home.att.net

Thanks !

"Hank Oredson" wrote:

Exactly so.

--

... Hank

http://horedson.home.att.net
http://w0rli.home.att.net
"Steve Riley [MSFT]" wrote in message
...
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




"Robert Moir" wrote in message
...

Hank Oredson wrote:

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

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 ;-)
http://horedson.home.att.net
http://w0rli.home.att.net