If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. |
|
|
Thread Tools | Display Modes |
#1
|
|||
|
|||
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 |
Ads |
#2
|
|||
|
|||
About the initial sequence number (ISN) in windows XP SP2
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? |
#3
|
|||
|
|||
About the initial sequence number (ISN) in windows XP SP2
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 |
#4
|
|||
|
|||
About the initial sequence number (ISN) in windows XP SP2
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. |
#5
|
|||
|
|||
About the initial sequence number (ISN) in windows XP SP2
"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 |
#7
|
|||
|
|||
About the initial sequence number (ISN) in windows XP SP2
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 |
#8
|
|||
|
|||
About the initial sequence number (ISN) in windows XP SP2
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 |
Thread Tools | |
Display Modes | |
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
creating boot disc for windows xp home edition | Big Bearded Buddy | Performance and Maintainance of XP | 28 | September 7th 05 06:56 PM |
which security updates should be kept, which can be deleted? | Stan Hill | General XP issues or comments | 5 | January 8th 05 12:49 PM |
xp sp2 | Jagdish Chandra | Windows Service Pack 2 | 4 | December 13th 04 09:33 AM |
XP SP2 very slow | kosice | Windows Service Pack 2 | 2 | December 13th 04 09:21 AM |
xp home sp2 | hounddog | Windows Service Pack 2 | 3 | September 25th 04 06:50 AM |