TCP Timestamps and ASP PAWS test

[justintime]

Hi all,

I have a wierd issue that I've found the workaround to, but I'm not sure I like it. I was having problems doing large file transfers over a l2l VPN between two PIX 515e's.

After way too much troubleshooting, I noticed that the "TCP packet failed PAWS test" was incrementing fast when doing a file transfer. On my linux box, I did an 'echo 0 > /proc/sys/net/ipv4/tcp_timestamps' and the problem went away - I could transfer files no problem. Just to ensure this was the issue, I turned back on tcp_timestamps in the linux kernel, then I created a tcp-map that cleared the timestamp field. This works as well.

Does anyone know why my PIX is dropping packets with the timestamp field set? I'm running PIX 7.0(6.4). I've verified this issue on PIX 7.0(1), 7.0(4), and 7.0(6.4).

[jgervia_2]

Hi:

PAWS is an algorithm that protects again wrapped sequence numbers. What *can* happen is that in the course of a connection, a segment could be lost and then retransmitted - but when it retransmitsthat segment, the sequence number window is being re-used because the sequence number has wrapped due to the large amount of data being sent. You could then get data corruption

You can read about it a little here:

http://www.goldfish.org/books/TCPIP%20Illustrated%20Vol%201/tcp_fut.htm#24_6

And the RFC (which explains why wrapping is bad)

http://www.ietf.org/rfc/rfc1323.txt

Which explains it a little bit better

Basically the pix was doing it's job, dropping the old segments coming in with sequence numbers that were in the current window but whose timestamp was less than what it was supposed to be.

From the RFC (so you don't have to read the entire thingg) :

"An especially serious kind of error may result from an accidental

reuse of TCP sequence numbers in data segments. Suppose that an

"old duplicate segment", e.g., a duplicate data segment that was

delayed in Internet queues, is delivered to the receiver at the

wrong moment, so that its sequence numbers falls somewhere within

the current window. There would be no checksum failure to warn of

the error, and the result could be an undetected corruption of the

data. Reception of an old duplicate ACK segment at the

transmitter could be only slightly less serious: it is likely to lock up the connection so that no further progress can be made,forcing an RST on the connection."

An interesting test might be to take linux out of the equation - try transfering from windows machines without the tcp-map on and see if you still see the issue. My guess is that linux install is interpreting how to implement the RFC differently than how the pix is enforcing it - hence the issue.

--Jason

Please rate this message if it helped resolve some or all of your issue.