TCP Daytona in userland

[Andrea Campi]

Hi all,

I have started working on a "TCP Daytona" implementation [1]. I'm
quite familiar with TCP/IP in theory, and sort of familiar with the
BSD implementation ideas, but looking into tcp_input and tcp_output is
always a mistic experience ;-) I tried to understand how I could
generate multiple (either duplicate or better partial ACKs), but I
guess tcp_output is really not meant to do such a thing. Does anyone
have an idea of how hard would it be to generate more than one ACK for
an input packet, and could you give me some suggestion?

So to get my feet wet, I've decided to start from a simple userland
implementation using BPF. Currently I'm using a test program that does
an HTTP transfer and, from a parallel thread, I monitor the
conversation and send additional ACKs for each genuine ACK I see. This
doesn't seem to have any (positive or negative) effect if I send 1 or
2 duplicate ACKs, but slows the connection down if I send 3 or more
additional ACKs. I didn't have much time to investigate this yet.

Sadly, this wouldn't work if I wanted to send partial ACKs instead.
What would be nice is to be able to stop the genuine ACK from being
sent and inject partial ACKs instead. Do we have any mechanism that
would allow me to do this? Maybe I should be using divert(4) instead?

Lastly, if anybody already worked on this: do you have any additional
suggestion? In particular regarding the testing methodology: since a
few years have passed, I'm not quite sure whether different OSs have
implemented any countermeasure. I'm mainly testing against a FreeBSD
box I control, and I don't think we have any defence against this yet.

Bye,
	Andrea

1. as per the Savage et al. paper:
http://www-cse.ucsd.edu/~savage/papers/CCR99.pdf