netdev - TCP TSecr question

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Date:	Fri, 10 Apr 2009 19:24:56 +0300
From:	Cosmin Ratiu <cratiu@...acom.com>
To:	netdev@...r.kernel.org
Subject: TCP TSecr question

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.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html