Re: [tcpm] TCP Long Options - Why not as payload in SYNs?

[Joe Touch <[e-mail]>]

Adam Langley wrote:
> On Mon, Jul 14, 2008 at 5:14 AM, Michael Scharf
> <[e-mail]> wrote:
>> Even though RFC 793 explicitly allows payload in SYN segments, there
>> are TCP stacks that just seem to ignore it. Couldn't this offer an
>> opportunity to transport long TCP options in the payload of SYN
>> segments, instead of expanding the header option space?

See Usenix 2008, "A TCP-layer Name Service for TCP Ports"
http://www.usenix.org/events/usenix08/tech/full_papers/freire/freire_html/index.html

The authors, Sergio and Andre (cc'd), therein combine options in the SYN 
payload with other mechanisms in a port-names solution. I have spoken 
with them about cleanly separating the idea of data as payload option 
space (i.e., removing other features that are distinct, e.g., use of 
port 0, changing ports after the SYN, etc.), and basically we came up with:

	set a conventional option that says where the
	payload option ends, within the SYN segment
	(typically the end of that segment)

	wait for an ACK indicating that option is set
	(could be set in advance), indicating the
	options will be processed correctly
		NB - the option is set in advance when
		a sender speaks the option but has no
		long options to send, or has long options
		to send and is doing so. EITHER WAY
		the option MUST occur, or the handshake
		will fail.

	if the ACK does not confirm the ability to
	process options in the data, then RST the
	connection and retry without data options

Note that this works only for the SYN segment, and it isn't clear how it 
might interoperate with SYN cookies. It also ALWAYS consumes option 
space, and MUST occur in the existing options.

...
> And that suggests that it's not just those OSes which ignore SYNs with
> payloads - it's also those which reject the packet completely.

AFAICT, ACKing the SYN and not the data is compliant, but rejecting the 
SYN entirely doesn't appear to be - it should be called a bug, IMO.

Joe

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