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

[Joe Touch <[e-mail]>]

-----BEGIN PGP SIGNED MESSAGE-----
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:[e-mail]] 
>> Sent: Friday, September 26, 2008 12:10 PM
>> To: Ish Shalom, Ran
>> Cc: [e-mail]
>> 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
>>> [e-mail]
>>> 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

iEYEARECAAYFAkjdDuAACgkQE5f5cImnZrtDOwCdHzgmKZF4EG/HDYuacxNA5s6x
X5gAoMySfW3hWkvg3y3vpFNGsRD4klcG
=n4ho
-----END PGP SIGNATURE-----
_______________________________________________
tcpm mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/tcpm