Re: [tcpm] End to End Proprietary Information Field - Request for a new TCP option

Joe Touch <touch@ISI.EDU> Fri, 26 September 2008 16:34 UTC

Return-Path: <>
Received: from [] (localhost []) by (Postfix) with ESMTP id 85D7D3A6B14; Fri, 26 Sep 2008 09:34:33 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3EC0C3A6B14 for <>; Fri, 26 Sep 2008 09:34:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.567
X-Spam-Status: No, score=-2.567 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id x3nU4Bnlj74B for <>; Fri, 26 Sep 2008 09:34:31 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 292A03A6B6A for <>; Fri, 26 Sep 2008 09:34:31 -0700 (PDT)
Received: from [] ( []) by (8.13.8/8.13.8) with ESMTP id m8QGXbu4028452 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 26 Sep 2008 09:33:40 -0700 (PDT)
Message-ID: <>
Date: Fri, 26 Sep 2008 09:33:36 -0700
From: Joe Touch <touch@ISI.EDU>
User-Agent: Thunderbird (Windows/20080914)
MIME-Version: 1.0
To: Joe Touch <touch@ISI.EDU>
References: <> <> <> <>
In-Reply-To: <>
X-Enigmail-Version: 0.95.7
X-ISI-4-43-8-MailScanner: Found to be clean
Subject: Re: [tcpm] End to End Proprietary Information Field - Request for a new TCP option
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

Hash: SHA1

Joe Touch wrote:
> Ish Shalom, Ran wrote:
>> Joe,
>> Thank you for your comments. I certainly agree with your stand that we
>> should not make TCP proprietary. My proposal was not to make it
>> proprietary but to assign an option to allow us to communicate local
>> information (such as private IP addresses and local ports) end to end
>> despite the many gateways that may change this information in the header
>> fields.
> Ran,
> As I noted before, NAT/NAPTs already cannot be trusted to pass options
> unchanged, so this doesn't solve the problem.
> It's already possible to exchange that information using a tunnel, which
> does not require a change to the protocol. Use of a tunnel requires mods
> to both ends of the protocol, but then so does use of this sort of option.

(both ends of the connection; TCP, as noted, isn't modified)

> Further, a tunnel allows use of TCP authentication (TCP MD5, TCP-AO) to
> verify that the addr/port values have not changed, or even the use of
> IPsec (depending on the layer of the tunneling).
> Joe
>> Ran 
>> -----Original Message-----
>> From: Joe Touch [mailto:touch@ISI.EDU] 
>> Sent: Friday, September 26, 2008 12:10 PM
>> To: Ish Shalom, Ran
>> Cc:
>> Subject: Re: [tcpm] End to End Proprietary Information Field - Request
>> for a new TCP option
>> Ish,
>> TCP options signal changes to the TCP protocol. That protocol is not
>> proprietary, and I do not support making it - or any variants thereof -
>> proprietary.
>> Proprietary information about a TCP connection is already encoded in the
>> port number, and in-band in the application data. If the information
>> determines the nature of the application data, it is a port number
>> issue. If the information is application data, it belongs in the data
>> path.
>> I see no reason for a TCP option based on this argument, nor do I see a
>> reason for a proprietary TCP option either.
>> Additional note below...
>> Joe
>> Ish Shalom, Ran wrote:
>>> Increasingly businesses and their workforces are becoming more and 
>>> more distributed as they spread globally and move their offices to be 
>>> closer to their customers. At the same time, financial wisdom dictates
>>> strict cost control. The combination of which pushed more business to 
>>> use the Internet as a transport medium for remote offices and/or
>> employees.
>>> IP addresses shortage, privacy and security concerns have generated a 
>>> myriad of solutions in the form of NATs, PATs, firewalls, etc. As a 
>>> result, local information such as private IP addresses, ports and 
>>> potentially additional local private information often gets rewritten 
>>> and lost when a session traverses these functions. Furthermore, some 
>>> gateway services might terminate sessions in order to carry them over 
>>> a different medium or using a different service. All of which result 
>>> in the same way - lost of end to end transparency. However, 
>>> occasionally applications and/or network administrators may need a 
>>> means to communicate local private IP information across the Internet 
>>> domain so that the far end may be able to process the session
>> correctly.
>> Any device that destroys information of a TCP connection (e.g.,
>> destination port of a SYN, or rewriting IP addresss) cannot be trusted
>> to preserve TCP options either. They often rewrite or omit such options
>> anyway.
>>> I would like to propose creating a proprietary information channel 
>>> using a dedicated TCP option that can be used by such application to 
>>> communicate private local information across the internet. A flexible 
>>> end-to-end private channel will allow Service Providers and 
>>> application vendors to provide seamless communication across the 
>>> Internet domain despite the many intermediate functions that are in
>> place today.
>>> Sincerely,
>>> Ran Ish-Shalom
>>> Akamai technologies
>>> ----------------------------------------------------------------------
>>> --
>>> _______________________________________________
>>> tcpm mailing list
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla -

tcpm mailing list