Network Working Group B. Williams
Internet-Draft Akamai, Inc.
Intended status: Standards Track December 2012

Overlay Path Option for IP and TCP

Abstract

Data transport through overlay networks often uses either connection termination or network address translation (NAT) in such a way that the public IP addresses of the true endpoint machines involved in the data transport are invisible to each other. This document describes IPv4, IPv6, and TCP options for communicating this information from the overlay network to the endpoint machines.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http:/⁠/⁠datatracker.ietf.org/⁠drafts/⁠current/⁠.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

Copyright Notice

Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http:/⁠/⁠trustee.ietf.org/⁠license-⁠info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.


Table of Contents

1. Introduction

An overlay network is a network of machines distributed throughout multiple autonomous systems within the public Internet (see Figure 1). IP packets from the sender are delivered first to one of the machines that make up the overlay network. That machine will relay the IP packets via one or more other machines in the overlay network to an overlay egress machine that will deliver the packets to the real intended receiver.

               +------------------------------------+
               |                                    |
               |              INTERNET              |
               |                                    |
+-----------+  |  +------------+                    |
|  HOST_1   |-----| OVRLY_IN_1 |-----------+        |
+-----------+  |  +------------+           |        |
               |                           |        |
+-----------+  |  +------------+     +-----------+  |  +--------+
|  HOST_2   |-----| OVRLY_IN_2 |-----| OVRLY_OUT |-----| SERVER |
+-----------+  |  +------------+     +-----------+  |  +--------+
               |                           |        |
+-----------+  |  +------------+           |        |
|  HOST_3   |-----| OVRLY_IN_3 |-----------+        |
+-----------+  |  +------------+                    |
               |                                    |
               +------------------------------------+
        

Figure 1

Such overlay networks are used to improve the performance of content delivery [IEEE1344002]. Overlay networks are also used for peer-to-peer data transport [RFC5694], and they have been suggested for use in both improved scalability for the internet routing infrastructure [RFC6179] and provision of security services (intrusion detection, anti-virus software, etc.) over the public internet [IEEE101109].

Data transport through such an overlay network will often use network address translation for the source (SNAT) or destination (DNAT) addresses [RFC2663] in such a way that the public IP addresses of the true endpoint machines involved in the data transport are invisible to each other. For example, the actual sender and receiver may use two completely different pairs of source and destination addresses to identify the connection on the sending and receiving networks.

---------------------------------------------------------------------

          ip hdr contains:               ip hdr contains:
SENDER -> src = sender   --> OVERLAY --> src = overlay2  --> RECEIVER 
          dst = overlay1                 dst = receiver  

---------------------------------------------------------------------
        

Figure 2

A broad range of issues associated with address sharing have been well documented [RFC6269], and they are not unique to overlay networks [I-D.boucadair-intarea-host-identifier-scenarios]. However, overlay networks can pose a bigger traceability problem than most other use cases, due to their combined use of SNAT and DNAT.

1.1. Detailed Use Case

The following list describes typical operation of an overlay network to provide context for the solution-set analysis that follows.

  • The sending endpoint host performs a DNS lookup that returns the IP address of a machine on the overlay network. The sending endpoint addresses its packets with its own public IP address as the source and the provided overlay IP address as the destination.
  • The overlay ingress host receives the packet on its public IP address, and forwards the packet through the overlay to the egress host. The overlay egress host performs SNAT, replacing the source IP address of the sending endpoint with its own IP address in order to ensure that return traffic will also use the overlay network. This use of SNAT hides the client's public IP address for the receiving network.
  • The overlay egress host is located on the receiver's network, which means there is a relatively small set of source addresses used for connections between the overlay egress host and the application server.
  • For load balancing and diagnostic purposes, it is important for one or more machines on the receiver's network to be able to determine the public IP address associated with the sending host and the destination IP address used by the sending host (i.e. the addresses that were hidden by the overlay due to the use of SNAT and DNAT).
  • The data transferred via the overlay network is typically encrypted (e.g. using SSL) such that the overlay network can apply network and transport layer optimizations but cannot access information provided at the application layer.
  • For diagnostic purposes, the overlay network must also support traceroute using UDP probe packets.

1.2. Solution-set Analysis

A detailed analysis of various solutions to the problem of revealing the sending host's ID information to the receiver is presented by [I-D.ietf-intarea-nat-reveal-analysis]. A solution that is suitable for overlay networks will have the following properties:

  • The method must support both TCP and UDP.
  • The method must work in the presence of encrypted traffic.
  • The method must have a high success ratio for existing servers and networks.
  • The method must have a minimal impact on performance.
  • The method must support provision of multiple addresses.
  • The method must provide client identification at connection initiation.

