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

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

Return-Path: <>
Received: from [] (localhost []) by (Postfix) with ESMTP id DE4F43A6B9F; Fri, 26 Sep 2008 09:31:53 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id A8A243A6AB3 for <>; Fri, 26 Sep 2008 09:31:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.534
X-Spam-Status: No, score=-2.534 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 6QYtmetmI8Ty for <>; Fri, 26 Sep 2008 09:31:51 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id A7AED3A6B9F for <>; Fri, 26 Sep 2008 09:31:51 -0700 (PDT)
Received: from [] ( []) by (8.13.8/8.13.8) with ESMTP id m8QGV9Fh027266 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 26 Sep 2008 09:31:12 -0700 (PDT)
Message-ID: <>
Date: Fri, 26 Sep 2008 09:31:09 -0700
From: Joe Touch <touch@ISI.EDU>
User-Agent: Thunderbird (Windows/20080914)
MIME-Version: 1.0
To: "Ish Shalom, Ran" <>
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

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.


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.

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).


> 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