idnits 2.17.1 draft-williams-overlaypath-ip-tcp-rfc-02.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: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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 199: '... version 2 MUST also support version...' RFC 2119 keyword, line 203: '...number, the receiver MAY either ignore...' RFC 2119 keyword, line 235: '...ss). The option MUST be ignored if th...' RFC 2119 keyword, line 249: '... of IP addresses MUST be provided in o...' RFC 2119 keyword, line 259: '... 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: 1 error (**), 0 flaws (~~), 1 warning (==), 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, Inc. 4 Intended status: Standards Track September 2012 5 Expires: March 5, 2013 7 Overlay Path Option for IP and TCP 8 draft-williams-overlaypath-ip-tcp-rfc-02 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 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 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 This Internet-Draft will expire on March 5, 2013. 36 Copyright Notice 38 Copyright (c) 2012 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Detailed Use Case . . . . . . . . . . . . . . . . . . . . . . 5 55 3. Option Format . . . . . . . . . . . . . . . . . . . . . . . . 6 56 3.1. Version 1 . . . . . . . . . . . . . . . . . . . . . . . . 6 57 3.2. Version 2 . . . . . . . . . . . . . . . . . . . . . . . . 7 58 4. Network Traversal . . . . . . . . . . . . . . . . . . . . . . 9 59 5. Option Use . . . . . . . . . . . . . . . . . . . . . . . . . . 10 60 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 61 7. Forward Compatibility Support . . . . . . . . . . . . . . . . 12 62 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 63 9. Informative References . . . . . . . . . . . . . . . . . . . . 14 64 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15 66 1. Introduction 68 An overlay network is a network of machines distributed throughout 69 multiple autonomous systems within the public Internet that can be 70 used to improve the performance of data transport. IP packets from 71 the sender are delivered first to one of the machines that make up 72 the overlay network. That machine will relay the IP packets via one 73 or more other machines in the overlay network, applying various 74 performance enhancement methods and eventually delivering the packets 75 to the real intended receiver. Such overlay networks are used to 76 improve the performance of content delivery [IEEE1344002]. Overlay 77 networks are also used for peer-to-peer data transport [RFC5694], and 78 they have been suggested for use in improved scalability for the 79 internet routing infrastructure [RFC6179]. 81 Data transport through such an overlay network will often use network 82 address translation for the source (SNAT) or destination (DNAT) 83 addresses [RFC2663] in such a way that the public IP addresses of the 84 true endpoint machines involved in the data transport are invisible 85 to each other. For example, the actual sender and receiver may use 86 two completely different pairs of source and destination addresses to 87 identify the connection on the sending and receiving networks. 89 --------------------------------------------------------------------- 91 ip hdr contains: ip hdr contains: 92 SENDER -> src = sender --> OVERLAY --> src = overlay2 --> RECEIVER 93 dst = overlay1 dst = receiver 95 --------------------------------------------------------------------- 97 Figure 1 99 This can be problematic for network security and diagnostics, since 100 the source and destination IP addresses used by the sender are not 101 accessible by the receiver. 103 Some application layer protocols provide functionality that allows 104 the overlay network to communicate the sender's public IP address to 105 the receiver, such as the HTTP X-FORWARDED-FOR header field. 106 However, use of such application specific options requires both the 107 overlay network and the receiver to perform application layer 108 processing with associated overhead. It also requires separate 109 implementations for each supported application type. 111 Some proprietary implementations use IP-in-IP or UDP tunneling in 112 order to communicate the information in question, but these solutions 113 require continuous network overhead throughout the life of the 114 connection. 116 In order to limit the network and processing overhead associated with 117 the other commonly used approaches, the mechanism described herein 118 uses an internet or transport layer protocol option to communication 119 the required address(es). 121 Theoretically, the existing IP Record Route option could be used to 122 provide the required information, but there are a few problems 123 associated with this approach. First, this use would be a re- 124 purposing of the option, and thus existing implementations of support 125 for the option would quite possibly conflict with this new use. More 126 importantly, many IP-layer devices are configured to drop packets 127 that include IP protocol options. Allowing the information to be 128 transmitted at either the internet layer or the transport layer 129 allows for more reliable packet delivery in a broad range of network 130 configurations. 132 This document describes IPv4 [RFC0791], IPv6 [RFC2460], and TCP 133 [RFC0793] options for communicating this information from the overlay 134 to the destination network/machine. The list of addresses specified 135 in the option may include any addresses that might be useful to the 136 eventual receiver for security and/or diagnostic purposes, including 137 but not limited to the source and destination addresses as seen by 138 the sender. 140 The IPv4 and TCP protocol options described herein provide limited 141 support for IPv6 addresses. It should be noted that inclusion of 142 even a single IPv6 address would require the option to consume nearly 143 half of the total option space provided by TCP and IPv4, which means 144 that the entire TCP option space would be consumed for SYN packets 145 that include the most commonly used options (i.e. MSS, WSOPT, SACK 146 permitted, and TSOPT). This may prevent effective use of the IPv4 147 and TCP protocol options for communicating IPv6 addresses in some 148 circumstances. 150 2. Detailed Use Case 152 An example use case that is satisfied by this design is as follows. 154 1. The sending endpoint host performs a DNS lookup that returns the 155 IP address of a machine on the overlay network. The sending 156 endpoint addresses its packets with its own public IP address as 157 the source and the provided overlay IP address as the 158 destination. 160 2. The overlay ingress host receives the packet on its public IP 161 address, and forwards the packet through the overlay to the 162 egress host. The overlay egress host performs SNAT, replacing 163 the source IP address of the sending endpoint with its own IP 164 address in order to ensure that return traffic will also use the 165 overlay network. This use of SNAT hides the client's public IP 166 address for the receiving network. 168 3. For load balancing and diagnostic purposes, it is important for 169 one or more machines on the receiver's network to be able to 170 determine the public IP address associated with the sending host 171 (i.e. the address that was hidden due to the use of SNAT by the 172 overlay). 174 4. The overlay egress host is located on the receiver's network, 175 which means there is a relatively small set of addresses for 176 machines that may be producing packets that include the overlay 177 path option. 179 Under these circumstances, the overlay path option will contain a 180 single IP address: the public IP address of the sending host. If the 181 receiving network must use the IP address included in the option for 182 a purpose that requires trust, the fact that the overlay egress host 183 is under the receiver's administrative control allows the receiver to 184 apply the necessary limitations to the network configuration. For 185 example, under these circumstances, the receiver's firewall device 186 could be configured to drop packets from external hosts if they 187 contain the overlay path option. 189 3. Option Format 191 Some implementations already exist for version 1 of the overlay path 192 option. However, version 1 of the option does not provide support 193 for communicating IPv6 addresses in either the IPv4 or TCP option. 194 Both version 1 and version 2 of the option are described here in 195 order to reflect the requirements of current and future implementors. 197 It is up to the implementor whether version 1 is supported or both 198 versions are supported. A receiving implementation that supports 199 version 2 MUST also support version 1. The format changes defined 200 for version 2 directly support the required backward compatibility. 202 When a receiving implementation encounters the overlay path option 203 with an unsupported version number, the receiver MAY either ignore 204 the option or drop the packet. The appropriate response will be 205 dependent upon how the overlay path option's value is used by the 206 receiver. 208 3.1. Version 1 210 Version 1 of the option supports only IPv4 addresses. The option 211 format for both IPv4 and TCP is identical. 213 +---------+---------+---------+--------------------------------+ 214 |Type/Kind| Length | Version | Addresses ... 215 +---------+---------+---------+--------------------------------+ 216 1 1 1 4 x Address Count 217 ---------------------------------------------------------------- 219 Figure 2 221 IPv4 Type: The type value for IPv4 is TBD-IP4-FULL (see also IANA 222 Considerations (Section 8)). 224 Copied flag: 1 (All fragments must carry the option.) 226 Option class: 2 (debugging/measurement) 228 Option number: TBD-IP4 (decimal) 230 TCP Kind: The option kind value for TCP is TBD-TCP (see also IANA 231 Considerations (Section 8)). 233 Length: The length of the option is variable, based on the number of 234 addresses provided. The minimum value is 7 (3 1-octet fields plus 235 one 4-octet address). The option MUST be ignored if the length 236 value cannot represent 3 octets plus a list of 4-octet address 237 value. 239 Version: The version number is 1. 241 Addresses: Version 1 of the option supports only IPv4 addresses. 242 The remainder of the option space is filled with standard 32-bit 243 IPv4 addresses. In practice, the first address will be the public 244 source address used by the sender and the second address (if 245 present) will be the public destination address used by the 246 sender. However, the nature of the addresses provided may vary 247 depending on the nature of the overlay network in question and is 248 not required to include every IP address used for the connection. 249 The list of IP addresses MUST be provided in order of traversal 250 from sender to receiver. 252 3.2. Version 2 254 Version 2 of the options supports either IPv4 addresses or IPv6 255 addresses, but it does not support a mix of IPv4 and IPv6 options 256 within the same option value. Version 2 provides not only IPv4 and 257 TCP options, but also an IPv6 option for inclusion in the IPv6 Hop- 258 by-hop Options header. When IPv6 address support is required, the 259 implementation SHOULD use the IPv6 header option whenever possible in 260 order to avoid exhaustion of the TCP option space. The option format 261 for all three protocols is identical. 263 +---------------+---------------+---------------+-------------------\ 264 | Type/Kind | Length |Fmly| Version | Addresses ... 265 +---------------+---------------+---------------+-------------------\ 266 8b 8b | 3b 5b | 267 ----------------- 268 1 1 1 Addr Size x Count 269 --------------------------------------------------------------------- 271 Figure 3 273 IPv4 Type: Identical to Version 1. 275 TCP Kind: Identical to Version 1. 277 IPv6 Type: The Type value for IPv6 is TBD-IP6 (see also IANA 278 Considerations (Section 8)). 280 act flag: 00 (skip over option) 281 chg flag: 0 (option data does not change en-route) 283 rest: TBD-IP6 (decimal) 285 Length: The length of the option is variable, based on the address 286 family and the number of addresses provided. The minimum value is 287 7 (3 1-octet fields plus one 4-octet IPv4 address). The option 288 MUST be ignored if the length value cannot represent 3 octets plus 289 a list of addresses of the correct address family. 291 Family/Version: The third octet is comprised of two fields: family 292 and version.Note that the possible family values have been 293 selected to support backward compatibility with the 8-bit version 294 field in version 1 of the option format. 296 Family: The high order 3 bits of the third octet indicate the 297 address family for all IP addresses represented in the variable- 298 length Addresses field. The allowed values are: 300 0: Address family is IPv4. 302 1: Address family is IPv6. 304 Version: The low order 5 bits of the third octet indicate the 305 protocol version number. The version number is 2. 307 Addresses: The remainder of the option space is filled with either 308 32-bit IPv4 or 128-bit IPv6 addresses, as indicated by the Family 309 field. In practice, the first address will be the public source 310 address used by the sender and the second address (if present) 311 will be the public destination address used by the sender. 312 However, the nature of the addresses provided may vary depending 313 on the nature of the overlay network in question and is not 314 required to include every IP address used for the connection. The 315 list of IP addresses MUST be provided in order of traversal from 316 sender to receiver. 318 4. Network Traversal 320 The following block diagram illustrates the use of addresses in the 321 IPv4 header and the overlay path option as a packet traverses the 322 network from sender to receiver. The diagram assumes that the 323 overlay network uses separate addresses (overlay1 and overlay2) for 324 ingress and egress. 326 ----------------------------------------------------------------- 328 SENDER 329 | 330 V 331 +----------------+ 332 | | 333 | src: sender | 334 | dst: overlay1 | 335 | opt: none | 336 | | 337 +----------------+ 338 | 339 V 340 OVERLAY 341 NETWORK 342 | 343 V 344 +----------------+ 345 | | 346 | src: overlay2 | 347 | dst: receiver | 348 | opt: sender | 349 | | 350 +----------------+ 351 | 352 V 353 RECEIVER 355 ----------------------------------------------------------------- 357 Figure 4 359 5. Option Use 361 Use of the TCP option allows an implementation to minimize the impact 362 of this option on bandwidth utilization. Due to the connection- 363 oriented nature of TCP, the addresses used by the overlay network 364 cannot change throughout the life of the connection. For this 365 reason, it is not necessary for the overlay network to include the 366 overlay path option on every packet. On the other hand, it is not 367 enough for the option to be provided exclusively in the TCP SYN 368 packet because the use of SYN cookies, for example, would mean that 369 connection state is not stored until completion of the three-way 370 handshake. For this reason, the overlay network MUST include the TCP 371 overlay path option in every outgoing packet until the receiver has 372 either acknowledged or transmitted at least one byte of real data. 373 The overlay network SHOULD discontinue inclusion of the TCP overlay 374 path option after the first byte is either received or acknowledged. 375 The receiver MAY ignore the TCP overlay path option on subsequent 376 packets after successfully processing one instance of the option 377 attached to a single in-order TCP packet. 379 IP is not connection oriented, which means that the above described 380 optimization is not possible. In order to make effective use of the 381 TCP optimization, an overlay network SHOULD only send the IP option 382 on packets that do not use TCP as the transport layer protocol. When 383 the IP option is in use, the overlay network MUST transmit the option 384 with every packet. The receiver MUST NOT assume that that addresses 385 in the IP overlay path option will remain consistent, but instead 386 MUST be prepared to handle address changes in an application 387 appropriate way. 389 Use of the IP option is dependent upon support for IP options in all 390 routers between the overlay egress point and the packet receiver. If 391 any router along the path is configured to drop packets with unknown 392 IPv4 options (or any IP options, as is sometimes done as part of a 393 DoS protection scheme), then use of the IP option will cause 394 connections to simply fail. For this reason, the IP option SHOULD 395 only be used in environments where the full path between the overlay 396 egress machine and the packet receiver is under common administrative 397 control. 399 As explained above, the intention of both the TCP and IP options is 400 to provide the receiver with public IP addresses that it would 401 otherwise have seen if the overlay network were not in use. There 402 are security implications associated with exposing a network's use of 403 the private [RFC1918] address space to the public internet, and for 404 this reason, the overlay path option SHOULD NOT be used to 405 communicate RFC1918 addresses in packets that traverse the public 406 internet. 408 6. Security Considerations 410 This specification provides no authentication/validity verification 411 for the data contained in the address fields. For this reason, the 412 data contained in the addresses field of the new option cannot itself 413 be considered inherently secure. In other words, confidence in the 414 validity of the source address of the IPv4/IPv6 packet does not 415 translate into confidence in the validity of the addresses in the 416 overlay path option. With this exception, this specification does 417 not alter the inherent security of IPv4, IPv6, or TCP. 419 The addresses provided in the option SHOULD NOT be used for purposes 420 that require a trust relationship between the overlay network and the 421 receiver (e.g. billing and/or intrusion prevention) unless a 422 mechanism outside the scope of this specification is used to ensure 423 the necessary level of trust. As noted above, one possible example 424 of such a mechanism would be to place the overlay egress host on the 425 receiver's own network and to configure the receiver's firewall to 426 drop any packets from external hosts that provide the overlay path 427 option. When the receiving network uses the values provided by the 428 option in a way that does not require trust (e.g. maintaining session 429 affinity in a load-balancing system), then use of a mechanism to 430 enforce the trust relationship may not be required. 432 7. Forward Compatibility Support 434 The most common use of this option on the internet today will require 435 recording IP addresses for a single address family only. However, it 436 may be important in the future to be able to record a mix of IPv4 and 437 IPv6 addresses. Alternatively, future security requirements may 438 demand the use of, for example, a keyed hash for data integrity and 439 authentication purposes and/or inclusion of additional information 440 specific to the sender's connection. 442 To balance current-day performance and efficiency against the need 443 for future extensibility, the option includes a version field, so 444 that future requirements can be met without the need to consume a new 445 option number. 447 8. IANA Considerations 449 [Paragraphs below in braces should be removed by the RFC Editor upon 450 publication] 452 [The TCP Overlay Path Option requires that IANA allocate a value from 453 the TCP option kind namespace, to be replaced for TBD-TCP throughout 454 this document.] 456 [The IPv4 Overlay Path Option requires that IANA allocate a value 457 from the IP option number namespace. The copy flag for this option 458 is 1 and the class for this option is 2. The assigned number will 459 replace TBD-IP4 throughout this document, and the full type value 460 (representing copy, class, and number) will replace TBD-IP4-FULL 461 throughout the document.] 463 [The IPv6 Overlay Path Option requires that IANA allocate a value 464 from the IPv6 parameters: hop-by-hop options namespace. The action 465 for this option is 00 and the change flag for this option is 0. The 466 assigned number will replace TBD-IP6 throughout this document.] 468 This document defines the TCP Overlay Path option, described in 469 Section 3.1 and Section 3.2. This option has been assigned the 470 option number TBD-TCP by IANA action. 472 This document also defines the IPv4 Overlay Path option, described in 473 Section 3.1 and Section 3.2. This option has been assigned the 474 option number TBD-IP4-FULL by IANA action. 476 This document also defines the IPv6 Overlay Path hop-by-hop option, 477 described in Section 3.2. This option has been assigned the option 478 number TBD-IP6 by IANA action. 480 This document defines no new namespaces. 482 9. Informative References 484 [RFC0791] Postel, J., "Internet Protocol", RFC 791, STD 5, 485 September 1981. 487 [RFC0793] Postel, J., "Transmission Control Protocol", RFC 793, 488 STD 7, September 1981. 490 [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., 491 and E. Lear, "Address Allocation for Private Internets", 492 RFC 1918, BCP 5, February 1996. 494 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 495 (IPv6)", RFC 2460, December 1998. 497 [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address 498 Translator (NAT) Terminology and Considerations", 499 RFC 2663, August 1999. 501 [RFC5694] Camarillo, G., "Peer-to-Peer (P2P) Architecture: 502 Definition, Taxonomies, Examples, and Applicability", 503 RFC 5694, November 2009. 505 [RFC6179] Templin, F., "The Internet Routing Overlay Network 506 (IRON)", RFC 6179, March 2011. 508 [IEEE1344002] 509 Byers, J., Considine, J., Mitzenmacher, M., and S. Rost, 510 "Informed content delivery across adaptive overlay 511 networks: IEEE/ACM Transactions on Networking, Vol 12, 512 Issue 5, ppg 767-780", October 2004. 514 Author's Address 516 Brandon Williams 517 Akamai, Inc. 518 Cambridge, MA 519 USA 521 Email: brandon.williams@akamai.com