idnits 2.17.1 draft-boucadair-intarea-host-identifier-scenarios-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 (December 3, 2012) is 4134 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-10) exists of draft-ietf-intarea-nat-reveal-analysis-04 == Outdated reference: A later version (-04) exists of draft-williams-overlaypath-ip-tcp-rfc-02 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTAREA Working Group M. Boucadair 3 Internet-Draft D. Binet 4 Intended status: Informational S. Durel 5 Expires: June 6, 2013 France Telecom 6 T. Reddy 7 Cisco 8 B. Williams 9 Akamai, Inc. 10 December 3, 2012 12 Host Identification: Use Cases 13 draft-boucadair-intarea-host-identifier-scenarios-02 15 Abstract 17 This document describes a set of scenarios in which host 18 identification is required. 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on June 6, 2013. 37 Copyright Notice 39 Copyright (c) 2012 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 3. Use Case 1: CGN . . . . . . . . . . . . . . . . . . . . . . . 4 57 4. Use Case 2: A+P . . . . . . . . . . . . . . . . . . . . . . . 4 58 5. Use Case 3: Application Proxies . . . . . . . . . . . . . . . 5 59 6. Use Case 4: Open Wi-Fi or Provider Wi-Fi . . . . . . . . . . . 6 60 7. Use Case 5: Policy and Charging Control Architecture . . . . . 7 61 8. Use Case 6: Cellular Networks . . . . . . . . . . . . . . . . 9 62 9. Use Case 7: Femtocells . . . . . . . . . . . . . . . . . . . . 9 63 10. Use Case 8: Overlay Network . . . . . . . . . . . . . . . . . 10 64 11. Security Considerations . . . . . . . . . . . . . . . . . . . 12 65 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 66 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 67 14. Informative References . . . . . . . . . . . . . . . . . . . . 12 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 70 1. Introduction 72 The ultimate goal of this document is to enumerate scenarios which 73 encounter the issue of uniquely identifying a host among those 74 sharing the same IP address. Examples of encountered issues are: 75 o Blacklist a misbehaving host without impacting all hosts sharing 76 the same IP address. 77 o Enforce a per-subscriber/per-UE policy (e.g., limit access to the 78 service based on some counters such as volume-based service 79 offering); enforcing the policy will have impact on all hosts 80 sharing the same IP address. 81 o If invoking a service has failed (e.g., wrong login/passwd), all 82 hosts sharing the same IP address may not be able to access that 83 service. 84 o Need to correlate between the internal address:port and external 85 address:port to generate and therefore to enforce policies. 87 It is out of scope of this document to list all the encountered 88 issues as this is already covered in [RFC6269]. 90 The generic concept of host identifier, denoted as HOST_ID, is 91 defined in [I-D.ietf-intarea-nat-reveal-analysis]. 93 The analysis of the use cases listed in this document indicates two 94 root causes for the host identification issue: 95 1. Presence of address sharing (NAT, A+P, application proxies, 96 etc.). 97 2. Use of tunnels between two administrative domains. 98 3. Combination of NAT and presence of tunnels in the path. 100 The following use cases are identified so far: 101 (1) Section 3: Carrier Grade NAT (CGN) 102 (2) Section 4: A+P (e.g., MAP ) 103 (3) Section 5: Application Proxies 104 (4) Section 6: Provider Wi-Fi 105 (5) Section 7: Policy and Charging Architectures 106 (6) Section 8: Cellular Networks 107 (7) Section 9: Femtocells 108 (8) Section 10: Overlay Networks (e.g., CDNs) 110 2. Scope 112 It is out of scope of this document to argue in favor or against the 113 use cases listed in the following sub-sections. The goal is to 114 identify scenarios the authors are aware of and which share the same 115 issue of host identification. 117 This document does not include any solution-specific discussion. 118 This document can be used as a tool to design solution(s) mitigating 119 the encountered issues. Having a generic solution which would solve 120 the issues encountered in these use cases is preferred over designing 121 a solution for each use case. Describing the use case allows to 122 identify what is common between the use cases and then would help 123 during the solution design phase. 125 The first version of the document does not elaborate whether explicit 126 authentication is enabled or not. 128 3. Use Case 1: CGN 130 Several flavors of stateful CGN have been defined. A non-exhaustive 131 list is provided below: 133 1. NAT44 135 2. DS-Lite NAT44 [RFC6333] 137 3. NAT64 [RFC6146] 139 4. NPTv6 [RFC6296] 141 As discussed in [I-D.ietf-intarea-nat-reveal-analysis], remote 142 servers are not able to distinguish between hosts sharing the same IP 143 address (Figure 1). 144 +-----------+ 145 | HOST_1 |----+ 146 +-----------+ | +--------------------+ +------------+ 147 | | |------| server 1 | 148 +-----------+ +-----+ | | +------------+ 149 | HOST_2 |--| CGN |----| INTERNET | :: 150 +-----------+ +-----+ | | +------------+ 151 | | |------| server n | 152 +-----------+ | +--------------------+ +------------+ 153 | HOST_3 |-----+ 154 +-----------+ 156 Figure 1: CGN: Architecture Example 158 4. Use Case 2: A+P 160 A+P [RFC6346] denotes a flavor of address sharing solutions which 161 does not require any additional NAT function be enabled in the 162 service provider's network. A+P assumes subscribers are assigned 163 with the same IPv4 address together with a port set. Subscribers 164 assigned with the same IPv4 address should be assigned non 165 overlapping port sets. Devices connected to an A+P-enabled network 166 should be able to restrict the IPv4 source port to be within a 167 configure range of ports. To forward incoming packets to the 168 appropriate host, a dedicated entity called PRR (Port Range Router, 169 [RFC6346]) is needed (Figure 2). 171 Similar to the CGN case, the same issue to identify hosts sharing the 172 same IP address is encountered by remote servers. 174 +-----------+ 175 | HOST_1 |----+ 176 +-----------+ | +--------------------+ +------------+ 177 | | |------| server 1 | 178 +-----------+ +-----+ | | +------------+ 179 | HOST_2 |--| PRR |----| INTERNET | :: 180 +-----------+ +-----+ | | +------------+ 181 | | |------| server n | 182 +-----------+ | +--------------------+ +------------+ 183 | HOST_3 |-----+ 184 +-----------+ 186 Figure 2: A+P: Architecture Example 188 5. Use Case 3: Application Proxies 190 This scenario is similar to the CGN scenario. Remote servers are not 191 able to distinguish hosts located behind the PROXY. Applying 192 policies on the perceived external IP address as received from the 193 PROXY will impact all hosts connected to that PROXY. 195 Figure 3 illustrates a simple configuration involving a proxy. Note 196 several (per-application) proxies may be deployed. 198 +-----------+ 199 | HOST_1 |----+ 200 +-----------+ | +--------------------+ +------------+ 201 | | |------| server 1 | 202 +-----------+ +-----+ | | +------------+ 203 | HOST_2 |--|PROXY|----| INTERNET | :: 204 +-----------+ +-----+ | | +------------+ 205 | | |------| server n | 206 +-----------+ | +--------------------+ +------------+ 207 | HOST_3 |-----+ 208 +-----------+ 210 Figure 3: Proxy: Overview 212 6. Use Case 4: Open Wi-Fi or Provider Wi-Fi 214 In the context of Provider Wi-Fi, a dedicated SSID can be configured 215 and advertised by the RG (Residential Gateway) for visiting 216 terminals. These visiting terminals can be mobile terminals, PCs, 217 etc. 219 Several deployment scenarios are envisaged: 221 1. Deploy a dedicated node in the service provider's network which 222 will be responsible to intercept all the traffic issued from 223 visiting terminals (see Figure 4). This node may be co-located 224 with a CGN function if private IPv4 addresses are assigned to 225 visiting terminals. Similar to the CGN case discussed in 226 Section 3, remote servers may not be able to distinguish visiting 227 hosts sharing the same IP address (see [RFC6269]). 229 2. Unlike the previous deployment scenario, IPv4 addresses are 230 managed by the RG without requiring any additional NAT to be 231 deployed in the service provider's network for handling traffic 232 issued from visiting terminals. Concretely, a visiting terminal 233 is assigned with a private IPv4 address from the pool managed by 234 the RG. Packets issued form a visiting terminal are translated 235 using the public IP address assigned to the RG (see Figure 5). 236 This deployment scenario induces the following identification 237 concerns: 239 * The provider is not able to distinguish the traffic belonging 240 to the visiting terminal from the traffic of the subscriber 241 owning the RG. This is needed to apply some policies such as: 242 accounting, DSCP remarking, black list, etc. 244 * Similar to the CGN case Section 3, a misbehaving visiting 245 terminal is likely to have some impact on the experienced 246 service by the customer owning the RG (e.g., some of the 247 issues are discussed in [RFC6269]). 249 +-------------+ 250 |Local_HOST_1 |----+ 251 +-------------+ | 252 | | 253 +-------------+ +-----+ | +-----------+ 254 |Local_HOST_2 |--| RG |-|--|Border Node| 255 +-------------+ +-----+ | +----NAT----+ 256 | | 257 +-------------+ | | Service Provider 258 |Visiting Host|-----+ 259 +-------------+ 261 Figure 4: NAT enforced in a Service Provider's Node 263 +-------------+ 264 |Local_HOST_1 |----+ 265 +-------------+ | 266 | | 267 +-------------+ +-----+ | +-----------+ 268 |Local_HOST_2 |--| RG |-|--|Border Node| 269 +-------------+ +-NAT-+ | +-----------+ 270 | | 271 +-------------+ | | Service Provider 272 |Visiting Host|-----+ 273 +-------------+ 275 Figure 5: NAT located in the RG 277 7. Use Case 5: Policy and Charging Control Architecture 279 This issue is related to the framework defined in [TS.23203] when a 280 NAT is located between the PCEF (Policy and Charging Enforcement 281 Function) and the AF (Application Function) as shown in Figure 6. 283 The main issue is: PCEF, PCRF and AF all receive information bound to 284 the same UE but without being able to correlate between the piece of 285 data visible for each entity. Concretely, 287 o PCEF is aware of the IMSI (International Mobile Subscriber 288 Identity) and an internal IP address assigned to the UE. 290 o AF receives an external IP address and port as assigned by the NAT 291 function. 293 o PCRF is not able to correlate between the external IP address/port 294 assigned by the NAT and the internal IP address and IMSI of the 295 UE. 297 +------+ 298 | PCRF |-----------------+ 299 +------+ | 300 | | 301 +----+ +------+ +-----+ +-----+ 302 | UE |------| PCEF |---| NAT |----| AF | 303 +----+ +------+ +-----+ +-----+ 305 Figure 6 307 This scenario can be generalized as follows (Figure 7): 309 o Policy Enforcement Point (PEP, [RFC2753]) 311 o Policy Decision Point (PDP, [RFC2753]) 313 +------+ 314 | PDP |-----------------+ 315 +------+ | 316 | | 317 +----+ +------+ +-----+ +------+ 318 |Host|------| PEP |---| NAT |----|Server| 319 +----+ +------+ +-----+ +------+ 321 Figure 7 323 A similar issue is encounterd when the NAT is located before the PEP 324 function (see Figure 8): 326 +------+ 327 | PDP |------+ 328 +------+ | 329 | | 330 +----+ +------+ +-----+ +------+ 331 |Host|------| NAT |---| PEP |----|Server| 332 +----+ +------+ +-----+ +------+ 334 Figure 8 336 8. Use Case 6: Cellular Networks 338 Cellular operators allocate private IPv4 addresses to mobile 339 customers and deploy NAT44 function, generally co-located with 340 firewalls, to access to public IP services. The NAT function is 341 located at the boundaries of the PLMN. IPv6-only strategy, 342 consisting in allocating IPv6 prefixes only to customers, is 343 considered by various operators. A NAT64 function is also considered 344 in order to preserve IPv4 service continuity for these customers. 346 These NAT44 and NAT64 functions bring some issues very similar to 347 those mentioned in Figure 1 and Section 7. This issue is 348 particularly encountered if policies are to be applied on the Gi 349 interface: a private IP address may be assigned to several UEs, no 350 correlation between the internal IP address and the address:port 351 assigned by the NAT function, etc. 353 9. Use Case 7: Femtocells 355 This issue is discussed in [I-D.so-ipsecme-ikev2-cpext]. This use 356 case can be seen as a combination of the use cases described in 357 Section 6 and Section 7. 359 The reference architecture, originally provided in 360 [I-D.so-ipsecme-ikev2-cpext], is shown in Figure 8. 362 +---------------------------+ 363 | +----+ +--------+ +----+ | +-----------+ +-------------------+ 364 | | UE | | Stand- |<=|====|=|===|===========|==|=>+--+ +--+ | 365 | +----+ | alone | | RG | | | | | | | | | Mobile | 366 | | FAP | +----+ | | | | |S | |F | Network| 367 | +--------+ (NAPT) | | Broadband | | |e | |A | | 368 +---------------------------+ | Fixed | | |G |-|P | +-----+| 369 | Network | | |W | |G |-| Core|| 370 +---------------------------+ | (BBF) | | | | |W | | Ntwk|| 371 | +----+ +------------+ | | | | | | | | +-----+| 372 | | UE | | Integrated |<====|===|===========|==|=>+--+ +--+ | 373 | +----+ | FAP (NAPT) | | +-----------+ +-------------------+ 374 | +------------+ | 375 +---------------------------+ 377 <=====> IPsec tunnel 378 CoreNtwk Core Network 379 FAPGW FAP Gateway 380 SeGW Security Gateway 382 Figure 9: Femtocell: Overall Architecture 384 UE is connected to the FAP at the residential gateway (RG), routed 385 back to 3GPP Evolved Packet Core (EPC). UE is assigned IPv4 address 386 by the Mobile Network. Mobile operator's FAP leverages the IPSec 387 IKEv2 to interconnect FAP with the SeGW over the BBF network. Both 388 the FAP and the SeGW are managed by the mobile operator which may be 389 a different operator for the BBF network. 391 An investigated scenario is the mobile network to pass on its mobile 392 subscriber's policies to the BBF to support remote network 393 management. But most of today's broadband fixed networks are relying 394 on the private IPv4 addressing plan (+NAPT) to support its attached 395 devices including the mobile operator's FAP. In this scenario, the 396 mobile network needs to: 398 o determine the FAP's public IPv4 address to identify the location 399 of the FAP to ensure its legitimacy to operate on the license 400 spectrum for a given mobile operator prior to the FAP be ready to 401 serve its mobile devices. 403 o determine the FAP's pubic IPv4 address together with the 404 translated port number of the UDP header of the encapsulated IPsec 405 tunnel for identifying the UE's traffic at the fixed broadband 406 network. 408 o determine the corresponding FAP's public IPv4 address associated 409 with the UE's inner-IPv4 address which is assigned by the mobile 410 network to identify the mobile UE to allow the PCRF to retrieve 411 the UE's policy (e.g., QoS) to be passed onto the Broadband Policy 412 Control Function (BPCF) at the BBF network. 414 SecGW would have the complete knowledge of such mapping, but the 415 reasons for unable to use SecGW for this purpose is explained in 416 "Problem Statements" (section 2 of [I-D.so-ipsecme-ikev2-cpext]). 418 This use case makes use of PCRF/BPCF but it is valid in other 419 deployment scenarios making use of AAA servers. 421 The issue of correlating the internal IP address and the public IP 422 address is valid even if there is no NAT in the path. 424 10. Use Case 8: Overlay Network 426 An overlay network is a network of machines distributed throughout 427 multiple autonomous systems within the public Internet that can be 428 used to improve the performance of data transport (see Figure 10). 429 IP packets from the sender are delivered first to one of the machines 430 that make up the overlay network. That machine then relays the IP 431 packets to the receiver via one or more machines in the overlay 432 network, applying various performance enhancement methods. 434 +------------------------------------+ 435 | | 436 | INTERNET | 437 | | 438 +-----------+ | +------------+ | 439 | HOST_1 |-----| OVRLY_IN_1 |-----------+ | 440 +-----------+ | +------------+ | | 441 | | | 442 +-----------+ | +------------+ +-----------+ | +--------+ 443 | HOST_2 |-----| OVRLY_IN_2 |-----| OVRLY_OUT |-----| SERVER | 444 +-----------+ | +------------+ +-----------+ | +--------+ 445 | | | 446 +-----------+ | +------------+ | | 447 | HOST_3 |-----| OVRLY_IN_3 |-----------+ | 448 +-----------+ | +------------+ | 449 | | 450 +------------------------------------+ 452 Figure 10: Overlay Network 454 Data transport using an overlay network requires network address 455 translation for both the source and destination addresses in such a 456 way that the public IP addresses of the true endpoint machines 457 involved in data transport are invisible to each other (see 458 Figure 11). In other words, the true sender and receiver use two 459 completely different pairs of source and destination addresses to 460 identify the connection on the sending and receiving networks. 462 ip hdr contains: ip hdr contains: 463 SENDER -> src = sender --> OVERLAY --> src = overlay2 --> RECEIVER 464 dst = overlay1 dst = receiver 466 Figure 11: NAT operations in an Overlay Network 468 This scenario is similar to the CGN (Section 3) and proxy (Section 5) 469 scenarios. The remote server is not able to distinguish among hosts 470 using the overlay for transport. In addition, the remote server is 471 not able to determine the overlay ingress point being used by the 472 host, which can be useful for diagnosing host connectivity issues. 474 More details about this use case are provided in 475 [I-D.williams-overlaypath-ip-tcp-rfc]. 477 11. Security Considerations 479 This document does not define an architecture nor a protocol; as such 480 it does not raise any security concern. 482 12. IANA Considerations 484 This document does not require any action from IANA. 486 13. Acknowledgments 488 Many thanks to F. Klamm for the review. 490 Figure 8 and part of the text in Section 9 are inspired from 491 [I-D.so-ipsecme-ikev2-cpext]. 493 14. Informative References 495 [I-D.ietf-intarea-nat-reveal-analysis] 496 Boucadair, M., Touch, J., Levis, P., and R. Penno, 497 "Analysis of Solution Candidates to Reveal a Host 498 Identifier (HOST_ID) in Shared Address Deployments", 499 draft-ietf-intarea-nat-reveal-analysis-04 (work in 500 progress), August 2012. 502 [I-D.so-ipsecme-ikev2-cpext] 503 So, T., "IKEv2 Configuration Payload Extension for Private 504 IPv4 Support for Fixed Mobile Convergence", 505 draft-so-ipsecme-ikev2-cpext-02 (work in progress), 506 June 2012. 508 [I-D.williams-overlaypath-ip-tcp-rfc] 509 Williams, B., "Overlay Path Option for IP and TCP", 510 draft-williams-overlaypath-ip-tcp-rfc-02 (work in 511 progress), September 2012. 513 [RFC2753] Yavatkar, R., Pendarakis, D., and R. Guerin, "A Framework 514 for Policy-based Admission Control", RFC 2753, 515 January 2000. 517 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 518 NAT64: Network Address and Protocol Translation from IPv6 519 Clients to IPv4 Servers", RFC 6146, April 2011. 521 [RFC6269] Ford, M., Boucadair, M., Durand, A., Levis, P., and P. 523 Roberts, "Issues with IP Address Sharing", RFC 6269, 524 June 2011. 526 [RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix 527 Translation", RFC 6296, June 2011. 529 [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 530 Stack Lite Broadband Deployments Following IPv4 531 Exhaustion", RFC 6333, August 2011. 533 [RFC6346] Bush, R., "The Address plus Port (A+P) Approach to the 534 IPv4 Address Shortage", RFC 6346, August 2011. 536 [TS.23203] 537 3GPP, "Policy and charging control architecture", 538 September 2012. 540 Authors' Addresses 542 Mohamed Boucadair 543 France Telecom 544 Rennes, 35000 545 France 547 Email: mohamed.boucadair@orange.com 549 David Binet 550 France Telecom 551 Rennes, 552 France 554 Email: david.binet@orange.com 556 Sophie Durel 557 France Telecom 558 Rennes 559 France 561 Email: sophie.durel@orange.com 562 Tirumaleswar Reddy 563 Cisco Systems, Inc. 564 Cessna Business Park, Varthur Hobli 565 Sarjapur Marathalli Outer Ring Road 566 Bangalore, Karnataka 560103 567 India 569 Email: tireddy@cisco.com 571 Brandon Williams 572 Akamai, Inc. 573 Cambridge, MA 574 USA 576 Phone: 577 Fax: 578 Email: brandon.williams@akamai.com 579 URI: