netdev - Re: 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-prev] [day] [month] [year] [list]

Message-ID: <7370b4385c2112fe13d9db663ad7c7c9.squirrel@squirrel.science.ru.nl>
Date:	Fri, 9 May 2014 02:01:44 +0200
From:	P.Fiterau-Brostean@...ence.ru.nl
To:	"Neal Cardwell" <ncardwell@...gle.com>
Cc:	"Netdev" <netdev@...r.kernel.org>,
	"Frits Vaandrager" <f.vaandrager@...ru.nl>
Subject: Re: TCP CLOSE_WAIT unacceptable ACK behavior and RFC 793 compliance

First of all, thanks for your very fast reply. My posts on stackoverflow
and other sites were starting to gather cobwebs.

> Have you checked what other OSes do?
Yes, so far we ran this scenario on Ubuntu 13.10, Ubuntu 12.04 and a very
recent version on MacOs. For all these 3 systems we got the same behavior
in terms of the server CLOSE_WAIT state. We also tested the Windows 8
implementation, where we found that we'd always get a timeout. We suspect
that for versions of Windows starting from Vista we would get a similar
timeout behavior.

>Have you tried this scenario with SEG.ACK > SND.NXT in other states,
>e.g. ESTABLISHED?
>From what I can remember, it was only in CLOSE_WAIT from 4 states tested
that we encountered this behavior but will need to check again. I attached
here the partial state models we obtained for Ubuntu 13.10 and Windows 8.
The Ubuntu 13.10 model lacks 3 inputs: ACK and FIN+ACK segment with the
valid seq but invalid ack (to avoid non-determinism) , and a RST+ACK with
valid seq and invalid ack because it proved too difficult to incorporate.
In the diagrams we use some condensed notations: V = an acceptable value,
INV = an unacceptable value, LAS = last ack sent, CLSN = sequence number
on the client side...

Perhaps it might interest you how we came up with models. We used tools
that can actively and automatically learn/infer a state model for symbolic
i/o blackbox systems, we then placed an adapter over the learner software
in order to map those symbolic i/o to packets that would be sent
to/received from the server. These tools always fail when the system
behaves non-deterministically. In the scenario I showed, the system
behaved non-deterministically with regards to the inputs given (flags, seq
and ack). Once I eliminated those inputs and the time constraints were
suppressed, a deterministic 4 state model was learned.

packetdrill could perhaps be used as an adapter for learning niches of TCP
for Linux systems in the future. So far, we had to make do with Scapy,
which can be slow and unreliable. Our plan, aside from advancing the
current algorithms, is to incorporate more parameters or to learn
different niches of TCP, as well as to learn other protocols and see if
the implementation meets the specification.

I will rerun the experiments tomorrow to see if ACK/timeout occurs in
other states other than CLOSE_WAIT for Ubuntu 13.10.

Cheers, Paul
Download attachment "ubuntu1310.pdf" of type "application/pdf" (219783 bytes)

Download attachment "win8.pdf" of type "application/pdf" (219062 bytes)