idnits 2.17.1 draft-williams-overlaypath-ip-tcp-rfc-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == It seems as if not all pages are separated by form feeds - found 0 form feeds but 15 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 3 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 205: '... version 2 MUST also support version...' RFC 2119 keyword, line 209: '...number, the receiver MAY either ignore...' RFC 2119 keyword, line 241: '...ss). The option MUST be ignored if th...' RFC 2119 keyword, line 255: '... of IP addresses MUST be provided in o...' RFC 2119 keyword, line 265: '... implementation SHOULD use the IPv6 h...' (12 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Obsolete informational reference (is this intentional?): RFC 793 (Obsoleted by RFC 9293) -- Obsolete informational reference (is this intentional?): RFC 2460 (Obsoleted by RFC 8200) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group B. Williams 3 Internet-Draft Akamai Technologies, Inc. 4 Intended status: Standards Track December 2011 5 Expires: June 3, 2012 7 Overlay Path Option for IP and TCP 8 draft-williams-overlaypath-ip-tcp-rfc-00.txt 10 Abstract 12 Data transport through overlay networks often uses either connection 13 termination or network address translation (NAT) in such a way that 14 the public IP addresses of the true endpoint machines involved in the 15 data transport are invisible to each other. This document describes 16 IPv4, IPv6, and TCP options for communicating this information from 17 the overlay network to the endpoint machines. 19 Status of this Memo 21 This Internet-Draft is submitted in full conformance with the provisions 22 of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as Internet- 27 Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt. 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 This Internet-Draft will expire on June 3, 2012. 42 Copyright Notice 44 Copyright (c) 2011 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Detailed Use Case . . . . . . . . . . . . . . . . . . . . . . 5 61 3. Option Format . . . . . . . . . . . . . . . . . . . . . . . . 6 62 3.1. Version 1 . . . . . . . . . . . . . . . . . . . . . . . . 6 63 3.2. Version 2 . . . . . . . . . . . . . . . . . . . . . . . . 7 64 4. Network Traversal . . . . . . . . . . . . . . . . . . . . . . 9 65 5. Option Use . . . . . . . . . . . . . . . . . . . . . . . . . . 10 66 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 67 7. Forward Compatibility Support . . . . . . . . . . . . . . . . 12 68 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 69 9. Informative References . . . . . . . . . . . . . . . . . . . . 14 70 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15 72 1. Introduction 74 An overlay network is a network of machines distributed throughout 75 multiple autonomous systems within the public Internet that can be 76 used to improve the performance of data transport. IP packets from 77 the sender are delivered first to one of the machines that make up 78 the overlay network. That machine will relay the IP packets via one 79 or more other machines in the overlay network, applying various 80 performance enhancement methods and eventually delivering the packets 81 to the real intended receiver. Such overlay networks are used to 82 improve the performance of content delivery [IEEE1344002]. Overlay 83 networks are also used for peer-to-peer data transport [RFC5694], and 84 they have been suggested for use in improved scalability for the 85 internet routing infrastructure [RFC6179]. 87 Data transport through such an overlay network will often use network 88 address translation for the source (SNAT) or destination (DNAT) 89 addresses [RFC2663] in such a way that the public IP addresses of the 90 true endpoint machines involved in the data transport are invisible 91 to each other. For example, the actual sender and receiver may use 92 two completely different pairs of source and destination addresses to 93 identify the connection on the sending and receiving networks. 95 --------------------------------------------------------------------- 97 ip hdr contains: ip hdr contains: 98 SENDER -> src = sender --> OVERLAY --> src = overlay2 --> RECEIVER 99 dst = overlay1 dst = receiver 101 --------------------------------------------------------------------- 103 Figure 1 105 This can be problematic for network security and diagnostics, since 106 the source and destination IP addresses used by the sender are not 107 accessible by the receiver. 109 Some application layer protocols provide functionality that allows 110 the overlay network to communicate the sender's public IP address to 111 the receiver, such as the HTTP X-FORWARDED-FOR header field. 112 However, use of such application specific options requires both the 113 overlay network and the receiver to perform application layer 114 processing with associated overhead. It also requires separate 115 implementations for each supported application type. 117 Some proprietary implementations use IP-in-IP or UDP tunneling in 118 order to communicate the information in question, but these solutions 119 require continuous network overhead throughout the life of the 120 connection. 122 In order to limit the network and processing overhead associated with 123 the other commonly used approaches, the mechanism described herein 124 uses an internet or transport layer protocol option to communication 125 the required address(es). 127 Theoretically, the existing IP Record Route option could be used to 128 provide the required information, but there are a few problems 129 associated with this approach. First, this use would be a re- 130 purposing of the option, and thus existing implementations of support 131 for the option would quite possibly conflict with this new use. More 132 importantly, many IP-layer devices are configured to drop packets 133 that include IP protocol options. Allowing the information to be 134 transmitted at either the internet layer or the transport layer 135 allows for more reliable packet delivery in a broad range of network 136 configurations. 138 This document describes IPv4 [RFC0791], IPv6 [RFC2460], and TCP 139 [RFC0793] options for communicating this information from the overlay 140 to the destination network/machine. The list of addresses specified 141 in the option may include any addresses that might be useful to the 142 eventual receiver for security and/or diagnostic purposes, including 143 but not limited to the source and destination addresses as seen by 144 the sender. 146 The IPv4 and TCP protocol options described herein provide limited 147 support for IPv6 addresses. It should be noted that inclusion of 148 even a single IPv6 address would require the option to consume nearly 149 half of the total option space provided by TCP and IPv4, which means 150 that the entire TCP option space would be consumed for SYN packets 151 that include the most commonly used options (i.e. MSS, WSOPT, SACK 152 permitted, and TSOPT). This may prevent effective use of the IPv4 153 and TCP protocol options for communicating IPv6 addresses in some 154 circumstances. 156 2. Detailed Use Case 158 An example use case that is satisfied by this design is as follows. 160 1. The sending endpoint host performs a DNS lookup that returns the 161 IP address of a machine on the overlay network. The sending 162 endpoint addresses its packets with its own public IP address as 163 the source and the provided overlay IP address as the 164 destination. 166 2. The overlay ingress host receives the packet on its public IP 167 address, and forwards the packet through the overlay to the 168 egress host. The overlay egress host performs SNAT, replacing 169 the source IP address of the sending endpoint with its own IP 170 address in order to ensure that return traffic will also use the 171 overlay network. This use of SNAT hides the client's public IP 172 address for the receiving network. 174 3. For load balancing and diagnostic purposes, it is important for 175 one or more machines on the receiver's network to be able to 176 determine the public IP address associated with the sending host 177 (i.e. the address that was hidden due to the use of SNAT by the 178 overlay). 180 4. The overlay egress host is located on the receiver's network, 181 which means there is a relatively small set of addresses for 182 machines that may be producing packets that include the overlay 183 path option. 185 Under these circumstances, the overlay path option will contain a 186 single IP address: the public IP address of the sending host. If the 187 receiving network must use the IP address included in the option for 188 a purpose that requires trust, the fact that the overlay egress host 189 is under the receiver's administrative control allows the receiver to 190 apply the necessary limitations to the network configuration. For 191 example, under these circumstances, the receiver's firewall device 192 could be configured to drop packets from external hosts if they 193 contain the overlay path option. 195 3. Option Format 197 Some implementations already exist for version 1 of the overlay path 198 option. However, version 1 of the option does not provide support 199 for communicating IPv6 addresses in either the IPv4 or TCP option. 200 Both version 1 and version 2 of the option are described here in 201 order to reflect the requirements of current and future implementors. 203 It is up to the implementor whether version 1 is supported or both 204 versions are supported. A receiving implementation that supports 205 version 2 MUST also support version 1. The format changes defined 206 for version 2 directly support the required backward compatibility. 208 When a receiving implementation encounters the overlay path option 209 with an unsupported version number, the receiver MAY either ignore 210 the option or drop the packet. The appropriate response will be 211 dependent upon how the overlay path option's value is used by the 212 receiver. 214 3.1. Version 1 216 Version 1 of the option supports only IPv4 addresses. The option 217 format for both IPv4 and TCP is identical. 219 +---------+---------+---------+--------------------------------+ 220 |Type/Kind| Length | Version | Addresses ... 221 +---------+---------+---------+--------------------------------+ 222 1 1 1 4 x Address Count 223 ---------------------------------------------------------------- 225 Figure 2 227 IPv4 Type: The type value for IPv4 is 218 (see also IANA 228 Considerations (Section 8)). 230 Copied flag: 1 (All fragments must carry the option.) 232 Option class: 2 (debugging/measurement) 234 Option number: 26 (decimal) 236 TCP Kind: The option kind value for TCP is 30 (see also IANA 237 Considerations (Section 8)). 239 Length: The length of the option is variable, based on the number of 240 addresses provided. The minimum value is 7 (3 1-octet fields plus 241 one 4-octet address). The option MUST be ignored if the length 242 value cannot represent 3 octets plus a list of 4-octet address 243 value. 245 Version: The version number is 1. 247 Addresses: Version 1 of the option supports only IPv4 addresses. 248 The remainder of the option space is filled with standard 32-bit 249 IPv4 addresses. In practice, the first address will be the public 250 source address used by the sender and the second address (if 251 present) will be the public destination address used by the 252 sender. However, the nature of the addresses provided may vary 253 depending on the nature of the overlay network in question and is 254 not required to include every IP address used for the connection. 255 The list of IP addresses MUST be provided in order of traversal 256 from sender to receiver. 258 3.2. Version 2 260 Version 2 of the options supports either IPv4 addresses or IPv6 261 addresses, but it does not support a mix of IPv4 and IPv6 options 262 within the same option value. Version 2 provides not only IPv4 and 263 TCP options, but also an IPv6 option for inclusion in the IPv6 Hop- 264 by-hop Options header. When IPv6 address support is required, the 265 implementation SHOULD use the IPv6 header option whenever possible in 266 order to avoid exhaustion of the TCP option space. The option format 267 for all three protocols is identical. 269 +---------------+---------------+---------------+----------------------\ 270 | Type/Kind | Length |Fmly| Version | Addresses ... 271 +---------------+---------------+---------------+----------------------\ 272 8b 8b | 3b 5b | 273 ----------------- 274 1 1 1 Addr Size x Count 275 ------------------------------------------------------------------------ 277 Figure 3 279 IPv4 Type: Identical to Version 1. 281 TCP Kind: Identical to Version 1. 283 IPv6 Type: The Type value for IPv6 is 11 (see also IANA 284 Considerations (Section 8)). 286 act flag: 00 (skip over option) 287 chg flag: 0 (option data does not change en-route) 289 rest: 11 (decimal) 291 Length: The length of the option is variable, based on the address 292 family and the number of addresses provided. The minimum value is 293 7 (3 1-octet fields plus one 4-octet IPv4 address). The option 294 MUST be ignored if the length value cannot represent 3 octets plus 295 a list of addresses of the correct address family. 297 Family/Version: The third octet is comprised of two fields: family 298 and version.Note that the possible family values have been 299 selected to support backward compatibility with the 8-bit version 300 field in version 1 of the option format. 302 Family: The high order 3 bits of the third octet indicate the 303 address family for all IP addresses represented in the variable- 304 length Addresses field. The allowed values are: 306 0: Address family is IPv4. 308 1: Address family is IPv6. 310 Version: The low order 5 bits of the third octet indicate the 311 protocol version number. The version number is 2. 313 Addresses: The remainder of the option space is filled with either 314 32-bit IPv4 or 128-bit IPv6 addresses, as indicated by the Family 315 field. In practice, the first address will be the public source 316 address used by the sender and the second address (if present) 317 will be the public destination address used by the sender. 318 However, the nature of the addresses provided may vary depending 319 on the nature of the overlay network in question and is not 320 required to include every IP address used for the connection. The 321 list of IP addresses MUST be provided in order of traversal from 322 sender to receiver. 324 4. Network Traversal 326 The following block diagram illustrates the use of addresses in the 327 IPv4 header and the overlay path option as a packet traverses the 328 network from sender to receiver. The diagram assumes that the 329 overlay network uses separate addresses (overlay1 and overlay2) for 330 ingress and egress. 332 ----------------------------------------------------------------- 334 SENDER 335 | 336 V 337 +----------------+ 338 | | 339 | src: sender | 340 | dst: overlay1 | 341 | opt: none | 342 | | 343 +----------------+ 344 | 345 V 346 OVERLAY 347 NETWORK 348 | 349 V 350 +----------------+ 351 | | 352 | src: overlay2 | 353 | dst: receiver | 354 | opt: sender | 355 | | 356 +----------------+ 357 | 358 V 359 RECEIVER 361 ----------------------------------------------------------------- 363 Figure 4 365 5. Option Use 367 Use of the TCP option allows an implementation to minimize the impact 368 of this option on bandwidth utilization. Due to the connection- 369 oriented nature of TCP, the addresses used by the overlay network 370 cannot change throughout the life of the connection. For this 371 reason, it is not necessary for the overlay network to include the 372 overlay path option on every packet. On the other hand, it is not 373 enough for the option to be provided exclusively in the TCP SYN 374 packet because the use of SYN cookies, for example, would mean that 375 connection state is not stored until completion of the three-way 376 handshake. For this reason, the overlay network MUST include the TCP 377 overlay path option in every outgoing packet until the receiver has 378 either acknowledged or transmitted at least one byte of real data. 379 The overlay network SHOULD discontinue inclusion of the TCP overlay 380 path option after the first byte is either received or acknowledged. 381 The receiver MAY ignore the TCP overlay path option on subsequent 382 packets after successfully processing one instance of the option 383 attached to a single in-order TCP packet. 385 IP is not connection oriented, which means that the above described 386 optimization is not possible. In order to make effective use of the 387 TCP optimization, an overlay network SHOULD only send the IP option 388 on packets that do not use TCP as the transport layer protocol. When 389 the IP option is in use, the overlay network MUST transmit the option 390 with every packet. The receiver MUST NOT assume that that addresses 391 in the IP overlay path option will remain consistent, but instead 392 MUST be prepared to handle address changes in an application 393 appropriate way. 395 Use of the IP option is dependent upon support for IP options in all 396 routers between the overlay egress point and the packet receiver. If 397 any router along the path is configured to drop packets with unknown 398 IPv4 options (or any IP options, as is sometimes done as part of a 399 DoS protection scheme), then use of the IP option will cause 400 connections to simply fail. For this reason, the IP option SHOULD 401 only be used in environments where the full path between the overlay 402 egress machine and the packet receiver is under common administrative 403 control. 405 As explained above, the intention of both the TCP and IP options is 406 to provide the receiver with public IP addresses that it would 407 otherwise have seen if the overlay network were not in use. There 408 are security implications associated with exposing a network's use of 409 the private [RFC1918] address space to the public internet, and for 410 this reason, the overlay path option SHOULD NOT be used to 411 communicate RFC1918 addresses in packets that traverse the public 412 internet. 414 6. Security Considerations 416 This specification provides no authentication/validity verification 417 for the data contained in the address fields. For this reason, the 418 data contained in the addresses field of the new option cannot itself 419 be considered inherently secure. In other words, confidence in the 420 validity of the source address of the IPv4/IPv6 packet does not 421 translate into confidence in the validity of the addresses in the 422 overlay path option. With this exception, this specification does 423 not alter the inherent security of IPv4, IPv6, or TCP. 425 The addresses provided in the option SHOULD NOT be used for purposes 426 that require a trust relationship between the overlay network and the 427 receiver (e.g. billing and/or intrusion prevention) unless a 428 mechanism outside the scope of this specification is used to ensure 429 the necessary level of trust. As noted above, one possible example 430 of such a mechanism would be to place the overlay egress host on the 431 receiver's own network and to configure the receiver's firewall to 432 drop any packets from external hosts that provide the overlay path 433 option. When the receiving network uses the values provided by the 434 option in a way that does not require trust (e.g. maintaining session 435 affinity in a load-balancing system), then use of a mechanism to 436 enforce the trust relationship may not be required. 438 7. Forward Compatibility Support 440 The most common use of this option on the internet today will require 441 recording IP addresses for a single address family only. However, it 442 may be important in the future to be able to record a mix of IPv4 and 443 IPv6 addresses. Alternatively, future security requirements may 444 demand the use of, for example, a keyed hash for data integrity and 445 authentication purposes and/or inclusion of additional information 446 specific to the sender's connection. 448 To balance current-day performance and efficiency against the need 449 for future extensibility, the option includes a version field, so 450 that future requirements can be met without the need to consume a new 451 option number. 453 8. IANA Considerations 455 The assignment of numbers 26 for IPv4, 11 for IPv6, and 30 for TCP 456 are provisional pending official IANA approval. The Type values 457 could change if IANA assigns different numbers. 459 It may be important to note that some early implementations of this 460 specification use TCP option numbers 28 and 29 due to the fact that 461 these numbers were available at the time of the implementation. 462 These early implementations will require updates after an official 463 option number has been assigned. 465 9. Informative References 467 [RFC0791] Postel, J., "Internet Protocol", RFC 791, STD 5, 468 September 1981. 470 [RFC0793] Postel, J., "Transmission Control Protocol", RFC 793, 471 STD 7, September 1981. 473 [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., 474 and E. Lear, "Address Allocation for Private Internets", 475 RFC 1918, BCP 5, February 1996. 477 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 478 (IPv6)", RFC 2460, December 1998. 480 [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address 481 Translator (NAT) Terminology and Considerations", 482 RFC 2663, August 1999. 484 [RFC5694] Camarillo, G., "Peer-to-Peer (P2P) Architecture: 485 Definition, Taxonomies, Examples, and Applicability", 486 RFC 5694, November 2009. 488 [RFC6179] Templin, F., "The Internet Routing Overlay Network 489 (IRON)", RFC 6179, March 2011. 491 [IEEE1344002] 492 Byers, J., Considine, J., Mitzenmacher, M., and S. Rost, 493 "Informed content delivery across adaptive overlay 494 networks: IEEE/ACM Transactions on Networking, Vol 12, 495 Issue 5, ppg 767-780", October 2004. 497 Author's Address 499 Brandon Williams 500 Akamai, Inc. 501 Cambridge, MA 502 USA 504 Email: brandon.williams@akamai.com