Re: [tcpm] TCP Long Options

Hi Joe et all,
Yes, I think it would be a great idea to write an I-D concerning the use of
TCP options in the payload.. what is the deadline?
Sergio

-----Original Message-----
From: Joe Touch [mailto:touch@ISI.EDU] 
Sent: segunda-feira, 14 de Julho de 2008 16:20
To: Joe Touch
Cc: andre.zuquete@ua.pt; tcpm@ietf.org; Sérgio Freire
Subject: Re: [tcpm] TCP Long Options - Why not as payload in SYNs?

PS - if there's interest in this, we could pull together an I-D in time for
Dublin, but it won't (didn't) make the individual deadline...

Joe

Joe Touch wrote:
> Adam Langley wrote:
>> On Mon, Jul 14, 2008 at 5:14 AM, Michael Scharf 
>> <michael.scharf@ikr.uni-stuttgart.de> 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_h
> tml/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
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm