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

[Joe Touch <[e-mail]>]

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



Adam Langley wrote:
| On Wed, Aug 13, 2008 at 6:01 PM, Joe Touch <[e-mail]> wrote:
|> I'm wondering why an implementation in user space would expect to find
|> out anything about a TCP connection that hadn't finished handshaking,
|> i.e., the accept call above (AFAIR) ought to return only after the end
|> of the three-way handshake (I'll have to dig out my Stephens book to
|> confirm, though):
|
| Absolutely accept() only returns after the 3-way has completed.
|
| Note that the draft only requires that the stack be able to configure
| a static payload.

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?

Here's your code:

- ----

The existing patches make the change fairly easy. From the comments:

"A listening socket is configured with a setsockopt with non-zero
payload len
and, optionally, TCP_SADATA_INC_NONCE and tcpsa_nonce_offset if the kernel
should include random data.

On a resulting, accepted socket, a getsockopt reveals:
~  TCP_SADATA_REQ - a SYN/ACK payload was requested
~  TCP_SADATA_NONCE - the 8 random bytes generated are in tcpsa_payload"

So the code looks like:

int newsocket = accept(...)
getsockopt(newsocket, SOL_TCP, &tcpsa, ...)
if (TCP_SADATA_REQ & tcpsa.tcpsa_flags) {
~   // The first data from the socket is the client's draft-agl handshake
~   decode_tagged_data(newsocket);
~   ...
} else {
~   // No special case,
~   continue_as_normal();
}

- ---

The SERVER is the one in listen; this means that the server thinks there
is different data on the socket depending on whether the client has the
option set? That would mean that the SYN had the data, not the SYN-ACK.

Or am I misreading the code?

Further, how does the server put different code in the connection
depending on a socket option it can't see until after the listen? It
can't write to the socket until the listen completes, at which point the
SYN-ACK is gone.

It seems like you're going to end up needing a new call to write to the
socket before the listen completes, i.e., a setsockopt that effectively
'writes'. Again, this is --far-- afield from TCP semantics.

| Thus, the kernel is able to send the SYN/ACK (with payload) without
| any application involvement.

This is truly confusing to me. The payload **is** application
communication. You're creating an option to generate that data inside
the TCP protocol?

| Thus, all the application needs to find
| out, after an accept() is weather the kernel echoed the SYNACK Payload
| Permitted option. If it did, then the server knows that it's SYNACK
| payload was sent and the data from the client will be a tagged
| structure that I don't actually define in the draft (since it's not
| anything to do with TCP). Otherwise, the option wasn't echoed in which
| case the protocol continues as normal.

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)

Joe
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkijwLMACgkQE5f5cImnZruCBgCgrAvDgU64o97PAsLJU06yqJJ0
aMgAoM98Y1W3EMCRFPgrt2AJ5n2gY/3A
=VihK
-----END PGP SIGNATURE-----
_______________________________________________
tcpm mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/tcpm