idnits 2.17.1 draft-boucadair-intarea-host-identifier-scenarios-07.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 (July 21, 2014) is 3567 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-13) exists of draft-ietf-softwire-lw4over6-10 == Outdated reference: A later version (-13) exists of draft-ietf-softwire-map-10 -- Obsolete informational reference (is this intentional?): RFC 3633 (Obsoleted by RFC 8415) Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Boucadair, Ed. 3 Internet-Draft D. Binet 4 Intended status: Informational S. Durel 5 Expires: January 22, 2015 B. Chatras 6 France Telecom 7 T. Reddy 8 Cisco Systems 9 B. Williams 10 Akamai, Inc. 11 B. Sarikaya 12 L. Xue 13 Huawei 14 R. Wheeldon 15 Cisco Systems 16 July 21, 2014 18 Scenarios with Host Identification Complications 19 draft-boucadair-intarea-host-identifier-scenarios-07 21 Abstract 23 This document describes a set of scenarios in which complications to 24 identify which policy to apply for a host are encountered. This 25 problem is abstracted as "host identification". The document does 26 not include any solution-specific discussion. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on January 22, 2015. 45 Copyright Notice 47 Copyright (c) 2014 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 63 2. What is in? What is out? . . . . . . . . . . . . . . . . . . 3 64 3. Scenario 1: CGN . . . . . . . . . . . . . . . . . . . . . . . 4 65 4. Scenario 2: A+P . . . . . . . . . . . . . . . . . . . . . . . 5 66 5. Scenario 3: On-Premise Application Proxy Deployment . . . . . 6 67 6. Scenario 4: Distributed Proxy Deployment . . . . . . . . . . 7 68 7. Scenario 5: Overlay Network . . . . . . . . . . . . . . . . . 8 69 8. Scenario 6: Policy and Charging Control Architecture . . . . 10 70 9. Scenario 7: Emergency Calls . . . . . . . . . . . . . . . . . 12 71 10. Other Deployment Scenarios . . . . . . . . . . . . . . . . . 13 72 10.1. Scenario 8: Open WLAN or Provider WLAN . . . . . . . . . 13 73 10.2. Scenario 9: Cellular Networks . . . . . . . . . . . . . 14 74 10.3. Scenario 10: Femtocells . . . . . . . . . . . . . . . . 15 75 10.4. Scenario 11: Traffic Detection Function . . . . . . . . 16 76 10.5. Scenario 12: Fixed and Mobile Network Convergence . . . 17 77 11. Synthesis . . . . . . . . . . . . . . . . . . . . . . . . . . 20 78 12. Privacy Considerations . . . . . . . . . . . . . . . . . . . 20 79 13. Security Considerations . . . . . . . . . . . . . . . . . . . 20 80 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 81 15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21 82 16. Informative References . . . . . . . . . . . . . . . . . . . 21 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 85 1. Introduction 87 The goal of this document is to enumerate scenarios which encounter 88 the issue of uniquely identifying a host among those sharing the same 89 IP address. An exhaustive list of encountered issues for the Carrier 90 Grade NAT, A+P, and Application Proxies scenarios are documented in 91 [RFC6269]. In addition to those issues, some of the scenarios 92 described in this document suffer from additional issues such as: 94 o Identify which policy to enforce for a subscriber/UE (e.g., limit 95 access to the service based on some counters such as volume-based 96 service offering); enforcing the policy will have impact on all 97 hosts sharing the same IP address. 98 o Need to correlate between the internal address:port and external 99 address:port to generate and therefore to enforce policies. 100 o Query a location server for the location of an emergency caller 101 based on the source IP address. 103 The analysis of the scenarios listed in this document indicates 104 several root causes for the host identification issue: 106 1. Presence of address sharing (NAT, A+P, application proxies, 107 etc.). 108 2. Use of tunnels between two administrative domains. 109 3. Combination of address sharing and presence of tunnels in the 110 path. 112 2. What is in? What is out? 114 The goal of this document is to identify scenarios the authors are 115 aware of and which share the same complications to identify which 116 policy to apply for a host. This problem is abstracted as host 117 identification problem. 119 This document can be used as a tool to design solution(s) mitigating 120 the encountered issues. Describing the scenario allows to identify 121 what is common between the scenarios and then would help during the 122 solution design phase. Note, [RFC6967] focuses only on the CGN, A+P, 123 and application proxies cases. The analysis in [RFC6967] may not be 124 accurate for some of the scenarios that do not span multiple 125 administrative domains (e.g., Section 10.1). 127 This document does not target means that would lead to expose a host 128 (or a user) beyond what the original packet, issued from that host, 129 would have already exposed. Such means are not desirable, nor 130 required to solve the issues encountered in the scenarios discussed 131 in this document. The focus is exclusively on means to restore the 132 information conveyed in the original packet issued by a given host. 133 These means are intended to help in identifying which policy to apply 134 for a given flow. These means rely on some bits of the source IP 135 address and/or port number(s) used by the host to issue packets. To 136 prevent side effects and mis-uses of such means on privacy, solution 137 specification document(s) should explain, in addition to what is 138 already documented in [RFC6967], the following: 140 o To what extent the solution can be used to nullify the effect of 141 using address sharing to preserve privacy (see for example 143 [EFFOpenWireless]). Note, this concern can be mitigated if the 144 address sharing platform is under the responsibility of the host's 145 owner and the host does not leak information that would interfere 146 with its privacy protection tool. 148 o To what extent the solution can be used to expose privacy 149 information beyond what the original packet would have already 150 exposed. Note, the solutions discussed in [RFC6967] do not allow 151 to reveal extra information than what is conveyed in the original 152 packet. 154 This document does not include any solution-specific discussion. In 155 particular, the document does not elaborate whether explicit 156 authentication is enabled or not. Moreover, this document does not 157 discuss whether specific information is needed to be leaked in 158 packets, whether this is achieved out-of-band, etc. Those 159 considerations are out of scope. 161 3. Scenario 1: CGN 163 Several flavors of stateful CGN have been defined. A non-exhaustive 164 list is provided below: 166 1. NAT44 ([RFC6888], [I-D.tsou-stateless-nat44]) 168 2. DS-Lite NAT44 [RFC6333] 170 3. NAT64 [RFC6146] 172 4. NPTv6 [RFC6296] 174 As discussed in [RFC6967], remote servers are not able to distinguish 175 between hosts sharing the same IP address (Figure 1). As a reminder, 176 remote servers rely on the source IP address for various purposes 177 such as access control or abuse management. The loss of the host 178 identification will lead to issues discussed in [RFC6269]. 180 +-----------+ 181 | HOST_1 |----+ 182 +-----------+ | +--------------------+ +------------+ 183 | | |------| server 1 | 184 +-----------+ +-----+ | | +------------+ 185 | HOST_2 |--| CGN |----| INTERNET | :: 186 +-----------+ +-----+ | | +------------+ 187 | | |------| server n | 188 +-----------+ | +--------------------+ +------------+ 189 | HOST_3 |-----+ 190 +-----------+ 192 Figure 1: CGN Reference Architecture 194 Some of the above referenced CGN scenarios will be satisfied by 195 eventual completion of the transition to IPv6 across the Internet 196 (e.g., NAT64), but this is not true of all CGN scenarios (e.g. NPTv6 197 [RFC6296]) for which some of the issues discussed in [RFC6269] will 198 be encountered (e.g., impact on geolocation). 200 Privacy-related considerations discussed in [RFC6967] apply for this 201 scenario. 203 4. Scenario 2: A+P 205 A+P [RFC6346][I-D.ietf-softwire-map][I-D.ietf-softwire-lw4over6] 206 denotes a flavor of address sharing solutions which does not require 207 any additional NAT function be enabled in the service provider's 208 network. A+P assumes subscribers are assigned with the same IPv4 209 address together with a port set. Subscribers assigned with the same 210 IPv4 address should be assigned non overlapping port sets. Devices 211 connected to an A+P-enabled network should be able to restrict the 212 IPv4 source port to be within a configured range of ports. To 213 forward incoming packets to the appropriate host, a dedicated entity 214 called PRR (Port Range Router, [RFC6346]) is needed (Figure 2). 216 Similar to the CGN case, remote servers rely on the source IP address 217 for various purposes such as access control or abuse management. The 218 loss of the host identification will lead to the issues discussed in 219 [RFC6269]. In particular, it will be impossible to identify hosts 220 sharing the same IP address by remote servers. 222 +-----------+ 223 | HOST_1 |----+ 224 +-----------+ | +--------------------+ +------------+ 225 | | |------| server 1 | 226 +-----------+ +-----+ | | +------------+ 227 | HOST_2 |--| PRR |----| INTERNET | :: 228 +-----------+ +-----+ | | +------------+ 229 | | |------| server n | 230 +-----------+ | +--------------------+ +------------+ 231 | HOST_3 |-----+ 232 +-----------+ 234 Figure 2: A+P Reference Architecture 236 Privacy-related considerations discussed in [RFC6967] apply for this 237 scenario. 239 5. Scenario 3: On-Premise Application Proxy Deployment 241 This scenario is similar to the CGN scenario. Remote servers are not 242 able to distinguish hosts located behind the PROXY. Applying 243 policies on the perceived external IP address as received from the 244 PROXY will impact all hosts connected to that PROXY. 246 Figure 3 illustrates a simple configuration involving a proxy. Note 247 several (per-application) proxies may be deployed. This scenario is 248 a typical deployment approach used within enterprise networks. 250 +-----------+ 251 | HOST_1 |----+ 252 +-----------+ | +--------------------+ +------------+ 253 | | |------| server 1 | 254 +-----------+ +-----+ | | +------------+ 255 | HOST_2 |--|PROXY|----| INTERNET | :: 256 +-----------+ +-----+ | | +------------+ 257 | | |------| server n | 258 +-----------+ | +--------------------+ +------------+ 259 | HOST_3 |-----+ 260 +-----------+ 262 Figure 3: Proxy Reference Architecture 264 The administrator of the proxy may have many reasons for wanting to 265 proxy traffic - including caching, policy enforcement, malware 266 scanning, reporting on network or user behavior for compliance or 267 security monitoring. The same administrator may also wish to 268 selectively hide or expose the internal host (or user) identity to 269 servers. He/she may wish to hide the identity to protect end-user 270 privacy or to reduce the ability of a rogue agent to learn the 271 internal structure of the network. He/she may wish to allow upstream 272 servers to identify hosts (and/or users) to enforce access policies 273 (for example on documents or online databases), to enable account 274 identification (on subscription-based services) or to prevent 275 spurious misidentification of high traffic patterns as a DoS attack. 276 Application-specific protocols exist for enabling such forwarding on 277 some plain-text protocols (e.g., Forwarded headers on HTTP [RFC7239] 278 or time-stamp-line headers in SMTP [RFC5321]). 280 Servers not receiving such notifications but wishing to perform host 281 or user-specific processing are obliged to use other application- 282 specific means of identification (e.g. Cookies [RFC6265]). 284 Packets/connections must be received by the proxy regardless of the 285 IP address family in use. The requirements of this scenario are not 286 satisfied by eventual completion of the transition to IPv6 across the 287 Internet. Complications will arise for both IPv4 and IPv6. 289 Privacy-related considerations discussed in [RFC6967] apply for this 290 scenario. 292 6. Scenario 4: Distributed Proxy Deployment 294 This scenario is similar to the proxy deployment scenario (Section 5) 295 with the same use-cases. However, in this instance part of the 296 functionality of the application proxy is located in a remote site. 297 This may be desirable to reduce infrastructure and administration 298 costs or because the hosts in question are mobile or roaming hosts 299 tied to a particular administrative zone of control but not to a 300 particular network. 302 In some cases, a distributed proxy is required to identify an account 303 holder on whose behalf it is performing the caching, filtering or 304 other desired service - for example to know which policies to 305 enforce. Typically, IP addresses are used as a surrogate. However, 306 in the presence of CGN, this identification becomes difficult. 307 Alternative solutions include the use of cookies, which only work for 308 HTTP traffic, tunnels or proprietary extensions to existing 309 protocols. 311 +-----------+ +----------+ 312 | HOST_1 |-------------| | 313 +-----------+ | | +-------+ +------------+ 314 | | | |-----| server 1 | 315 +-----------+ | | | | +------------+ 316 | HOST_2 |----+ | INTERNET |---| Proxy | :: 317 +-----------+ +-----+ | | | | +------------+ 318 |Proxy|----| | | |-----| server n | 319 +-----------+ +-----+ | | +-------+ +------------+ 320 | HOST_3 |----+ +----------+ 321 +-----------+ 323 Figure 4: Distributed Proxy Reference Architecture (1) 325 +-----------+ +---+ +---+ +----------+ 326 | Host 1 +---------+ I | | I +--+ Server 1 | 327 +-----------+ | n | +---+ | n | +----------+ 328 | t | | P | | t | 329 +-----------+ +---+ | e | | r | | e | +----------+ 330 | Host 2 +--+ P | | r +--+ o +--+ r +--+ Server 2 | 331 +-----------+ | r | | n | | x | | n | +----------+ 332 | o |--+ e | | y | | e | :: 333 +-----------+ | x | | t | +---+ | t | +----------+ 334 | Host 3 +--+ y | | | | +--+ Server N | 335 +-----------+ +---+ +---+ +---+ +----------+ 337 Figure 5: Distributed Proxy Reference Architecture (2) 339 Packets/connections must be received by the proxy regardless of the 340 IP address family in use. The requirements of this scenario are not 341 satisfied by eventual completion of the transition to IPv6 across the 342 Internet. Complications will arise for both IPv4 and IPv6. 344 If the proxy and the servers are under the responsibility of the same 345 administrative entity (Figure 4), no privacy concerns are raised. 346 Nevertheless, privacy-related considerations discussed in [RFC6967] 347 apply if the proxy and the servers are not managed by the same 348 administrative entity (Figure 5). 350 7. Scenario 5: Overlay Network 352 An overlay network is a network of machines distributed throughout 353 multiple autonomous systems within the public Internet that can be 354 used to improve the performance of data transport (see Figure 6). IP 355 packets from the sender are delivered first to one of the machines 356 that make up the overlay network. That machine then relays the IP 357 packets to the receiver via one or more machines in the overlay 358 network, applying various performance enhancement methods. 360 +------------------------------------+ 361 | | 362 | INTERNET | 363 | | 364 +-----------+ | +------------+ | 365 | HOST_1 |-----| OVRLY_IN_1 |-----------+ | 366 +-----------+ | +------------+ | | 367 | | | 368 +-----------+ | +------------+ +-----------+ | +--------+ 369 | HOST_2 |-----| OVRLY_IN_2 |-----| OVRLY_OUT |-----| SERVER | 370 +-----------+ | +------------+ +-----------+ | +--------+ 371 | | | 372 +-----------+ | +------------+ | | 373 | HOST_3 |-----| OVRLY_IN_3 |-----------+ | 374 +-----------+ | +------------+ | 375 | | 376 +------------------------------------+ 378 Figure 6: Overlay Network Reference Architecture 380 Such overlay networks are used to improve the performance of content 381 delivery [IEEE1344002]. Overlay networks are also used for peer-to- 382 peer data transport [RFC5694], and they have been suggested for use 383 in both improved scalability for the Internet routing infrastructure 384 [RFC6179] and provisioning of security services (intrusion detection, 385 anti-virus software, etc.) over the public Internet [IEEE101109]. 387 In order for an overlay network to intercept packets and/or 388 connections transparently via base Internet connectivity 389 infrastructure, the overlay ingress and egress hosts (OVERLAY_IN and 390 OVERLAY_OUT) must be reliably in-path in both directions between the 391 connection-initiating HOST and the SERVER. When this is not the 392 case, packets may be routed around the overlay and sent directly to 393 the receiving host. 395 For public overlay networks, where the ingress and/or egress hosts 396 are on the public Internet, packet interception commonly uses network 397 address translation for the source (SNAT) or destination (DNAT) 398 addresses in such a way that the public IP addresses of the true 399 endpoint hosts involved in the data transport are invisible to each 400 other (see Figure 7). For example, the actual sender and receiver 401 may use two completely different pairs of source and destination 402 addresses to identify the connection on the sending and receiving 403 networks in cases where both the ingress and egress hosts are on the 404 public Internet. 406 ip hdr contains: ip hdr contains: 407 SENDER -> src = sender --> OVERLAY --> src = overlay2 --> RECEIVER 408 dst = overlay1 dst = receiver 410 Figure 7: NAT operations in an Overlay Network 412 In this scenario, the remote server is not able to distinguish among 413 hosts using the overlay for transport. In addition, the remote 414 server is not able to determine the overlay ingress point being used 415 by the host, which can be useful for diagnosing host connectivity 416 issues. 418 In some of the above referenced scenarios, IP packets traverse the 419 overlay network fundamentally unchanged, with the overlay network 420 functioning much like a CGN (Section 3). In other cases, connection- 421 oriented data flows (e.g. TCP) are terminated by the overlay in 422 order to perform object caching and other such transport and 423 application layer optimizations, similar to the proxy scenario 424 (Section 5). In both cases, address sharing is a requirement for 425 packet/connection interception, which means that the requirements for 426 this scenario are not satisfied by the eventual completion of the 427 transition to IPv6 across the Internet. 429 More details about this scenario are provided in 430 [I-D.williams-overlaypath-ip-tcp-rfc]. 432 This scenario does not introduce privacy concerns since the 433 identification of the host is local to a single administrative domain 434 (i.e., CDN overlay Network) or passed to a remote server to help 435 forwarding back the response to the appropriate host. 437 8. Scenario 6: Policy and Charging Control Architecture 439 This issue is related to the framework defined in [TS23.203] when a 440 NAT is located between the PCEF (Policy and Charging Enforcement 441 Function) and the AF (Application Function) as shown in Figure 8. 443 The main issue is: PCEF, PCRF and AF all receive information bound to 444 the same UE( User Equipment) but without being able to correlate 445 between the piece of data visible for each entity. Concretely, 447 o PCEF is aware of the IMSI (International Mobile Subscriber 448 Identity) and an internal IP address assigned to the UE. 450 o AF receives an external IP address and port as assigned by the NAT 451 function. 453 o PCRF is not able to correlate between the external IP address/port 454 assigned by the NAT (received from the AF) and the internal IP 455 address and IMSI of the UE (received from the PCEF). 457 +------+ 458 | PCRF |-----------------+ 459 +------+ | 460 | | 461 +----+ +------+ +-----+ +-----+ 462 | UE |------| PCEF |---| NAT |----| AF | 463 +----+ +------+ +-----+ +-----+ 465 Figure 8: NAT located between AF and PCEF 467 This scenario can be generalized as follows (Figure 9): 469 o Policy Enforcement Point (PEP, [RFC2753]) 471 o Policy Decision Point (PDP, [RFC2753]) 473 +------+ 474 | PDP |-----------------+ 475 +------+ | 476 | | 477 +----+ +------+ +-----+ +------+ 478 | UE |------| PEP |---| NAT |----|Server| 479 +----+ +------+ +-----+ +------+ 481 Figure 9: NAT located between PEP and Server 483 Note that an issue is encountered to enforce per-UE policies when the 484 NAT is located before the PEP function (see Figure 10): 486 +------+ 487 | PDP |------+ 488 +------+ | 489 | | 490 +----+ +------+ +-----+ +------+ 491 | UE |------| NAT |---| PEP |----|Server| 492 +----+ +------+ +-----+ +------+ 494 Figure 10: NAT located before PEP 496 This scenario does not introduce privacy concerns since the 497 identification of the host is local to a single administrative domain 498 and is meant to help identifying which policy to select for a UE. 500 9. Scenario 7: Emergency Calls 502 Voice service providers (VSPs) operating under certain jurisdictions 503 are required to route emergency calls from their subscribers and have 504 to include information about the caller's location in signaling 505 messages they send towards PSAPs (Public Safety Answering Points, 506 [RFC6443]), via an Emergency Service Routing Proxy (ESRP, [RFC6443]). 507 This information is used both for the determination of the correct 508 PSAP and to reveal the caller's location to the selected PSAP. 510 In many countries, regulation bodies require that this information be 511 provided by the network rather than the user equipment, in which case 512 the VSP needs to retrieve this information (by reference or by value) 513 from the access network where the caller is attached. 515 This requires the VSP call server receiving an emergency call request 516 to identify the relevant access network and to query a Location 517 Information Server (LIS) in this network using a suitable look-up 518 key. In the simplest case, the source IP address of the IP packet 519 carrying the call request is used both for identifying the access 520 network (thanks to a reverse DNS query) and as a look-up key to query 521 the LIS. Obviously the user-id as known by the VSP (e.g., telephone 522 number, or email-formatted URI) can't be used as it is not known by 523 the access network. 525 The above mechanism is broken when there is a NAT between the user 526 and the VSP and/or if the emergency call is established over a VPN 527 tunnel (e.g., an employee remotely connected to a company VoIP server 528 through a tunnel wishes to make an emergency call). In such cases, 529 the source IP address received by the VSP call server will identity 530 the NAT or the address assigned to the caller equipment by the VSP 531 (i.e., the address inside the tunnel). This is similar to the CGN 532 case (Section 3) and overlay network case (Section 7) and applies 533 irrespective of the IP versions used on both sides of the NAT and/or 534 inside and outside the tunnel. 536 Therefore, the VSP needs to receive an additional piece of 537 information that can be used to both identify the access network 538 where the caller is attached and query the LIS for his/her location. 539 This would require the NAT or the Tunnel Endpoint to insert this 540 extra information in the call requests delivered to the VSP call 541 servers. For example, this extra information could be a combination 542 of the local IP address assigned by the access network to the 543 caller's equipment with some form of identification of this access 544 network. 546 However, because it shall be possible to setup an emergency call 547 regardless of the actual call control protocol used between the user 548 and the VSP (e.g., SIP [RFC3261], IAX [RFC5456], tunneled over HTTP, 549 or proprietary protocol, possibly encrypted), this extra information 550 has to be conveyed outside the call request, in the header of lower 551 layers protocols. 553 Privacy-related considerations discussed in [RFC6967] apply for this 554 scenario. 556 10. Other Deployment Scenarios 558 10.1. Scenario 8: Open WLAN or Provider WLAN 560 In the context of Provider WLAN, a dedicated SSID can be configured 561 and advertised by the RG (Residential Gateway) for visiting 562 terminals. These visiting terminals can be mobile terminals, PCs, 563 etc. 565 Several deployment scenarios are envisaged: 567 1. Deploy a dedicated node in the service provider's network which 568 will be responsible to intercept all the traffic issued from 569 visiting terminals (see Figure 11). This node may be co-located 570 with a CGN function if private IPv4 addresses are assigned to 571 visiting terminals. Similar to the CGN case discussed in 572 Section 3, remote servers may not be able to distinguish visiting 573 hosts sharing the same IP address (see [RFC6269]). 575 2. Unlike the previous deployment scenario, IPv4 addresses are 576 managed by the RG without requiring any additional NAT to be 577 deployed in the service provider's network for handling traffic 578 issued from visiting terminals. Concretely, a visiting terminal 579 is assigned with a private IPv4 address from the IPv4 address 580 pool managed by the RG. Packets issued form a visiting terminal 581 are translated using the public IP address assigned to the RG 582 (see Figure 12). This deployment scenario induces the following 583 identification concerns: 585 * The provider is not able to distinguish the traffic belonging 586 to the visiting terminal from the traffic of the subscriber 587 owning the RG. This is needed to identify which policies are 588 to be enforced such as: accounting, DSCP remarking, black 589 list, etc. 591 * Similar to the CGN case Section 3, a misbehaving visiting 592 terminal is likely to have some impact on the experienced 593 service by the subscriber owning the RG (e.g., some of the 594 issues are discussed in [RFC6269]). 596 +-------------+ 597 |Local_HOST_1 |----+ 598 +-------------+ | 599 | | 600 +-------------+ +-----+ | +-----------+ 601 |Local_HOST_2 |--| RG |-|--|Border Node| 602 +-------------+ +-----+ | +----NAT----+ 603 | | 604 +-------------+ | | Service Provider 605 |Visiting Host|-----+ 606 +-------------+ 608 Figure 11: NAT enforced in a Service Provider's Node 610 +-------------+ 611 |Local_HOST_1 |----+ 612 +-------------+ | 613 | | 614 +-------------+ +-----+ | +-----------+ 615 |Local_HOST_2 |--| RG |-|--|Border Node| 616 +-------------+ +-NAT-+ | +-----------+ 617 | | 618 +-------------+ | | Service Provider 619 |Visiting Host|-----+ 620 +-------------+ 622 Figure 12: NAT located in the RG 624 This scenario does not introduce privacy concerns since the 625 identification of the host is local to a single administrative domain 626 and is meant to help identifying which policy to select for a 627 visiting UE. 629 10.2. Scenario 9: Cellular Networks 631 Cellular operators allocate private IPv4 addresses to mobile 632 terminals and deploy NAT44 function, generally co-located with 633 firewalls, to access to public IP services. The NAT function is 634 located at the boundaries of the PLMN (Public Land Mobile Network). 635 IPv6-only strategy, consisting in allocating IPv6 prefixes only to 636 mobile terminals, is considered by various operators. A NAT64 637 function is also considered in order to preserve IPv4 service 638 continuity for these customers. 640 These NAT44 and NAT64 functions bring some issues very similar to 641 those mentioned in Figure 1 and Section 8. This issue is 642 particularly encountered if policies are to be applied on the Gi 643 interface: a private IP address is assigned to the mobile terminals, 644 there is no correlation between the internal IP address and the 645 external address:port assigned by the NAT function, etc. 647 Privacy-related considerations discussed in [RFC6967] apply for this 648 scenario. 650 10.3. Scenario 10: Femtocells 652 This scenario can be seen as a combination of the scenarios described 653 in Section 10.1 and Section 8. 655 The reference architecture is shown in Figure 8. 657 +---------------------------+ 658 | +----+ +--------+ +----+ | +-----------+ +-------------------+ 659 | | UE | | Stand- |<=|====|=|===|===========|==|=>+--+ +--+ | 660 | +----+ | alone | | RG | | | | | | | | | Mobile | 661 | | FAP | +----+ | | | | |S | |F | Network| 662 | +--------+ (NAPT) | | Broadband | | |e | |A | | 663 +---------------------------+ | Fixed | | |G |-|P | +-----+| 664 | Network | | |W | |G |-| Core|| 665 +---------------------------+ | (BBF) | | | | |W | | Ntwk|| 666 | +----+ +------------+ | | | | | | | | +-----+| 667 | | UE | | Integrated |<====|===|===========|==|=>+--+ +--+ | 668 | +----+ | FAP (NAPT) | | +-----------+ +-------------------+ 669 | +------------+ | 670 +---------------------------+ 672 <=====> IPsec tunnel 673 CoreNtwk Core Network 674 FAPGW FAP Gateway 675 SeGW Security Gateway 677 Figure 13: Femtocell Reference Architecture 679 UE is connected to the FAP at the residential gateway (RG), routed 680 back to 3GPP Evolved Packet Core (EPC). UE is assigned IPv4 address 681 by the Mobile Network. Mobile operator's FAP leverages the IPsec 682 IKEv2 to interconnect FAP with the SeGW over the BBF network. Both 683 the FAP and the SeGW are managed by the mobile operator which may be 684 a different operator for the BBF network. 686 An investigated scenario is the mobile operator to pass on its mobile 687 subscriber's policies to the BBF to support traffic policy control . 688 But most of today's broadband fixed networks are relying on the 689 private IPv4 addressing plan (+NAPT) to support its attached devices 690 including the mobile operator's FAP. In this scenario, the mobile 691 network needs to: 693 o determine the FAP's public IPv4 address to identify the location 694 of the FAP to ensure its legitimacy to operate on the license 695 spectrum for a given mobile operator prior to the FAP be ready to 696 serve its mobile devices. 698 o determine the FAP's pubic IPv4 address together with the 699 translated port number of the UDP header of the encapsulated IPsec 700 tunnel for identifying the UE's traffic at the fixed broadband 701 network. 703 o determine the corresponding FAP's public IPv4 address associated 704 with the UE's inner-IPv4 address which is assigned by the mobile 705 network to identify the mobile UE to allow the PCRF to retrieve 706 the special UE's policy (e.g., QoS) to be passed onto the 707 Broadband Policy Control Function (BPCF) at the BBF network. 709 SeGW would have the complete knowledge of such mapping, but the 710 reasons for unable to use SeGW for this purpose is explained in 711 "Problem Statements" (section 2 of [I-D.so-ipsecme-ikev2-cpext]). 713 This scenario involves PCRF/BPCF but it is valid in other deployment 714 scenarios making use of AAA servers. 716 The issue of correlating the internal IP address and the public IP 717 address is valid even if there is no NAT in the path. 719 This scenario does not introduce privacy concerns since the 720 identification of the host is local to a single administrative domain 721 and is meant to help identifying which policy to select for a UE. 723 10.4. Scenario 11: Traffic Detection Function 725 Operators expect that the traffic subject to the packet inspection is 726 routed via the Traffic Detection Function (TDF) function as 727 requirement specified in [TS29.212], otherwise, the traffic may 728 bypass the TDF. This assumption only holds if it is possible to 729 identify individual UEs behind NA(P)T which may be deployed into the 730 RG in fixed broadband network, shown in Figure 14. As a result, 731 additional mechanisms are needed to enable this requirement. 733 +--------+ 734 | | 735 +-------+ PCRF | 736 | | | 737 | +--------+ 738 +--------+ +--------+ +--------+ +----+----+ 739 | | | | | +-----+ | 740 | ------------------------------------------------------------------ 741 | | | | | | | TDF | / \ 742 | ****************************************************************** 743 | | | +-------+ | | | Service 744 | | | | | | | \ / 745 | | | | | | | +--------+ 746 | | | | | | +--------+ PDN | 747 | ********---------**********--------************------------******* | 748 | UE | | RG | | BNG +------------------+ Gateway| 749 +--------+ +--------+ +--------+ +--------+ 751 Legends: 752 --------- 3GPP UE User Plane Traffic Offloaded subject to packet 753 inspection 754 ********* 3GPP UE User Plane Traffic Offloaded not subject to packet 755 inspection 756 *****---- 3GPP UE User Plane Traffic Home Routed 758 Figure 14: UE's Traffic Routed with TDF 760 This scenario does not introduce privacy concerns since the 761 identification of the host is local to a single administrative domain 762 and is meant to help identifying which policy to select for a UE. 764 10.5. Scenario 12: Fixed and Mobile Network Convergence 766 In the Policy for Convergence of Fixed Mobile Convergence (FMC) 767 scenario, the fixed broadband network must partner with the mobile 768 network to acquire the policies for the terminals or hosts attaching 769 to the fixed broadband network, shown in Figure 15 so that host- 770 specific QoS and accounting policies can be applied. 772 A UE is connected to the RG, routed back to the mobile network. The 773 mobile operator's PCRF needs to maintain the interconnect with the 774 Broadband Policy Control Function (BPCF) in the BBF network for PCC 775 (Section 8). The hosts (i.e., UEs) attaching to fixed broadband 776 network with a NA(P)T deployed should be identified. Based on the UE 777 identification, the BPCF to deploy policy rules in the fixed 778 broadband network can acquire the associated policy rules of the 779 identified UE from the PCRF in the mobile network. But in the fixed 780 broadband network, private IPv4 address is supported. The similar 781 requirements are raised in this scenario as Section 10.3. 783 +------------------------------+ +-------------+ 784 | | | | 785 | +------+ | | +------+ | 786 | | BPCF +---+---+-+ PCRF | | 787 | +--+---+ | | +---+--+ | 788 +-------+ | | | | | | 789 |HOST_1 |Private IP1 +--+---+ | | +---+--+ | 790 +-------+ | +----+ | | | | | | | 791 | | RG | | | | | | | | 792 | |with+-------------+ BNG +--------+ PGW | | 793 +-------+ | | NAT| | | | | | | | 794 |HOST_2 | | +----+ | | | | | | | 795 +-------+Private IP2 +------+ | | +------+ | 796 | | | | 797 | | | | 798 | Fixed | | Mobile | 799 | Broadband | | Network | 800 | Network | | | 801 | | | | 802 +------------------------------+ +-------------+ 804 Figure 15: Reference Architecture for Policy for Convergence in Fixed 805 and Mobile Network Convergence (1) 807 In IPv6 network, the similar issues exists when the IPv6 prefix is 808 sharing between multiple UEs attaching to the RG (see Figure 16). 809 The case applies when RG is assigned a single prefix, the home 810 network prefix, e.g. using DHCPv6 Prefix Delegation [RFC3633] with 811 the edge router, BNG acting as the Delegating Router (DR). RG uses 812 the home network prefix in the address configuration using stateful 813 (DHCPv6) or stateless address assignment (SLAAC) techniques. 815 +------------------------------+ +-------------+ 816 | | | | 817 | | | +------+ | 818 | +-------------+ PCRF | | 819 | | | | +---+--+ | 820 +-------+ | | | | | | 821 |HOST_1 |--+ +--+---+ | | +---+--+ | 822 +-------+ | +----+ | | | | | | | 823 | | RG | | | | | | | | 824 | | +------------+ BNG +---------+ PGW | | 825 +-------+ | | | | | | | | | | 826 |HOST_2 |--+ +----+ | | | | | | | 827 +-------+ | +------+ | | +------+ | 828 | | | | 829 | | | | 830 | Fixed | | Mobile | 831 | Broadband | | Network | 832 | Network | | | 833 | | | | 834 +------------------------------+ +-------------+ 836 Figure 16: Reference Architecture for Policy for Convergence in Fixed 837 and Mobile Network Convergence (2) 839 BNG acting as PCEF initiates an IP Connectivity Access Network (IP- 840 CAN) session with the policy server, a.k.a. Policy and Charging 841 Rules Function (PCRF), to receive the Quality of Service (QoS) 842 parameters and Charging rules. BNG provides to the PCRF the IPv6 843 Prefix assigned to the host, in this case the home network prefix and 844 an ID which in this case has to be equal to the RG specific home 845 network line ID. 847 HOST_1 in Figure 16 creates an 128-bit IPv6 address using this prefix 848 and adding its interface id. Having completed the address 849 configuration, the host can start communication with a remote hosts 850 over Internet. However, no specific IP-CAN session can be assigned 851 to HOST_1, and consequently the QoS and accounting performed will be 852 based on RG subscription. 854 Another host, e.g. HOST_2, attaches to RG and also establishes an 855 IPv6 address using the home network prefix. Edge router, the BNG, is 856 not involved with this and all other such address assignments. 858 This leads to the case where no specific IP-CAN session/sub-session 859 can be assigned to the hosts, HOST_1, HOST_2, etc., and consequently 860 the QoS and accounting performed can only be based on RG subscription 861 and not host specific. Therefore IPv6 prefix sharing in Policy for 862 Convergence scenario leads to similar issues as the address sharing 863 as it has been explained in the previous scenarios in this document. 865 11. Synthesis 867 The following table shows whether each scenario is valid for IPv4/ 868 IPv6 and if it is within one single administrative domain or span 869 multiple domains. 871 +-------------------+------+-------------+-----------------------+ 872 | scenario | IPv4 | IPv6 | Single Administrative | 873 | | |------+------| Domain | 874 | | |Client|Server| | 875 +-------------------+------+------+------+-----------------------+ 876 | CGN | Yes |Yes(1)| No | No | 877 | A+P | Yes | No | No | No | 878 | Application Proxy | Yes | Yes | Yes | No | 879 | Distributed Proxy | Yes | Yes | Yes | Yes/No | 880 | Overlay Networks | Yes |Yes(3)|Yes(3)| No | 881 | PCC | Yes |Yes(1)| No | Yes | 882 | Emergency Calls | Yes | Yes |Yes | No | 883 | Provider WLAN | Yes | No | No | Yes | 884 | Cellular Networks | Yes |Yes(1)| No | Yes | 885 | Femtocells | Yes | No | No | No | 886 | TDF | Yes | Yes | No | Yes | 887 | FMC | Yes |Yes(1)| No | No | 888 +-------------------+------+------+------------------------------+ 890 Notes: 891 (1) e.g., NAT64 892 (2) A proxy can use IPv6 for the communication leg with the server 893 or the application client. 894 (3) This scenario is a combination of CGN and Application Proxies. 896 12. Privacy Considerations 898 Privacy-related considerations that apply to means to reveal a host 899 identifiers are discussed in [RFC6967]. This document does not 900 introduce additional privacy issues than those discussed in 901 [RFC6967]. 903 13. Security Considerations 905 This document does not define an architecture nor a protocol; as such 906 it does not raise any security concern. Host identifier related 907 security considerations are discussed in [RFC6967]. 909 14. IANA Considerations 911 This document does not require any action from IANA. 913 15. Acknowledgments 915 Many thanks to F. Klamm, D. Wing, and D. von Hugo for their review. 917 J. Touch, S. Farrel, and S. Moonesamy provided useful comments in 918 the intarea mailing list. 920 Figure 8 and part of the text in Section 10.3 are inspired from 921 [I-D.so-ipsecme-ikev2-cpext]. 923 16. Informative References 925 [EFFOpenWireless] 926 EFF, , "Open Wireless, https://www.eff.org/issues/open- 927 wireless", 2014. 929 [I-D.ietf-softwire-lw4over6] 930 Cui, Y., Qiong, Q., Boucadair, M., Tsou, T., Lee, Y., and 931 I. Farrer, "Lightweight 4over6: An Extension to the DS- 932 Lite Architecture", draft-ietf-softwire-lw4over6-10 (work 933 in progress), June 2014. 935 [I-D.ietf-softwire-map] 936 Troan, O., Dec, W., Li, X., Bao, C., Matsushima, S., 937 Murakami, T., and T. Taylor, "Mapping of Address and Port 938 with Encapsulation (MAP)", draft-ietf-softwire-map-10 939 (work in progress), January 2014. 941 [I-D.so-ipsecme-ikev2-cpext] 942 So, T., "IKEv2 Configuration Payload Extension for Private 943 IPv4 Support for Fixed Mobile Convergence", draft-so- 944 ipsecme-ikev2-cpext-02 (work in progress), June 2012. 946 [I-D.tsou-stateless-nat44] 947 Tsou, T., Liu, W., Perreault, S., Penno, R., and M. Chen, 948 "Stateless IPv4 Network Address Translation", draft-tsou- 949 stateless-nat44-02 (work in progress), October 2012. 951 [I-D.williams-overlaypath-ip-tcp-rfc] 952 Williams, B., "Overlay Path Option for IP and TCP", draft- 953 williams-overlaypath-ip-tcp-rfc-04 (work in progress), 954 June 2013. 956 [IEEE101109] 957 Salah, K., Calero, J., Zeadally, S., Almulla, S., and M. 958 ZAaabi, "Using Cloud Computing to Implement a Security 959 Overlay Network, IEEE Security & Privacy, 21 June 2012. 960 IEEE Computer Society Digital Library.", June 2012. 962 [IEEE1344002] 963 Byers, J., Considine, J., Mitzenmacher, M., and S. Rost, 964 "Informed content delivery across adaptive overlay 965 networks: IEEE/ACM Transactions on Networking, Vol 12, 966 Issue 5, ppg 767-780", October 2004. 968 [RFC2753] Yavatkar, R., Pendarakis, D., and R. Guerin, "A Framework 969 for Policy-based Admission Control", RFC 2753, January 970 2000. 972 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 973 A., Peterson, J., Sparks, R., Handley, M., and E. 974 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 975 June 2002. 977 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 978 Host Configuration Protocol (DHCP) version 6", RFC 3633, 979 December 2003. 981 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 982 October 2008. 984 [RFC5456] Spencer, M., Capouch, B., Guy, E., Miller, F., and K. 985 Shumard, "IAX: Inter-Asterisk eXchange Version 2", RFC 986 5456, February 2010. 988 [RFC5694] Camarillo, G. and IAB, "Peer-to-Peer (P2P) Architecture: 989 Definition, Taxonomies, Examples, and Applicability", RFC 990 5694, November 2009. 992 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 993 NAT64: Network Address and Protocol Translation from IPv6 994 Clients to IPv4 Servers", RFC 6146, April 2011. 996 [RFC6179] Templin, F., "The Internet Routing Overlay Network 997 (IRON)", RFC 6179, March 2011. 999 [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, 1000 April 2011. 1002 [RFC6269] Ford, M., Boucadair, M., Durand, A., Levis, P., and P. 1003 Roberts, "Issues with IP Address Sharing", RFC 6269, June 1004 2011. 1006 [RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix 1007 Translation", RFC 6296, June 2011. 1009 [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 1010 Stack Lite Broadband Deployments Following IPv4 1011 Exhaustion", RFC 6333, August 2011. 1013 [RFC6346] Bush, R., "The Address plus Port (A+P) Approach to the 1014 IPv4 Address Shortage", RFC 6346, August 2011. 1016 [RFC6443] Rosen, B., Schulzrinne, H., Polk, J., and A. Newton, 1017 "Framework for Emergency Calling Using Internet 1018 Multimedia", RFC 6443, December 2011. 1020 [RFC6888] Perreault, S., Yamagata, I., Miyakawa, S., Nakagawa, A., 1021 and H. Ashida, "Common Requirements for Carrier-Grade NATs 1022 (CGNs)", BCP 127, RFC 6888, April 2013. 1024 [RFC6967] Boucadair, M., Touch, J., Levis, P., and R. Penno, 1025 "Analysis of Potential Solutions for Revealing a Host 1026 Identifier (HOST_ID) in Shared Address Deployments", RFC 1027 6967, June 2013. 1029 [RFC7239] Petersson, A. and M. Nilsson, "Forwarded HTTP Extension", 1030 RFC 7239, June 2014. 1032 [TS23.203] 1033 3GPP, , "Policy and charging control architecture", 1034 September 2012. 1036 [TS29.212] 1037 3GPP, , "Policy and Charging Control (PCC); Reference 1038 Points", December 2013. 1040 Authors' Addresses 1042 Mohamed Boucadair (editor) 1043 France Telecom 1044 Rennes 35000 1045 France 1047 Email: mohamed.boucadair@orange.com 1048 David Binet 1049 France Telecom 1050 Rennes 1051 France 1053 Email: david.binet@orange.com 1055 Sophie Durel 1056 France Telecom 1057 Rennes 1058 France 1060 Email: sophie.durel@orange.com 1062 Bruno Chatras 1063 France Telecom 1064 Paris 1065 France 1067 Email: bruno.chatras@orange.com 1069 Tirumaleswar Reddy 1070 Cisco Systems 1071 Cessna Business Park, Varthur Hobli 1072 Sarjapur Marathalli Outer Ring Road 1073 Bangalore, Karnataka 560103 1074 India 1076 Email: tireddy@cisco.com 1078 Brandon Williams 1079 Akamai, Inc. 1080 Cambridge MA 1081 USA 1083 Email: brandon.williams@akamai.com 1084 Behcet Sarikaya 1085 Huawei 1086 5340 Legacy Dr. Building 3, 1087 Plano, TX 75024 1088 USA 1090 Email: sarikaya@ieee.org 1092 Li Xue 1093 Huawei 1094 Beijing 1095 China 1097 Email: xueli@huawei.com 1099 Richard Stewart Wheeldon 1100 Cisco Systems 1101 Qube, 90 Whitfield Street 1102 London W1T 4EZ 1103 UK 1105 Email: rwheeldo@cisco.com