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

"Ish Shalom, Ran" <rishshal@akamai.com> Fri, 26 September 2008 16:22 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 40F993A6B76; Fri, 26 Sep 2008 09:22:06 -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 160793A6B76 for <tcpm@core3.amsl.com>; Fri, 26 Sep 2008 09:22:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.469
X-Spam-Level:
X-Spam-Status: No, score=-2.469 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_RMML_Stock9=0.13]
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 UyL6SU87tbIv for <tcpm@core3.amsl.com>; Fri, 26 Sep 2008 09:22:04 -0700 (PDT)
Received: from prod-mail-xrelay03.akamai.com (prod-mail-xrelay03.akamai.com [72.247.150.167]) by core3.amsl.com (Postfix) with ESMTP id 3E9EF3A6B6E for <tcpm@ietf.org>; Fri, 26 Sep 2008 09:22:04 -0700 (PDT)
Received: from prod-mail-xrelay03.akamai.com (localhost [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 2F9191000055; Fri, 26 Sep 2008 16:22:11 +0000 (GMT)
Received: from prod-mail-relay03.akamai.com (unknown [63.116.109.131]) by prod-mail-xrelay03.akamai.com (Postfix) with ESMTP id 164AF1000048; Fri, 26 Sep 2008 16:22:11 +0000 (GMT)
Received: from USMA1EX-GATE1.kendall.corp.akamai.com (usma1ex-gate1.kendall.corp.akamai.com [172.17.0.215]) by prod-mail-relay03.akamai.com (Postfix) with ESMTP id C8C131000088; Fri, 26 Sep 2008 16:22:10 +0000 (GMT)
Received: from MAVS1.kendall.corp.akamai.com ([172.17.33.15]) by USMA1EX-GATE1.kendall.corp.akamai.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 26 Sep 2008 12:22:10 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Fri, 26 Sep 2008 12:22:09 -0400
Message-ID: <5342C364A2C3A6458B15BB147FB4B724AC482F@MAVS1.kendall.corp.akamai.com>
In-Reply-To: <48DD0961.4020802@isi.edu>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [tcpm] End to End Proprietary Information Field - Request for a new TCP option
thread-index: Ackf8nlJOWd6Di7YQ9qHLV4H2pYSaQAAUPSg
References: <5342C364A2C3A6458B15BB147FB4B724AC479D@MAVS1.kendall.corp.akamai.com> <48DD0961.4020802@isi.edu>
From: "Ish Shalom, Ran" <rishshal@akamai.com>
To: Joe Touch <touch@ISI.EDU>
X-OriginalArrivalTime: 26 Sep 2008 16:22:10.0229 (UTC) FILETIME=[06BCD650:01C91FF4]
Cc: tcpm@ietf.org
Subject: Re: [tcpm] End to End Proprietary Information Field - Request for a new TCP option
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: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: tcpm-bounces@ietf.org
Errors-To: tcpm-bounces@ietf.org

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 

-----Original Message-----
From: Joe Touch [mailto:touch@ISI.EDU] 
Sent: Friday, September 26, 2008 12:10 PM
To: Ish Shalom, Ran
Cc: tcpm@ietf.org
Subject: Re: [tcpm] End to End Proprietary Information Field - Request
for a new TCP option

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkjdCWEACgkQE5f5cImnZruh1wCfdUvaaEp7Zfmz0IljtN6rXLrA
zegAn31/adWJ8mpOuMDGfANcBlPmG2n0
=88Rb
-----END PGP SIGNATURE-----
_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm