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

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

Adam Langley wrote:
...
| 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();
| }

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):

	syn ->
		<- syn/ack
	ack ->
				--->accept returns

The above code would do what you intend only if the accept returns on
the initial SYN. At the very least, even if the accept returns when the
initial SYN is received, by the time the accept returns the syn/ack
ought to have been sent. unix doesn't wait for the accept call to
actually return the syn/ack - various discussions confirm this - or are
you also modifying that code?

Joe

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

iEYEARECAAYFAkijg/AACgkQE5f5cImnZrtQXQCfegdXCInIO9WTnwfjPPGxEbxL
S9EAmwR29E5/8jSnStzOKnSykzAHAfar
=CQVT
-----END PGP SIGNATURE-----
_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm