Re: [tcpm] SYN/ACK Payloads, draft 01

["Adam Langley" <[e-mail]>]

On Wed, Aug 13, 2008 at 10:20 PM, Joe Touch <[e-mail]> wrote:
> I'm confused now; your code - and your note. Let's go back to the key issue:
>
>        - is the data received by the client dependent on the option?

I do apologise, the confusion is my fault:

There are two extensions interacting here. Firstly, there's an
extension to include data in the SYNACK. Then there's the application
layer signaling with the option. I was outlining the code for the
latter. The former is an extension that could be deployed today, it's
managed with a setsockopt on the server socket:

struct tcpsa tcpsa;
memcpy(tcpsa.tcpsa_payload, mysynackdata, length);
setsockopt(socket, SOL_TCP, TCP_SADATA, &tcpsa, sizeof(tcpsa));

listen(socket);

for (;;) { accept(); ... }

Obviously, this is just an implementation detail. It's nice for
sockets based APIs to do it like this. Since such stacks are dominant,
the idea of a constant payload appears in the draft. I make a couple
of exceptions to this. The ability to include a 64-bit nonce is very
useful and easy for the stack to manage. That's done with:

struct tcpsa tcpsa;
memcpy(tcpsa.tcpsa_payload, mysynackdata, length);
tcpsa.tcpsa_flags = TCP_SADATA_INC_NONCE;
tcpsa.tcpsa_nonce_offset = 0;
setsockopt(socket, SOL_TCP, TCP_SADATA, &tcpsa, sizeof(tcpsa));

Also, the ability to only send this data when the SYN includes the
SAPP option. At the moment, this is the default, although there is
space in the flags set aside for when I get round to it.

Example client side code and stack patches are referenced below.

Again, this is just to appease the sockets API. Stacks like [1] allow
the application to process the SYN directly and construct any SYNACK
payload they like on a per-packet basis.

[1] http://tservice.net.ru/~s0mbre/old/?section=projects&item=unetstack

> As a final question, if this is experimental, why not just use the
> experimental TCP option KIND?
>
> (and how much of this has been implemented, traced, and checked for
> things like simultaneous open - I don't recall if you noted that before)

A linux patch[2] has been reviewed by the networking maintainer,
although I haven't asked for it to be applied yet because it's not
quite final. (It's using an experimental KIND number for one). Example
client side code example can be found at [3]. This includes preload
code to support Apache, Firefox etc (screenshot: [4]). It's been
tested by several people over the real Internet. (Note that [3] is
just a dump of my current code, it has many rough edges at the moment.
And ignore the TCP-AO stuff therein, it's #ifdef'ed out).

Also, I believe that I currently have the Diffie-Hellman speed record
with [5] since my implementation is 10% faster than the previously
claimed best[6]. (The version in [3] is much slower, I've yet to
update it.)

I'm am currently using an experimental KIND. However, if I were to,
say, deploy this on all the Google frontend servers (hypothetically,
of course), I suspect that would be in excess of what the experimental
kinds were for.

As for simultaneous open. The linux patch handles it by not doing
anything different. The option may be carried in the SYN, but the ACKs
are as normal. Since all BSD like stacks would, very likely, work the
same, it might be best to specify that behaviour in the draft.


Cheers


AGL

[2] http://marc.info/?l=linux-netdev&m=121857466907992&w=2
[3] http://www.imperialviolet.org/binary/libobstcp-0.2a.tar.bz2
[4] http://bp3.blogger.com/_kRcqvZJgJFs/SH0B_oPSlzI/AAAAAAAAAUM/eg-IxgbyhIs/s1600-h/firefox-obstcp.png
[5] http://code.google.com/p/curve25519-donna
[6] http://cr.yp.to/ecdh/reports.html


-- 
Adam Langley [e-mail] http://www.imperialviolet.org
_______________________________________________
tcpm mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/tcpm