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

[Joe Touch <[e-mail]>]

The deadline was last week for new individual submissions, but if useful 
we could just issue it when it's done anyway.

The question is whether the WG has interest... otherwise, we could wait 
until after the IETF ;-)

Joe

Sérgio Freire wrote:
> 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:[e-mail]] 
> Sent: segunda-feira, 14 de Julho de 2008 16:20
> To: Joe Touch
> Cc: [e-mail]; [e-mail]; 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 
>>> <[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_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
[e-mail]
https://www.ietf.org/mailman/listinfo/tcpm