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

On Wed, Aug 13, 2008 at 3:32 PM, Joe Touch <touch@isi.edu> wrote:
> Sites that understand this option would be listening on the desired
> ports. It's trivial to issue two SYNs and wait to see which ones are
> returned.

If the two connections are made in parallel, and port 80 returns
first, how long do you wait for the other one? In this case, that
additional latency effects all *existing* sites. Hopefully the
difference would be small, but 5ms, 10ms? Also, in the case that both
return, the application probably can't close the socket in time for
the kernel not to ACK it, in which case clients would constantly be
opening very short lived connections to port 80.

I understand that application level changes based on options is a bit
discomforting but, personally, I find racing SYNs to be much worse.

> Further, I'm not even sure how to write the application at the server -
> one that responds with different data depending on signals in a SYN.
> What does that even mean, and how does the TCP API (as specified in
> RFC793, e.g.) need to be extended to support that?

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();
}

> Firewalls and NATs also sometimes munge TCP options, especially ones
> they don't understand, FWIW.

Certainly, and middleware which drops packets packets with the extra
option would be a concern. (The draft makes provisions for retrying
without the extra option in case implementations wish to do this).
However, hosts with restricted outbound port numbers are downright
common, sadly.

Cheers

AGL

-- 
Adam Langley agl@imperialviolet.org http://www.imperialviolet.org
_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm