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

[Guest]

Archived from groups: microsoft.public.windowsxp.security_admin (More info?)

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

 

[Guest]

Archived from groups: microsoft.public.windowsxp.security_admin (More info?)

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" <boyhill@discussions.microsoft.com> wrote in message
news:23C678CC-806D-4244-848E-ABEE33290A96@microsoft.com...
> 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
>
>

 

[Guest]

Archived from groups: microsoft.public.windowsxp.security_admin (More info?)

"Robert Moir" <robspamtrap+msnews@gmail.com> wrote in message
news:%23jF5zt37EHA.3840@tk2msftngp13.phx.gbl...
> 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

 

[Guest]

Archived from groups: microsoft.public.windowsxp.security_admin (More info?)

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
steriley@microsoft.com



> "Robert Moir" <robspamtrap+msnews@gmail.com> wrote in message
> news:%23jF5zt37EHA.3840@tk2msftngp13.phx.gbl...
>
>> 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

 

[Guest]

Archived from groups: microsoft.public.windowsxp.security_admin (More info?)

Exactly so.

--

... Hank

http://horedson.home.att.net
http://w0rli.home.att.net
"Steve Riley [MSFT]" <steriley@microsoft.com> wrote in message
news:28577632402741024049440@news.microsoft.com...
> 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
> steriley@microsoft.com
>
>
>
>> "Robert Moir" <robspamtrap+msnews@gmail.com> wrote in message
>> news:%23jF5zt37EHA.3840@tk2msftngp13.phx.gbl...
>>
>>> 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
>
>

 

[Guest]

Archived from groups: microsoft.public.windowsxp.security_admin (More info?)

Thanks !

"Hank Oredson" wrote:

> Exactly so.
>
> --
>
> ... Hank
>
> http://horedson.home.att.net
> http://w0rli.home.att.net
> "Steve Riley [MSFT]" <steriley@microsoft.com> wrote in message
> news:28577632402741024049440@news.microsoft.com...
> > 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
> > steriley@microsoft.com
> >
> >
> >
> >> "Robert Moir" <robspamtrap+msnews@gmail.com> wrote in message
> >> news:%23jF5zt37EHA.3840@tk2msftngp13.phx.gbl...
> >>
> >>> 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
> >
> >
>
>
>