netdev - TCP CLOSE_WAIT unacceptable ACK behavior and RFC 793 compliance

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>] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 8 May 2014 19:13:52 +0200
From:	P.Fiterau-Brostean@...ence.ru.nl
To:	netdev@...r.kernel.org
Cc:	"Frits Vaandrager" <f.vaandrager@...ru.nl>
Subject: TCP CLOSE_WAIT unacceptable ACK behavior and RFC 793 compliance

In my group at the Radboud University Nijmegen, the Netherlands, we do
research on automata learning. We develop algorithms that allow us to
learn state diagrams of black box systems by providing inputs and
observing outputs. We applied these algorithms on TCP implementations. We
have a publication on this here:
http://www.mbsd.cs.ru.nl/publications/papers/fvaan/TCP/

As part of our work, we used Scapy/pcapy/wireshark to analyze the TCP
behavior on Ubuntu 13.10 and check it against the reference standards. We
came across a scenario which seems to occur regardless of TCP_QUICKACK or
TCP_NODELAY parameters.

      CLIENT                                     SERVER

  1.  -                                          LISTEN

  2.  - --> <SEQ=100><CTL=SYN>               --> SYN-RECEIVED

  3.  - <-- <SEQ=300><ACK=101><CTL=SYN,ACK>  <-- SYN-RECEIVED

  4.  - --> <SEQ=101><ACK=301><CTL=ACK>      --> ESTABLISHED

  5.  - --> <SEQ=101><ACK=301><CTL=FIN,ACK>  --> CLOSE-WAIT

  6.  - <-- <SEQ=301><ACK=102><CTL=ACK>      <-- CLOSE-WAIT

  7.  - --> <SEQ=102><ACK=500><CTL=ACK>      --> CLOSE-WAIT

  8.  - <-- <SEQ=301><ACK=102><CTL=ACK>      <-- CLOSE-WAIT

OR

  8.  -    timeout/nothing sent              <-- CLOSE-WAIT

In short, when the SERVER is in CLOSE_WAIT state and the CLIENT sends an
ACK  (or a FIN+ACK) with a valid seq number but an unacceptable ack
number, the SERVER either responds with an ACK (re-transmission of last
ACK sent by the server) or it doesn't respond at all. I attached a capture
file and an image of the capture. A note, should the seq number sent by
the CLIENT be invalid/not "in line", then the SERVER always re-transmits
the last ACK it sent.

What is intriguing about this scenario is that the timeout occurrence does
not comply with the rfc 793 standard, where on page 37, it is stated:

3.  If the connection is in a synchronized state (ESTABLISHED,
    FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK, TIME-WAIT), any
unacceptable segment (out of window sequence number or
    unacceptable acknowledgment number) must elicit only an empty
    acknowledgment segment containing the current send-sequence number and
an acknowledgment indicating the next sequence number expected to be
received, and the connection remains in the same state.

My questions are, is this behavior normal/expected and is there a
parameter/condition/setting that would affect it? Secondly, do you agree
that this behavior is not compliant with the rfc 793 standard? If not, is
there an official optimization over rfc 793 that allows for it.  We asked
tcpm@...f.org and they replied that indeed, it MAY be a violation.
Obviously, in case it is a violation, it is harmless.

Finally, a completely unrelated question. Is there a way of setting the
time the SERVER waits in SYN_RECEIVED before the first SYN+ACK
re-transmission kicks in? I couldn't find such a parameter.

Thanks!
Paul FITERAU.

Download attachment "ubuntu.pcap" of type "application/octet-stream" (2536 bytes)

Download attachment "ubuntu.PNG" of type "image/png" (99719 bytes)