of tcp sequence numbers and PAWS
in a not so sunny Reading, I saw it best fit to sit down and write about one of the more interesting problems that have been solved in tcp, the wrapping of sequence numbers and how this is implemented in Windows.
In a very fast network connection and during the transfer of a long enough data stream, tcp sequence numbers can wrap and cause the receiving system under certain conditions to reset the connection(some references give figures of this happening in 34 seconds on a 1 Gbps link).
Sequence numbers are a way to mark the offset in data to the receiving end, letting them know which part of the data they have received. the current tcp implementation uses 32 bit unsigned integers for sequence numbers. during such a transfer as described above, the receiving end could receive data that seems to be already received and may decide to discard this.
RFC 1323 has come up with a solution and calls this Protection against Wrapped Sequence Numbers or PAWS in short. PAWS is implemented in Windows and allows for the use of the TCP Timestamping option in addition to the sequence number to make sure that even when a seemingly wrapped sequence number is received, the timestamp of the packet that has been received is also checked to make sure that it is actually a new packet and not a part that we are re-receiving.
so as we are checking the timestamp now as well as the sequence number, there are other things to consider. what about clock synchronization on the sender and the receiver? PAWS does not rely on any sort of time sync between the sender and the receiver. what basically happens is, when a packet is received that contains a timestamp, we take that and save it as TS.Recent as referenced in RFC 1323, the current timestamp for that sender. as we receive more packets, the timestamp is increased accordingly and is based on what we receive as a timestamp of that packet from the sender.
Timestamps are ever increasing and that also is an important characteristic of the checks that PAWS does. if we receive a packet that has an older timestamp we decide that this packet cannot be received and in the end passed to the user and as it is an old packet, it will be discarded. an attacker could actually use this to reset a connection on the server: if you send the server a packet with a good sequence number and a much later timestamp in the future, you will invalidate all packets that should actually be received from the original sender. Microsoft released https://www.microsoft.com/technet/security/advisory/899480.mspx to address this and actually all systems running XP SP2 and 2003 Srv SP1 are protected against this. the issue was first addressed in the MS05-019, however that advisory does not contain references to this issue.
To read more on this see RFC 1323 and the KB article from Microsoft where we give details as to how this is implemented in Windows.
RFC 1323 - TCP Extensions for High Performance, https://www.faqs.org/rfcs/rfc1323.html
Description of Windows 2000 and Windows Server 2003 TCP Features, https://support.microsoft.com/kb/224829
Make sure to put in a comment with any questions you may have. Happy networking!