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

[Joe Touch <[e-mail]>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

FWIW, IMO it is not wise to deploy code into a widely-used codebase that
uses the experimental KIND values. Experiments should be controlled.

See RFC4727, notably:

~   ... The network scope of support
~   for experimental values should carefully be evaluated before
~   deploying any experiment across extended network domains, such as the
~   public Internet.

Joe

Adam Langley wrote:
| 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
|
|
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkikY3IACgkQE5f5cImnZru7hQCg1o2zdXMursx8kNpgMLh0xtuj
R+EAoOTQhKfHeKusrxwDuxY1qCO68oee
=r4iA
-----END PGP SIGNATURE-----
_______________________________________________
tcpm mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/tcpm