idnits 2.17.1 draft-ietf-intarea-nat-reveal-analysis-01.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 (March 06, 2012) is 4433 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 (-10) exists of draft-ietf-appsawg-http-forwarded-00 == Outdated reference: A later version (-10) exists of draft-ietf-behave-lsn-requirements-05 == 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: September 7, 2012 USC/ISI 6 P. Levis 7 France Telecom 8 R. Penno 9 Juniper Networks 10 March 06, 2012 12 Analysis of Solution Candidates to Reveal a Host Identifier in Shared 13 Address Deployments 14 draft-ietf-intarea-nat-reveal-analysis-01 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 September 7, 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. Problem to Be Solved . . . . . . . . . . . . . . . . . . . 4 66 1.2. IPv6 May Also Be Concerned . . . . . . . . . . . . . . . . 5 67 1.3. Purpose and Scope . . . . . . . . . . . . . . . . . . . . 5 68 2. Synthesis . . . . . . . . . . . . . . . . . . . . . . . . . . 6 69 3. Solutions Analysis . . . . . . . . . . . . . . . . . . . . . . 9 70 3.1. Use the Identification Field of IP Header (IP-ID) . . . . 9 71 3.1.1. Description . . . . . . . . . . . . . . . . . . . . . 9 72 3.1.2. Analysis . . . . . . . . . . . . . . . . . . . . . . . 9 73 3.2. Define an IP Option . . . . . . . . . . . . . . . . . . . 9 74 3.2.1. Description . . . . . . . . . . . . . . . . . . . . . 9 75 3.2.2. Analysis . . . . . . . . . . . . . . . . . . . . . . . 9 76 3.3. Assign Port Sets . . . . . . . . . . . . . . . . . . . . . 10 77 3.3.1. Description . . . . . . . . . . . . . . . . . . . . . 10 78 3.3.2. Analysis . . . . . . . . . . . . . . . . . . . . . . . 10 79 3.4. Use ICMP . . . . . . . . . . . . . . . . . . . . . . . . . 10 80 3.4.1. Description . . . . . . . . . . . . . . . . . . . . . 10 81 3.4.2. Analysis . . . . . . . . . . . . . . . . . . . . . . . 11 82 3.5. Define a TCP Option . . . . . . . . . . . . . . . . . . . 11 83 3.5.1. Description . . . . . . . . . . . . . . . . . . . . . 12 84 3.5.2. Analysis . . . . . . . . . . . . . . . . . . . . . . . 12 85 3.6. PROXY Protocol . . . . . . . . . . . . . . . . . . . . . . 13 86 3.6.1. Description . . . . . . . . . . . . . . . . . . . . . 13 87 3.6.2. Analysis . . . . . . . . . . . . . . . . . . . . . . . 14 88 3.7. Host Identity Protocol (HIP) . . . . . . . . . . . . . . . 14 89 3.7.1. Description . . . . . . . . . . . . . . . . . . . . . 14 90 3.7.2. Analysis . . . . . . . . . . . . . . . . . . . . . . . 14 91 3.8. Inject Application Headers . . . . . . . . . . . . . . . . 14 92 3.8.1. Description . . . . . . . . . . . . . . . . . . . . . 14 93 3.8.2. Analysis . . . . . . . . . . . . . . . . . . . . . . . 15 94 4. HOST_ID and Privacy . . . . . . . . . . . . . . . . . . . . . 15 95 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 96 6. Security Considerations . . . . . . . . . . . . . . . . . . . 17 97 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 98 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 99 8.1. Normative References . . . . . . . . . . . . . . . . . . . 17 100 8.2. Informative References . . . . . . . . . . . . . . . . . . 17 101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 103 1. Introduction 105 As reported in [RFC6269], several issues are encountered when an IP 106 address is shared among several subscribers. Examples of such issues 107 are listed below: 109 o Implicit identification (Section 13.2 of [RFC6269]) 110 o SPAM (Section 13.3 of [RFC6269]) 111 o Blacklisting a mis-behaving user (Section 13.1 of [RFC6269]) 112 o Redirect users with infected machines to a dedicated portal 113 (Section 5.1 of [RFC6269]) 115 The sole use of the IPv4 address is not sufficient to uniquely 116 distinguish a host. As a mitigation, it is tempting to investigate 117 means which would help in disclosing an information to be used by the 118 remote server as a means to uniquely disambiguate packets of hosts 119 using the same IPv4 address. 121 The risk of not mitigating these issues are: OPEX increase for IP 122 connectivity service providers (costs induced by calls to a hotline), 123 revenue loss for content providers (loss of users audience), 124 customers unsatisfaction (low quality of experience, service 125 segregation, etc.). 127 1.1. Problem to Be Solved 129 Observation: Today, some servers use the source IPv4 address as an 130 identifier to treat some incoming connections differently. 131 Tomorrow, due to the introduction of CGNs (e.g., NAT44 132 [I-D.ietf-behave-lsn-requirements], NAT64 [RFC6146]), that 133 address will be shared. In particular, when a server 134 receives packets from the same source address, because this 135 address is shared, the server does not know which host is 136 the sending host. 137 Objective: The server should be able to sort out the packets by 138 sending host. 139 Requirement: The server must have extra information than the source 140 IP address to differentiate the sending host. We call 141 HOST_ID this information. 143 For all solutions analyzed, we provide answers to the following 144 questions: 146 What is the HOST_ID? It must be unique to each host under the same 147 IP address. It does not need to be globally unique. Of course, 148 the combination of the (public) IP source address and the 149 identifier (i.e., HOST_ID) ends up being relatively unique. As 150 unique as today's 32-bit IPv4 addresses which, today, can change 151 when a host re-connects. 153 Where is the HOST_ID? (which protocol, which field): If the HOST_ID 154 is put at the IP level, all packets will have to bear the 155 identifier. If it is put at a higher connection-oriented level, 156 the identifier is only needed once in the session establishment 157 phase (for instance TCP three-way-handshake), then, all packets 158 received in this session will be attributed to the HOST_ID 159 designated during the session opening. 161 Who puts the HOST_ID? For almost all the analyzed solutions, the 162 address sharing function injects the HOST_ID. When there are 163 several address sharing functions in the data path, we describe 164 to what extent the proposed solution is efficient. Another 165 option to avoid potential performance degradation is to let the 166 host inject its HOST_ID but the address sharing function will 167 check its content (just like an IP anti-spoofing function). 169 What are the security considerations? Security considerations are 170 common to all analyzed solutions (see Section 6). Privacy- 171 related aspect are discussed in Section 4. 173 1.2. IPv6 May Also Be Concerned 175 Some of the issues mentioned in Section 1.1 are independent of IPv4 176 vs. IPv6. Even in IPv6, address sharing can be used for a variety of 177 reasons (e.g., to hide network topology, to defeat hosts from 178 offering network services directly, etc.). 180 A solution to reveal HOST_ID is also needed in IPv6 deployment. 182 1.3. Purpose and Scope 184 The purpose of this document is not to argue in favor of mandating 185 the use of a HOST_ID but to identify encountered issues, proposed 186 solutions and their limitations. 188 The purpose of this document is to analyze a set of solution 189 candidates and to assess to what extent they solve the problem (see 190 Section 1.1). Below are listed the solutions analyzed in the 191 document: 193 o Use the Identification field of IP header (denoted as IP-ID, 194 Section 3.1). 195 o Define a new IP option (Section 3.2). 196 o Assign port sets (Section 3.3). 198 o Use ICMP (Section 3.3). 199 o Define a new TCP Option (Section 3.5). 200 o Enable Proxy Protocol ( (Section 3.6)). 201 o Activate HIP (Section 3.7). 202 o Inject application headers (Section 3.8). 204 2. Synthesis 206 The following Table 1 summarizes the approaches analyzed in this 207 document. 209 o "Success ratio" indicates the ratio of successful communications 210 when the option is used. Provided figures are inspired from the 211 results documented in [Options]. 212 o "Deployable today" indicates if the solution can be generalized 213 without any constraint on current architectures and practices. 214 o "Possible Perf Impact" indicates the level of expected performance 215 degradation. The rationale behind the indicated potential 216 performance degradation is whether the injection requires some 217 treatment at the IP level or not. 218 o "OS TCP/IP Modif" indicates whether a modification of the OS 219 TCP/IP stack is required at the server side. 221 +------+------+-------+-------+-------+------+-----+------+ 222 | IP | TCP | IP-ID | HTTP | Proxy | Port | HIP | ICMP | 223 |Option|Option| | Header| | Set | | | 224 | | | | (XFF) | | | | | 225 ----------+------+------+-------+-------+-------+------+-----+------+ 226 UDP | Yes | No | Yes | No | No | Yes | | Yes | 227 ----------+------+------+-------+-------+-------+------+-----+------+ 228 TCP | Yes | Yes | Yes | No | Yes | Yes | | Yes | 229 ----------+------+------+-------+-------+-------+------+-----+------+ 230 HTTP | Yes | Yes | Yes | Yes | Yes | Yes | | Yes | 231 ----------+------+------+-------+-------+-------+------+-----+------+ 232 Encrypted | Yes | Yes | Yes | No | Yes | Yes | | Yes | 233 Traffic | | | | | | | | | 234 ----------+------+------+-------+-------+-------+------+-----+------+ 235 Success | 30% | 99% | 100% | 100% | Low | 100% |Low | ~100%| 236 Ratio | | | | | | | | (6) | 237 ----------+------+------+-------+-------+-------+------+-----+------+ 238 Possible | High | Med | Low | Med | High | No | N/A | High | 239 Perf | | to | to | to | | | | | 240 Impact | | High | Med | High | | | | | 241 ----------+------+------+-------+-------+-------+------+-----+------+ 242 OS TCP/IP | Yes | Yes | Yes | No | No | No | | Yes | 243 Modif | | | | | | | | | 244 ----------+------+------+-------+-------+-------+------+-----+------+ 245 Deployable| Yes | Yes | Yes | Yes | No | Yes | No | Yes | 246 Today | | | | | | | | | 247 ----------+------+------+-------+-------+-------+------+-----+------+ 248 Notes | | | (1) | (2) | | (1) | (4) | (7) | 249 | | | | | | (3) | (5) | | 250 ----------+------+------+-------+-------+-------+------+-----+------+ 252 Notes: 254 (1) Requires mechanism to advertise NAT is participating in this 255 scheme (e.g., DNS PTR record). 256 (2) This solution is widely deployed. 257 (3) When the port set is not advertised, the solution is less 258 efficient for third-party services. 259 (4) Requires the client and the server to be HIP-compliant and HIP 260 infrastructure to be deployed. 261 (5) If the client and the server are HIP-enabled, the address 262 sharing function does not need to insert a host-hint. If the 263 client is not HIP-enabled, designing the device that performs 264 address sharing to act as a UDP/TCP-HIP relay is not viable. 265 (6) Implementation specific. 266 (7) The solution is inefficient is various scenarios as discussed 267 in Section 3. 269 Figure 1: Table 1: Summary of analyzed solutions. 271 According to the above table and the analysis elaborated in 272 Section 3: 274 o IP Option, IP-ID and Proxy Protocol proposals are broken; 276 o HIP is not largely deployed; 278 o The use of Port Set may contradict the port randomization 279 [RFC6056] requirement identified in [RFC6269]. This solution can 280 be used by a service provider for the delivery of its own service 281 offerings relying on implicit identification. 283 o XFF is de facto standard deployed and supported in operational 284 networks (e.g., HTTP Severs, Load-Balancers, etc.). 286 o From an application standpoint, the TCP Option is superior to XFF 287 since it is not restricted to HTTP. Nevertheless XFF is 288 compatible with the presence of address sharing and load-balancers 289 in the communication path. To provide a similar functionality, 290 the TCP Option may be extended to allow conveying a list of IP 291 addresses and port numbers to not lose the source IP address in 292 the presence of load-balancers. Another alternative is to combine 293 the usage of both the HOST_ID TCP Option and XFF. Note that TCP 294 Option requires the modification of the OS TCP/IP stack of remote 295 servers; which can be seen as a blocking point. 297 For all HOST_ID proposals, the following recommendations are made: 299 Uniqueness of identifiers in HOST_ID: It is RECOMMENDED that 300 HOST_IDs be limited to providing local uniqueness rather than 301 global uniqueness. 303 Refresh rate of HOST_ID: Address sharing function SHOULD NOT use 304 permanent HOST_ID values. 306 Manipulate HOST_IDs: Address sharing function SHOULD be able to 307 strip, re-write and add HOST_ID fields. 309 Interference between HOST_IDs: An address sharing function, able to 310 inject HOST_IDs in several layers, SHOULD reveal subsets of the 311 same information (e.g., full IP address, lower 16 bits of IP 312 address, etc.). 314 3. Solutions Analysis 316 3.1. Use the Identification Field of IP Header (IP-ID) 318 3.1.1. Description 320 IP-ID (Identification field of IP header) can be used to insert an 321 information which uniquely distinguishes a host among those sharing 322 the same IPv4 address. An address sharing function can re-write the 323 IP-ID field to insert a value unique to the host (16 bits are 324 sufficient to uniquely disambiguate hosts sharing the same IP 325 address). Note that this field is not altered by some NATs; hence 326 some side effects such as counting hosts behind a NAT as reported in 327 [Count]. 329 A variant of this approach relies upon the format of certain packets, 330 such as TCP SYN, where the IP-ID can be modified to contain a 16 bit 331 HOST_ID. Address sharing devices performing this function would 332 require to indicate they are performing this function out of band, 333 possibly using a special DNS record. 335 3.1.2. Analysis 337 This usage is not compliant with what is recommended in 338 [I-D.ietf-intarea-ipv4-id-update]. 340 3.2. Define an IP Option 342 3.2.1. Description 344 A solution alternative to convey the HOST_ID is to define an IP 345 option [RFC0791]. HOST_ID IP option can be inserted by the address 346 sharing function to uniquely distinguish a host among those sharing 347 the same IP address. An example of such option is documented in 348 [I-D.chen-intarea-v4-uid-header-option]. This IP option allows to 349 convey an IPv4 address, an IPv6 prefix, a GRE key, IPv6 Flow Label, 350 etc. 352 Another way for using IP option has been described in Section 4.6 of 353 [RFC3022]. 355 3.2.2. Analysis 357 Unlike the solution presented in Section 3.5, this proposal can apply 358 for any transport protocol. Nevertheless, it is widely known that 359 routers (and other middleboxes) filter IP options. IP packets with 360 IP options can be dropped by some IP nodes. Previous studies 361 demonstrated that "IP Options are not an option" (Refer to 363 [Not_An_Option], [Options]). 365 As a conclusion, using an IP option to convey a host-hint is not 366 viable. 368 3.3. Assign Port Sets 370 3.3.1. Description 372 This solution does not require any action from the address sharing 373 function to disclose a host identifier. Instead of assuming all 374 transport ports are associated with one single host, each host under 375 the same external IP address is assigned a restricted port set. 376 These port sets are then advertised to remote servers using off-line 377 means. This announcement is not required for the delivery of 378 internal services (i.e., offered by the service provider deploying 379 the address sharing function) relying on implicit identification. 381 Port sets assigned to hosts may be static or dynamic. 383 Port set announcements to remote servers do not require to reveal the 384 identity of individual hosts but only to advertise the enforced 385 policy to generate non-overlapping port sets (e.g., the transport 386 space associated with an IP address is fragmented to contiguous 387 blocks of 2048 port numbers). 389 3.3.2. Analysis 391 The solution does not require defining new fields nor options; it is 392 policy-based. 394 The solution may contradict the port randomization as identified in 395 [RFC6269]. A mitigation would be to avoid assigning static port sets 396 to individual hosts. 398 The method is convenient for the delivery of services offered by the 399 service provider offering also the IP connectivity service. 401 3.4. Use ICMP 403 3.4.1. Description 405 Another alternative is to convey the HOST_ID using a separate 406 notification channel than the packets issued to invoke the service. 408 An implementation example is defined in 409 [I-D.yourtchenko-nat-reveal-ping]. This solution relies on a 410 mechanism where the address sharing function encapsulates the 411 necessary differentiating information into an ICMP Echo Request 412 packet that it sends in parallel with the initial session creation 413 (e.g., SYN). The information included in the ICMP Request Data 414 portion describes the five-tuples as seen on both of the sides of the 415 address sharing function. 417 3.4.2. Analysis 419 o This ICMP proposal is valid for both UDP and TCP. Address sharing 420 function may be configurable with the transport protocol which is 421 allowed to trigger those ICMP messages. 422 o A hint should be provided to the ultimate server (or intermediate 423 nodes) an ICMP Echo Request conveys a HOST_ID. This may be 424 implemented using magic numbers. 425 o Even if ICMP packets are blocked in the communication path, the 426 user connection does not have to be impacted. 427 o Some implementations requiring to delay the establishment of a 428 session until receiving the companion ICMP Echo Request, may lead 429 to some user experience degradation. 430 o Because of the presence of load-balancers in the path, the 431 ultimate server receiving the SYN packet may not be the one which 432 may receive the ICMP message conveying the HOST_ID. 433 o Because of the presence of load-balancers in the path, the port 434 number assigned by address sharing may be lost. Therefore the 435 mapping information conveyed in the ICMP may not be sufficient to 436 associate a SYN packet with a received ICMP. 437 o The proposal is not compatible with the presence of cascaded NAT. 438 o The ICMP proposal will add a traffic overhead for both the server 439 and the address sharing device. 440 o The ICMP proposal is similar to other mechanisms (e.g., syslog, 441 netflow) for reporting dynamic mappings to a mediation platform 442 (mainly for legal traceability purposes). Performance degradation 443 are likely to be experienced by address sharing functions because 444 ICMP messages are to be sent in particular for each new 445 instantiated mapping (and also even if the mapping exists). 446 o In some scenarios (e.g., Fixed-Mobile Convergence, Open WiFi, 447 etc.), HOST_ID should be interpreted by intermediate devices which 448 embed Policy Enforcement Points (PEP, [RFC2753]) responsible for 449 granting access to some services. These PEPs need to inspect all 450 received packets in order to find the companion (traffic) messages 451 to be correlated with ICMP messages conveying HOST_IDs. This 452 induces more complexity to these intermediate devices. 454 3.5. Define a TCP Option 455 3.5.1. Description 457 HOST_ID may be conveyed in a dedicated TCP Option. An example is 458 specified in [I-D.wing-nat-reveal-option] which defines a new TCP 459 Option called USER_HINT. This option encloses the TCP client's 460 identifier (e.g., the lower 16 bits of their IPv4 address, their VLAN 461 ID, VRF ID, subscriber ID). The address sharing device inserts this 462 TCP Option into the TCP SYN packet. 464 3.5.2. Analysis 466 Using a new TCP Option to convey the HOST_ID does not require any 467 modification to the applications but it is applicable only for TCP- 468 based applications. Applications relying on other transport 469 protocols are therefore left unsolved. 471 [I-D.wing-nat-reveal-option] discusses the interference with other 472 TCP Options. 474 The risk related to handling a new TCP Option is low as measured in 475 [Options]. [I-D.abdo-hostid-tcpopt-implementation] provides a 476 detailed implementation and experimentation report of HOST_ID TCP 477 Option. [I-D.abdo-hostid-tcpopt-implementation] investigated in 478 depth the impact of activation HOST_ID in host, address sharing 479 function and the enforcement of policies at the server side. 480 [I-D.abdo-hostid-tcpopt-implementation] reports a failure ratio of 481 0,103% among top 100000 websites. 483 Some downsides have been raised against defining a TCP Option to 484 reveal a host identity: 486 o Conveying an IP address in a TCP Option may be seen as a violation 487 of OSI layers but since IP addresses are already used for the 488 checksum computation, this is not seen as a blocking point. 489 Moreover, updated version of [I-D.wing-nat-reveal-option] does not 490 allow anymore to convey an IP address (the HOST_ID is encoded in 491 16bits). 493 o TCP Option space is limited, and might be consumed by the TCP 494 client. Earlier versions of [I-D.wing-nat-reveal-option] discuss 495 two approaches to sending the HOST_ID: sending the HOST_ID in the 496 TCP SYN (which consumes more bytes in the TCP header of the TCP 497 SYN) and sending the HOST_ID in a TCP ACK (which consumes only two 498 bytes in the TCP SYN). Content providers may find it more 499 desirable to receive the HOST_ID in the TCP SYN, as that more 500 closely preserves the HOST_ID received in the source IP address as 501 per current practices. It is more complicated to implement 502 sending the HOST_ID in a TCP ACK, as it can introduce MTU issues 503 if the ACK packet also contains TCP data, or a TCP segment is 504 lost. The latest specification of the HOST_ID TCP Option, 505 documented at [I-D.wing-nat-reveal-option], allows only to enclose 506 the HOST_ID in the TCP SYN packet. 508 o When there are several NATs in the path, the original HOST_ID may 509 be lost. In such case, the procedure may not be efficient. 511 o Interference with current usages such as X-Forwarded-For (see 512 Section 3.8) should be elaborated to specify the behavior of 513 servers when both options are used; in particular specify which 514 information to use: the content of the TCP Option or what is 515 conveyed in the application headers. 517 o When load-balancers or proxies are in the path, this option does 518 not allow to preserve the original source IP address and source 519 port. Preserving such information is required for logging 520 purposes for instance (e.g., [RFC6302]) . 521 [I-D.abdo-hostid-tcpopt-implementation] defines a TCP Option which 522 allows to reveal various combinations of source information (e.g., 523 source port, source port and source IP address, source IPv6 524 prefix, etc.). 526 More discussion about issues raised when extending TCP can be found 527 at [ExtendTCP]. 529 3.6. PROXY Protocol 531 3.6.1. Description 533 The solution, referred to as Proxy Protocol [Proxy], does not require 534 any application-specific knowledge. The rationale behind this 535 solution is to prepend each connection with a line reporting the 536 characteristics of the other side's connection as shown in the 537 example depicted in Figure 2: 539 PROXY TCP4 192.0.2.1 192.0.2.15 56324 443\r\n 541 Figure 2: Example of PROXY conection report 543 Upon receipt of a message conveying this line, the server removes the 544 line. The line is parsed to retrieve the transported protocol. The 545 content of this line is recorded in logs and used to enforce 546 policies. 548 3.6.2. Analysis 550 This solution can be deployed in a controlled environment but it can 551 not be deployed to all access services available in the Internet. If 552 the remote server does not support the Proxy Protocol, the session 553 will fail. Other complications will raise due to the presence of 554 firewalls for instance. 556 As a consequence, this solution is broken and can not be recommended. 558 3.7. Host Identity Protocol (HIP) 560 3.7.1. Description 562 [RFC5201] specifies an architecture which introduces a new namespace 563 to convey an identity information. 565 3.7.2. Analysis 567 This solution requires both the client and the server to support HIP 568 [RFC5201]. Additional architectural considerations are to be taken 569 into account such as the key exchanges, etc. 571 If the address sharing function is required to act as a UDP/TCP-HIP 572 relay, this is not a viable option. 574 3.8. Inject Application Headers 576 3.8.1. Description 578 Another option is to not require any change at the transport nor the 579 IP levels but to convey at the application payload the required 580 information which will be used to disambiguate hosts. This format 581 and the related semantics depend on its application (e.g., HTTP, SIP, 582 SMTP, etc.). 584 For HTTP, the X-Forwarded-For (XFF) or Forwarded-For 585 ([I-D.ietf-appsawg-http-forwarded]) headers can be used to display 586 the original IP address when an address sharing device is involved. 587 Service Providers operating address sharing devices can enable the 588 feature of injecting the XFF header which will enclose the original 589 IPv4 address or the IPv6 prefix part (see the example shown in 590 Figure 3). The address sharing device has to strip all included XFF 591 headers before injecting their own. Servers may rely on the contents 592 of this field to enforce some policies such as blacklisting 593 misbehaving users. Note that XFF can also be logged by some servers 594 (this is for instance supported by Apache). 596 Forwarded: for=192.0.2.1,for=[2001:db8::1] 597 Forwarded: proto=https;by=192.0.2.15 599 Figure 3: Example of Forwarded-For 601 3.8.2. Analysis 603 Not all applications impacted by the address sharing can support the 604 ability to disclose the original IP address. Only a subset of 605 protocols (e.g., HTTP) can rely on this solution. 607 For the HTTP case, to prevent users injecting invalid HOST_IDs, an 608 initiative has been launched to maintain a list of trusted ISPs using 609 XFF: See for example the list available at: [Trusted_ISPs] of trusted 610 ISPs as maintained by Wikipedia. If an address sharing device is on 611 the trusted XFF ISPs list, users editing Wikipedia located behind the 612 address sharing device will appear to be editing from their 613 "original" IP address and not from the NATed IP address. If an 614 offending activity is detected, individual hosts can be blacklisted 615 instead of all hosts sharing the same IP address. 617 XFF header injection is a common practice of load balancers. When a 618 load balancer is in the path, the original content of any included 619 XFF header should not be stripped. Otherwise the information about 620 the "origin" IP address will be lost. 622 When several address sharing devices are crossed, XFF header can 623 convey the list of IP addresses (e.g., Figure 3). The origin HOST_ID 624 can be exposed to the target server. 626 XFF also introduces some implementation complexity if the HTTP packet 627 is at or close to the MTU size. 629 It has been reported that some "poor" implementation may encounter 630 some parsing issues when injecting XFF header. 632 For encrypted HTTP traffic, injecting XFF header may be broken. 634 4. HOST_ID and Privacy 636 IP address sharing is motivated by a number of different factors. 637 For years, many network operators have conserved the use of public 638 IPv4 addresses by making use of Customer Premises Equipment (CPE) 639 that assigns a single public IPv4 address to all hosts within the 640 customer's local area network and uses NAT [RFC3022] to translate 641 between locally unique private IPv4 addresses and the CPE's public 642 address. With the exhaustion of IPv4 address space, address sharing 643 between customers on a much larger scale is likely to become much 644 more prevalent. While many individual users are unaware of and 645 uninvolved in decisions about whether their unique IPv4 addresses get 646 revealed when they send data via IP, some users realize privacy 647 benefits associated with IP address sharing, and some may even take 648 steps to ensure that NAT functionality sits between them and the 649 public Internet. IP address sharing makes the actions of all users 650 behind the NAT function unattributable to any single host, creating 651 room for abuse but also providing some identity protection for non- 652 abusive users who wish to transmit data with reduced risk of being 653 uniquely identified. 655 The proposals considered in this document add a measure of uniqueness 656 back to hosts that share a public IP address. The extent of that 657 uniqueness depends on which information is included in the HOST_ID. 659 The volatility of the HOST_ID information is similar to the source IP 660 address: a distinct HOST_ID may be used by the address sharing 661 function when the host reboots or gets a new internal IP address. As 662 with persistent IP addresses, persistent HOST_IDs facilitate user 663 tracking over time. 665 As a general matter, the HOST_ID proposals do not seek to make hosts 666 any more identifiable than they would be if they were using a public, 667 non-shared IP address. However, depending on the solution proposal, 668 the addition of HOST_ID information may allow a device to be 669 fingerprinted more easily than it otherwise would be. Should 670 multiple solutions be combined (e.g., TCP Option and XFF) that 671 include different pieces of information in the HOST_ID, 672 fingerprinting may become even easier. 674 The trust placed in the information conveyed in the HOST_ID is likely 675 to be the same as for current practices with source IP addresses. In 676 that sense, a HOST_ID can be spoofed as this is also the case for 677 spoofing an IP address. Furthermore, users of network-based 678 anonymity services (like Tor) may be capable of stripping HOST_ID 679 information before it reaches its destination. 681 For more discussion about privacy, refer to [RFC6462]. 683 5. IANA Considerations 685 This document does not require any action from IANA. 687 6. Security Considerations 689 The same security concerns apply for the injection of an IP option, 690 TCP Option and application-related content (e.g., XFF) by the address 691 sharing device. If the server trusts the content of the HOST_ID 692 field, a third party user can be impacted by a misbehaving user to 693 reveal a "faked" original IP address. 695 7. Acknowledgments 697 Many thanks to D. Wing and C. Jacquenet for their review, comments 698 and inputs. 700 Thanks also to P. McCann, T. Tsou, Z. Dong, B. Briscoe, T. Taylor, M. 701 Blanchet, D. Wing and A. Yourtchenko for the discussions in Prague. 703 Some of the issues related to defining a new TCP Option have been 704 raised by L. Eggert. 706 Privacy text is provided by A. Cooper. 708 8. References 710 8.1. Normative References 712 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 713 September 1981. 715 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 716 Requirement Levels", BCP 14, RFC 2119, March 1997. 718 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 719 Address Translator (Traditional NAT)", RFC 3022, 720 January 2001. 722 [RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport- 723 Protocol Port Randomization", BCP 156, RFC 6056, 724 January 2011. 726 8.2. Informative References 728 [Count] "A technique for counting NATted hosts", 729 . 731 [ExtendTCP] 732 Honda, M., Nishida, Y., Raiciu, C., Greenhalgh, A., 733 Handley, M. and H. Tokuda,, "Is it still possible to 734 extend TCP?", November 2011, 735 . 737 [I-D.abdo-hostid-tcpopt-implementation] 738 Abdo, E., Boucadair, M., and J. Queiroz, "HOST_ID TCP 739 Options: Implementation & Preliminary Test Results", 740 draft-abdo-hostid-tcpopt-implementation-02 (work in 741 progress), January 2012. 743 [I-D.chen-intarea-v4-uid-header-option] 744 Wu, Y., Ji, H., Chen, Q., and T. ZOU), "IPv4 Header Option 745 For User Identification In CGN Scenario", 746 draft-chen-intarea-v4-uid-header-option-00 (work in 747 progress), March 2011. 749 [I-D.ietf-appsawg-http-forwarded] 750 Petersson, A. and M. Nilsson, "Forwarded HTTP Extension", 751 draft-ietf-appsawg-http-forwarded-00 (work in progress), 752 January 2012. 754 [I-D.ietf-behave-lsn-requirements] 755 Perreault, S., Yamagata, I., Miyakawa, S., Nakagawa, A., 756 and H. Ashida, "Common requirements for Carrier Grade NATs 757 (CGNs)", draft-ietf-behave-lsn-requirements-05 (work in 758 progress), November 2011. 760 [I-D.ietf-intarea-ipv4-id-update] 761 Touch, J., "Updated Specification of the IPv4 ID Field", 762 draft-ietf-intarea-ipv4-id-update-04 (work in progress), 763 September 2011. 765 [I-D.wing-nat-reveal-option] 766 Yourtchenko, A. and D. Wing, "Revealing hosts sharing an 767 IP address using TCP option", 768 draft-wing-nat-reveal-option-03 (work in progress), 769 December 2011. 771 [I-D.yourtchenko-nat-reveal-ping] 772 Yourtchenko, A., "Revealing hosts sharing an IP address 773 using ICMP Echo Request", 774 draft-yourtchenko-nat-reveal-ping-00 (work in progress), 775 March 2012. 777 [Not_An_Option] 778 R. Fonseca, G. Porter, R. Katz, S. Shenker, and I. 779 Stoica,, "IP options are not an option", 2005, . 783 [Options] Alberto Medina, Mark Allman, Sally Floyd, "Measuring 784 Interactions Between Transport Protocols and Middleboxes", 785 2005, . 788 [Proxy] Tarreau, W., "The PROXY protocol", November 2010, . 791 [RFC2753] Yavatkar, R., Pendarakis, D., and R. Guerin, "A Framework 792 for Policy-based Admission Control", RFC 2753, 793 January 2000. 795 [RFC5201] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson, 796 "Host Identity Protocol", RFC 5201, April 2008. 798 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 799 NAT64: Network Address and Protocol Translation from IPv6 800 Clients to IPv4 Servers", RFC 6146, April 2011. 802 [RFC6269] Ford, M., Boucadair, M., Durand, A., Levis, P., and P. 803 Roberts, "Issues with IP Address Sharing", RFC 6269, 804 June 2011. 806 [RFC6302] Durand, A., Gashinsky, I., Lee, D., and S. Sheppard, 807 "Logging Recommendations for Internet-Facing Servers", 808 BCP 162, RFC 6302, June 2011. 810 [RFC6462] Cooper, A., "Report from the Internet Privacy Workshop", 811 RFC 6462, January 2012. 813 [Trusted_ISPs] 814 "Trusted XFF list", . 817 Authors' Addresses 819 Mohamed Boucadair 820 France Telecom 821 Rennes, 35000 822 France 824 Email: mohamed.boucadair@orange.com 825 Joe Touch 826 USC/ISI 828 Email: touch@isi.edu 830 Pierre Levis 831 France Telecom 832 Caen, 14000 833 France 835 Email: pierre.levis@orange.com 837 Reinaldo Penno 838 Juniper Networks 839 1194 N Mathilda Avenue 840 Sunnyvale, California 94089 841 USA 843 Email: rpenno@juniper.net