idnits 2.17.1 draft-boucadair-intarea-host-identifier-scenarios-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 (October 17, 2012) is 4209 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 Summary: 0 errors (**), 0 flaws (~~), 2 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: April 20, 2013 France Telecom 6 T. Reddy 7 Cisco 8 October 17, 2012 10 HOST_ID: Use Cases 11 draft-boucadair-intarea-host-identifier-scenarios-01 13 Abstract 15 This document describes a set of scenarios in which host 16 identification is required. 18 Status of this Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on April 20, 2013. 35 Copyright Notice 37 Copyright (c) 2012 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 3. Use Case 1: CGN . . . . . . . . . . . . . . . . . . . . . . . 4 55 4. Use Case 2: A+P . . . . . . . . . . . . . . . . . . . . . . . 4 56 5. Use Case 3: Application Proxies . . . . . . . . . . . . . . . 5 57 6. Use Case 4: Open Wi-Fi or Provider Wi-Fi . . . . . . . . . . . 6 58 7. Use Case 5: Policy and Charging Control Architecture . . . . . 7 59 8. Use Case 6: Cellular Networks . . . . . . . . . . . . . . . . 8 60 9. Use Case 7: Femtocells . . . . . . . . . . . . . . . . . . . . 9 61 10. Security Considerations . . . . . . . . . . . . . . . . . . . 10 62 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 63 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 64 13. Informative References . . . . . . . . . . . . . . . . . . . . 10 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 67 1. Introduction 69 The ultimate goal of this document is to enumerate scenarios which 70 encounter the issue of uniquely identifying a host among those 71 sharing the same IP address. Examples of encountered issues are: 73 o Blacklist a misbehaving host without impacting all hosts sharing 74 the same IP address. 76 o Enforce a per-subscriber/per-UE policy (e.g., limit access to the 77 service based on some counters such as volume-based service 78 offering); enforcing the policy will have impact on all hosts 79 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. 85 o Need to correlate between the internal address:port and external 86 address:port to generate and therefore to enforce policies. 88 It is out of scope of this document to list all the encountered 89 issues as this is already covered in [RFC6269]. 91 The generic concept of host identifier, denoted as HOST_ID, is 92 defined in [I-D.ietf-intarea-nat-reveal-analysis]. 94 The analysis of the use cases listed in this document indicates two 95 root causes for the host identification issue: 97 1. Presence of address sharing (NAT, A+P, application proxies, 98 etc.). 100 2. Use of tunnels between two administrative domains. 102 3. Combination of NAT and presence of tunnels in the path. 104 2. Scope 106 It is out of scope of this document to argue in favor or against the 107 use cases listed in the following sub-sections. The goal is to 108 identify scenarios the authors are aware of and which share the same 109 issue of host identification. 111 This document does not include any solution-specific discussion. 112 This document can be used as a tool to design solution(s) mitigating 113 the encountered issues. Having a generic solution which would solve 114 the issues encountered in these use cases is preferred over designing 115 a solution for each use case. Describing the use case allows to 116 identify what is common between the use cases and then would help 117 during the solution design phase. 119 The first version of the document does not elaborate whether explicit 120 authentication is enabled or not. 122 3. Use Case 1: CGN 124 Several flavors of stateful CGN have been defined. A non-exhaustive 125 list is provided below: 127 1. NAT44 129 2. DS-Lite NAT44 [RFC6333] 131 3. NAT64 [RFC6146] 133 4. NPTv6 [RFC6296] 135 As discussed in [I-D.ietf-intarea-nat-reveal-analysis], remote 136 servers are not able to distinguish between hosts sharing the same IP 137 address (Figure 1). 138 +-----------+ 139 | HOST_1 |----+ 140 +-----------+ | +--------------------+ +------------+ 141 | | |------| server 1 | 142 +-----------+ +-----+ | | +------------+ 143 | HOST_2 |--| CGN |----| INTERNET | :: 144 +-----------+ +-----+ | | +------------+ 145 | | |------| server n | 146 +-----------+ | +--------------------+ +------------+ 147 | HOST_3 |-----+ 148 +-----------+ 150 Figure 1 152 4. Use Case 2: A+P 154 A+P [RFC6346] denotes a flavor of address sharing solutions which 155 does not require any additional NAT function be enabled in the 156 service provider's network. A+P assumes subscribers are assigned 157 with the same IPv4 address together with a port set. Subscribers 158 assigned with the same IPv4 address should be assigned non 159 overlapping port sets. Devices connected to an A+P-enabled network 160 should be able to restrict the IPv4 source port to be within a 161 configure range of ports. To forward incoming packets to the 162 appropriate host, a dedicated entity called PRR (Port Range Router, 163 [RFC6346]) is needed (Figure 2). 165 Similar to the CGN case, the same issue to identify hosts sharing the 166 same IP address is encountered by remote servers. 168 +-----------+ 169 | HOST_1 |----+ 170 +-----------+ | +--------------------+ +------------+ 171 | | |------| server 1 | 172 +-----------+ +-----+ | | +------------+ 173 | HOST_2 |--| PRR |----| INTERNET | :: 174 +-----------+ +-----+ | | +------------+ 175 | | |------| server n | 176 +-----------+ | +--------------------+ +------------+ 177 | HOST_3 |-----+ 178 +-----------+ 180 Figure 2 182 5. Use Case 3: Application Proxies 184 This scenario is similar to the CGN scenario. Remote servers are not 185 able to distinguish hosts located behind the PROXY. Applying 186 policies on the perceived external IP address as received from the 187 PROXY will impact all hosts connected to that PROXY. 189 Figure 3 illustrates a simple configuration involving a proxy. Note 190 several (per-application) proxies may be deployed. 192 +-----------+ 193 | HOST_1 |----+ 194 +-----------+ | +--------------------+ +------------+ 195 | | |------| server 1 | 196 +-----------+ +-----+ | | +------------+ 197 | HOST_2 |--|PROXY|----| INTERNET | :: 198 +-----------+ +-----+ | | +------------+ 199 | | |------| server n | 200 +-----------+ | +--------------------+ +------------+ 201 | HOST_3 |-----+ 202 +-----------+ 203 Figure 3 205 6. Use Case 4: Open Wi-Fi or Provider Wi-Fi 207 In the context of Provider Wi-Fi, a dedicated SSID can be configured 208 and advertised by the RG (Residential Gateway) for visiting 209 terminals. These visiting terminals can be mobile terminals, PCs, 210 etc. 212 Several deployment scenarios are envisaged: 214 1. Deploy a dedicated node in the service provider's network which 215 will be responsible to intercept all the traffic issued from 216 visiting terminals (see Figure 4). This node may be co-located 217 with a CGN function if private IPv4 addresses are assigned to 218 visiting terminals. Similar to the CGN case discussed in 219 Section 3, remote servers may not be able to distinguish visiting 220 hosts sharing the same IP address (see [RFC6269]). 222 2. Unlike the previous deployment scenario, IPv4 addresses are 223 managed by the RG without requiring any additional NAT to be 224 deployed in the service provider's network for handling traffic 225 issued from visiting terminals. Concretely, a visiting terminal 226 is assigned with a private IPv4 address from the pool managed by 227 the RG. Packets issued form a visiting terminal are translated 228 using the public IP address assigned to the RG (see Figure 5). 229 This deployment scenario induces the following identification 230 concerns: 232 * The provider is not able to distinguish the traffic belonging 233 to the visiting terminal from the traffic of the subscriber 234 owning the RG. This is needed to apply some policies such as: 235 accounting, DSCP remarking, black list, etc. 237 * Similar to the CGN case Section 3, a misbehaving visiting 238 terminal is likely to have some impact on the experienced 239 service by the customer owning the RG (e.g., some of the 240 issues are discussed in [RFC6269]). 242 +-----------+ 243 | TV |----+ 244 +-----------+ | 245 | | 246 +-----------+ +-----+ | +-----------+ 247 | HOST |--| RG |-|--|Border Node| 248 +-----------+ +-----+ | +----NAT----+ 249 | | 250 +-----------+ | | Service Provider 251 |Visiting UE|-----+ 252 +-----------+ 254 Figure 4 256 +-----------+ 257 | TV |----+ 258 +-----------+ | 259 | | 260 +-----------+ +-----+ | +-----------+ 261 | HOST |--| RG |-|--|Border Node| 262 +-----------+ +-NAT-+ | +-----------+ 263 | | 264 +-----------+ | | Service Provider 265 |Visiting UE|-----+ 266 +-----------+ 268 Figure 5 270 7. Use Case 5: Policy and Charging Control Architecture 272 This issue is related to the framework defined in [TS.23203] when a 273 NAT is located between the PCEF (Policy and Charging Enforcement 274 Function) and the AF (Application Function) as shown in Figure 6. 276 The main issue is: PCEF, PCRF and AF all receive information bound to 277 the same UE but without being able to correlate between the piece of 278 data visible for each entity. Concretely, 280 o PCEF is aware of the IMSI (International Mobile Subscriber 281 Identity) and an internal IP address assigned to the UE. 283 o AF receives an external IP address and port as assigned by the NAT 284 function. 286 o PCRF is not able to correlate between the external IP address/port 287 assigned by the NAT and the internal IP address and IMSI of the 288 UE. 290 +------+ 291 | PCRF |-----------------+ 292 +------+ | 293 | | 294 +----+ +------+ +-----+ +-----+ 295 | UE |------| PCEF |---| NAT |----| AF | 296 +----+ +------+ +-----+ +-----+ 298 Figure 6 300 This scenario can be generalized as follows (Figure 7): 302 o Policy Enforcement Point (PEP, [RFC2753]) 304 o Policy Decision Point (PDP, [RFC2753]) 306 +------+ 307 | PDP |-----------------+ 308 +------+ | 309 | | 310 +----+ +------+ +-----+ +------+ 311 |Host|------| PEP |---| NAT |----|Server| 312 +----+ +------+ +-----+ +------+ 314 Figure 7 316 8. Use Case 6: Cellular Networks 318 Cellular operators allocate private IPv4 addresses to mobile 319 customers and deploy NAT44 function, generally co-located with 320 firewalls, to access to public IP services. The NAT function is 321 located at the boundaries of the PLMN. IPv6-only strategy, 322 consisting in allocating IPv6 prefixes only to customers, is 323 considered by various operators. A NAT64 function is also considered 324 in order to preserve IPv4 service continuity for these customers. 326 These NAT44 and NAT64 functions bring some issues very similar to 327 those mentioned in Figure 1 and Section 7. This issue is 328 particularly encountered if policies are to be applied on the Gi 329 interface: a private IP address may be assigned to several UEs, no 330 correlation between the internal IP address and the address:port 331 assigned by the NAT function, etc. 333 9. Use Case 7: Femtocells 335 This issue is discussed in [I-D.so-ipsecme-ikev2-cpext]. This use 336 case can be seen as a combination of the use cases described in 337 Section 6 and Section 7. 339 The reference architecture, originally provided in 340 [I-D.so-ipsecme-ikev2-cpext], is shown in Figure 8. 342 +---------------------------+ 343 | +----+ +--------+ +----+ | +-----------+ +-------------------+ 344 | | UE | | Stand- |<=|====|=|===|===========|==|=>+--+ +--+ | 345 | +----+ | alone | | RG | | | | | | | | | Mobile | 346 | | FAP | +----+ | | | | |S | |F | Network| 347 | +--------+ (NAPT) | | Broadband | | |e | |A | | 348 +---------------------------+ | Fixed | | |G |-|P | +-----+| 349 | Network | | |W | |G |-| Core|| 350 +---------------------------+ | (BBF) | | | | |W | | Ntwk|| 351 | +----+ +------------+ | | | | | | | | +-----+| 352 | | UE | | Integrated |<====|===|===========|==|=>+--+ +--+ | 353 | +----+ | FAP (NAPT) | | +-----------+ +-------------------+ 354 | +------------+ | 355 +---------------------------+ 357 <=====> IPsec tunnel 358 CoreNtwk Core Network 359 FAPGW FAP Gateway 360 SeGW Security Gateway 362 Figure 8 364 UE is connected to the FAP at the residential gateway (RG), routed 365 back to 3GPP Evolved Packet Core (EPC). UE is assigned IPv4 address 366 by the Mobile Network. Mobile operator's FAP leverages the IPSec 367 IKEv2 to interconnect FAP with the SeGW over the BBF network. Both 368 the FAP and the SeGW are managed by the mobile operator which may be 369 a different operator for the BBF network. 371 An investigated scenario is the mobile network to pass on its mobile 372 subscriber's policies to the BBF to support remote network 373 management. But most of today's broadband fixed networks are relying 374 on the private IPv4 addressing plan (+NAPT) to support its attached 375 devices including the mobile operator's FAP. In this scenario, the 376 mobile network needs to: 378 o determine the FAP's public IPv4 address to identify the location 379 of the FAP to ensure its legitimacy to operate on the license 380 spectrum for a given mobile operator prior to the FAP be ready to 381 serve its mobile devices. 383 o determine the FAP's pubic IPv4 address together with the 384 translated port number of the UDP header of the encapsulated IPsec 385 tunnel for identifying the UE's traffic at the fixed broadband 386 network. 388 o determine the corresponding FAP's public IPv4 address associated 389 with the UE's inner-IPv4 address which is assigned by the mobile 390 network to identify the mobile UE to allow the PCRF to retrieve 391 the UE's policy (e.g., QoS) to be passed onto the Broadband Policy 392 Control Function (BPCF) at the BBF network. 394 SecGW would have the complete knowledge of such mapping, but the 395 reasons for unable to use SecGW for this purpose is explained in 396 "Problem Statements" (section 2 of [I-D.so-ipsecme-ikev2-cpext]). 398 This use case makes use of PCRF/BPCF but it is valid in other 399 deployment scenarios making use of AAA servers. 401 The issue of correlating the internal IP address and the public IP 402 address is valid even if there is no NAT in the path. 404 10. Security Considerations 406 This document does not define an architecture nor a protocol; as such 407 it does not raise any security concern. 409 11. IANA Considerations 411 This document does not require any action from IANA. 413 12. Acknowledgments 415 Many thanks to F. Klamm for the review. 417 Figure 8 and part of the text in Section 9 are inspired from 418 [I-D.so-ipsecme-ikev2-cpext]. 420 13. Informative References 422 [I-D.ietf-intarea-nat-reveal-analysis] 423 Boucadair, M., Touch, J., Levis, P., and R. Penno, 424 "Analysis of Solution Candidates to Reveal a Host 425 Identifier (HOST_ID) in Shared Address Deployments", 426 draft-ietf-intarea-nat-reveal-analysis-04 (work in 427 progress), August 2012. 429 [I-D.so-ipsecme-ikev2-cpext] 430 So, T., "IKEv2 Configuration Payload Extension for Private 431 IPv4 Support for Fixed Mobile Convergence", 432 draft-so-ipsecme-ikev2-cpext-02 (work in progress), 433 June 2012. 435 [RFC2753] Yavatkar, R., Pendarakis, D., and R. Guerin, "A Framework 436 for Policy-based Admission Control", RFC 2753, 437 January 2000. 439 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 440 NAT64: Network Address and Protocol Translation from IPv6 441 Clients to IPv4 Servers", RFC 6146, April 2011. 443 [RFC6269] Ford, M., Boucadair, M., Durand, A., Levis, P., and P. 444 Roberts, "Issues with IP Address Sharing", RFC 6269, 445 June 2011. 447 [RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix 448 Translation", RFC 6296, June 2011. 450 [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 451 Stack Lite Broadband Deployments Following IPv4 452 Exhaustion", RFC 6333, August 2011. 454 [RFC6346] Bush, R., "The Address plus Port (A+P) Approach to the 455 IPv4 Address Shortage", RFC 6346, August 2011. 457 [TS.23203] 458 3GPP, "Policy and charging control architecture", 459 September 2012. 461 Authors' Addresses 463 Mohamed Boucadair 464 France Telecom 465 Rennes, 35000 466 France 468 Email: mohamed.boucadair@orange.com 469 David Binet 470 France Telecom 471 Rennes, 472 France 474 Email: david.binet@orange.com 476 Sophie Durel 477 France Telecom 478 Rennes 479 France 481 Email: sophie.durel@orange.com 483 Tirumaleswar Reddy 484 Cisco Systems, Inc. 485 Cessna Business Park, Varthur Hobli 486 Sarjapur Marathalli Outer Ring Road 487 Bangalore, Karnataka 560103 488 India 490 Email: tireddy@cisco.com