Based on the above referenced analysis and overlay network suitability requirements, the best-fit solution for providing address visibility for application data flows is to use a TCP option. A feasibility assessment of two proposed TCP host ID options is provided by [I-D.abdo-hostid-tcpopt-implementation]. Although the options implemented for that assessment do not meet the "multiple address" criteria highlighted above, the proof-of-concept implementations and testing show that this category of solution is workable.

Unfortunately, there is no solution for UDP traffic that meets all of the above criteria. However, in the case where the full path from the overlay egress machine to the application server is under common administrative control, it is possible to mitigate the shortcomings associated with IP options and generate both a high success ratio and low-to-medium performance impact when using an IP option to communicate the address information. For this reason, provision of an IP option can be useful enough for overlay networks to be worth consideration.

It should be noted that IPv4 and TCP protocol options can provide only limited support for IPv6 addresses. Inclusion of even a single IPv6 address would require the option to consume nearly half of the total option space provided by TCP and IPv4, which means that the entire TCP option space would be consumed for SYN packets that include the most commonly used options (i.e. MSS, WSOPT, SACK permitted, and TSOPT). This may prevent effective use of the IPv4 and TCP protocol options for communicating IPv6 addresses in some circumstances.

This document describes IPv4 [RFC0791], IPv6 [RFC2460], and TCP [RFC0793] options for communicating sender-side address information from the overlay to the destination network/machine. The list of addresses specified in the option may include any addresses that might be useful to the eventual receiver, including but not limited to the source and destination addresses as seen by the sender.

2. Option Format

Some implementations already exist for version 1 of the overlay path option. However, version 1 of the option does not provide support for communicating IPv6 addresses in either the IPv4 or TCP option. Both version 1 and version 2 of the option are described here in order to reflect the requirements of current and future implementors.

It is up to the implementor whether version 1 is supported or both versions are supported. A receiving implementation that supports version 2 MUST also support version 1. The format changes defined for version 2 directly support the required backward compatibility.

When a receiving implementation encounters the overlay path option with an unsupported version number, the receiver MAY either ignore the option or drop the packet. The appropriate response will be dependent upon how the overlay path option's value is used by the receiver.

2.1. Version 1

Version 1 of the option supports only IPv4 addresses. The option format for both IPv4 and TCP is identical.

+---------+---------+---------+--------------------------------+ 
|Type/Kind| Length  | Version | Addresses ...
+---------+---------+---------+--------------------------------+ 
     1         1         1            4 x Address Count
----------------------------------------------------------------
          

Figure 3

IPv4 Type:
The type value for IPv4 is TBD-IP4-FULL (see also IANA Considerations [iana]).
Copied flag:
1 (All fragments must carry the option.)
Option class:
2 (debugging/measurement)
Option number:
TBD-IP4 (decimal)

TCP Kind:
The option kind value for TCP is TBD-TCP (see also IANA Considerations [iana]).
Length:
The length of the option is variable, based on the number of addresses provided. The minimum value is 7 (3 1-octet fields plus one 4-octet address). The option MUST be ignored if the length value cannot represent 3 octets plus a list of 4-octet address value.
Version:
The version number is 1.
Addresses:
Version 1 of the option supports only IPv4 addresses. The remainder of the option space is filled with standard 32-bit IPv4 addresses. In practice, the first address will be the public source address used by the sender and the second address (if present) will be the public destination address used by the sender. However, the nature of the addresses provided may vary depending on the nature of the overlay network in question and is not required to include every IP address used for the connection. The list of IP addresses MUST be provided in order of traversal from sender to receiver.

2.2. Version 2

Version 2 of the options supports either IPv4 addresses or IPv6 addresses, but it does not support a mix of IPv4 and IPv6 options within the same option value. Version 2 provides not only IPv4 and TCP options, but also an IPv6 option for inclusion in the IPv6 Hop-by-hop Options header. When IPv6 address support is required, the implementation SHOULD use the IPv6 header option whenever possible in order to avoid exhaustion of the TCP option space. The option format for all three protocols is identical.

+---------------+---------------+---------------+-------------------\ 
|   Type/Kind   |    Length     |Fmly| Version  |  Addresses ...
+---------------+---------------+---------------+-------------------\
       8b              8b       | 3b     5b     |
                                -----------------
        1               1              1          Addr Size x Count
---------------------------------------------------------------------
          

Figure 4

