idnits 2.17.1 draft-boucadair-intarea-host-identifier-scenarios-00.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 11, 2012) is 4187 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 14, 2013 France Telecom 6 October 11, 2012 8 HOST_ID: Use Cases 9 draft-boucadair-intarea-host-identifier-scenarios-00 11 Abstract 13 This document describes a set of scenarios in which host 14 identification is required. 16 Status of this Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at http://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on April 14, 2013. 33 Copyright Notice 35 Copyright (c) 2012 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 3. Use Case 1: CGN . . . . . . . . . . . . . . . . . . . . . . . . 3 53 4. Use Case 2: A+P . . . . . . . . . . . . . . . . . . . . . . . . 4 54 5. Use Case 3: Application Proxies . . . . . . . . . . . . . . . . 5 55 6. Use Case 4: Open Wi-Fi or Provider Wi-Fi . . . . . . . . . . . 5 56 7. Use Case 5: Policy and Charging Control Architecture . . . . . 7 57 8. Use Case 6: Cellular Networks . . . . . . . . . . . . . . . . . 8 58 9. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 59 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 60 11. Informative References . . . . . . . . . . . . . . . . . . . . 8 61 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 63 1. Introduction 65 The ultimate goal of this document is to enumerate scenarios which 66 encounter the issue of uniquely identifying a host among those 67 sharing the same IP address. Examples of encountered issues are: 69 o Blacklist a misbehaving host without impacting all hosts sharing 70 the same IP address. 72 o If a remote server enforces a policy to limit access to the 73 service (based on some counters), the policy will have impact on 74 all hosts sharing the same IP address. 76 o If access to a service has failed (e.g., wrong login/passwd), all 77 hosts sharing the same IP address may not be able to access that 78 service. 80 It is out of scope of this document to list all the encountered 81 issues as this is already covered in [RFC6269]. 83 The generic concept of host identifier, denoted as HOST_ID, is 84 defined in [I-D.ietf-intarea-nat-reveal-analysis]. 86 2. Scope 88 It is out of scope of this document to argue in favor or against the 89 use cases listed in the following sub-sections. The goal is to 90 identify scenarios the authors are aware of and which share the same 91 issue of host identification. 93 This document does not include any solution-specific discussion. 94 This document can be used as a tool to design solution(s) mitigating 95 the encountered issues. Having a generic solution which would solve 96 the issues encountered in these use cases is preferred over designing 97 a solution for each use case. Describing the use case allows to 98 identify what is common between the use cases and then would help 99 during the solution design phase. 101 The first version of the document does not elaborate whether explicit 102 authentication is enabled or not. 104 3. Use Case 1: CGN 106 Several flavors of stateful CGN have been defined. A non-exhaustive 107 list is provided below: 109 1. NAT44 111 2. DS-Lite NAT44 [RFC6333] 113 3. NAT64 [RFC6146] 115 4. NPTv6 [RFC6296] 117 As discussed in [I-D.ietf-intarea-nat-reveal-analysis], remote 118 servers are not able to distinguish between hosts sharing the same IP 119 address (Figure 1). 120 +-----------+ 121 | HOST_1 |----+ 122 +-----------+ | +--------------------+ +------------+ 123 | | |------| server 1 | 124 +-----------+ +-----+ | | +------------+ 125 | HOST_2 |--| CGN |----| INTERNET | :: 126 +-----------+ +-----+ | | +------------+ 127 | | |------| server n | 128 +-----------+ | +--------------------+ +------------+ 129 | HOST_3 |-----+ 130 +-----------+ 132 Figure 1 134 4. Use Case 2: A+P 136 A+P [RFC6346] denotes a flavor of address sharing solutions which 137 does not require any additional NAT function be enabled in the 138 service provider's network. A+P assumes subscribers are assigned 139 with the same IPv4 address together with a port set. Subscribers 140 assigned with the same IPv4 address should be assigned non 141 overlapping port sets. Devices connected to an A+P-enabled network 142 should be able to restrict the IPv4 source port to be within a 143 configure range of ports. To forward incoming packets to the 144 appropriate host, a dedicated entity called PRR (Port Range Router, 145 [RFC6346]) is needed (Figure 2). 147 Similar to the CGN case, the same issue to identify hosts sharing the 148 same IP address is encountered by remote servers. 150 +-----------+ 151 | HOST_1 |----+ 152 +-----------+ | +--------------------+ +------------+ 153 | | |------| server 1 | 154 +-----------+ +-----+ | | +------------+ 155 | HOST_2 |--| PRR |----| INTERNET | :: 156 +-----------+ +-----+ | | +------------+ 157 | | |------| server n | 158 +-----------+ | +--------------------+ +------------+ 159 | HOST_3 |-----+ 160 +-----------+ 162 Figure 2 164 5. Use Case 3: Application Proxies 166 This scenario is similar to the CGN scenario. Remote servers are not 167 able to distinguish hosts located behind the PROXY. Applying 168 policies on the perceived external IP address as received from the 169 PROXY will impact all hosts connected to that PROXY. 171 Figure 3 illustrates a simple configuration involving a proxy. Note 172 several (per-application) proxies may be deployed. 174 +-----------+ 175 | HOST_1 |----+ 176 +-----------+ | +--------------------+ +------------+ 177 | | |------| server 1 | 178 +-----------+ +-----+ | | +------------+ 179 | HOST_2 |--|PROXY|----| INTERNET | :: 180 +-----------+ +-----+ | | +------------+ 181 | | |------| server n | 182 +-----------+ | +--------------------+ +------------+ 183 | HOST_3 |-----+ 184 +-----------+ 186 Figure 3 188 6. Use Case 4: Open Wi-Fi or Provider Wi-Fi 190 In the context of Provider Wi-Fi (also called Open Wi-Fi or FMC 191 scenario), a dedicated SSID can be configured and advertised by a CPE 192 for visiting terminals. These visiting terminals can be mobile 193 terminals, PCs, etc. 195 Several deployment scenarios are envisaged: 197 1. Deploy a dedicated node in the service provider's network which 198 will be responsible to intercept all the traffic issued from 199 visiting terminals (see Figure 4). This node may be co-located 200 with a CGN function if private IPv4 addresses are assigned to 201 visiting terminals. Similar to the CGN case discussed in 202 Section 3, remote servers may not be able to distinguish visiting 203 hosts sharing the same IP address (see [RFC6269]). 205 2. Unlike the previous deployment scenario, IPv4 addresses are 206 managed by the CPE without requiring any additional NAT to be 207 deployed in the service provider's network for handling traffic 208 issued from visiting terminals. Concretely, a visiting terminal 209 is assigned with a private IPv4 address from the pool managed by 210 the CPE. Packets issued form a visiting terminal are translated 211 using the public IP address assigned to the CPE (see Figure 5). 212 This deployment scenario induces the following identification 213 concerns: 215 * The provider is not able to distinguish the traffic belonging 216 to the visiting terminal from the traffic of the subscriber 217 owning the CPE. This is needed to apply some policies such 218 as: accounting, DSCP remarking, black list, etc. 220 * Similar to the CGN case Section 3, a misbehaving visiting 221 terminal is likely to have some impact on the experienced 222 service by the customer owning the CPE (e.g., some of the 223 issues are discussed in [RFC6269]). 225 +-----------+ 226 | TV |----+ 227 +-----------+ | 228 | | 229 +-----------+ +-----+ | +-----------+ 230 | HOST |--| CPE |-|--|Border Node| 231 +-----------+ +-----+ | +----NAT----+ 232 | | 233 +-----------+ | | Service Provider 234 |Visiting UE|-----+ 235 +-----------+ 237 Figure 4 239 +-----------+ 240 | TV |----+ 241 +-----------+ | 242 | | 243 +-----------+ +-----+ | +-----------+ 244 | HOST |--| CPE |-|--|Border Node| 245 +-----------+ +-NAT-+ | +-----------+ 246 | | 247 +-----------+ | | Service Provider 248 |Visiting UE|-----+ 249 +-----------+ 251 Figure 5 253 7. Use Case 5: Policy and Charging Control Architecture 255 This issue is related to the framework defined in [TS.23203] when a 256 NAT is located between the PCEF (Policy and Charging Enforcement 257 Function) and the AF (Application Function) as shown in Figure 6. 259 The main issue is: PCEF, PCRF and AF all receive information bound to 260 the same UE but without being able to correlate between the piece of 261 data visible for each entity. Concretely, 263 o PCEF is aware of the IMSI (International Mobile Subscriber 264 Identity) and an internal IP address assigned to the UE. 266 o AF receives an external IP address and port as assigned by the NAT 267 function. 269 o PCRF is not able to correlate between the external IP address/port 270 assigned by the NAT and the internal IP address and IMSI of the 271 UE. 273 +------+ 274 | PCRF |-----------------+ 275 +------+ | 276 | | 277 +----+ +------+ +-----+ +-----+ 278 | UE |------| PCEF |---| NAT |----| AF | 279 +----+ +------+ +-----+ +-----+ 281 Figure 6 283 This scenario can be generalized as follows (Figure 7): 285 o Policy Enforcement Point (PEP, [RFC2753]) 287 o Policy Decision Point (PDP, [RFC2753]) 289 +------+ 290 | PDP |-----------------+ 291 +------+ | 292 | | 293 +----+ +------+ +-----+ +------+ 294 |Host|------| PEP |---| NAT |----|Server| 295 +----+ +------+ +-----+ +------+ 297 Figure 7 299 8. Use Case 6: Cellular Networks 301 Cellular operators allocate private IPv4 addresses to mobile 302 customers and deploy NAT44 function, generally co-located with 303 firewalls, to access to public IP services. The NAT function is 304 located at the boundaries of the PLMN. IPv6-only strategy, 305 consisting in allocating IPv6 prefixes only to customers, is 306 considered by various operators. A NAT64 function is also considered 307 in order to preserve IPv4 service continuity for these customers. 309 These NAT44 and NAT64 functions bring some issues very similar to 310 those mentioned in Figure 1 and Section 7. This issue is 311 particularly encountered if policies are to be applied on the Gi 312 interface: a private IP address may be assigned to several UEs, no 313 correlation between the internal IP address and the address:port 314 assigned by the NAT function, etc. 316 9. Security Considerations 318 This document does not define an architecture nor a protocol; as such 319 it does not raise any security concern. 321 10. IANA Considerations 323 This document does not require any action from IANA. 325 11. Informative References 327 [I-D.ietf-intarea-nat-reveal-analysis] 328 Boucadair, M., Touch, J., Levis, P., and R. Penno, 329 "Analysis of Solution Candidates to Reveal a Host 330 Identifier (HOST_ID) in Shared Address Deployments", 331 draft-ietf-intarea-nat-reveal-analysis-04 (work in 332 progress), August 2012. 334 [RFC2753] Yavatkar, R., Pendarakis, D., and R. Guerin, "A Framework 335 for Policy-based Admission Control", RFC 2753, 336 January 2000. 338 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 339 NAT64: Network Address and Protocol Translation from IPv6 340 Clients to IPv4 Servers", RFC 6146, April 2011. 342 [RFC6269] Ford, M., Boucadair, M., Durand, A., Levis, P., and P. 343 Roberts, "Issues with IP Address Sharing", RFC 6269, 344 June 2011. 346 [RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix 347 Translation", RFC 6296, June 2011. 349 [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 350 Stack Lite Broadband Deployments Following IPv4 351 Exhaustion", RFC 6333, August 2011. 353 [RFC6346] Bush, R., "The Address plus Port (A+P) Approach to the 354 IPv4 Address Shortage", RFC 6346, August 2011. 356 [TS.23203] 357 3GPP, "Policy and charging control architecture", 358 September 2012. 360 Authors' Addresses 362 Mohamed Boucadair 363 France Telecom 364 Rennes, 35000 365 France 367 Email: mohamed.boucadair@orange.com 368 David Binet 369 France Telecom 370 Rennes, 371 France 373 Email: david.binet@orange.com 375 Sophie Durel 376 France Telecom 377 Rennes 378 France 380 Email: sophie.durel@orange.com