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

[Joe Touch <[e-mail]>]

-----BEGIN PGP SIGNED MESSAGE-----
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.

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.

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

iEYEARECAAYFAkjdDk0ACgkQE5f5cImnZruNnQCfefutXF1ciE7W4IOlRLTXppOZ
RbgAoJOnhfNdGHcaaYMWIDkHIWUWyO32
=o0Rw
-----END PGP SIGNATURE-----
_______________________________________________
tcpm mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/tcpm