idnits 2.17.1 draft-ietf-intarea-nat-reveal-analysis-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 18, 2012) is 4363 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-03) exists of draft-abdo-hostid-tcpopt-implementation-02 == Outdated reference: A later version (-09) exists of draft-iab-privacy-considerations-02 == Outdated reference: A later version (-10) exists of draft-ietf-appsawg-http-forwarded-01 == Outdated reference: A later version (-07) exists of draft-ietf-intarea-ipv4-id-update-04 -- Obsolete informational reference (is this intentional?): RFC 5201 (Obsoleted by RFC 7401) Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTAREA WG M. Boucadair 3 Internet-Draft France Telecom 4 Intended status: Informational J. Touch 5 Expires: October 20, 2012 USC/ISI 6 P. Levis 7 France Telecom 8 R. Penno 9 Cisco 10 April 18, 2012 12 Analysis of Solution Candidates to Reveal a Host Identifier (HOST_ID) in 13 Shared Address Deployments 14 draft-ietf-intarea-nat-reveal-analysis-02 16 Abstract 18 This document analyzes a set of solution candidates to mitigate some 19 of the issues encountered when address sharing is used. In 20 particular, this document focuses on means to reveal a host 21 identifier (HOST_ID) when a Carrier Grade NAT (CGN) or application 22 proxies are involved in the path. This host identifier must be 23 unique to each host under the same shared IP address. 25 Requirements Language 27 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 28 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 29 document are to be interpreted as described in RFC 2119 [RFC2119]. 31 Status of this Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on October 20, 2012. 48 Copyright Notice 49 Copyright (c) 2012 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 1.1. Context . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 1.2. Purpose and Scope . . . . . . . . . . . . . . . . . . . . 4 67 2. Problem to Be Solved . . . . . . . . . . . . . . . . . . . . . 5 68 2.1. IPv6 May Also Be Concerned . . . . . . . . . . . . . . . . 6 69 3. Solutions Analysis . . . . . . . . . . . . . . . . . . . . . . 6 70 3.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 6 71 3.2. Synthesis . . . . . . . . . . . . . . . . . . . . . . . . 6 72 3.3. Recommendation . . . . . . . . . . . . . . . . . . . . . . 9 73 4. HOST_ID and Privacy . . . . . . . . . . . . . . . . . . . . . 9 74 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 75 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 76 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 77 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 78 8.1. Normative References . . . . . . . . . . . . . . . . . . . 11 79 8.2. Informative References . . . . . . . . . . . . . . . . . . 12 80 Appendix A. Detailed Solutions Analysis . . . . . . . . . . . . . 14 81 A.1. Use the Identification Field of IP Header (IP-ID) . . . . 14 82 A.1.1. Description . . . . . . . . . . . . . . . . . . . . . 14 83 A.1.2. Analysis . . . . . . . . . . . . . . . . . . . . . . . 14 84 A.2. Define an IP Option . . . . . . . . . . . . . . . . . . . 14 85 A.2.1. Description . . . . . . . . . . . . . . . . . . . . . 14 86 A.2.2. Analysis . . . . . . . . . . . . . . . . . . . . . . . 15 87 A.3. Assign Port Sets . . . . . . . . . . . . . . . . . . . . . 15 88 A.3.1. Description . . . . . . . . . . . . . . . . . . . . . 15 89 A.3.2. Analysis . . . . . . . . . . . . . . . . . . . . . . . 15 90 A.4. Use ICMP . . . . . . . . . . . . . . . . . . . . . . . . . 16 91 A.4.1. Description . . . . . . . . . . . . . . . . . . . . . 16 92 A.4.2. Analysis . . . . . . . . . . . . . . . . . . . . . . . 16 93 A.5. Define a TCP Option . . . . . . . . . . . . . . . . . . . 17 94 A.5.1. Description . . . . . . . . . . . . . . . . . . . . . 17 95 A.5.2. Analysis . . . . . . . . . . . . . . . . . . . . . . . 17 96 A.6. PROXY Protocol . . . . . . . . . . . . . . . . . . . . . . 18 97 A.6.1. Description . . . . . . . . . . . . . . . . . . . . . 18 98 A.6.2. Analysis . . . . . . . . . . . . . . . . . . . . . . . 19 99 A.7. Host Identity Protocol (HIP) . . . . . . . . . . . . . . . 19 100 A.7.1. Description . . . . . . . . . . . . . . . . . . . . . 19 101 A.7.2. Analysis . . . . . . . . . . . . . . . . . . . . . . . 19 102 A.8. Inject Application Headers . . . . . . . . . . . . . . . . 19 103 A.8.1. Description . . . . . . . . . . . . . . . . . . . . . 19 104 A.8.2. Analysis . . . . . . . . . . . . . . . . . . . . . . . 20 105 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 107 1. Introduction 109 1.1. Context 111 As reported in [RFC6269], several issues are encountered when an IP 112 address is shared among several subscribers. Examples of such issues 113 are listed below: 115 o Implicit identification (Section 13.2 of [RFC6269]) 116 o SPAM (Section 13.3 of [RFC6269]) 117 o Blacklisting a mis-behaving host (Section 13.1 of [RFC6269]) 118 o Redirect users with infected machines to a dedicated portal 119 (Section 5.1 of [RFC6269]) 120 The sole use of the IPv4 address is not sufficient to uniquely 121 distinguish a host. As a mitigation, it is tempting to investigate 122 means which would help in disclosing an information to be used by the 123 remote server as a means to uniquely disambiguate packets of hosts 124 using the same IPv4 address. 126 The risk of not mitigating these issues are: OPEX increase for IP 127 connectivity service providers (costs induced by calls to a hotline), 128 revenue loss for content providers (loss of users audience), 129 customers unsatisfaction (low quality of experience, service 130 segregation, etc.). 132 1.2. Purpose and Scope 134 The purpose of this document is to analyze a set of alternative 135 channels to convey a host identifier and to assess to what extent 136 they solve the problem described in Section 2. Below are listed the 137 candidates analyzed in the document: 139 o Use the Identification field of IP header (denoted as IP-ID, 140 Appendix A.1). 141 o Define a new IP option (Appendix A.2). 142 o Assign port sets (Appendix A.3). 143 o Use ICMP (Appendix A.3). 144 o Define a new TCP Option (Appendix A.5). 145 o Enable Proxy Protocol ( (Appendix A.6)). 146 o Activate HIP (Appendix A.7). 147 o Inject application headers (Appendix A.8). 149 A synthesis is provided in Section 3 while the detailed analysis is 150 elaborated in Appendix A. 152 Section 4 discusses privacy issues common to all HOST_ID solutions. 153 It is out of scope of this document to elaborate on privacy issues 154 specific to each solution. 156 2. Problem to Be Solved 158 Observation: Today, some servers use the source IPv4 address as an 159 identifier to treat some incoming connections differently. 160 Tomorrow, due to the introduction of CGNs (e.g., NAT44 161 [RFC3022], NAT64 [RFC6146]), that address will be shared. 162 In particular, when a server receives packets from the same 163 source address, because this address is shared, the server 164 does not know which host is the sending host [RFC6269]. 166 Objective: The server should be able to sort out the packets by 167 sending host. 169 Requirement: The server must have extra information than the source 170 IP address to differentiate the sending host. We call 171 HOST_ID this information. 173 For all solutions analyzed, we provide answers to the following 174 questions: 176 What is the HOST_ID? It must be unique to each host under the same 177 IP address. It does not need to be globally unique. Of course, 178 the combination of the (public) IP source address and the 179 identifier (i.e., HOST_ID) ends up being relatively unique. As 180 unique as today's 32-bit IPv4 addresses which, today, can change 181 when a host re-connects. 183 Where is the HOST_ID? (which protocol, which field): If the HOST_ID 184 is put at the IP level, all packets will have to bear the 185 identifier. If it is put at a higher connection-oriented level, 186 the identifier is only needed once in the session establishment 187 phase (for instance TCP three-way-handshake), then, all packets 188 received in this session will be attributed to the HOST_ID 189 designated during the session opening. 191 Who puts the HOST_ID? For almost all the analyzed solutions, the 192 address sharing function injects the HOST_ID. When there are 193 several address sharing functions in the data path, we describe 194 to what extent the proposed solution is efficient. Another 195 option to avoid potential performance degradation is to let the 196 host inject its HOST_ID but the address sharing function will 197 check its content (just like an IP anti-spoofing function). 199 What are the security considerations? Security considerations are 200 common to all analyzed solutions (see Section 6). Privacy- 201 related aspects are discussed in Section 4. 203 2.1. IPv6 May Also Be Concerned 205 Some of the issues mentioned in Section 2 are independent of IPv4 vs. 206 IPv6. Even in IPv6, address sharing can be used for a variety of 207 reasons (e.g., to hide network topology, to defeat hosts from 208 offering network services directly, etc.). 210 A solution to reveal HOST_ID is also needed in IPv6 deployment. 212 3. Solutions Analysis 214 3.1. Requirements 216 Whatever the channel used to convey the HOST_ID, the following 217 requirements are to be met: 219 Uniqueness of identifiers in HOST_ID: It is RECOMMENDED that 220 HOST_IDs be limited to providing local uniqueness rather than 221 global uniqueness. 223 Refresh rate of HOST_ID: Address sharing function SHOULD NOT use 224 permanent HOST_ID values. 226 Manipulate HOST_IDs: Address sharing function SHOULD be able to 227 strip, re-write and add HOST_ID fields. 229 Interference between HOST_IDs: An address sharing function, able to 230 inject HOST_IDs in several layers, SHOULD reveal subsets of the 231 same information (e.g., full IP address, lower 16 bits of IP 232 address, etc.). 234 3.2. Synthesis 236 The following Table 1 summarizes the approaches analyzed in this 237 document. 239 o "Success ratio" indicates the ratio of successful communications 240 when the option is used. Provided figures are inspired from the 241 results documented in [Options]. 242 o "Deployable today" indicates if the solution can be generalized 243 without any constraint on current architectures and practices. 244 o "Possible Perf Impact" indicates the level of expected performance 245 degradation. The rationale behind the indicated potential 246 performance degradation is whether the injection requires some 247 treatment at the IP level or not. 249 o "OS TCP/IP Modif" indicates whether a modification of the OS 250 TCP/IP stack is required at the server side. 252 +------+------+-------+-------+-------+------+-----+------+ 253 | IP | TCP | IP-ID | HTTP | Proxy | Port | HIP | ICMP | 254 |Option|Option| | Header| | Set | | | 255 | | | | (XFF) | | | | | 256 ----------+------+------+-------+-------+-------+------+-----+------+ 257 UDP | Yes | No | Yes | No | No | Yes | | Yes | 258 ----------+------+------+-------+-------+-------+------+-----+------+ 259 TCP | Yes | Yes | Yes | No | Yes | Yes | | Yes | 260 ----------+------+------+-------+-------+-------+------+-----+------+ 261 HTTP | Yes | Yes | Yes | Yes | Yes | Yes | | Yes | 262 ----------+------+------+-------+-------+-------+------+-----+------+ 263 Encrypted | Yes | Yes | Yes | No | Yes | Yes | | Yes | 264 Traffic | | | | | | | | | 265 ----------+------+------+-------+-------+-------+------+-----+------+ 266 Success | 30% | 99% | 100% | 100% | Low | 100% |Low | ~100%| 267 Ratio | | | | | | | | (6) | 268 ----------+------+------+-------+-------+-------+------+-----+------+ 269 Possible | High | Med | Low | Med | High | No | N/A | High | 270 Perf | | to | to | to | | | | | 271 Impact | | High | Med | High | | | | | 272 ----------+------+------+-------+-------+-------+------+-----+------+ 273 OS TCP/IP | Yes | Yes | Yes | No | No | No | | Yes | 274 Modif | | | | | | | | | 275 ----------+------+------+-------+-------+-------+------+-----+------+ 276 Deployable| Yes | Yes | Yes | Yes | No | Yes | No | Yes | 277 Today | | | | | | | | | 278 ----------+------+------+-------+-------+-------+------+-----+------+ 279 Notes | | | (1) | (2) | | (1) | (4) | (7) | 280 | | | | | | (3) | (5) | | 281 ----------+------+------+-------+-------+-------+------+-----+------+ 283 Notes: 285 (1) Requires mechanism to advertise NAT is participating in this 286 scheme (e.g., DNS PTR record). 287 (2) This solution is widely deployed. 288 (3) When the port set is not advertised, the solution is less 289 efficient for third-party services. 290 (4) Requires the client and the server to be HIP-compliant and HIP 291 infrastructure to be deployed. 292 (5) If the client and the server are HIP-enabled, the address 293 sharing function does not need to insert a host-hint. If the 294 client is not HIP-enabled, designing the device that performs 295 address sharing to act as a UDP/TCP-HIP relay is not viable. 296 (6) Implementation-specific. 297 (7) The solution is inefficient in various scenarios as discussed 298 in Section 3. 300 Figure 1: Table 1: Summary of analyzed solutions. 302 According to the above table and the analysis elaborated in 303 Appendix A: 305 o IP Option, IP-ID and Proxy Protocol proposals are broken; 307 o HIP is not largely deployed; 309 o The use of Port Set may contradict the port randomization 310 [RFC6056] requirement identified in [RFC6269]. This solution can 311 be used by a service provider for the delivery of its own service 312 offerings relying on implicit identification. 314 o XFF is de facto standard deployed and supported in operational 315 networks (e.g., HTTP Severs, Load-Balancers, etc.). 317 o From an application standpoint, the TCP Option is superior to XFF/ 318 Forwarded-For since it is not restricted to HTTP. Nevertheless 319 XFF/Forwarded-For is compatible with the presence of address 320 sharing and load-balancers in the communication path. To provide 321 a similar functionality, the TCP Option may be extended to allow 322 conveying a list of IP addresses and port numbers to not lose the 323 source IP address in the presence of load-balancers. Another 324 alternative is to combine the usage of both the HOST_ID TCP Option 325 and XFF/Forwarded-For. Extending TCP is still possible as 326 analyzed in [ExtendTCP]. 328 3.3. Recommendation 330 Taking into account the analysis above and [RFC6269] context, the 331 following recommendation is made to mitigate the problem formulated 332 in Section 2: 334 An address sharing function SHOULD support HOST_ID TCP Option 335 (Appendix A.5). 337 4. HOST_ID and Privacy 339 IP address sharing is motivated by a number of different factors. 340 For years, many network operators have conserved the use of public 341 IPv4 addresses by making use of Customer Premises Equipment (CPE) 342 that assigns a single public IPv4 address to all hosts within the 343 customer's local area network and uses NAT [RFC3022] to translate 344 between locally unique private IPv4 addresses and the CPE's public 345 address. With the exhaustion of IPv4 address space, address sharing 346 between customers on a much larger scale is likely to become much 347 more prevalent. While many individual users are unaware of and 348 uninvolved in decisions about whether their unique IPv4 addresses get 349 revealed when they send data via IP, some users realize privacy 350 benefits associated with IP address sharing, and some may even take 351 steps to ensure that NAT functionality sits between them and the 352 public Internet. IP address sharing makes the actions of all users 353 behind the NAT function unattributable to any single host, creating 354 room for abuse but also providing some identity protection for non- 355 abusive users who wish to transmit data with reduced risk of being 356 uniquely identified. 358 The proposals considered in this document add a measure of uniqueness 359 back to hosts that share a public IP address. The extent of that 360 uniqueness depends on which information is included in the HOST_ID. 362 The volatility of the HOST_ID information is similar to the source IP 363 address: a distinct HOST_ID may be used by the address sharing 364 function when the host reboots or gets a new internal IP address. As 365 with persistent IP addresses, persistent HOST_IDs facilitate user 366 tracking over time. 368 As a general matter, the HOST_ID proposals do not seek to make hosts 369 any more identifiable than they would be if they were using a public, 370 non-shared IP address. However, depending on the solution proposal, 371 the addition of HOST_ID information may allow a device to be 372 fingerprinted more easily than it otherwise would be. Should 373 multiple solutions be combined (e.g., TCP Option and XFF) that 374 include different pieces of information in the HOST_ID, 375 fingerprinting may become even easier. 377 The trust placed in the information conveyed in the HOST_ID is likely 378 to be the same as for current practices with source IP addresses. In 379 that sense, a HOST_ID can be spoofed as this is also the case for 380 spoofing an IP address. Furthermore, users of network-based 381 anonymity services (like Tor) may be capable of stripping HOST_ID 382 information before it reaches its destination. 384 HOST_ID specification document(s) SHOULD explain the privacy impact 385 of the solutions they specify, including the extent of HOST_ID 386 uniqueness and persistence, assumptions made about the lifetime of 387 the HOST_ID, whether and how the HOST_ID can be obfuscated or 388 recycled, and the impact of the use of the HOST_ID on device or 389 implementation fingerprinting. [I-D.iab-privacy-considerations] 390 provides further guidance. 392 For more discussion about privacy, refer to [RFC6462]. 394 5. IANA Considerations 396 This document does not require any action from IANA. 398 6. Security Considerations 400 The same security concerns apply for the injection of an IP option, 401 TCP Option and application-related content (e.g., XFF) by the address 402 sharing device. If the server trusts the content of the HOST_ID 403 field, a third party user can be impacted by a misbehaving user to 404 reveal a "faked" HOST_ID (e.g., original IP address). 406 HOST_ID may be used to leak information about the internal structure 407 of a network behind an address sharing function. If this behavior is 408 undesired for the network administrator, the address sharing function 409 can be configured to strip any existing HOST_ID in received packets 410 from internal hosts. 412 HOST_ID specification documents SHOULD elaborate further on threats 413 inherent to each individual solution to convey the HOST_ID (e.g., use 414 of the IP-ID field to count hosts behind a NAT [Count]). 416 7. Acknowledgments 418 Many thanks to D. Wing and C. Jacquenet for their review, comments 419 and inputs. 421 Thanks also to P. McCann, T. Tsou, Z. Dong, B. Briscoe, T. Taylor, M. 422 Blanchet, D. Wing and A. Yourtchenko for the discussions in Prague. 424 Some of the issues related to defining a new TCP Option have been 425 raised by L. Eggert. 427 Privacy text is provided by A. Cooper. 429 8. References 431 8.1. Normative References 433 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 434 September 1981. 436 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 437 Requirement Levels", BCP 14, RFC 2119, March 1997. 439 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 440 Address Translator (Traditional NAT)", RFC 3022, 441 January 2001. 443 [RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport- 444 Protocol Port Randomization", BCP 156, RFC 6056, 445 January 2011. 447 8.2. Informative References 449 [Count] "A technique for counting NATted hosts", 450 . 452 [ExtendTCP] 453 Honda, M., Nishida, Y., Raiciu, C., Greenhalgh, A., 454 Handley, M. and H. Tokuda,, "Is it still possible to 455 extend TCP?", November 2011, 456 . 458 [I-D.abdo-hostid-tcpopt-implementation] 459 Abdo, E., Boucadair, M., and J. Queiroz, "HOST_ID TCP 460 Options: Implementation & Preliminary Test Results", 461 draft-abdo-hostid-tcpopt-implementation-02 (work in 462 progress), January 2012. 464 [I-D.chen-intarea-v4-uid-header-option] 465 Wu, Y., Ji, H., Chen, Q., and T. ZOU), "IPv4 Header Option 466 For User Identification In CGN Scenario", 467 draft-chen-intarea-v4-uid-header-option-00 (work in 468 progress), March 2011. 470 [I-D.iab-privacy-considerations] 471 Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., and 472 J. Morris, "Privacy Considerations for Internet 473 Protocols", draft-iab-privacy-considerations-02 (work in 474 progress), March 2012. 476 [I-D.ietf-appsawg-http-forwarded] 477 Petersson, A. and M. Nilsson, "Forwarded HTTP Extension", 478 draft-ietf-appsawg-http-forwarded-01 (work in progress), 479 March 2012. 481 [I-D.ietf-intarea-ipv4-id-update] 482 Touch, J., "Updated Specification of the IPv4 ID Field", 483 draft-ietf-intarea-ipv4-id-update-04 (work in progress), 484 September 2011. 486 [I-D.wing-nat-reveal-option] 487 Yourtchenko, A. and D. Wing, "Revealing hosts sharing an 488 IP address using TCP option", 489 draft-wing-nat-reveal-option-03 (work in progress), 490 December 2011. 492 [I-D.yourtchenko-nat-reveal-ping] 493 Yourtchenko, A., "Revealing hosts sharing an IP address 494 using ICMP Echo Request", 495 draft-yourtchenko-nat-reveal-ping-00 (work in progress), 496 March 2012. 498 [Not_An_Option] 499 R. Fonseca, G. Porter, R. Katz, S. Shenker, and I. 500 Stoica,, "IP options are not an option", 2005, . 504 [Options] Alberto Medina, Mark Allman, Sally Floyd, "Measuring 505 Interactions Between Transport Protocols and Middleboxes", 506 2005, . 509 [Proxy] Tarreau, W., "The PROXY protocol", November 2010, . 512 [RFC2753] Yavatkar, R., Pendarakis, D., and R. Guerin, "A Framework 513 for Policy-based Admission Control", RFC 2753, 514 January 2000. 516 [RFC5201] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson, 517 "Host Identity Protocol", RFC 5201, April 2008. 519 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 520 NAT64: Network Address and Protocol Translation from IPv6 521 Clients to IPv4 Servers", RFC 6146, April 2011. 523 [RFC6269] Ford, M., Boucadair, M., Durand, A., Levis, P., and P. 524 Roberts, "Issues with IP Address Sharing", RFC 6269, 525 June 2011. 527 [RFC6302] Durand, A., Gashinsky, I., Lee, D., and S. Sheppard, 528 "Logging Recommendations for Internet-Facing Servers", 529 BCP 162, RFC 6302, June 2011. 531 [RFC6462] Cooper, A., "Report from the Internet Privacy Workshop", 532 RFC 6462, January 2012. 534 [Trusted_ISPs] 535 "Trusted XFF list", . 538 Appendix A. Detailed Solutions Analysis 540 A.1. Use the Identification Field of IP Header (IP-ID) 542 A.1.1. Description 544 IP-ID (Identification field of IP header) can be used to insert an 545 information which uniquely distinguishes a host among those sharing 546 the same IPv4 address. An address sharing function can re-write the 547 IP-ID field to insert a value unique to the host (16 bits are 548 sufficient to uniquely disambiguate hosts sharing the same IP 549 address). Note that this field is not altered by some NATs; hence 550 some side effects such as counting hosts behind a NAT as reported in 551 [Count]. 553 A variant of this approach relies upon the format of certain packets, 554 such as TCP SYN, where the IP-ID can be modified to contain a 16 bit 555 HOST_ID. Address sharing devices performing this function would 556 require to indicate they are performing this function out of band, 557 possibly using a special DNS record. 559 A.1.2. Analysis 561 This usage is not compliant with what is recommended in 562 [I-D.ietf-intarea-ipv4-id-update]. 564 A.2. Define an IP Option 566 A.2.1. Description 568 A solution alternative to convey the HOST_ID is to define an IP 569 option [RFC0791]. HOST_ID IP option can be inserted by the address 570 sharing function to uniquely distinguish a host among those sharing 571 the same IP address. An example of such option is documented in 572 [I-D.chen-intarea-v4-uid-header-option]. This IP option allows to 573 convey an IPv4 address, an IPv6 prefix, a GRE key, IPv6 Flow Label, 574 etc. 576 Another way for using IP option has been described in Section 4.6 of 577 [RFC3022]. 579 A.2.2. Analysis 581 Unlike the solution presented in Appendix A.5, this proposal can 582 apply for any transport protocol. Nevertheless, it is widely known 583 that routers (and other middleboxes) filter IP options. IP packets 584 with IP options can be dropped by some IP nodes. Previous studies 585 demonstrated that "IP Options are not an option" (Refer to 586 [Not_An_Option], [Options]). 588 As a conclusion, using an IP option to convey a host-hint is not 589 viable. 591 A.3. Assign Port Sets 593 A.3.1. Description 595 This solution does not require any action from the address sharing 596 function to disclose a host identifier. Instead of assuming all 597 transport ports are associated with one single host, each host under 598 the same external IP address is assigned a restricted port set. 599 These port sets are then advertised to remote servers using off-line 600 means. This announcement is not required for the delivery of 601 internal services (i.e., offered by the service provider deploying 602 the address sharing function) relying on implicit identification. 604 Port sets assigned to hosts may be static or dynamic. 606 Port set announcements to remote servers do not require to reveal the 607 identity of individual hosts but only to advertise the enforced 608 policy to generate non-overlapping port sets (e.g., the transport 609 space associated with an IP address is fragmented to contiguous 610 blocks of 2048 port numbers). 612 A.3.2. Analysis 614 The solution does not require defining new fields nor options; it is 615 policy-based. 617 The solution may contradict the port randomization as identified in 618 [RFC6269]. A mitigation would be to avoid assigning static port sets 619 to individual hosts. 621 The method is convenient for the delivery of services offered by the 622 service provider offering also the IP connectivity service. 624 A.4. Use ICMP 626 A.4.1. Description 628 Another alternative is to convey the HOST_ID using a separate 629 notification channel than the packets issued to invoke the service. 631 An implementation example is defined in 632 [I-D.yourtchenko-nat-reveal-ping]. This solution relies on a 633 mechanism where the address sharing function encapsulates the 634 necessary differentiating information into an ICMP Echo Request 635 packet that it sends in parallel with the initial session creation 636 (e.g., SYN). The information included in the ICMP Request Data 637 portion describes the five-tuples as seen on both of the sides of the 638 address sharing function. 640 A.4.2. Analysis 642 o This ICMP proposal is valid for both UDP and TCP. Address sharing 643 function may be configurable with the transport protocol which is 644 allowed to trigger those ICMP messages. 645 o A hint should be provided to the ultimate server (or intermediate 646 nodes) an ICMP Echo Request conveys a HOST_ID. This may be 647 implemented using magic numbers. 648 o Even if ICMP packets are blocked in the communication path, the 649 user connection does not have to be impacted. 650 o Some implementations requiring to delay the establishment of a 651 session until receiving the companion ICMP Echo Request, may lead 652 to some user experience degradation. 653 o Because of the presence of load-balancers in the path, the 654 ultimate server receiving the SYN packet may not be the one which 655 may receive the ICMP message conveying the HOST_ID. 656 o Because of the presence of load-balancers in the path, the port 657 number assigned by address sharing may be lost. Therefore the 658 mapping information conveyed in the ICMP may not be sufficient to 659 associate a SYN packet with a received ICMP. 660 o The proposal is not compatible with the presence of cascaded NAT. 661 o The ICMP proposal will add a traffic overhead for both the server 662 and the address sharing device. 663 o The ICMP proposal is similar to other mechanisms (e.g., syslog, 664 netflow) for reporting dynamic mappings to a mediation platform 665 (mainly for legal traceability purposes). Performance degradation 666 are likely to be experienced by address sharing functions because 667 ICMP messages are to be sent in particular for each new 668 instantiated mapping (and also even if the mapping exists). 669 o In some scenarios (e.g., Fixed-Mobile Convergence, Open WiFi, 670 etc.), HOST_ID should be interpreted by intermediate devices which 671 embed Policy Enforcement Points (PEP, [RFC2753]) responsible for 672 granting access to some services. These PEPs need to inspect all 673 received packets in order to find the companion (traffic) messages 674 to be correlated with ICMP messages conveying HOST_IDs. This 675 induces more complexity to these intermediate devices. 677 A.5. Define a TCP Option 679 A.5.1. Description 681 HOST_ID may be conveyed in a dedicated TCP Option. An example is 682 specified in [I-D.wing-nat-reveal-option] which defines a new TCP 683 Option called USER_HINT. This option encloses the TCP client's 684 identifier (e.g., the lower 16 bits of their IPv4 address, their VLAN 685 ID, VRF ID, subscriber ID). The address sharing device inserts this 686 TCP Option into the TCP SYN packet. 688 A.5.2. Analysis 690 Using a new TCP Option to convey the HOST_ID does not require any 691 modification to the applications but it is applicable only for TCP- 692 based applications. Applications relying on other transport 693 protocols are therefore left unsolved. 695 [I-D.wing-nat-reveal-option] discusses the interference with other 696 TCP Options. 698 The risk related to handling a new TCP Option is low as measured in 699 [Options]. [I-D.abdo-hostid-tcpopt-implementation] provides a 700 detailed implementation and experimentation report of HOST_ID TCP 701 Option. [I-D.abdo-hostid-tcpopt-implementation] investigated in 702 depth the impact of activation HOST_ID in host, address sharing 703 function and the enforcement of policies at the server side. 704 [I-D.abdo-hostid-tcpopt-implementation] reports a failure ratio of 705 0,103% among top 100000 websites. 707 Some downsides have been raised against defining a TCP Option to 708 reveal a host identity: 710 o Conveying an IP address in a TCP Option may be seen as a violation 711 of OSI layers but since IP addresses are already used for the 712 checksum computation, this is not seen as a blocking point. 713 Moreover, updated version of [I-D.wing-nat-reveal-option] does not 714 allow anymore to convey an IP address (the HOST_ID is encoded in 715 16bits). 717 o TCP Option space is limited, and might be consumed by the TCP 718 client. Earlier versions of [I-D.wing-nat-reveal-option] discuss 719 two approaches to sending the HOST_ID: sending the HOST_ID in the 720 TCP SYN (which consumes more bytes in the TCP header of the TCP 721 SYN) and sending the HOST_ID in a TCP ACK (which consumes only two 722 bytes in the TCP SYN). Content providers may find it more 723 desirable to receive the HOST_ID in the TCP SYN, as that more 724 closely preserves the HOST_ID received in the source IP address as 725 per current practices. It is more complicated to implement 726 sending the HOST_ID in a TCP ACK, as it can introduce MTU issues 727 if the ACK packet also contains TCP data, or a TCP segment is 728 lost. The latest specification of the HOST_ID TCP Option, 729 documented at [I-D.wing-nat-reveal-option], allows only to enclose 730 the HOST_ID in the TCP SYN packet. 732 o When there are several NATs in the path, the original HOST_ID may 733 be lost. In such case, the procedure may not be efficient. 735 o Interference with current usages such as X-Forwarded-For (see 736 Appendix A.8) should be elaborated to specify the behavior of 737 servers when both options are used; in particular specify which 738 information to use: the content of the TCP Option or what is 739 conveyed in the application headers. 741 o When load-balancers or proxies are in the path, this option does 742 not allow to preserve the original source IP address and source 743 port. Preserving such information is required for logging 744 purposes for instance (e.g., [RFC6302]). 745 [I-D.abdo-hostid-tcpopt-implementation] defines a TCP Option which 746 allows to reveal various combinations of source information (e.g., 747 source port, source port and source IP address, source IPv6 748 prefix, etc.). 750 More discussion about issues raised when extending TCP can be found 751 at [ExtendTCP]. 753 A.6. PROXY Protocol 755 A.6.1. Description 757 The solution, referred to as Proxy Protocol [Proxy], does not require 758 any application-specific knowledge. The rationale behind this 759 solution is to prepend each connection with a line reporting the 760 characteristics of the other side's connection as shown in the 761 example depicted in Figure 2: 763 PROXY TCP4 192.0.2.1 192.0.2.15 56324 443\r\n 765 Figure 2: Example of PROXY conection report 767 Upon receipt of a message conveying this line, the server removes the 768 line. The line is parsed to retrieve the transported protocol. The 769 content of this line is recorded in logs and used to enforce 770 policies. 772 A.6.2. Analysis 774 This solution can be deployed in a controlled environment but it can 775 not be deployed to all access services available in the Internet. If 776 the remote server does not support the Proxy Protocol, the session 777 will fail. Other complications will raise due to the presence of 778 firewalls for instance. 780 As a consequence, this solution is broken and can not be recommended. 782 A.7. Host Identity Protocol (HIP) 784 A.7.1. Description 786 [RFC5201] specifies an architecture which introduces a new namespace 787 to convey an identity information. 789 A.7.2. Analysis 791 This solution requires both the client and the server to support HIP 792 [RFC5201]. Additional architectural considerations are to be taken 793 into account such as the key exchanges, etc. 795 If the address sharing function is required to act as a UDP/TCP-HIP 796 relay, this is not a viable option. 798 A.8. Inject Application Headers 800 A.8.1. Description 802 Another option is to not require any change at the transport nor the 803 IP levels but to convey at the application payload the required 804 information which will be used to disambiguate hosts. This format 805 and the related semantics depend on its application (e.g., HTTP, SIP, 806 SMTP, etc.). 808 For HTTP, the X-Forwarded-For (XFF) or Forwarded-For 809 ([I-D.ietf-appsawg-http-forwarded]) headers can be used to display 810 the original IP address when an address sharing device is involved. 811 Service Providers operating address sharing devices can enable the 812 feature of injecting the XFF header which will enclose the original 813 IPv4 address or the IPv6 prefix part (see the example shown in 814 Figure 3). The address sharing device has to strip all included XFF 815 headers before injecting their own. Servers may rely on the contents 816 of this field to enforce some policies such as blacklisting 817 misbehaving users. Note that XFF can also be logged by some servers 818 (this is for instance supported by Apache). 820 Forwarded: for=192.0.2.1,for=[2001:db8::1] 821 Forwarded: proto=https;by=192.0.2.15 823 Figure 3: Example of Forwarded-For 825 A.8.2. Analysis 827 Not all applications impacted by the address sharing can support the 828 ability to disclose the original IP address. Only a subset of 829 protocols (e.g., HTTP) can rely on this solution. 831 For the HTTP case, to prevent users injecting invalid HOST_IDs, an 832 initiative has been launched to maintain a list of trusted ISPs using 833 XFF: See for example the list available at: [Trusted_ISPs] of trusted 834 ISPs as maintained by Wikipedia. If an address sharing device is on 835 the trusted XFF ISPs list, users editing Wikipedia located behind the 836 address sharing device will appear to be editing from their 837 "original" IP address and not from the NATed IP address. If an 838 offending activity is detected, individual hosts can be blacklisted 839 instead of all hosts sharing the same IP address. 841 XFF header injection is a common practice of load balancers. When a 842 load balancer is in the path, the original content of any included 843 XFF header should not be stripped. Otherwise the information about 844 the "origin" IP address will be lost. 846 When several address sharing devices are crossed, XFF header can 847 convey the list of IP addresses (e.g., Figure 3). The origin HOST_ID 848 can be exposed to the target server. 850 XFF also introduces some implementation complexity if the HTTP packet 851 is at or close to the MTU size. 853 It has been reported that some "poor" implementation may encounter 854 some parsing issues when injecting XFF header. 856 For encrypted HTTP traffic, injecting XFF header may be broken. 858 Authors' Addresses 860 Mohamed Boucadair 861 France Telecom 862 Rennes, 35000 863 France 865 Email: mohamed.boucadair@orange.com 867 Joe Touch 868 USC/ISI 870 Email: touch@isi.edu 872 Pierre Levis 873 France Telecom 874 Caen, 14000 875 France 877 Email: pierre.levis@orange.com 879 Reinaldo Penno 880 Cisco 881 USA 883 Email: repenno@cisco.com