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

[Joe Touch <[e-mail]>]

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
>> <[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