idnits 2.17.1 draft-boucadair-intarea-host-identifier-scenarios-04.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 : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 9 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 641: '...REQ#1: HOST_ID MUST be set by a trus...' RFC 2119 keyword, line 642: '... HOST_ID MUST be able to valid...' RFC 2119 keyword, line 643: '...evice. Receiver MUST detect HOST_ID s...' RFC 2119 keyword, line 647: '...t generates HOST_ID MUST strip HOST_ID...' RFC 2119 keyword, line 651: '...ces policy based on HOST_ID MUST strip...' (16 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 14, 2014) is 3717 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.cui-softwire-b4-translated-ds-lite' is defined on line 752, but no explicit reference was found in the text == Outdated reference: A later version (-13) exists of draft-ietf-softwire-map-10 Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTAREA Working Group M. Boucadair, Ed. 3 Internet-Draft D. Binet 4 Intended status: Informational S. Durel 5 Expires: August 18, 2014 B. Chatras 6 France Telecom 7 T. Reddy 8 Cisco 9 B. Williams 10 Akamai, Inc. 11 L. Xue 12 Huawei 13 February 14, 2014 15 Host Identification: Use Cases 16 draft-boucadair-intarea-host-identifier-scenarios-04 18 Abstract 20 This document describes a set of scenarios in which host 21 identification is required. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on August 18, 2014. 40 Copyright Notice 42 Copyright (c) 2014 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 3.1. Use Case 1: CGN . . . . . . . . . . . . . . . . . . . . . 4 61 3.2. Use Case 2: A+P . . . . . . . . . . . . . . . . . . . . . 4 62 3.3. Use Case 3: Application Proxies . . . . . . . . . . . . . 5 63 3.4. Use Case 4: Open Wi-Fi or Provider Wi-Fi . . . . . . . . 5 64 3.5. Use Case 5: Policy and Charging Control Architecture . . 7 65 3.6. Use Case 6: Cellular Networks . . . . . . . . . . . . . . 8 66 3.7. Use Case 7: Femtocells . . . . . . . . . . . . . . . . . 8 67 3.8. Use Case 8: Overlay Network . . . . . . . . . . . . . . . 10 68 3.9. Use Case 9: Emergency Calls . . . . . . . . . . . . . . . 11 69 3.10. Use Case 10: Traffic Detection Function . . . . . . . . . 12 70 3.11. Use Case 11: Fixed and Mobile Network Convergence . . . . 13 71 4. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 14 72 4.1. HOST_ID Requirements . . . . . . . . . . . . . . . . . . 14 73 4.2. Synthesis . . . . . . . . . . . . . . . . . . . . . . . . 16 74 5. Security Considerations . . . . . . . . . . . . . . . . . . . 16 75 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 76 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 77 8. Informative References . . . . . . . . . . . . . . . . . . . 17 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 80 1. Introduction 82 The ultimate goal of this document is to enumerate scenarios which 83 encounter the issue of uniquely identifying a host among those 84 sharing the same IP address. Examples of encountered issues are: 86 o Blacklist a misbehaving host without impacting all hosts sharing 87 the same IP address. 88 o Enforce a per-subscriber/per-UE policy (e.g., limit access to the 89 service based on some counters such as volume-based service 90 offering); enforcing the policy will have impact on all hosts 91 sharing the same IP address. 92 o If invoking a service has failed (e.g., wrong login/password), all 93 hosts sharing the same IP address may not be able to access that 94 service. 95 o Need to correlate between the internal address:port and external 96 address:port to generate and therefore to enforce policies. 98 It is out of scope of this document to list all the encountered 99 issues as this is already covered in [RFC6269]. 101 The generic concept of host identifier, denoted as HOST_ID, is 102 defined in [I-D.ietf-intarea-nat-reveal-analysis]. 104 The analysis of the use cases listed in this document indicates 105 several root causes for the host identification issue: 107 1. Presence of address sharing (NAT, A+P, application proxies, 108 etc.). 109 2. Use of tunnels between two administrative domains. 110 3. Combination of NAT and presence of tunnels in the path. 112 The following use cases are identified so far: 114 (1) Section 3.1: Carrier Grade NAT (CGN) 115 (2) Section 3.2: A+P (e.g., MAP ) 116 (3) Section 3.3: Application Proxies 117 (4) Section 3.4: Provider Wi-Fi 118 (5) Section 3.5: Policy and Charging Architectures 119 (6) Section 3.6: Cellular Networks 120 (7) Section 3.7: Femtocells 121 (8) Section 3.8: Overlay Networks (e.g., CDNs) 122 (9) Section 3.9: Emergency Calls 123 (10) Section 3.10: Traffic Detection Function 124 (11) Section 3.11: Fixed and Mobile Network Convergence 126 2. Scope 128 It is out of scope of this document to argue in favor or against the 129 use cases listed in the following sub-sections. The goal is to 130 identify scenarios the authors are aware of and which share the same 131 issue of host identification. 133 This document does not include any solution-specific discussion. 134 This document can be used as a tool to design solution(s) mitigating 135 the encountered issues. Having a generic solution which would solve 136 the issues encountered in these use cases is preferred over designing 137 a solution for each use case. Describing the use case allows to 138 identify what is common between the use cases and then would help 139 during the solution design phase. 141 The first version of the document does not elaborate whether explicit 142 authentication is enabled or not. 144 3. Use Cases 146 3.1. Use Case 1: CGN 148 Several flavors of stateful CGN have been defined. A non-exhaustive 149 list is provided below: 151 1. NAT44 ( [I-D.ietf-behave-lsn-requirements], 152 [I-D.tsou-stateless-nat44]) 154 2. DS-Lite NAT44 [RFC6333] 156 3. NAT64 [RFC6146] 158 4. NPTv6 [RFC6296] 160 As discussed in [I-D.ietf-intarea-nat-reveal-analysis], remote 161 servers are not able to distinguish between hosts sharing the same IP 162 address (Figure 1). 164 +-----------+ 165 | HOST_1 |----+ 166 +-----------+ | +--------------------+ +------------+ 167 | | |------| server 1 | 168 +-----------+ +-----+ | | +------------+ 169 | HOST_2 |--| CGN |----| INTERNET | :: 170 +-----------+ +-----+ | | +------------+ 171 | | |------| server n | 172 +-----------+ | +--------------------+ +------------+ 173 | HOST_3 |-----+ 174 +-----------+ 176 Figure 1: CGN: Architecture Example 178 3.2. Use Case 2: A+P 180 A+P [RFC6346][I-D.ietf-softwire-map][I-D.cui-softwire-b4-translated-d 181 s-lite] denotes a flavor of address sharing solutions which does not 182 require any additional NAT function be enabled in the service 183 provider's network. A+P assumes subscribers are assigned with the 184 same IPv4 address together with a port set. Subscribers assigned 185 with the same IPv4 address should be assigned non overlapping port 186 sets. Devices connected to an A+P-enabled network should be able to 187 restrict the IPv4 source port to be within a configured range of 188 ports. To forward incoming packets to the appropriate host, a 189 dedicated entity called PRR (Port Range Router, [RFC6346]) is needed 190 (Figure 2). 192 Similar to the CGN case, the same issue to identify hosts sharing the 193 same IP address is encountered by remote servers. 195 +-----------+ 196 | HOST_1 |----+ 197 +-----------+ | +--------------------+ +------------+ 198 | | |------| server 1 | 199 +-----------+ +-----+ | | +------------+ 200 | HOST_2 |--| PRR |----| INTERNET | :: 201 +-----------+ +-----+ | | +------------+ 202 | | |------| server n | 203 +-----------+ | +--------------------+ +------------+ 204 | HOST_3 |-----+ 205 +-----------+ 207 Figure 2: A+P: Architecture Example 209 3.3. Use Case 3: Application Proxies 211 This scenario is similar to the CGN scenario. Remote servers are not 212 able to distinguish hosts located behind the PROXY. Applying 213 policies on the perceived external IP address as received from the 214 PROXY will impact all hosts connected to that PROXY. 216 Figure 3 illustrates a simple configuration involving a proxy. Note 217 several (per-application) proxies may be deployed. 219 +-----------+ 220 | HOST_1 |----+ 221 +-----------+ | +--------------------+ +------------+ 222 | | |------| server 1 | 223 +-----------+ +-----+ | | +------------+ 224 | HOST_2 |--|PROXY|----| INTERNET | :: 225 +-----------+ +-----+ | | +------------+ 226 | | |------| server n | 227 +-----------+ | +--------------------+ +------------+ 228 | HOST_3 |-----+ 229 +-----------+ 231 Figure 3: Proxy: Overview 233 3.4. Use Case 4: Open Wi-Fi or Provider Wi-Fi 235 In the context of Provider Wi-Fi, a dedicated SSID can be configured 236 and advertised by the RG (Residential Gateway) for visiting 237 terminals. These visiting terminals can be mobile terminals, PCs, 238 etc. 240 Several deployment scenarios are envisaged: 242 1. Deploy a dedicated node in the service provider's network which 243 will be responsible to intercept all the traffic issued from 244 visiting terminals (see Figure 4). This node may be co-located 245 with a CGN function if private IPv4 addresses are assigned to 246 visiting terminals. Similar to the CGN case discussed in 247 Section 3.1, remote servers may not be able to distinguish 248 visiting hosts sharing the same IP address (see [RFC6269]). 250 2. Unlike the previous deployment scenario, IPv4 addresses are 251 managed by the RG without requiring any additional NAT to be 252 deployed in the service provider's network for handling traffic 253 issued from visiting terminals. Concretely, a visiting terminal 254 is assigned with a private IPv4 address from the IPv4 address 255 pool managed by the RG. Packets issued form a visiting terminal 256 are translated using the public IP address assigned to the RG 257 (see Figure 5). This deployment scenario induces the following 258 identification concerns: 260 * The provider is not able to distinguish the traffic belonging 261 to the visiting terminal from the traffic of the subscriber 262 owning the RG. This is needed to apply some policies such as: 263 accounting, DSCP remarking, black list, etc. 265 * Similar to the CGN case Section 3.1, a misbehaving visiting 266 terminal is likely to have some impact on the experienced 267 service by the subscriber owning the RG (e.g., some of the 268 issues are discussed in [RFC6269]). 270 +-------------+ 271 |Local_HOST_1 |----+ 272 +-------------+ | 273 | | 274 +-------------+ +-----+ | +-----------+ 275 |Local_HOST_2 |--| RG |-|--|Border Node| 276 +-------------+ +-----+ | +----NAT----+ 277 | | 278 +-------------+ | | Service Provider 279 |Visiting Host|-----+ 280 +-------------+ 282 Figure 4: NAT enforced in a Service Provider's Node 284 +-------------+ 285 |Local_HOST_1 |----+ 286 +-------------+ | 287 | | 288 +-------------+ +-----+ | +-----------+ 289 |Local_HOST_2 |--| RG |-|--|Border Node| 290 +-------------+ +-NAT-+ | +-----------+ 291 | | 292 +-------------+ | | Service Provider 293 |Visiting Host|-----+ 294 +-------------+ 296 Figure 5: NAT located in the RG 298 3.5. Use Case 5: Policy and Charging Control Architecture 300 This issue is related to the framework defined in [TS23.203] when a 301 NAT is located between the PCEF (Policy and Charging Enforcement 302 Function) and the AF (Application Function) as shown in Figure 6. 304 The main issue is: PCEF, PCRF and AF all receive information bound to 305 the same UE( User Equipment) but without being able to correlate 306 between the piece of data visible for each entity. Concretely, 308 o PCEF is aware of the IMSI (International Mobile Subscriber 309 Identity) and an internal IP address assigned to the UE. 311 o AF receives an external IP address and port as assigned by the NAT 312 function. 314 o PCRF is not able to correlate between the external IP address/port 315 assigned by the NAT and the internal IP address and IMSI of the 316 UE. 318 +------+ 319 | PCRF |-----------------+ 320 +------+ | 321 | | 322 +----+ +------+ +-----+ +-----+ 323 | UE |------| PCEF |---| NAT |----| AF | 324 +----+ +------+ +-----+ +-----+ 326 Figure 6: NAT located between AF and PCEF 328 This scenario can be generalized as follows (Figure 7): 330 o Policy Enforcement Point (PEP, [RFC2753]) 331 o Policy Decision Point (PDP, [RFC2753]) 333 +------+ 334 | PDP |-----------------+ 335 +------+ | 336 | | 337 +----+ +------+ +-----+ +------+ 338 | UE |------| PEP |---| NAT |----|Server| 339 +----+ +------+ +-----+ +------+ 341 Figure 7: NAT located between PEP and Server 343 A similar issue is encountered when the NAT is located before the PEP 344 function (see Figure 8): 346 +------+ 347 | PDP |------+ 348 +------+ | 349 | | 350 +----+ +------+ +-----+ +------+ 351 | UE |------| NAT |---| PEP |----|Server| 352 +----+ +------+ +-----+ +------+ 354 Figure 8: NAT located before PEP 356 3.6. Use Case 6: Cellular Networks 358 Cellular operators allocate private IPv4 addresses to mobile 359 terminals and deploy NAT44 function, generally co-located with 360 firewalls, to access to public IP services. The NAT function is 361 located at the boundaries of the PLMN (Public Land Mobile Network). 362 IPv6-only strategy, consisting in allocating IPv6 prefixes only to 363 mobile terminals, is considered by various operators. A NAT64 364 function is also considered in order to preserve IPv4 service 365 continuity for these customers. 367 These NAT44 and NAT64 functions bring some issues very similar to 368 those mentioned in Figure 1 and Section 3.5. This issue is 369 particularly encountered if policies are to be applied on the Gi 370 interface: a private IP address is assigned to the mobile terminals, 371 there is no correlation between the internal IP address and the 372 external address:port assigned by the NAT function, etc. 374 3.7. Use Case 7: Femtocells 376 This issue is discussed in [I-D.so-ipsecme-ikev2-cpext]. This use 377 case can be seen as a combination of the use cases described in 378 Section 3.4 and Section 3.5. 380 The reference architecture, originally provided in 381 [I-D.so-ipsecme-ikev2-cpext], is shown in Figure 8. 383 +---------------------------+ 384 | +----+ +--------+ +----+ | +-----------+ +-------------------+ 385 | | UE | | Stand- |<=|====|=|===|===========|==|=>+--+ +--+ | 386 | +----+ | alone | | RG | | | | | | | | | Mobile | 387 | | FAP | +----+ | | | | |S | |F | Network| 388 | +--------+ (NAPT) | | Broadband | | |e | |A | | 389 +---------------------------+ | Fixed | | |G |-|P | +-----+| 390 | Network | | |W | |G |-| Core|| 391 +---------------------------+ | (BBF) | | | | |W | | Ntwk|| 392 | +----+ +------------+ | | | | | | | | +-----+| 393 | | UE | | Integrated |<====|===|===========|==|=>+--+ +--+ | 394 | +----+ | FAP (NAPT) | | +-----------+ +-------------------+ 395 | +------------+ | 396 +---------------------------+ 398 <=====> IPsec tunnel 399 CoreNtwk Core Network 400 FAPGW FAP Gateway 401 SeGW Security Gateway 403 Figure 9: Femtocell: Overall Architecture 405 UE is connected to the FAP at the residential gateway (RG), routed 406 back to 3GPP Evolved Packet Core (EPC). UE is assigned IPv4 address 407 by the Mobile Network. Mobile operator's FAP leverages the IPSec 408 IKEv2 to interconnect FAP with the SeGW over the BBF network. Both 409 the FAP and the SeGW are managed by the mobile operator which may be 410 a different operator for the BBF network. 412 An investigated scenario is the mobile operator to pass on its mobile 413 subscriber's policies to the BBF to support traffic policy control . 414 But most of today's broadband fixed networks are relying on the 415 private IPv4 addressing plan (+NAPT) to support its attached devices 416 including the mobile operator's FAP. In this scenario, the mobile 417 network needs to: 419 o determine the FAP's public IPv4 address to identify the location 420 of the FAP to ensure its legitimacy to operate on the license 421 spectrum for a given mobile operator prior to the FAP be ready to 422 serve its mobile devices. 424 o determine the FAP's pubic IPv4 address together with the 425 translated port number of the UDP header of the encapsulated IPsec 426 tunnel for identifying the UE's traffic at the fixed broadband 427 network. 429 o determine the corresponding FAP's public IPv4 address associated 430 with the UE's inner-IPv4 address which is assigned by the mobile 431 network to identify the mobile UE to allow the PCRF to retrieve 432 the special UE's policy (e.g., QoS) to be passed onto the 433 Broadband Policy Control Function (BPCF) at the BBF network. 435 SecGW would have the complete knowledge of such mapping, but the 436 reasons for unable to use SecGW for this purpose is explained in 437 "Problem Statements" (section 2 of [I-D.so-ipsecme-ikev2-cpext]). 439 This use case makes use of PCRF/BPCF but it is valid in other 440 deployment scenarios making use of AAA servers. 442 The issue of correlating the internal IP address and the public IP 443 address is valid even if there is no NAT in the path. 445 3.8. Use Case 8: Overlay Network 447 An overlay network is a network of machines distributed throughout 448 multiple autonomous systems within the public Internet that can be 449 used to improve the performance of data transport (see Figure 10). 450 IP packets from the sender are delivered first to one of the machines 451 that make up the overlay network. That machine then relays the IP 452 packets to the receiver via one or more machines in the overlay 453 network, applying various performance enhancement methods. 455 +------------------------------------+ 456 | | 457 | INTERNET | 458 | | 459 +-----------+ | +------------+ | 460 | HOST_1 |-----| OVRLY_IN_1 |-----------+ | 461 +-----------+ | +------------+ | | 462 | | | 463 +-----------+ | +------------+ +-----------+ | +--------+ 464 | HOST_2 |-----| OVRLY_IN_2 |-----| OVRLY_OUT |-----| SERVER | 465 +-----------+ | +------------+ +-----------+ | +--------+ 466 | | | 467 +-----------+ | +------------+ | | 468 | HOST_3 |-----| OVRLY_IN_3 |-----------+ | 469 +-----------+ | +------------+ | 470 | | 471 +------------------------------------+ 473 Figure 10: Overlay Network 475 Data transport using an overlay network requires network address 476 translation for both the source and destination addresses in such a 477 way that the public IP addresses of the true endpoint machines 478 involved in data transport are invisible to each other (see 479 Figure 11). In other words, the true sender and receiver use two 480 completely different pairs of source and destination addresses to 481 identify the connection on the sending and receiving networks. 483 ip hdr contains: ip hdr contains: 484 SENDER -> src = sender --> OVERLAY --> src = overlay2 --> RECEIVER 485 dst = overlay1 dst = receiver 487 Figure 11: NAT operations in an Overlay Network 489 This scenario is similar to the CGN (Section 3.1) and proxy 490 (Section 3.3) scenarios. The remote server is not able to 491 distinguish among hosts using the overlay for transport. In 492 addition, the remote server is not able to determine the overlay 493 ingress point being used by the host, which can be useful for 494 diagnosing host connectivity issues. 496 More details about this use case are provided in 497 [I-D.williams-overlaypath-ip-tcp-rfc]. 499 3.9. Use Case 9: Emergency Calls 501 Voice service providers (VSPs) operating under certain jurisdictions 502 are required to route emergency calls from their subscribers and have 503 to include information about the caller's location in signaling 504 messages they send towards PSAPs (Public Safety Answering Points, 505 [RFC6443]), via an Emergency Service Routing Proxy (ESRP, [RFC6443]). 506 This information is used both for the determination of the correct 507 PSAP and to reveal the caller's location to the selected PSAP. 509 In many countries, regulation bodies require that this information be 510 provided by the network rather than the user equipment, in which case 511 the VSP needs to retrieve this information (by reference or by value) 512 from the access network where the caller is attached. 514 This requires the VSP call server receiving an emergency call request 515 to identify the relevant access network and to query a Location 516 Information Server (LIS) in this network using a suitable look-up 517 key. In the simplest case, the source IP address of the IP packet 518 carrying the call request is used both for identifying the access 519 network (thanks to a reverse DNS query) and as a look-up key to query 520 the LIS. Obviously the user-id as known by the VSP (e.g., telephone 521 number, or email-formatted URI) can't be used as it is not known by 522 the access network. 524 The above mechanism is broken when there is a NAT between the user 525 and the VSP or if the emergency call is established over a VPN tunnel 526 (e.g., an employee remotely connected to a company VoIP server 527 through a tunnel wishes to make an emergency call). In such cases, 528 the source IP address received by the VSP call server will identity 529 the NAT or the address assigned to the caller equipment by the VSP 530 (i.e., the address inside the tunnel). 532 Therefore, the VSP needs to receive an additional piece of 533 information that can be used to both identify the access network 534 where the caller is attached and query the LIS for his/her location. 535 This would require the NAT or the Tunnel Endpoint to insert this 536 extra information in the call requests delivered to the VSP call 537 servers. For example, this extra information could be a combination 538 of the local IP address assigned by the access network to the 539 caller's equipment with some form of identification of this access 540 network. 542 However, because it shall be possible to setup an emergency call 543 regardless of the actual call control protocol used between the user 544 and the VSP (e.g., SIP [RFC3261], IAX [RFC5456], tunneled over HTTP, 545 or proprietary protocol, possibly encrypted), this extra information 546 has to be conveyed outside the call request, in the header of lower 547 layers protocols. 549 3.10. Use Case 10: Traffic Detection Function 551 Operators expect that the traffic subject to the packet inspection is 552 routed via the Traffic Detection Function (TDF) function as 553 requirement specified in [TS29.212], otherwise, the traffic may 554 bypass the TDF. This assumption only holds if it is possible to 555 identify individual UEs behind NA(P)T which may be deployed into the 556 RG in fixed broadband network, shown in Figure 12. As a result, 557 additional mechanisms are needed to enable this requirement. 559 +--------+ 560 | | 561 +-------+ PCRF | 562 | | | 563 | +--------+ 564 +--------+ +--------+ +--------+ +----+----+ 565 | | | | | +-----+ | 566 | ------------------------------------------------------------------ 567 | | | | | | | TDF | / \ 568 | ****************************************************************** 569 | | | +-------+ | | | Service 570 | | | | | | | \ / 571 | | | | | | | +--------+ 572 | | | | | | +--------+ PDN | 573 | ********---------**********--------************------------******* | 574 | UE | | RG | | BNG +------------------+ Gateway| 575 +--------+ +--------+ +--------+ +--------+ 576 Legends: 577 --------- 3GPP UE User Plane Traffic Offloaded subject to packet inspection 579 ********* 3GPP UE User Plane Traffic Offloaded not subject to packet inspection 581 *****---- 3GPP UE User Plane Traffic Home Routed 583 Figure 12: UE's Traffic Routed with TDF 585 3.11. Use Case 11: Fixed and Mobile Network Convergence 587 In the Fixed and Mobile network convergence (FMC) scenario, the fixed 588 broadband network must partner with the mobile network to perform 589 authorisation, authentication, and accounting (AAA) and acquire the 590 policies for the mobile terminals attaching to the fixed broadband 591 network, shown in Figure 13. 593 A UE is connected to the RG, routed back to the mobile network. The 594 mobile operator's PCRF needs to maintain the interconnect with the 595 Broadband Policy Control Function (BPCF) in the BBF network for PCC 596 (Section 3.5). The hosts (i.e. UEs) attaching to fixed broadband 597 network with a NA(P)T deployed should be identified. Based on the UE 598 identification, the BPCF to deploy policy rules in the fixed 599 broadband network can acquire the associated policy rules of the 600 identified UE from the PCRF in the mobile network. But in the fixed 601 broadband network, private IPv4 address is supported. The similar 602 requirements are raised in this use case as Figure 9. 604 +------------------------------+ +-------------+ 605 | | | | 606 | +------+ | | +------+ | 607 | | BPCF +---+---+-+ PCRF | | 608 | +--+---+ | | +---+--+ | 609 +-------+ | | | | | | 610 |HOST_1 |Private IP1 +--+---+ | | +---+--+ | 611 +-------+ | +----+ | | | | | | | 612 | | RG | | | | | | | | 613 | |with+-------------+ BNG +--------+ PGW | | 614 +-------+ | | NAT| | | | | | | | 615 |HOST_2 | | +----+ | | | | | | | 616 +-------+Private IP2 +------+ | | +------+ | 617 | | | | 618 | | | | 619 | Fixed | | Mobile | 620 | Broadband | | Network | 621 | Network | | | 622 | | | | 623 +------------------------------+ +-------------+ 625 Figure 13: Fixed and Mobile Network Convergence 627 In IPv6 network, the similar issues exists when the IPv6 prefix is 628 sharing between multiple UEs attaching to the RG. More details about 629 the IPv6 prefix sharing issues are provided 630 in[I-D.sarikaya-fmc-prefix-sharing-usecase]. 632 4. Discussion 634 This section is to be completed. 636 4.1. HOST_ID Requirements 638 Below is listed as set of requirements to be used to characterize 639 each use case (discussed in Section 3): 641 REQ#1: HOST_ID MUST be set by a trusted device. Receiver using 642 HOST_ID MUST be able to validate that HOST_ID is set by a 643 trusted device. Receiver MUST detect HOST_ID set by rogue 644 devices and discard HOST_ID (i.e. not use HOST_ID for 645 policy enforcement). 647 REQ#2: Trusted Device that generates HOST_ID MUST strip HOST_ID 648 received from the host or HOST_ID set by any other 649 downstream devices. 651 REQ#3: Receiver that enforces policy based on HOST_ID MUST strip 652 HOST_ID before sending it upstream 654 REQ#4: Host SHOULD be permitted to set HOST_ID 656 REQ#5: HOST_ID MUST be provided in all the IP packets 658 REQ#6: HOST_ID MUST be provided in-line (i.e. Multiplexed) with the 659 transport protocol 661 REQ#7: HOST_ID MUST be provided using out-of-band mechanism 663 REQ#8: HOST_ID MUST be provided either using in-line or out-of-band 664 mechanism 666 REQ#9: HOST_ID MUST be encrypted so that other devices cannot glean 667 the HOST_ID information, that could result in identity 668 leakage. 670 REQ#10: HOST_ID MUST be conveyed for consumption within a single 671 administrative domain. 673 REQ#11: HOST_ID MUST be conveyed across multiple administrative 674 domain. In other words, the producer and consumer of 675 HOST_ID are in different administrative domains. 677 REQ#12: Connection-oriented protocols (e.g., TCP or SCTP) MUST 678 convey HOST_ID. 680 REQ#13: Connection-less protocols (e.g., UDP) MUST convey HOST_ID. 682 REQ#14: The entire IPv6/IPv4 address MUST be conveyed in the HOST_ID 684 REQ#15: 16-bit value representing a host hint is sufficient to be 685 conveyed in the HOST_ID 687 REQ#16: HOST_ID propagation MUST be supported for IPv4-only. 689 REQ#17: HOST_ID propagation MUST be supported for IPv4 and IPv6. 691 REQ#18: Receiver MUST use HOST_ID to enforce policies like QoS. 693 REQ#19: Receiver uses HOST_ID only for Accounting and debugging 694 purposes. 696 REQ#20: Receiver MUST use HOST_ID to achieve specific traffic 697 treatment like TDF. 699 REQ#21: HOST_ID MUST be recongnized by different operators. 701 Once this list is stabilized, each use case will be checked against 702 these requirements. 704 4.2. Synthesis 706 The following table shows whether each use case is valid for IPv4/ 707 IPv6 and if it is to be applied within one single administrative 708 domain or not. This table will be completed. 710 +-------------------+------+-------------+-----------------------+ 711 | Use Case | IPv4 | IPv6 | Single Administrative | 712 | | |------+------| Domain | 713 | | |Client|Server| | 714 +-------------------+------+------+------+-----------------------+ 715 | CGN | Yes |Yes(1)| No | No | 716 | A+P | Yes | No | No | No | 717 | Application Proxy | Yes |Yes(2)|Yes(2)| No | 718 | Provider Wi-Fi | Yes | No | No | Yes | 719 | PCC | Yes |Yes(1)| No | Yes | 720 | Femtocells | Yes | No | No | No | 721 | Cellular Networks | Yes |Yes(1)| No | Yes | 722 | Overlay Networks | Yes |Yes(3)|Yes(3)| No | 723 | Emergency Calls | Yes | Yes |Yes | No | 724 | TDF | Yes | Yes | No | Yes | 725 | FMC | Yes |Yes(1)| No | No | 726 +-------------------+------+------+------------------------------+ 728 Notes: 729 (1) e.g., NAT64 730 (2) A proxy can use IPv6 for the communication leg with the server 731 or the application client. 732 (3) This use case is a combination of CGN and Application Proxies. 734 5. Security Considerations 736 This document does not define an architecture nor a protocol; as such 737 it does not raise any security concern. 739 6. IANA Considerations 741 This document does not require any action from IANA. 743 7. Acknowledgments 745 Many thanks to F. Klamm for the review. 747 Figure 8 and part of the text in Section 3.7 are inspired from 748 [I-D.so-ipsecme-ikev2-cpext]. 750 8. Informative References 752 [I-D.cui-softwire-b4-translated-ds-lite] 753 Cui, Y., Sun, Q., Boucadair, M., Tsou, T., Lee, Y., and I. 754 Farrer, "Lightweight 4over6: An Extension to the DS-Lite 755 Architecture", draft-cui-softwire-b4-translated-ds-lite-11 756 (work in progress), February 2013. 758 [I-D.ietf-behave-lsn-requirements] 759 Perreault, S., Yamagata, I., Miyakawa, S., Nakagawa, A., 760 and H. Ashida, "Common requirements for Carrier Grade NATs 761 (CGNs)", draft-ietf-behave-lsn-requirements-10 (work in 762 progress), December 2012. 764 [I-D.ietf-intarea-nat-reveal-analysis] 765 Boucadair, M., Touch, J., Levis, P., and R. Penno, 766 "Analysis of Solution Candidates to Reveal a Host 767 Identifier (HOST_ID) in Shared Address Deployments", 768 draft-ietf-intarea-nat-reveal-analysis-10 (work in 769 progress), April 2013. 771 [I-D.ietf-softwire-map] 772 Troan, O., Dec, W., Li, X., Bao, C., Matsushima, S., 773 Murakami, T., and T. Taylor, "Mapping of Address and Port 774 with Encapsulation (MAP)", draft-ietf-softwire-map-10 775 (work in progress), January 2014. 777 [I-D.sarikaya-fmc-prefix-sharing-usecase] 778 Sarikaya, B., Spini, M., and D. DH, "IPv6 Prefix Sharing 779 Problem Use Case", draft-sarikaya-fmc-prefix-sharing- 780 usecase-01 (work in progress), February 2013. 782 [I-D.so-ipsecme-ikev2-cpext] 783 So, T., "IKEv2 Configuration Payload Extension for Private 784 IPv4 Support for Fixed Mobile Convergence", draft-so- 785 ipsecme-ikev2-cpext-02 (work in progress), June 2012. 787 [I-D.tsou-stateless-nat44] 788 Tsou, T., Liu, W., Perreault, S., Penno, R., and M. Chen, 789 "Stateless IPv4 Network Address Translation", draft-tsou- 790 stateless-nat44-02 (work in progress), October 2012. 792 [I-D.williams-overlaypath-ip-tcp-rfc] 793 Williams, B., "Overlay Path Option for IP and TCP", draft- 794 williams-overlaypath-ip-tcp-rfc-04 (work in progress), 795 June 2013. 797 [RFC2753] Yavatkar, R., Pendarakis, D., and R. Guerin, "A Framework 798 for Policy-based Admission Control", RFC 2753, January 799 2000. 801 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 802 A., Peterson, J., Sparks, R., Handley, M., and E. 803 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 804 June 2002. 806 [RFC5456] Spencer, M., Capouch, B., Guy, E., Miller, F., and K. 807 Shumard, "IAX: Inter-Asterisk eXchange Version 2", RFC 808 5456, February 2010. 810 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 811 NAT64: Network Address and Protocol Translation from IPv6 812 Clients to IPv4 Servers", RFC 6146, April 2011. 814 [RFC6269] Ford, M., Boucadair, M., Durand, A., Levis, P., and P. 815 Roberts, "Issues with IP Address Sharing", RFC 6269, June 816 2011. 818 [RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix 819 Translation", RFC 6296, June 2011. 821 [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 822 Stack Lite Broadband Deployments Following IPv4 823 Exhaustion", RFC 6333, August 2011. 825 [RFC6346] Bush, R., "The Address plus Port (A+P) Approach to the 826 IPv4 Address Shortage", RFC 6346, August 2011. 828 [RFC6443] Rosen, B., Schulzrinne, H., Polk, J., and A. Newton, 829 "Framework for Emergency Calling Using Internet 830 Multimedia", RFC 6443, December 2011. 832 [TS23.203] 833 3GPP, , "Policy and charging control architecture", 834 September 2012. 836 [TS29.212] 837 3GPP, , "Policy and Charging Control (PCC); Reference 838 Points", December 2013. 840 Authors' Addresses 842 Mohamed Boucadair (editor) 843 France Telecom 844 Rennes 35000 845 France 847 Email: mohamed.boucadair@orange.com 849 David Binet 850 France Telecom 851 Rennes 852 France 854 Email: david.binet@orange.com 856 Sophie Durel 857 France Telecom 858 Rennes 859 France 861 Email: sophie.durel@orange.com 863 Bruno Chatras 864 France Telecom 865 Paris 866 France 868 Email: bruno.chatras@orange.com 870 Tirumaleswar Reddy 871 Cisco Systems, Inc. 872 Cessna Business Park, Varthur Hobli 873 Sarjapur Marathalli Outer Ring Road 874 Bangalore, Karnataka 560103 875 India 877 Email: tireddy@cisco.com 878 Brandon Williams 879 Akamai, Inc. 880 Cambridge MA 881 USA 883 Email: brandon.williams@akamai.com 885 Li Xue 886 Huawei 887 Beijing 888 China 890 Email: xueli@huawei.com