IPv4 Type:
Identical to Version 1.
TCP Kind:
Identical to Version 1.
IPv6 Type:
The Type value for IPv6 is TBD-IP6 (see also IANA Considerations [iana]).
act flag:
00 (skip over option)
chg flag:
0 (option data does not change en-route)
rest:
TBD-IP6 (decimal)

Length:
The length of the option is variable, based on the address family and the number of addresses provided. The minimum value is 7 (3 1-octet fields plus one 4-octet IPv4 address). The option MUST be ignored if the length value cannot represent 3 octets plus a list of addresses of the correct address family.
Family/Version:
The third octet is comprised of two fields: family and version.Note that the possible family values have been selected to support backward compatibility with the 8-bit version field in version 1 of the option format.
Family:
The high order 3 bits of the third octet indicate the address family for all IP addresses represented in the variable-length Addresses field. The allowed values are:
0:
Address family is IPv4.
1:
Address family is IPv6.

Version:
The low order 5 bits of the third octet indicate the protocol version number. The version number is 2.
Addresses:
The remainder of the option space is filled with either 32-bit IPv4 or 128-bit IPv6 addresses, as indicated by the Family field. In practice, the first address will be the public source address used by the sender and the second address (if present) will be the public destination address used by the sender. However, the nature of the addresses provided may vary depending on the nature of the overlay network in question and is not required to include every IP address used for the connection. The list of IP addresses MUST be provided in order of traversal from sender to receiver.

3. Network Traversal

The following block diagram illustrates the use of addresses in the IPv4 header and the overlay path option as a packet traverses the network from sender to receiver. The diagram assumes that the overlay network uses separate addresses (overlay1 and overlay2) for ingress and egress, and that the receiver has a need to know both addresses used by the sender.

-----------------------------------------------------------------

                             SENDER
                               |
                               V
                       +----------------+
                       |                |
                       | src: sender    |
                       | dst: overlay1  |
                       | opt: none      |
                       |                |
                       +----------------+
                               |
                               V
                            OVERLAY
                            NETWORK
                               |
                               V
                       +----------------+
                       |                |
                       | src: overlay2  |
                       | dst: receiver  |
                       | opt: sender    |
                       |      overlay1  |
                       |                |
                       +----------------+
                               |
                               V
                            RECEIVER

-----------------------------------------------------------------
        

Figure 5

4. Option Use

Use of the TCP option allows an implementation to minimize the impact of this option on bandwidth utilization. Due to the connection-oriented nature of TCP, the addresses used by the overlay network cannot change throughout the life of the connection. For this reason, it is not necessary for the overlay network to include the overlay path option on every packet. On the other hand, it is not enough for the option to be provided exclusively in the TCP SYN packet because the use of SYN cookies, for example, would mean that connection state is not stored until completion of the three-way handshake. For this reason, the overlay network MUST include the TCP overlay path option in every outgoing packet until the receiver has either acknowledged or transmitted at least one byte of real data. The overlay network SHOULD discontinue inclusion of the TCP overlay path option after the first byte is either received or acknowledged. The receiver MAY ignore the TCP overlay path option on subsequent packets after successfully processing one instance of the option attached to a single in-order TCP packet.

IP is not connection oriented, which means that the above described optimization is not possible. In order to make effective use of the TCP optimization, an overlay network SHOULD only send the IP option on packets that do not use TCP as the transport layer protocol. When the IP option is in use, the overlay network MUST transmit the option with every packet. The receiver MUST NOT assume that that addresses in the IP overlay path option will remain consistent, but instead MUST be prepared to handle address changes in an application appropriate way.

Use of the IP option is dependent upon support for IP options in all routers between the overlay egress point and the packet receiver. If any router along the path is configured to drop packets with unknown IPv4 options (or any IP options, as is sometimes done as part of a DoS protection scheme), then use of the IP option will cause connections to simply fail. For this reason, the IP option SHOULD only be used in environments where the full path between the overlay egress machine and the packet receiver is under common administrative control.

As explained above, the intention of both the TCP and IP options is to provide the receiver with public IP addresses that it would otherwise have seen if the overlay network were not in use. There are security implications associated with exposing a network's use of the private [RFC1918] address space to the public internet, and for this reason, the overlay path option SHOULD NOT be used to communicate RFC1918 addresses in packets that traverse the public internet.

5. Security Considerations

This specification provides no authentication/validity verification for the data contained in the addresses field. For this reason, the data contained in the addresses field of the new option cannot itself be considered inherently secure. In other words, confidence in the validity of the source address of the IPv4/IPv6 packet does not translate into confidence in the validity of the addresses in the overlay path option. With this exception, this specification does not alter the inherent security of IPv4, IPv6, or TCP.

