idnits 2.17.1 draft-boucadair-intarea-host-identifier-scenarios-06.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 4, 2014) is 3576 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 5, 2015 B. Chatras 6 France Telecom 7 T. Reddy 8 Cisco 9 B. Williams 10 Akamai, Inc. 11 B. Sarikaya 12 L. Xue 13 Huawei 14 R. Wheeldon 15 Cisco Systems 16 July 4, 2014 18 Scenarios with Host Identification Complications 19 draft-boucadair-intarea-host-identifier-scenarios-06 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 5, 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 325 Packets/connections must be received by the proxy regardless of the 326 IP address family in use. The requirements of this scenario are not 327 satisfied by eventual completion of the transition to IPv6 across the 328 Internet. Complications will arise for both IPv4 and IPv6. 330 Unlike the previous scenario, this scenario does not induce privacy 331 concerns since the remote PROXY and the servers are under the 332 responsibility of the same administrative entity. 334 7. Scenario 5: Overlay Network 336 An overlay network is a network of machines distributed throughout 337 multiple autonomous systems within the public Internet that can be 338 used to improve the performance of data transport (see Figure 5). IP 339 packets from the sender are delivered first to one of the machines 340 that make up the overlay network. That machine then relays the IP 341 packets to the receiver via one or more machines in the overlay 342 network, applying various performance enhancement methods. 344 +------------------------------------+ 345 | | 346 | INTERNET | 347 | | 348 +-----------+ | +------------+ | 349 | HOST_1 |-----| OVRLY_IN_1 |-----------+ | 350 +-----------+ | +------------+ | | 351 | | | 352 +-----------+ | +------------+ +-----------+ | +--------+ 353 | HOST_2 |-----| OVRLY_IN_2 |-----| OVRLY_OUT |-----| SERVER | 354 +-----------+ | +------------+ +-----------+ | +--------+ 355 | | | 356 +-----------+ | +------------+ | | 357 | HOST_3 |-----| OVRLY_IN_3 |-----------+ | 358 +-----------+ | +------------+ | 359 | | 360 +------------------------------------+ 362 Figure 5: Overlay Network Reference Architecture 364 Such overlay networks are used to improve the performance of content 365 delivery [IEEE1344002]. Overlay networks are also used for peer-to- 366 peer data transport [RFC5694], and they have been suggested for use 367 in both improved scalability for the Internet routing infrastructure 368 [RFC6179] and provisioning of security services (intrusion detection, 369 anti-virus software, etc.) over the public Internet [IEEE101109]. 371 In order for an overlay network to intercept packets and/or 372 connections transparently via base Internet connectivity 373 infrastructure, the overlay ingress and egress hosts (OVERLAY_IN and 374 OVERLAY_OUT) must be reliably in-path in both directions between the 375 connection-initiating HOST and the SERVER. When this is not the 376 case, packets may be routed around the overlay and sent directly to 377 the receiving host. 379 For public overlay networks, where the ingress and/or egress hosts 380 are on the public Internet, packet interception commonly uses network 381 address translation for the source (SNAT) or destination (DNAT) 382 addresses in such a way that the public IP addresses of the true 383 endpoint hosts involved in the data transport are invisible to each 384 other (see Figure 6). For example, the actual sender and receiver 385 may use two completely different pairs of source and destination 386 addresses to identify the connection on the sending and receiving 387 networks in cases where both the ingress and egress hosts are on the 388 public Internet. 390 ip hdr contains: ip hdr contains: 391 SENDER -> src = sender --> OVERLAY --> src = overlay2 --> RECEIVER 392 dst = overlay1 dst = receiver 394 Figure 6: NAT operations in an Overlay Network 396 In this scenario, the remote server is not able to distinguish among 397 hosts using the overlay for transport. In addition, the remote 398 server is not able to determine the overlay ingress point being used 399 by the host, which can be useful for diagnosing host connectivity 400 issues. 402 In some of the above referenced scenarios, IP packets traverse the 403 overlay network fundamentally unchanged, with the overlay network 404 functioning much like a CGN (Section 3). In other cases, connection- 405 oriented data flows (e.g. TCP) are terminated by the overlay in 406 order to perform object caching and other such transport and 407 application layer optimizations, similar to the proxy scenario 408 (Section 5). In both cases, address sharing is a requirement for 409 packet/connection interception, which means that the requirements for 410 this scenario are not satisfied by the eventual completion of the 411 transition to IPv6 across the Internet. 413 More details about this scenario are provided in 414 [I-D.williams-overlaypath-ip-tcp-rfc]. 416 This scenario does not introduce privacy concerns since the 417 identification of the host is local to a single administrative domain 418 (i.e., CDN overlay Network) or passed to a remote server to help 419 forwarding back the response to the appropriate host. 421 8. Scenario 6: Policy and Charging Control Architecture 423 This issue is related to the framework defined in [TS23.203] when a 424 NAT is located between the PCEF (Policy and Charging Enforcement 425 Function) and the AF (Application Function) as shown in Figure 7. 427 The main issue is: PCEF, PCRF and AF all receive information bound to 428 the same UE( User Equipment) but without being able to correlate 429 between the piece of data visible for each entity. Concretely, 431 o PCEF is aware of the IMSI (International Mobile Subscriber 432 Identity) and an internal IP address assigned to the UE. 434 o AF receives an external IP address and port as assigned by the NAT 435 function. 437 o PCRF is not able to correlate between the external IP address/port 438 assigned by the NAT (received from the AF) and the internal IP 439 address and IMSI of the UE (received from the PCEF). 441 +------+ 442 | PCRF |-----------------+ 443 +------+ | 444 | | 445 +----+ +------+ +-----+ +-----+ 446 | UE |------| PCEF |---| NAT |----| AF | 447 +----+ +------+ +-----+ +-----+ 449 Figure 7: NAT located between AF and PCEF 451 This scenario can be generalized as follows (Figure 8): 453 o Policy Enforcement Point (PEP, [RFC2753]) 455 o Policy Decision Point (PDP, [RFC2753]) 457 +------+ 458 | PDP |-----------------+ 459 +------+ | 460 | | 461 +----+ +------+ +-----+ +------+ 462 | UE |------| PEP |---| NAT |----|Server| 463 +----+ +------+ +-----+ +------+ 465 Figure 8: NAT located between PEP and Server 467 Note that an issue is encountered to enforce per-UE policies when the 468 NAT is located before the PEP function (see Figure 9): 470 +------+ 471 | PDP |------+ 472 +------+ | 473 | | 474 +----+ +------+ +-----+ +------+ 475 | UE |------| NAT |---| PEP |----|Server| 476 +----+ +------+ +-----+ +------+ 478 Figure 9: NAT located before PEP 480 This scenario does not introduce privacy concerns since the 481 identification of the host is local to a single administrative domain 482 and is meant to help identifying which policy to select for a UE. 484 9. Scenario 7: Emergency Calls 486 Voice service providers (VSPs) operating under certain jurisdictions 487 are required to route emergency calls from their subscribers and have 488 to include information about the caller's location in signaling 489 messages they send towards PSAPs (Public Safety Answering Points, 490 [RFC6443]), via an Emergency Service Routing Proxy (ESRP, [RFC6443]). 491 This information is used both for the determination of the correct 492 PSAP and to reveal the caller's location to the selected PSAP. 494 In many countries, regulation bodies require that this information be 495 provided by the network rather than the user equipment, in which case 496 the VSP needs to retrieve this information (by reference or by value) 497 from the access network where the caller is attached. 499 This requires the VSP call server receiving an emergency call request 500 to identify the relevant access network and to query a Location 501 Information Server (LIS) in this network using a suitable look-up 502 key. In the simplest case, the source IP address of the IP packet 503 carrying the call request is used both for identifying the access 504 network (thanks to a reverse DNS query) and as a look-up key to query 505 the LIS. Obviously the user-id as known by the VSP (e.g., telephone 506 number, or email-formatted URI) can't be used as it is not known by 507 the access network. 509 The above mechanism is broken when there is a NAT between the user 510 and the VSP and/or if the emergency call is established over a VPN 511 tunnel (e.g., an employee remotely connected to a company VoIP server 512 through a tunnel wishes to make an emergency call). In such cases, 513 the source IP address received by the VSP call server will identity 514 the NAT or the address assigned to the caller equipment by the VSP 515 (i.e., the address inside the tunnel). This is similar to the CGN 516 case (Section 3) and overlay network case (Section 7) and applies 517 irrespective of the IP versions used on both sides of the NAT and/or 518 inside and outside the tunnel. 520 Therefore, the VSP needs to receive an additional piece of 521 information that can be used to both identify the access network 522 where the caller is attached and query the LIS for his/her location. 523 This would require the NAT or the Tunnel Endpoint to insert this 524 extra information in the call requests delivered to the VSP call 525 servers. For example, this extra information could be a combination 526 of the local IP address assigned by the access network to the 527 caller's equipment with some form of identification of this access 528 network. 530 However, because it shall be possible to setup an emergency call 531 regardless of the actual call control protocol used between the user 532 and the VSP (e.g., SIP [RFC3261], IAX [RFC5456], tunneled over HTTP, 533 or proprietary protocol, possibly encrypted), this extra information 534 has to be conveyed outside the call request, in the header of lower 535 layers protocols. 537 Privacy-related considerations discussed in [RFC6967] apply for this 538 scenario. 540 10. Other Deployment Scenarios 542 10.1. Scenario 8: Open WLAN or Provider WLAN 544 In the context of Provider WLAN, a dedicated SSID can be configured 545 and advertised by the RG (Residential Gateway) for visiting 546 terminals. These visiting terminals can be mobile terminals, PCs, 547 etc. 549 Several deployment scenarios are envisaged: 551 1. Deploy a dedicated node in the service provider's network which 552 will be responsible to intercept all the traffic issued from 553 visiting terminals (see Figure 10). This node may be co-located 554 with a CGN function if private IPv4 addresses are assigned to 555 visiting terminals. Similar to the CGN case discussed in 556 Section 3, remote servers may not be able to distinguish visiting 557 hosts sharing the same IP address (see [RFC6269]). 559 2. Unlike the previous deployment scenario, IPv4 addresses are 560 managed by the RG without requiring any additional NAT to be 561 deployed in the service provider's network for handling traffic 562 issued from visiting terminals. Concretely, a visiting terminal 563 is assigned with a private IPv4 address from the IPv4 address 564 pool managed by the RG. Packets issued form a visiting terminal 565 are translated using the public IP address assigned to the RG 566 (see Figure 11). This deployment scenario induces the following 567 identification concerns: 569 * The provider is not able to distinguish the traffic belonging 570 to the visiting terminal from the traffic of the subscriber 571 owning the RG. This is needed to identify which policies are 572 to be enforced such as: accounting, DSCP remarking, black 573 list, etc. 575 * Similar to the CGN case Section 3, a misbehaving visiting 576 terminal is likely to have some impact on the experienced 577 service by the subscriber owning the RG (e.g., some of the 578 issues are discussed in [RFC6269]). 580 +-------------+ 581 |Local_HOST_1 |----+ 582 +-------------+ | 583 | | 584 +-------------+ +-----+ | +-----------+ 585 |Local_HOST_2 |--| RG |-|--|Border Node| 586 +-------------+ +-----+ | +----NAT----+ 587 | | 588 +-------------+ | | Service Provider 589 |Visiting Host|-----+ 590 +-------------+ 592 Figure 10: NAT enforced in a Service Provider's Node 594 +-------------+ 595 |Local_HOST_1 |----+ 596 +-------------+ | 597 | | 598 +-------------+ +-----+ | +-----------+ 599 |Local_HOST_2 |--| RG |-|--|Border Node| 600 +-------------+ +-NAT-+ | +-----------+ 601 | | 602 +-------------+ | | Service Provider 603 |Visiting Host|-----+ 604 +-------------+ 606 Figure 11: NAT located in the RG 608 This scenario does not introduce privacy concerns since the 609 identification of the host is local to a single administrative domain 610 and is meant to help identifying which policy to select for a 611 visiting UE. 613 10.2. Scenario 9: Cellular Networks 615 Cellular operators allocate private IPv4 addresses to mobile 616 terminals and deploy NAT44 function, generally co-located with 617 firewalls, to access to public IP services. The NAT function is 618 located at the boundaries of the PLMN (Public Land Mobile Network). 619 IPv6-only strategy, consisting in allocating IPv6 prefixes only to 620 mobile terminals, is considered by various operators. A NAT64 621 function is also considered in order to preserve IPv4 service 622 continuity for these customers. 624 These NAT44 and NAT64 functions bring some issues very similar to 625 those mentioned in Figure 1 and Section 8. This issue is 626 particularly encountered if policies are to be applied on the Gi 627 interface: a private IP address is assigned to the mobile terminals, 628 there is no correlation between the internal IP address and the 629 external address:port assigned by the NAT function, etc. 631 Privacy-related considerations discussed in [RFC6967] apply for this 632 scenario. 634 10.3. Scenario 10: Femtocells 636 This scenario can be seen as a combination of the scenarios described 637 in Section 10.1 and Section 8. 639 The reference architecture is shown in Figure 8. 641 +---------------------------+ 642 | +----+ +--------+ +----+ | +-----------+ +-------------------+ 643 | | UE | | Stand- |<=|====|=|===|===========|==|=>+--+ +--+ | 644 | +----+ | alone | | RG | | | | | | | | | Mobile | 645 | | FAP | +----+ | | | | |S | |F | Network| 646 | +--------+ (NAPT) | | Broadband | | |e | |A | | 647 +---------------------------+ | Fixed | | |G |-|P | +-----+| 648 | Network | | |W | |G |-| Core|| 649 +---------------------------+ | (BBF) | | | | |W | | Ntwk|| 650 | +----+ +------------+ | | | | | | | | +-----+| 651 | | UE | | Integrated |<====|===|===========|==|=>+--+ +--+ | 652 | +----+ | FAP (NAPT) | | +-----------+ +-------------------+ 653 | +------------+ | 654 +---------------------------+ 656 <=====> IPsec tunnel 657 CoreNtwk Core Network 658 FAPGW FAP Gateway 659 SeGW Security Gateway 661 Figure 12: Femtocell Reference Architecture 663 UE is connected to the FAP at the residential gateway (RG), routed 664 back to 3GPP Evolved Packet Core (EPC). UE is assigned IPv4 address 665 by the Mobile Network. Mobile operator's FAP leverages the IPsec 666 IKEv2 to interconnect FAP with the SeGW over the BBF network. Both 667 the FAP and the SeGW are managed by the mobile operator which may be 668 a different operator for the BBF network. 670 An investigated scenario is the mobile operator to pass on its mobile 671 subscriber's policies to the BBF to support traffic policy control . 672 But most of today's broadband fixed networks are relying on the 673 private IPv4 addressing plan (+NAPT) to support its attached devices 674 including the mobile operator's FAP. In this scenario, the mobile 675 network needs to: 677 o determine the FAP's public IPv4 address to identify the location 678 of the FAP to ensure its legitimacy to operate on the license 679 spectrum for a given mobile operator prior to the FAP be ready to 680 serve its mobile devices. 682 o determine the FAP's pubic IPv4 address together with the 683 translated port number of the UDP header of the encapsulated IPsec 684 tunnel for identifying the UE's traffic at the fixed broadband 685 network. 687 o determine the corresponding FAP's public IPv4 address associated 688 with the UE's inner-IPv4 address which is assigned by the mobile 689 network to identify the mobile UE to allow the PCRF to retrieve 690 the special UE's policy (e.g., QoS) to be passed onto the 691 Broadband Policy Control Function (BPCF) at the BBF network. 693 SeGW would have the complete knowledge of such mapping, but the 694 reasons for unable to use SeGW for this purpose is explained in 695 "Problem Statements" (section 2 of [I-D.so-ipsecme-ikev2-cpext]). 697 This scenario involves PCRF/BPCF but it is valid in other deployment 698 scenarios making use of AAA servers. 700 The issue of correlating the internal IP address and the public IP 701 address is valid even if there is no NAT in the path. 703 This scenario does not introduce privacy concerns since the 704 identification of the host is local to a single administrative domain 705 and is meant to help identifying which policy to select for a UE. 707 10.4. Scenario 11: Traffic Detection Function 709 Operators expect that the traffic subject to the packet inspection is 710 routed via the Traffic Detection Function (TDF) function as 711 requirement specified in [TS29.212], otherwise, the traffic may 712 bypass the TDF. This assumption only holds if it is possible to 713 identify individual UEs behind NA(P)T which may be deployed into the 714 RG in fixed broadband network, shown in Figure 13. As a result, 715 additional mechanisms are needed to enable this requirement. 717 +--------+ 718 | | 719 +-------+ PCRF | 720 | | | 721 | +--------+ 722 +--------+ +--------+ +--------+ +----+----+ 723 | | | | | +-----+ | 724 | ------------------------------------------------------------------ 725 | | | | | | | TDF | / \ 726 | ****************************************************************** 727 | | | +-------+ | | | Service 728 | | | | | | | \ / 729 | | | | | | | +--------+ 730 | | | | | | +--------+ PDN | 731 | ********---------**********--------************------------******* | 732 | UE | | RG | | BNG +------------------+ Gateway| 733 +--------+ +--------+ +--------+ +--------+ 735 Legends: 736 --------- 3GPP UE User Plane Traffic Offloaded subject to packet 737 inspection 738 ********* 3GPP UE User Plane Traffic Offloaded not subject to packet 739 inspection 740 *****---- 3GPP UE User Plane Traffic Home Routed 742 Figure 13: UE's Traffic Routed with TDF 744 This scenario does not introduce privacy concerns since the 745 identification of the host is local to a single administrative domain 746 and is meant to help identifying which policy to select for a UE. 748 10.5. Scenario 12: Fixed and Mobile Network Convergence 750 In the Policy for Convergence of Fixed Mobile Convergence (FMC) 751 scenario, the fixed broadband network must partner with the mobile 752 network to acquire the policies for the terminals or hosts attaching 753 to the fixed broadband network, shown in Figure 14 so that host- 754 specific QoS and accounting policies can be applied. 756 A UE is connected to the RG, routed back to the mobile network. The 757 mobile operator's PCRF needs to maintain the interconnect with the 758 Broadband Policy Control Function (BPCF) in the BBF network for PCC 759 (Section 8). The hosts (i.e., UEs) attaching to fixed broadband 760 network with a NA(P)T deployed should be identified. Based on the UE 761 identification, the BPCF to deploy policy rules in the fixed 762 broadband network can acquire the associated policy rules of the 763 identified UE from the PCRF in the mobile network. But in the fixed 764 broadband network, private IPv4 address is supported. The similar 765 requirements are raised in this scenario as Section 10.3. 767 +------------------------------+ +-------------+ 768 | | | | 769 | +------+ | | +------+ | 770 | | BPCF +---+---+-+ PCRF | | 771 | +--+---+ | | +---+--+ | 772 +-------+ | | | | | | 773 |HOST_1 |Private IP1 +--+---+ | | +---+--+ | 774 +-------+ | +----+ | | | | | | | 775 | | RG | | | | | | | | 776 | |with+-------------+ BNG +--------+ PGW | | 777 +-------+ | | NAT| | | | | | | | 778 |HOST_2 | | +----+ | | | | | | | 779 +-------+Private IP2 +------+ | | +------+ | 780 | | | | 781 | | | | 782 | Fixed | | Mobile | 783 | Broadband | | Network | 784 | Network | | | 785 | | | | 786 +------------------------------+ +-------------+ 788 Figure 14: Reference Architecture for Policy for Convergence in Fixed 789 and Mobile Network Convergence (1) 791 In IPv6 network, the similar issues exists when the IPv6 prefix is 792 sharing between multiple UEs attaching to the RG (see Figure 15). 793 The case applies when RG is assigned a single prefix, the home 794 network prefix, e.g. using DHCPv6 Prefix Delegation [RFC3633] with 795 the edge router, BNG acting as the Delegating Router (DR). RG uses 796 the home network prefix in the address configuration using stateful 797 (DHCPv6) or stateless address assignment (SLAAC) techniques. 799 +------------------------------+ +-------------+ 800 | | | | 801 | | | +------+ | 802 | +-------------+ PCRF | | 803 | | | | +---+--+ | 804 +-------+ | | | | | | 805 |HOST_1 |--+ +--+---+ | | +---+--+ | 806 +-------+ | +----+ | | | | | | | 807 | | RG | | | | | | | | 808 | | +------------+ BNG +---------+ PGW | | 809 +-------+ | | | | | | | | | | 810 |HOST_2 |--+ +----+ | | | | | | | 811 +-------+ | +------+ | | +------+ | 812 | | | | 813 | | | | 814 | Fixed | | Mobile | 815 | Broadband | | Network | 816 | Network | | | 817 | | | | 818 +------------------------------+ +-------------+ 820 Figure 15: Reference Architecture for Policy for Convergence in Fixed 821 and Mobile Network Convergence (2) 823 BNG acting as PCEF initiates an IP Connectivity Access Network (IP- 824 CAN) session with the policy server, a.k.a. Policy and Charging 825 Rules Function (PCRF), to receive the Quality of Service (QoS) 826 parameters and Charging rules. BNG provides to the PCRF the IPv6 827 Prefix assigned to the host, in this case the home network prefix and 828 an ID which in this case has to be equal to the RG specific home 829 network line ID. 831 HOST_1 in Figure 15 creates an 128-bit IPv6 address using this prefix 832 and adding its interface id. Having completed the address 833 configuration, the host can start communication with a remote hosts 834 over Internet. However, no specific IP-CAN session can be assigned 835 to HOST_1, and consequently the QoS and accounting performed will be 836 based on RG subscription. 838 Another host, e.g. HOST_2, attaches to RG and also establishes an 839 IPv6 address using the home network prefix. Edge router, the BNG, is 840 not involved with this and all other such address assignments. 842 This leads to the case where no specific IP-CAN session/sub-session 843 can be assigned to the hosts, HOST_1, HOST_2, etc., and consequently 844 the QoS and accounting performed can only be based on RG subscription 845 and not host specific. Therefore IPv6 prefix sharing in Policy for 846 Convergence scenario leads to similar issues as the address sharing 847 as it has been explained in the previous scenarios in this document. 849 11. Synthesis 851 The following table shows whether each scenario is valid for IPv4/ 852 IPv6 and if it is within one single administrative domain or span 853 multiple domains. 855 +-------------------+------+-------------+-----------------------+ 856 | scenario | IPv4 | IPv6 | Single Administrative | 857 | | |------+------| Domain | 858 | | |Client|Server| | 859 +-------------------+------+------+------+-----------------------+ 860 | CGN | Yes |Yes(1)| No | No | 861 | A+P | Yes | No | No | No | 862 | Application Proxy | Yes | Yes | Yes | No | 863 | Distributed Proxy | Yes | Yes | Yes | Yes | 864 | Overlay Networks | Yes |Yes(3)|Yes(3)| No | 865 | PCC | Yes |Yes(1)| No | Yes | 866 | Emergency Calls | Yes | Yes |Yes | No | 867 | Provider WLAN | Yes | No | No | Yes | 868 | Cellular Networks | Yes |Yes(1)| No | Yes | 869 | Femtocells | Yes | No | No | No | 870 | TDF | Yes | Yes | No | Yes | 871 | FMC | Yes |Yes(1)| No | No | 872 +-------------------+------+------+------------------------------+ 874 Notes: 875 (1) e.g., NAT64 876 (2) A proxy can use IPv6 for the communication leg with the server 877 or the application client. 878 (3) This scenario is a combination of CGN and Application Proxies. 880 12. Privacy Considerations 882 Privacy-related considerations that apply to means to reveal a host 883 identifiers are discussed in [RFC6967]. This document does not 884 introduce additional privacy issues than those discussed in 885 [RFC6967]. 887 13. Security Considerations 889 This document does not define an architecture nor a protocol; as such 890 it does not raise any security concern. Host identifier related 891 security considerations are discussed in [RFC6967]. 893 14. IANA Considerations 895 This document does not require any action from IANA. 897 15. Acknowledgments 899 Many thanks to F. Klamm, D. Wing, and D. von Hugo for their review. 901 J. Touch, S. Farrel, and S. Moonesamy provided useful comments in 902 the intarea mailing list. 904 Figure 8 and part of the text in Section 10.3 are inspired from 905 [I-D.so-ipsecme-ikev2-cpext]. 907 16. Informative References 909 [EFFOpenWireless] 910 EFF, , "Open Wireless, https://www.eff.org/issues/open- 911 wireless", 2014. 913 [I-D.ietf-softwire-lw4over6] 914 Cui, Y., Qiong, Q., Boucadair, M., Tsou, T., Lee, Y., and 915 I. Farrer, "Lightweight 4over6: An Extension to the DS- 916 Lite Architecture", draft-ietf-softwire-lw4over6-10 (work 917 in progress), June 2014. 919 [I-D.ietf-softwire-map] 920 Troan, O., Dec, W., Li, X., Bao, C., Matsushima, S., 921 Murakami, T., and T. Taylor, "Mapping of Address and Port 922 with Encapsulation (MAP)", draft-ietf-softwire-map-10 923 (work in progress), January 2014. 925 [I-D.so-ipsecme-ikev2-cpext] 926 So, T., "IKEv2 Configuration Payload Extension for Private 927 IPv4 Support for Fixed Mobile Convergence", draft-so- 928 ipsecme-ikev2-cpext-02 (work in progress), June 2012. 930 [I-D.tsou-stateless-nat44] 931 Tsou, T., Liu, W., Perreault, S., Penno, R., and M. Chen, 932 "Stateless IPv4 Network Address Translation", draft-tsou- 933 stateless-nat44-02 (work in progress), October 2012. 935 [I-D.williams-overlaypath-ip-tcp-rfc] 936 Williams, B., "Overlay Path Option for IP and TCP", draft- 937 williams-overlaypath-ip-tcp-rfc-04 (work in progress), 938 June 2013. 940 [IEEE101109] 941 Salah, K., Calero, J., Zeadally, S., Almulla, S., and M. 942 ZAaabi, "Using Cloud Computing to Implement a Security 943 Overlay Network, IEEE Security & Privacy, 21 June 2012. 944 IEEE Computer Society Digital Library.", June 2012. 946 [IEEE1344002] 947 Byers, J., Considine, J., Mitzenmacher, M., and S. Rost, 948 "Informed content delivery across adaptive overlay 949 networks: IEEE/ACM Transactions on Networking, Vol 12, 950 Issue 5, ppg 767-780", October 2004. 952 [RFC2753] Yavatkar, R., Pendarakis, D., and R. Guerin, "A Framework 953 for Policy-based Admission Control", RFC 2753, January 954 2000. 956 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 957 A., Peterson, J., Sparks, R., Handley, M., and E. 958 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 959 June 2002. 961 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 962 Host Configuration Protocol (DHCP) version 6", RFC 3633, 963 December 2003. 965 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 966 October 2008. 968 [RFC5456] Spencer, M., Capouch, B., Guy, E., Miller, F., and K. 969 Shumard, "IAX: Inter-Asterisk eXchange Version 2", RFC 970 5456, February 2010. 972 [RFC5694] Camarillo, G. and IAB, "Peer-to-Peer (P2P) Architecture: 973 Definition, Taxonomies, Examples, and Applicability", RFC 974 5694, November 2009. 976 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 977 NAT64: Network Address and Protocol Translation from IPv6 978 Clients to IPv4 Servers", RFC 6146, April 2011. 980 [RFC6179] Templin, F., "The Internet Routing Overlay Network 981 (IRON)", RFC 6179, March 2011. 983 [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, 984 April 2011. 986 [RFC6269] Ford, M., Boucadair, M., Durand, A., Levis, P., and P. 987 Roberts, "Issues with IP Address Sharing", RFC 6269, June 988 2011. 990 [RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix 991 Translation", RFC 6296, June 2011. 993 [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 994 Stack Lite Broadband Deployments Following IPv4 995 Exhaustion", RFC 6333, August 2011. 997 [RFC6346] Bush, R., "The Address plus Port (A+P) Approach to the 998 IPv4 Address Shortage", RFC 6346, August 2011. 1000 [RFC6443] Rosen, B., Schulzrinne, H., Polk, J., and A. Newton, 1001 "Framework for Emergency Calling Using Internet 1002 Multimedia", RFC 6443, December 2011. 1004 [RFC6888] Perreault, S., Yamagata, I., Miyakawa, S., Nakagawa, A., 1005 and H. Ashida, "Common Requirements for Carrier-Grade NATs 1006 (CGNs)", BCP 127, RFC 6888, April 2013. 1008 [RFC6967] Boucadair, M., Touch, J., Levis, P., and R. Penno, 1009 "Analysis of Potential Solutions for Revealing a Host 1010 Identifier (HOST_ID) in Shared Address Deployments", RFC 1011 6967, June 2013. 1013 [RFC7239] Petersson, A. and M. Nilsson, "Forwarded HTTP Extension", 1014 RFC 7239, June 2014. 1016 [TS23.203] 1017 3GPP, , "Policy and charging control architecture", 1018 September 2012. 1020 [TS29.212] 1021 3GPP, , "Policy and Charging Control (PCC); Reference 1022 Points", December 2013. 1024 Authors' Addresses 1026 Mohamed Boucadair (editor) 1027 France Telecom 1028 Rennes 35000 1029 France 1031 Email: mohamed.boucadair@orange.com 1032 David Binet 1033 France Telecom 1034 Rennes 1035 France 1037 Email: david.binet@orange.com 1039 Sophie Durel 1040 France Telecom 1041 Rennes 1042 France 1044 Email: sophie.durel@orange.com 1046 Bruno Chatras 1047 France Telecom 1048 Paris 1049 France 1051 Email: bruno.chatras@orange.com 1053 Tirumaleswar Reddy 1054 Cisco Systems, Inc. 1055 Cessna Business Park, Varthur Hobli 1056 Sarjapur Marathalli Outer Ring Road 1057 Bangalore, Karnataka 560103 1058 India 1060 Email: tireddy@cisco.com 1062 Brandon Williams 1063 Akamai, Inc. 1064 Cambridge MA 1065 USA 1067 Email: brandon.williams@akamai.com 1068 Behcet Sarikaya 1069 Huawei 1070 5340 Legacy Dr. Building 3, 1071 Plano, TX 75024 1072 USA 1074 Email: sarikaya@ieee.org 1076 Li Xue 1077 Huawei 1078 Beijing 1079 China 1081 Email: xueli@huawei.com 1083 Richard Stewart Wheeldon 1084 Cisco Systems 1085 Qube, 90 Whitfield Street 1086 London W1T 4EZ 1087 UK 1089 Email: rwheeldo@cisco.com