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

From: "Ish Shalom, Ran" <[email-masked]>
Date: Fri, 26 Sep 2008 11:48:53 -0400

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. 

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
[email-masked]
https://www.ietf.org/mailman/listinfo/tcpm

---

From: Joe Touch <[email-masked]>
Date: Fri, 26 Sep 2008 09:10:09 -0700

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

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

> ------------------------------------------------------------------------
>

---

From: "Ish Shalom, Ran" <[email-masked]>
Date: Fri, 26 Sep 2008 12:22:09 -0400

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:[email-masked]] 
Sent: Friday, September 26, 2008 12:10 PM
To: Ish Shalom, Ran
Cc: [email-masked]
Subject: Re: [tcpm] End to End Proprietary Information Field - Request
for a new TCP option

Ish,

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.

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

> I would like to propose creating a proprietary information channel 
> using a dedicated TCP option that can be used by such application to 
> 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.

---

From: Joe Touch <[email-masked]>
Date: Fri, 26 Sep 2008 09:31:09 -0700

> despite the many gateways that may change this information in the header

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

---

From: Joe Touch <[email-masked]>
Date: Fri, 26 Sep 2008 09:33:36 -0700

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

---

From: "Ish Shalom, Ran" <[email-masked]>
Date: Fri, 26 Sep 2008 12:39:26 -0400

Joe,

I agree and it was my oversight for not discussing it explicitly. A
tunnel is certainly an option to transmit such information (with
sometimes the added benefits of authentication). The main downside to
implementing it is its cost. Tunnels (at any layer) are sometimes very
expensive in terms of processing and delay. Having a TCP option may help
us avoid taking this hit. 

As for NAT devices still destroying TCP header information, I agree that
needs to be discussed and solved. The way I see it is that once we have
a formally assigned TCP option with a clear definition of what it is
used for and how to treat it, we can then work with NAT vendors to make
sure that this specific TCP option will not be changed. There are some
security concerns with it but there is also a benefit to communicating
this info.

Ran 

-----Original Message-----
From: Joe Touch [mailto:[email-masked]] 
Sent: Friday, September 26, 2008 12:31 PM
To: Ish Shalom, Ran
Cc: [email-masked]
Subject: Re: [tcpm] End to End Proprietary Information Field - Request
for a new TCP option

> despite the many gateways that may change this information in the 
> header fields.

Ran,

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.

Joe

> 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:

> to preserve TCP options either. They often rewrite or omit such 
> options anyway.
> 

>> ---------------------------------------------------------------------
>> -
>> --
>

---

From: Joe Touch <[email-masked]>
Date: Fri, 26 Sep 2008 09:51:08 -0700

Ran,

> us avoid taking this hit. 

That's an implementation issue, and largely impacts throughput and
processing (not latency). I don't think we should modify a core Internet
protocol to overcome the inefficiencies of some implementations.

> sure that this specific TCP option will not be changed. 

Cooperative NATs don't want to destroy the destination IP address or
port - which define the packet path and service.

Non-cooperative NATs, that destroy destination IP addresses or ports,
are no more likely to preserve this option than they were to preserve
the destination IP address and port.

It seems that there is only one reason for this sort of option - to
preserve the source IP address and source port. It's not clear why this
information is useful, however - e.g., the source address behind the NAT
could have been private and thus meaningless, and the source port is
useful only for demuxing anyway.

> There are some

Given the above, can you explain further? I.e., what is the benefit to
knowing the source IP and source port?

Joe

---

From: Fernando Gont <[email-masked]>
Date: Fri, 26 Sep 2008 15:48:47 -0300

>despite the many gateways that may change this information in the header

A TCP option is still a header field, and packet scrubbers may simply 
remove that option.

That said, it doesn't look like clean design the approach you are 
describing (stuffing IP addresses in TCP, or applications dealing 
with IP addresses in the first place).

Kind regards,

--
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1