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

Joe Touch <touch@ISI.EDU> Mon, 14 July 2008 22:54 UTC

Return-Path: <tcpm-bounces@ietf.org>
X-Original-To: tcpm-archive@megatron.ietf.org
Delivered-To: ietfarch-tcpm-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A26243A6A31; Mon, 14 Jul 2008 15:54:14 -0700 (PDT)
X-Original-To: tcpm@core3.amsl.com
Delivered-To: tcpm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 689BD3A6B0B for <tcpm@core3.amsl.com>; Mon, 14 Jul 2008 15:54:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.449
X-Spam-Level:
X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sdsArnQKSYPj for <tcpm@core3.amsl.com>; Mon, 14 Jul 2008 15:54:13 -0700 (PDT)
Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 9F6E63A68E3 for <tcpm@ietf.org>; Mon, 14 Jul 2008 15:54:13 -0700 (PDT)
Received: from [127.0.0.1] (228.sub-75-214-74.myvzw.com [75.214.74.228]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m6EMlj6A000606 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 14 Jul 2008 15:47:48 -0700 (PDT)
Message-ID: <487BD791.4020203@isi.edu>
Date: Mon, 14 Jul 2008 15:47:45 -0700
From: Joe Touch <touch@ISI.EDU>
User-Agent: Thunderbird 2.0.0.14 (Windows/20080421)
MIME-Version: 1.0
To: Sérgio Freire <sergio-s-freire@ptinovacao.pt>
References: <20080714121424.GA31382@ikr.uni-stuttgart.de> <396556a20807140648lb5f923x478665473667d807@mail.gmail.com> <487B6A79.2040608@isi.edu> <487B6EB1.6040308@isi.edu> <711EBBFA1DE9C64FB3CF8053A261C6FC05199B25@INOAVREX05.ptin.corpPT.com>
In-Reply-To: <711EBBFA1DE9C64FB3CF8053A261C6FC05199B25@INOAVREX05.ptin.corpPT.com>
X-Enigmail-Version: 0.95.6
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Cc: andre.zuquete@ua.pt, tcpm@ietf.org
Subject: Re: [tcpm] TCP Long Options - Why not as payload in SYNs?
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0366703310=="
Sender: tcpm-bounces@ietf.org
Errors-To: tcpm-bounces@ietf.org

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