idnits 2.17.1 draft-ietf-intarea-nat-reveal-analysis-04.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 (August 21, 2012) is 4265 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-09) exists of draft-iab-privacy-considerations-03 == Outdated reference: A later version (-10) exists of draft-ietf-appsawg-http-forwarded-07 == Outdated reference: A later version (-07) exists of draft-ietf-intarea-ipv4-id-update-05 -- Obsolete informational reference (is this intentional?): RFC 5201 (Obsoleted by RFC 7401) Summary: 0 errors (**), 0 flaws (~~), 4 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: February 22, 2013 USC/ISI 6 P. Levis 7 France Telecom 8 R. Penno 9 Cisco 10 August 21, 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-04 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 February 22, 2013. 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 3. HOST_ID and Privacy . . . . . . . . . . . . . . . . . . . . . 6 69 3.1. Privacy-related Requirements . . . . . . . . . . . . . . . 7 70 4. Detailed Solutions Analysis . . . . . . . . . . . . . . . . . 7 71 4.1. Use the Identification Field of IP Header (IP-ID) . . . . 7 72 4.1.1. Description . . . . . . . . . . . . . . . . . . . . . 7 73 4.1.2. Analysis . . . . . . . . . . . . . . . . . . . . . . . 8 74 4.2. Define an IP Option . . . . . . . . . . . . . . . . . . . 8 75 4.2.1. Description . . . . . . . . . . . . . . . . . . . . . 8 76 4.2.2. Analysis . . . . . . . . . . . . . . . . . . . . . . . 8 77 4.3. Define a TCP Option . . . . . . . . . . . . . . . . . . . 8 78 4.3.1. Description . . . . . . . . . . . . . . . . . . . . . 9 79 4.3.2. Analysis . . . . . . . . . . . . . . . . . . . . . . . 9 80 4.4. Inject Application Protocol Message Headers . . . . . . . 10 81 4.4.1. Description . . . . . . . . . . . . . . . . . . . . . 10 82 4.4.2. Analysis . . . . . . . . . . . . . . . . . . . . . . . 11 83 4.5. PROXY Protocol . . . . . . . . . . . . . . . . . . . . . . 11 84 4.5.1. Description . . . . . . . . . . . . . . . . . . . . . 11 85 4.5.2. Analysis . . . . . . . . . . . . . . . . . . . . . . . 12 86 4.6. Assign Port Sets . . . . . . . . . . . . . . . . . . . . . 12 87 4.6.1. Description . . . . . . . . . . . . . . . . . . . . . 12 88 4.6.2. Analysis . . . . . . . . . . . . . . . . . . . . . . . 12 89 4.7. Host Identity Protocol (HIP) . . . . . . . . . . . . . . . 13 90 4.7.1. Description . . . . . . . . . . . . . . . . . . . . . 13 91 4.7.2. Analysis . . . . . . . . . . . . . . . . . . . . . . . 13 92 4.8. Use a Notification Channel (e.g., ICMP) . . . . . . . . . 13 93 4.8.1. Description . . . . . . . . . . . . . . . . . . . . . 13 94 4.8.2. Analysis . . . . . . . . . . . . . . . . . . . . . . . 13 95 4.9. Use Out-of-Band Mechanisms (e.g., IDENT) . . . . . . . . . 14 96 4.9.1. Description . . . . . . . . . . . . . . . . . . . . . 14 97 4.9.2. Analysis . . . . . . . . . . . . . . . . . . . . . . . 14 98 5. Solutions Analysis: Synthesis . . . . . . . . . . . . . . . . 15 99 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 100 7. Security Considerations . . . . . . . . . . . . . . . . . . . 18 101 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 102 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 103 9.1. Normative References . . . . . . . . . . . . . . . . . . . 19 104 9.2. Informative References . . . . . . . . . . . . . . . . . . 19 105 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 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. These issues are 113 encountered in various deployment contexts: e.g., Carrier Grade NAT 114 (CGN), application proxies or A+P [RFC6346]. Examples of such issues 115 are listed below: 117 o Implicit identification (Section 13.2 of [RFC6269]) 118 o SPAM (Section 13.3 of [RFC6269]) 119 o Blacklisting a mis-behaving host (Section 13.1 of [RFC6269]) 120 o Redirect users with infected machines to a dedicated portal 121 (Section 5.1 of [RFC6269]) 123 The sole use of the IPv4 address is not sufficient to uniquely 124 distinguish a host. As a mitigation, it is tempting to investigate 125 means which would help in disclosing an information to be used by the 126 remote server as a means to uniquely disambiguate packets of hosts 127 using the same IPv4 address. 129 The risk of not mitigating these issues are: OPEX (Operational 130 Expenditure) increase for IP connectivity service providers (costs 131 induced by calls to a hotline), revenue loss for content providers 132 (loss of users audience), customers unsatisfaction (low quality of 133 experience, service segregation, etc.). 135 1.2. Purpose and Scope 137 The purpose of this document is to analyze a set of alternative 138 channels to convey a host identifier and to assess to what extent 139 they solve the problem described in Section 2. Below are listed the 140 candidates analyzed in the document: 142 o Use the Identification field of IP header (denoted as IP-ID, 143 Section 4.1). 144 o Define a new IP option (Section 4.2). 145 o Define a new TCP Option (Section 4.3). 146 o Inject application headers (Section 4.4). 147 o Enable Proxy Protocol ( (Section 4.5)). 148 o Assign port sets (Section 4.6). 149 o Activate HIP (Section 4.7). 150 o Use a notification channel (Section 4.8). 151 o Use an out-of-band mechanism (Section 4.9). 153 A synthesis is provided in Section 5 while the detailed analysis is 154 elaborated in Section 4. 156 Section 3 discusses privacy issues common to all HOST_ID solutions. 157 It is out of scope of this document to elaborate on privacy issues 158 specific to each solution. 160 2. Problem to Be Solved 162 Observation: Some servers use the source IPv4 address as an 163 identifier to treat some incoming connections differently. 164 Due to the deployment of CGNs (e.g., NAT44 [RFC3022], NAT64 165 [RFC6146]), that address will be shared. In particular, 166 when a server receives packets from the same source 167 address, because this address is shared, the server does 168 not know which host is the sending host [RFC6269]. 170 Objective: The server should be able to sort out the packets by 171 sending host. 173 Requirement: The server must have extra information than the source 174 IP address to differentiate the sending host. We call 175 HOST_ID this information. 177 For all solutions analyzed, we provide answers to the following 178 questions: 180 What is the HOST_ID? It must be unique to each host under the same 181 IP address. It does not need to be globally unique. Of course, 182 the combination of the (public) IP source address and the 183 identifier (i.e., HOST_ID) ends up being relatively unique. As 184 unique as today's 32-bit IPv4 addresses which, today, can change 185 when a host re-connects. 187 Where is the HOST_ID? (which protocol, which field): If the HOST_ID 188 is put at the IP level, all packets will have to bear the 189 identifier. If it is put at a higher connection-oriented level, 190 the identifier is only needed once in the session establishment 191 phase (for instance TCP three-way-handshake), then, all packets 192 received in this session will be attributed to the HOST_ID 193 designated during the session opening. 195 Who puts the HOST_ID? For almost all the analyzed solutions, the 196 address sharing function injects the HOST_ID. When there are 197 several address sharing functions in the data path, we describe 198 to what extent the proposed solution is efficient. Another 199 option to avoid potential performance degradation is to let the 200 host inject its HOST_ID but the address sharing function will 201 check its content (just like an IP anti-spoofing function). For 202 some proposals, the HOST_ID is retrieved using an out-of-band 203 mechanism or signaled in a dedicated notification channel. 205 What are the security considerations? Security considerations are 206 common to all analyzed solutions (see Section 7). Privacy- 207 related aspects are discussed in Section 3. 209 3. HOST_ID and Privacy 211 IP address sharing is motivated by a number of different factors. 212 For years, many network operators have conserved the use of public 213 IPv4 addresses by making use of Customer Premises Equipment (CPE) 214 that assigns a single public IPv4 address to all hosts within the 215 customer's local area network and uses NAT [RFC3022] to translate 216 between locally unique private IPv4 addresses and the CPE's public 217 address. With the exhaustion of IPv4 address space, address sharing 218 between customers on a much larger scale is likely to become much 219 more prevalent. While many individual users are unaware of and 220 uninvolved in decisions about whether their unique IPv4 addresses get 221 revealed when they send data via IP, some users realize privacy 222 benefits associated with IP address sharing, and some may even take 223 steps to ensure that NAT functionality sits between them and the 224 public Internet. IP address sharing makes the actions of all users 225 behind the NAT function unattributable to any single host, creating 226 room for abuse but also providing some identity protection for non- 227 abusive users who wish to transmit data with reduced risk of being 228 uniquely identified. 230 The proposals considered in this document add a measure of uniqueness 231 back to hosts that share a public IP address. The extent of that 232 uniqueness depends on which information is included in the HOST_ID. 234 The volatility of the HOST_ID information is similar to the source IP 235 address: a distinct HOST_ID may be used by the address sharing 236 function when the host reboots or gets a new internal IP address. As 237 with persistent IP addresses, persistent HOST_IDs facilitate user 238 tracking over time. 240 As a general matter, the HOST_ID proposals do not seek to make hosts 241 any more identifiable than they would be if they were using a public, 242 non-shared IP address. However, depending on the solution proposal, 243 the addition of HOST_ID information may allow a device to be 244 fingerprinted more easily than it otherwise would be. Should 245 multiple solutions be combined (e.g., TCP Option and XFF) that 246 include different pieces of information in the HOST_ID, 247 fingerprinting may become even easier. 249 A HOST_ID can be spoofed as this is also the case for spoofing an IP 250 address. Furthermore, users of network-based anonymity services 251 (like Tor) may be capable of stripping HOST_ID information before it 252 reaches its destination. 254 HOST_ID specification document(s) SHOULD explain the privacy impact 255 of the solutions they specify, including the extent of HOST_ID 256 uniqueness and persistence, assumptions made about the lifetime of 257 the HOST_ID, whether and how the HOST_ID can be obfuscated or 258 recycled, and the impact of the use of the HOST_ID on device or 259 implementation fingerprinting. [I-D.iab-privacy-considerations] 260 provides further guidance. 262 For more discussion about privacy, refer to [RFC6462]. 264 3.1. Privacy-related Requirements 266 Whatever the channel used to convey the HOST_ID, the following 267 requirements are to be met: 269 Uniqueness of identifiers in HOST_ID: It is RECOMMENDED that 270 HOST_IDs be limited to providing local uniqueness rather than 271 global uniqueness. 273 Refresh rate of HOST_ID: Address sharing function SHOULD NOT use 274 permanent HOST_ID values. 276 Manipulate HOST_IDs: Address sharing function SHOULD be able to 277 strip, re-write and add HOST_ID fields. 279 Interference between HOST_IDs: An address sharing function, able to 280 inject HOST_IDs in several layers, SHOULD reveal subsets of the 281 same information (e.g., full IP address, lower 16 bits of IP 282 address, etc.). 284 4. Detailed Solutions Analysis 286 4.1. Use the Identification Field of IP Header (IP-ID) 288 4.1.1. Description 290 IP-ID (Identification field of IP header) can be used to insert an 291 information which uniquely distinguishes a host among those sharing 292 the same IPv4 address. An address sharing function can re-write the 293 IP-ID field to insert a value unique to the host (16 bits are 294 sufficient to uniquely disambiguate hosts sharing the same IP 295 address). Note that this field is not altered by some NATs; hence 296 some side effects such as counting hosts behind a NAT as reported in 298 [Count]. 300 A variant of this approach relies upon the format of certain packets, 301 such as TCP SYN, where the IP-ID can be modified to contain a 16 bit 302 HOST_ID. 304 Address sharing devices performing this function would require to 305 indicate they are performing this function out of band, possibly 306 using a special DNS record. 308 4.1.2. Analysis 310 This usage is not compliant with what is recommended in 311 [I-D.ietf-intarea-ipv4-id-update]. 313 4.2. Define an IP Option 315 4.2.1. Description 317 A solution alternative to convey the HOST_ID is to define an IP 318 option [RFC0791]. HOST_ID IP option can be inserted by the address 319 sharing function to uniquely distinguish a host among those sharing 320 the same IP address. An example of such option is documented in 321 [I-D.chen-intarea-v4-uid-header-option]. This IP option allows to 322 convey an IPv4 address, an IPv6 prefix, a GRE key, IPv6 Flow Label, 323 etc. 325 Another way for using IP option has been described in Section 4.6 of 326 [RFC3022]. 328 4.2.2. Analysis 330 Unlike the solution presented in Section 4.3, this proposal can apply 331 for any transport protocol. Nevertheless, it is widely known that 332 routers (and other middleboxes) filter IP options. IP packets with 333 IP options can be dropped by some IP nodes. Previous studies 334 demonstrated that "IP Options are not an option" (Refer to 335 [Not_An_Option], [Options]). 337 As a conclusion, using an IP option to convey a host-hint is not 338 viable. 340 4.3. Define a TCP Option 341 4.3.1. Description 343 HOST_ID may be conveyed in a dedicated TCP Option. An example is 344 specified in [I-D.wing-nat-reveal-option] which defines a new TCP 345 Option called USER_HINT. This option encloses the TCP client's 346 identifier (e.g., the lower 16 bits of their IPv4 address, their VLAN 347 ID, VRF ID, subscriber ID). The address sharing device inserts this 348 TCP Option into the TCP SYN packet. 350 4.3.2. Analysis 352 Using a new TCP Option to convey the HOST_ID does not require any 353 modification to the applications but it is applicable only for TCP- 354 based applications. Applications relying on other transport 355 protocols are therefore left unsolved. 357 [I-D.wing-nat-reveal-option] discusses the interference with other 358 TCP Options. 360 The risk related to handling a new TCP Option is low as measured in 361 [Options]. [I-D.abdo-hostid-tcpopt-implementation] provides a 362 detailed implementation and experimentation report of HOST_ID TCP 363 Option. [I-D.abdo-hostid-tcpopt-implementation] investigated in 364 depth the impact of activation HOST_ID in host, address sharing 365 function and the enforcement of policies at the server side. 366 [I-D.abdo-hostid-tcpopt-implementation] reports a failure ratio of 367 0,103% among top 100000 websites. 369 Some downsides have been raised against defining a TCP Option to 370 reveal a host identity: 372 o Conveying an IP address in a TCP Option may be seen as a violation 373 of OSI layers but since IP addresses are already used for the 374 checksum computation, this is not seen as a blocking point. 375 Moreover, updated version of [I-D.wing-nat-reveal-option] does not 376 allow anymore to convey an IP address (the HOST_ID is encoded in 377 16bits). 379 o TCP Option space is limited, and might be consumed by the TCP 380 client. [I-D.abdo-hostid-tcpopt-implementation] discusses two 381 approaches to sending the HOST_ID: sending the HOST_ID in the TCP 382 SYN (which consumes more bytes in the TCP header of the TCP SYN) 383 and sending the HOST_ID in a TCP ACK (which consumes only two 384 bytes in the TCP SYN). Content providers may find it more 385 desirable to receive the HOST_ID in the TCP SYN, as that more 386 closely preserves the HOST_ID received in the source IP address as 387 per current practices. It is more complicated to implement 388 sending the HOST_ID in a TCP ACK, as it can introduce MTU issues 389 if the ACK packet also contains TCP data, or a TCP segment is 390 lost. Note [I-D.wing-nat-reveal-option] allows only to enclose 391 the HOST_ID in the TCP SYN packet. 393 o When there are several NATs in the path, the original HOST_ID may 394 be lost. 396 o Interference with current usages such as X-Forwarded-For (see 397 Section 4.4) should be elaborated to specify the behavior of 398 servers when both options are used; in particular specify which 399 information to use: the content of the TCP Option or what is 400 conveyed in the application headers. 402 o When load-balancers or proxies are in the path, this option does 403 not allow to preserve the original source IP address and source 404 port. Preserving such information is required for logging 405 purposes for instance (e.g., [RFC6302]). 406 [I-D.abdo-hostid-tcpopt-implementation] defines a TCP Option which 407 allows to reveal various combinations of source information (e.g., 408 source port, source port and source IP address, source IPv6 409 prefix, etc.). 411 More discussion about issues raised when extending TCP can be found 412 at [ExtendTCP]. 414 4.4. Inject Application Protocol Message Headers 416 4.4.1. Description 418 Another option is to not require any change at the transport nor the 419 IP levels but to convey at the application payload the required 420 information which will be used to disambiguate hosts. This format 421 and the related semantics depend on its application (e.g., HTTP, SIP, 422 SMTP, etc.). 424 For HTTP, the X-Forwarded-For (XFF) or Forwarded-For 425 ([I-D.ietf-appsawg-http-forwarded]) headers can be used to display 426 the original IP address when an address sharing device is involved. 427 Service Providers operating address sharing devices can enable the 428 feature of injecting the XFF/Forwarded-For header which will enclose 429 the original IPv4 address or the IPv6 prefix part (see the example 430 shown in Figure 1). The address sharing device has to strip all 431 included XFF/Forwarded-For headers before injecting their own. 432 Servers may rely on the contents of this field to enforce some 433 policies such as blacklisting misbehaving users. Note that XFF can 434 also be logged by some servers (this is for instance supported by 435 Apache). 437 Forwarded: for=192.0.2.1,for=[2001:db8::1] 438 Forwarded: proto=https;by=192.0.2.15 440 Figure 1: Example of Forwarded-For 442 4.4.2. Analysis 444 Not all applications impacted by the address sharing can support the 445 ability to disclose the original IP address. Only a subset of 446 protocols (e.g., HTTP) can rely on this solution. 448 For the HTTP case, to prevent users injecting invalid HOST_IDs, an 449 initiative has been launched to maintain a list of trusted ISPs using 450 XFF: See for example the list available at: [Trusted_ISPs] of trusted 451 ISPs as maintained by Wikipedia. If an address sharing device is on 452 the trusted XFF ISPs list, users editing Wikipedia located behind the 453 address sharing device will appear to be editing from their 454 "original" IP address and not from the NATed IP address. If an 455 offending activity is detected, individual hosts can be blacklisted 456 instead of all hosts sharing the same IP address. 458 XFF header injection is a common practice of load balancers. When a 459 load balancer is in the path, the original content of any included 460 XFF header should not be stripped. Otherwise the information about 461 the "origin" IP address will be lost. 463 When several address sharing devices are crossed, XFF/Forwarded-For 464 header can convey the list of IP addresses (e.g., Figure 1). The 465 origin HOST_ID can be exposed to the target server. 467 XFF also introduces some implementation complexity if the HTTP packet 468 is at or close to the MTU size. 470 It has been reported that some "poor" implementation may encounter 471 some parsing issues when injecting XFF header. 473 For encrypted HTTP traffic, injecting XFF header may be broken. 475 4.5. PROXY Protocol 477 4.5.1. Description 479 The solution, referred to as Proxy Protocol [Proxy], does not require 480 any application-specific knowledge. The rationale behind this 481 solution is to prepend each connection with a line reporting the 482 characteristics of the other side's connection as shown in the 483 example depicted in Figure 2: 485 PROXY TCP4 192.0.2.1 192.0.2.15 56324 443\r\n 487 Figure 2: Example of PROXY conection report 489 Upon receipt of a message conveying this line, the server removes the 490 line. The line is parsed to retrieve the transported protocol. The 491 content of this line is recorded in logs and used to enforce 492 policies. 494 4.5.2. Analysis 496 This solution can be deployed in a controlled environment but it can 497 not be deployed to all access services available in the Internet. If 498 the remote server does not support the Proxy Protocol, the session 499 will fail. Other complications will raise due to the presence of 500 firewalls for instance. 502 As a consequence, this solution is broken and can not be recommended. 504 4.6. Assign Port Sets 506 4.6.1. Description 508 This solution does not require any action from the address sharing 509 function to disclose a host identifier. Instead of assuming all 510 transport ports are associated with one single host, each host under 511 the same external IP address is assigned a restricted port set. 512 These port sets are then advertised to remote servers using off-line 513 means. This announcement is not required for the delivery of 514 internal services (i.e., offered by the service provider deploying 515 the address sharing function) relying on implicit identification. 517 Port sets assigned to hosts may be static or dynamic. 519 Port set announcements to remote servers do not require to reveal the 520 identity of individual hosts but only to advertise the enforced 521 policy to generate non-overlapping port sets (e.g., the transport 522 space associated with an IP address is fragmented to contiguous 523 blocks of 2048 port numbers). 525 4.6.2. Analysis 527 The solution does not require defining new fields nor options; it is 528 policy-based. 530 The solution may contradict the port randomization as identified in 531 [RFC6269]. A mitigation would be to avoid assigning static port sets 532 to individual hosts. 534 The method is convenient for the delivery of services offered by the 535 service provider offering also the IP connectivity service. 537 4.7. Host Identity Protocol (HIP) 539 4.7.1. Description 541 [RFC5201] specifies an architecture which introduces a new namespace 542 to convey an identity information. 544 4.7.2. Analysis 546 This solution requires both the client and the server to support HIP 547 [RFC5201]. Additional architectural considerations are to be taken 548 into account such as the key exchanges, etc. 550 If the address sharing function is required to act as a UDP/TCP-HIP 551 relay, this is not a viable option. 553 4.8. Use a Notification Channel (e.g., ICMP) 555 4.8.1. Description 557 Another alternative is to convey the HOST_ID using a separate 558 notification channel than the packets issued to invoke the service. 560 An implementation example is defined in 561 [I-D.yourtchenko-nat-reveal-ping]. This solution relies on a 562 mechanism where the address sharing function encapsulates the 563 necessary differentiating information into an ICMP Echo Request 564 packet that it sends in parallel with the initial session creation 565 (e.g., SYN). The information included in the ICMP Request Data 566 portion describes the five-tuples as seen on both of the sides of the 567 address sharing function. 569 4.8.2. Analysis 571 o This ICMP proposal is valid for both UDP and TCP. Address sharing 572 function may be configurable with the transport protocol which is 573 allowed to trigger those ICMP messages. 574 o A hint should be provided to the ultimate server (or intermediate 575 nodes) an ICMP Echo Request conveys a HOST_ID. This may be 576 implemented using magic numbers. 577 o Even if ICMP packets are blocked in the communication path, the 578 user connection does not have to be impacted. 579 o Some implementations requiring to delay the establishment of a 580 session until receiving the companion ICMP Echo Request, may lead 581 to some user experience degradation. 583 o Because of the presence of load-balancers in the path, the 584 ultimate server receiving the SYN packet may not be the one which 585 may receive the ICMP message conveying the HOST_ID. 586 o Because of the presence of load-balancers in the path, the port 587 number assigned by address sharing may be lost. Therefore the 588 mapping information conveyed in the ICMP may not be sufficient to 589 associate a SYN packet with a received ICMP. 590 o The proposal is not compatible with the presence of cascaded NAT. 591 o The ICMP proposal will add a traffic overhead for both the server 592 and the address sharing device. 593 o The ICMP proposal is similar to other mechanisms (e.g., syslog, 594 netflow) for reporting dynamic mappings to a mediation platform 595 (mainly for legal traceability purposes). Performance degradation 596 are likely to be experienced by address sharing functions because 597 ICMP messages are to be sent in particular for each new 598 instantiated mapping (and also even if the mapping exists). 599 o In some scenarios (e.g., Fixed-Mobile Convergence, Open WiFi, 600 etc.), HOST_ID should be interpreted by intermediate devices which 601 embed Policy Enforcement Points (PEP, [RFC2753]) responsible for 602 granting access to some services. These PEPs need to inspect all 603 received packets in order to find the companion (traffic) messages 604 to be correlated with ICMP messages conveying HOST_IDs. This 605 induces more complexity to these intermediate devices. 607 4.9. Use Out-of-Band Mechanisms (e.g., IDENT) 609 4.9.1. Description 611 Another alternative is to retrieve the HOST_ID using a dedicated 612 query channel. 614 An implementation example may rely on the Identification Protocol 615 (IDENT, [RFC1413]). This solution assumes address sharing function 616 implements the server part of IDENT while remote servers implement 617 the client part of the protocol. IDENT needs to be updated (see 618 [IDENT_NAT]) to be able to return a host identifier instead of the 619 user-id as defined in [RFC1413]. The IDENT response syntax uses the 620 same USERID field described in [RFC1413] but rather than returning a 621 username, a host identifier (e.g., a 16 bit value) is returned 622 [IDENT_NAT]. For any new incoming connection, the server contacts 623 the IDENT server to retrieve the associated identifier. During that 624 phase, the connection may be delayed. 626 4.9.2. Analysis 628 o IDENT is specific to TCP. Alternatives out-of-band mechanism may 629 be design to cover both TCP and UDP. 631 o This solution requires the address sharing function to embed an 632 IDENT server. 633 o A hint should be provided to the ultimate server (or intermediate 634 nodes) the address sharing function implements IDENT protocol. 635 This can be achieved by publishing this capability using DNS. 636 o An out-of-band mechanism may require some administrative setup 637 (e.g., contract agreement) between the entity managing the address 638 sharing function and the entity managing the remote server. This 639 deployment is not deployable in the Internet at large because 640 establishing and maintaining agreements between ISPs and all 641 service actors is heavy and not scalable. 642 o Some implementations requiring to delay the establishment of a 643 session until receiving the companion IDENT response, may lead to 644 some user experience degradation. 645 o The IDENT proposal will add a traffic overhead for both the server 646 and the address sharing device. 647 o Performance degradation are likely to be experienced by address 648 sharing functions embedding the IDENT server. This is even 649 exacerbated if the address sharing function has to handle an IDENT 650 query for each new instantiated mapping (and also even if the 651 mapping exists). 652 o In some scenarios (e.g., Fixed-Mobile Convergence, Open WiFi, 653 etc.), HOST_ID should be interpreted by intermediate devices which 654 embed Policy Enforcement Points (PEP, [RFC2753]) responsible for 655 granting access to some services. These PEPs need to inspect all 656 received packets in order to generate the companion IDENT queries. 657 This may induce more complexity to these intermediate devices. 658 o IDENT queries may be generated by non legitimate TCP servers. 659 This would require the address sharing function to enforce some 660 policies (e.g., rate limit queries, filter based on the source IP 661 address, etc.). 663 5. Solutions Analysis: Synthesis 665 The following Table 1 summarizes the approaches analyzed in this 666 document. 668 o "Success ratio" indicates the ratio of successful communications 669 when the option is used. Provided figures are inspired from the 670 results documented in [Options]. 671 o "Deployable today" indicates if the solution can be generalized 672 without any constraint on current architectures and practices. 673 o "Possible Perf Impact" indicates the level of expected performance 674 degradation. The rationale behind the indicated potential 675 performance degradation is whether the injection requires some 676 treatment at the IP level or not. 678 o "OS TCP/IP Modif" indicates whether a modification of the OS 679 TCP/IP stack is required at the server side. 681 +-----+------+------+------+-----+-----+-----+-----+-----+ 682 |IP-ID| IP | TCP |HTTP |PROXY|Port | HIP |ICMP |IDENT| 683 | |Option|Option|Header| | Set | | | | 684 | | | |(XFF) | | | | | | 685 ----------+-----+------+------+------+-----+-----+-----+-----+-----+ 686 UDP | Yes | Yes | No | No | No | Yes | | Yes | No | 687 ----------+-----+------+------+------+-----+-----+-----+-----+-----+ 688 TCP | Yes | Yes | Yes | No | Yes | Yes | | Yes | Yes | 689 ----------+-----+------+------+------+-----+-----+-----+-----+-----+ 690 HTTP | Yes | Yes | Yes | Yes | Yes | Yes | | Yes | Yes | 691 ----------+-----+------+------+------+-----+-----+-----+-----+-----+ 692 Encrypted | Yes | Yes | Yes | No | Yes | Yes | | Yes | Yes | 693 Traffic | | | | | | | | | | 694 ----------+-----+------+------+------+-----+-----+-----+-----+-----+ 695 Success | 100%| 30% | 99% | 100% | Low | 100%|Low |~100%|~100%| 696 Ratio | | | | | | | | (6) | (6) | 697 ----------+-----+------+------+------+-----+-----+-----+-----+-----+ 698 Possible | Low | High | Low | Med | High| No | N/A | High|High | 699 Perf | to | | to | to | | | | | | 700 Impact | Med | | Med | High | | | | | | 701 ----------+-----+------+------+------+-----+-----+-----+-----+-----+ 702 OS TCP/IP | Yes | Yes | Yes | No | No | No | | Yes | Yes | 703 Modif | | | | | | | | | | 704 ----------+-----+------+------+------+-----+-----+-----+-----+-----+ 705 Deployable| Yes | Yes | Yes | Yes | No | Yes | No | Yes | Yes | 706 Today | | | | | | | | | | 707 ----------+-----+------+------+------+-----+-----+-----+-----+-----+ 708 Notes | (1) | | | (2) | | (1) | (4) | (7) | (1) | 709 | | | | | | (3) | (5) | | (7) | 710 ----------+-----+------+------+------+-----+-----+-----+-----+-----+ 712 Notes: 714 (1) Requires mechanism to advertise NAT is participating in this 715 scheme (e.g., DNS PTR record). 716 (2) This solution is widely deployed. 717 (3) When the port set is not advertised, the solution is less 718 efficient for third-party services. 719 (4) Requires the client and the server to be HIP-compliant and HIP 720 infrastructure to be deployed. 721 (5) If the client and the server are HIP-enabled, the address 722 sharing function does not need to insert an identifier. If the 723 client is not HIP-enabled, designing the device that performs 724 address sharing to act as a UDP/TCP-HIP relay is not viable. 725 (6) Implementation-specific. 726 (7) The solution is inefficient in various scenarios as discussed 727 in Section 5. 729 Figure 3: Table 1: Summary of analyzed solutions. 731 According to the above table and the analysis elaborated in 732 Section 4: 734 o IP Option, IP-ID and Proxy Protocol proposals are broken; 736 o HIP (Host Identity Protocol) is not largely deployed; 738 o The use of Port Set may contradict the port randomization 739 [RFC6056] requirement identified in [RFC6269]. This solution can 740 be used by a service provider for the delivery of its own service 741 offerings relying on implicit identification. 743 o X-Forwarded-For (XFF) is de facto standard deployed and supported 744 in operational networks (e.g., HTTP Severs, Load-Balancers, etc.). 746 o From an application standpoint, the TCP Option is superior to XFF/ 747 Forwarded-For since it is not restricted to HTTP. Nevertheless 748 XFF/Forwarded-For is compatible with the presence of address 749 sharing and load-balancers in the communication path. To provide 750 a similar functionality, the TCP Option may be extended to allow 751 conveying a list of IP addresses and port numbers to not lose the 752 source IP address in the presence of load-balancers. Another 753 alternative is to combine the usage of both the HOST_ID TCP Option 754 and XFF/Forwarded-For. Extending TCP is still possible as 755 analyzed in [ExtendTCP]. 757 6. IANA Considerations 759 This document does not require any action from IANA. 761 7. Security Considerations 763 The same security concerns apply for the injection of an IP option, 764 TCP Option and application-related content (e.g., XFF) by the address 765 sharing device. If the server trusts the content of the HOST_ID 766 field, a third party user can be impacted by a misbehaving user to 767 reveal a "faked" HOST_ID (e.g., original IP address). 769 HOST_ID may be used to leak information about the internal structure 770 of a network behind an address sharing function. If this behavior is 771 undesired for the network administrator, the address sharing function 772 can be configured to strip any existing HOST_ID in received packets 773 from internal hosts. 775 HOST_ID specification documents SHOULD elaborate further on threats 776 inherent to each individual solution to convey the HOST_ID (e.g., use 777 of the IP-ID field to count hosts behind a NAT [Count]). 779 8. Acknowledgments 781 Many thanks to D. Wing, C. Jacquenet and J. Halpern for their review, 782 comments and inputs. 784 Thanks also to P. McCann, T. Tsou, Z. Dong, B. Briscoe, T. Taylor, M. 785 Blanchet, D. Wing and A. Yourtchenko for the discussions in Prague. 787 Some of the issues related to defining a new TCP Option have been 788 raised by L. Eggert. 790 Privacy text is provided by A. Cooper. 792 9. References 794 9.1. Normative References 796 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 797 September 1981. 799 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 800 Requirement Levels", BCP 14, RFC 2119, March 1997. 802 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 803 Address Translator (Traditional NAT)", RFC 3022, 804 January 2001. 806 [RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport- 807 Protocol Port Randomization", BCP 156, RFC 6056, 808 January 2011. 810 9.2. Informative References 812 [Count] "A technique for counting NATted hosts", 813 . 815 [ExtendTCP] 816 Honda, M., Nishida, Y., Raiciu, C., Greenhalgh, A., 817 Handley, M. and H. Tokuda,, "Is it still possible to 818 extend TCP?", November 2011, 819 . 821 [I-D.abdo-hostid-tcpopt-implementation] 822 Abdo, E., Boucadair, M., and J. Queiroz, "HOST_ID TCP 823 Options: Implementation & Preliminary Test Results", 824 draft-abdo-hostid-tcpopt-implementation-03 (work in 825 progress), July 2012. 827 [I-D.chen-intarea-v4-uid-header-option] 828 Wu, Y., Ji, H., Chen, Q., and T. ZOU), "IPv4 Header Option 829 For User Identification In CGN Scenario", 830 draft-chen-intarea-v4-uid-header-option-00 (work in 831 progress), March 2011. 833 [I-D.iab-privacy-considerations] 834 Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 835 Morris, J., Hansen, M., and R. Smith, "Privacy 836 Considerations for Internet Protocols", 837 draft-iab-privacy-considerations-03 (work in progress), 838 July 2012. 840 [I-D.ietf-appsawg-http-forwarded] 841 Petersson, A. and M. Nilsson, "Forwarded HTTP Extension", 842 draft-ietf-appsawg-http-forwarded-07 (work in progress), 843 August 2012. 845 [I-D.ietf-intarea-ipv4-id-update] 846 Touch, J., "Updated Specification of the IPv4 ID Field", 847 draft-ietf-intarea-ipv4-id-update-05 (work in progress), 848 May 2012. 850 [I-D.wing-nat-reveal-option] 851 Yourtchenko, A. and D. Wing, "Revealing hosts sharing an 852 IP address using TCP option", 853 draft-wing-nat-reveal-option-03 (work in progress), 854 December 2011. 856 [I-D.yourtchenko-nat-reveal-ping] 857 Yourtchenko, A., "Revealing hosts sharing an IP address 858 using ICMP Echo Request", 859 draft-yourtchenko-nat-reveal-ping-00 (work in progress), 860 March 2012. 862 [IDENT_NAT] 863 Wing, D., "Using the Identification Protocol with an 864 Address Sharing Device", August 2012, 865 . 867 [Not_An_Option] 868 R. Fonseca, G. Porter, R. Katz, S. Shenker, and I. 870 Stoica,, "IP options are not an option", 2005, . 874 [Options] Alberto Medina, Mark Allman, Sally Floyd, "Measuring 875 Interactions Between Transport Protocols and Middleboxes", 876 2005, . 879 [Proxy] Tarreau, W., "The PROXY protocol", November 2010, . 882 [RFC1413] St. Johns, M., "Identification Protocol", RFC 1413, 883 February 1993. 885 [RFC2753] Yavatkar, R., Pendarakis, D., and R. Guerin, "A Framework 886 for Policy-based Admission Control", RFC 2753, 887 January 2000. 889 [RFC5201] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson, 890 "Host Identity Protocol", RFC 5201, April 2008. 892 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 893 NAT64: Network Address and Protocol Translation from IPv6 894 Clients to IPv4 Servers", RFC 6146, April 2011. 896 [RFC6269] Ford, M., Boucadair, M., Durand, A., Levis, P., and P. 897 Roberts, "Issues with IP Address Sharing", RFC 6269, 898 June 2011. 900 [RFC6302] Durand, A., Gashinsky, I., Lee, D., and S. Sheppard, 901 "Logging Recommendations for Internet-Facing Servers", 902 BCP 162, RFC 6302, June 2011. 904 [RFC6346] Bush, R., "The Address plus Port (A+P) Approach to the 905 IPv4 Address Shortage", RFC 6346, August 2011. 907 [RFC6462] Cooper, A., "Report from the Internet Privacy Workshop", 908 RFC 6462, January 2012. 910 [Trusted_ISPs] 911 "Trusted XFF list", . 914 Authors' Addresses 916 Mohamed Boucadair 917 France Telecom 918 Rennes, 35000 919 France 921 Email: mohamed.boucadair@orange.com 923 Joe Touch 924 USC/ISI 926 Email: touch@isi.edu 928 Pierre Levis 929 France Telecom 930 Caen, 14000 931 France 933 Email: pierre.levis@orange.com 935 Reinaldo Penno 936 Cisco 937 USA 939 Email: repenno@cisco.com