The addresses provided in the option SHOULD NOT be used for purposes that require a trust relationship between the overlay network and the receiver (e.g. billing and/or intrusion prevention) unless a mechanism outside the scope of this specification is used to ensure the necessary level of trust. One possible example of such a mechanism would be to place the overlay egress host on the receiver's own network and to configure the receiver's firewall to drop any packets from external hosts that provide the overlay path option. When the receiving network uses the values provided by the option in a way that does not require trust (e.g. maintaining session affinity in a load-balancing system), then use of a mechanism to enforce the trust relationship may not be required.

6. Forward Compatibility Support

The most common use of this option on the internet today will require recording IP addresses for a single address family only. However, it may be important in the future to be able to record a mix of IPv4 and IPv6 addresses. Alternatively, future security requirements may demand the use of, for example, a keyed hash for data integrity and authentication purposes and/or inclusion of additional information specific to the sender's connection.

To balance current-day performance and efficiency against the need for future extensibility, the option includes a version field, so that future requirements can be met without the need to consume a new option number.

7. IANA Considerations

[Paragraphs below in braces should be removed by the RFC Editor upon publication]

[The TCP Overlay Path Option requires that IANA allocate a value from the TCP option kind namespace, to be replaced for TBD-TCP throughout this document.]

[The IPv4 Overlay Path Option requires that IANA allocate a value from the IP option number namespace. The copy flag for this option is 1 and the class for this option is 2. The assigned number will replace TBD-IP4 throughout this document, and the full type value (representing copy, class, and number) will replace TBD-IP4-FULL throughout the document.]

[The IPv6 Overlay Path Option requires that IANA allocate a value from the IPv6 parameters: hop-by-hop options namespace. The action for this option is 00 and the change flag for this option is 0. The assigned number will replace TBD-IP6 throughout this document.]

This document defines the TCP Overlay Path option, described in Section 2.1 and Section 2.2. This option has been assigned the option number TBD-TCP by IANA action.

This document also defines the IPv4 Overlay Path option, described in Section 2.1 and Section 2.2. This option has been assigned the option number TBD-IP4-FULL by IANA action.

This document also defines the IPv6 Overlay Path hop-by-hop option, described in Section 2.2. This option has been assigned the option number TBD-IP6 by IANA action.

This document defines no new namespaces.

8. References

8.1. Normative References

[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G. and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.
[RFC2460] Deering, S.E. and R.M. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, August 1999.

8.2. Informative References

[RFC5694] Camarillo, G., IAB, "Peer-to-Peer (P2P) Architecture: Definition, Taxonomies, Examples, and Applicability", RFC 5694, November 2009.
[RFC6179] Templin, F., "The Internet Routing Overlay Network (IRON)", RFC 6179, March 2011.
[RFC6269] Ford, M., Boucadair, M., Durand, A., Levis, P. and P. Roberts, "Issues with IP Address Sharing", RFC 6269, June 2011.
[IEEE1344002] Byers, J.W., Considine, J., Mitzenmacher, M. and S. Rost, "Informed content delivery across adaptive overlay networks: IEEE/ACM Transactions on Networking, Vol 12, Issue 5, ppg 767-780", October 2004.
[IEEE101109] Salah, K., Calero, J.M.A., Zeadally, S., Almulla, S. and M. ZAaabi, "Using Cloud Computing to Implement a Security Overlay Network, IEEE Security & Privacy, 21 June 2012. IEEE Computer Society Digital Library.", June 2012.
[I-D.boucadair-intarea-host-identifier-scenarios] Boucadair, M, Binet, D, Durel, S, Reddy, T and B Williams, "Host Identification: Use Cases", Internet-Draft draft-boucadair-intarea-host-identifier-scenarios-02, December 2012.
[I-D.abdo-hostid-tcpopt-implementation] Abdo, E, Boucadair, M and J Queiroz, "HOST_ID TCP Options: Implementation & Preliminary Test Results", Internet-Draft draft-abdo-hostid-tcpopt-implementation-02, January 2012.
[I-D.ietf-intarea-nat-reveal-analysis] Boucadair, M, Touch, J, Levis, P and R Penno, "Analysis of Solution Candidates to Reveal a Host Identifier (HOST_ID) in Shared Address Deployments", Internet-Draft draft-ietf-intarea-nat-reveal-analysis-02, April 2012.

Author's Address

Brandon Williams Akamai, Inc. Cambridge, MA USA EMail: brandon.williams@akamai.com