TCP TSecr question

TCP TSecr question

[Cosmin Ratiu]

Hello,

There is an issue with this field in SYN packets when tw reuse/recycle 
is on.
Quoting from RFC 1323, section 3.2:
    The Timestamp Echo Reply field (TSecr) is only valid if the ACK
    bit is set in the TCP header; if it is valid, it echos a times-
    tamp value that was sent by the remote TCP in the TSval field
    of a Timestamps option.  When TSecr is not valid, its value
    must be zero.  The TSecr value will generally be from the most
    recent Timestamp option that was received; however, there are
    exceptions that are explained below.

On Linux, when the sysctl_tcp_tw_reuse or recycle is on, the most recent
timestamp from a previous connection is sent instead of 0.  From what I've
seen in the source, this has to do with PAWS against delayed/duplicate SYN
packets.

My questions:
1) Is this violation of RFC 1323 useful in PAWS or did I misunderstand
   the whole situation?
2) Is there any other RFC that amends 1323 to specify this behavior or is it
   a Linux-specific enhancement?

Thank you,
Cosmin.