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