INTAREA Working Group M. Boucadair Internet-Draft D. Binet Intended status: Informational S. Durel Expires: June 6, 2013 France Telecom T. Reddy Cisco B. Williams Akamai, Inc. December 3, 2012 Host Identification: Use Cases draft-boucadair-intarea-host-identifier-scenarios-02 Abstract This document describes a set of scenarios in which host identification is required. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on June 6, 2013. Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of Boucadair, et al. Expires June 6, 2013 [Page 1] Internet-Draft Host ID Use Cases December 2012 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Use Case 1: CGN . . . . . . . . . . . . . . . . . . . . . . . 4 4. Use Case 2: A+P . . . . . . . . . . . . . . . . . . . . . . . 4 5. Use Case 3: Application Proxies . . . . . . . . . . . . . . . 5 6. Use Case 4: Open Wi-Fi or Provider Wi-Fi . . . . . . . . . . . 6 7. Use Case 5: Policy and Charging Control Architecture . . . . . 7 8. Use Case 6: Cellular Networks . . . . . . . . . . . . . . . . 9 9. Use Case 7: Femtocells . . . . . . . . . . . . . . . . . . . . 9 10. Use Case 8: Overlay Network . . . . . . . . . . . . . . . . . 10 11. Security Considerations . . . . . . . . . . . . . . . . . . . 12 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 14. Informative References . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 Boucadair, et al. Expires June 6, 2013 [Page 2] Internet-Draft Host ID Use Cases December 2012 1. Introduction The ultimate goal of this document is to enumerate scenarios which encounter the issue of uniquely identifying a host among those sharing the same IP address. Examples of encountered issues are: o Blacklist a misbehaving host without impacting all hosts sharing the same IP address. o Enforce a per-subscriber/per-UE policy (e.g., limit access to the service based on some counters such as volume-based service offering); enforcing the policy will have impact on all hosts sharing the same IP address. o If invoking a service has failed (e.g., wrong login/passwd), all hosts sharing the same IP address may not be able to access that service. o Need to correlate between the internal address:port and external address:port to generate and therefore to enforce policies. It is out of scope of this document to list all the encountered issues as this is already covered in [RFC6269]. The generic concept of host identifier, denoted as HOST_ID, is defined in [I-D.ietf-intarea-nat-reveal-analysis]. The analysis of the use cases listed in this document indicates two root causes for the host identification issue: 1. Presence of address sharing (NAT, A+P, application proxies, etc.). 2. Use of tunnels between two administrative domains. 3. Combination of NAT and presence of tunnels in the path. The following use cases are identified so far: (1) Section 3: Carrier Grade NAT (CGN) (2) Section 4: A+P (e.g., MAP ) (3) Section 5: Application Proxies (4) Section 6: Provider Wi-Fi (5) Section 7: Policy and Charging Architectures (6) Section 8: Cellular Networks (7) Section 9: Femtocells (8) Section 10: Overlay Networks (e.g., CDNs) 2. Scope It is out of scope of this document to argue in favor or against the use cases listed in the following sub-sections. The goal is to identify scenarios the authors are aware of and which share the same issue of host identification. Boucadair, et al. Expires June 6, 2013 [Page 3] Internet-Draft Host ID Use Cases December 2012 This document does not include any solution-specific discussion. This document can be used as a tool to design solution(s) mitigating the encountered issues. Having a generic solution which would solve the issues encountered in these use cases is preferred over designing a solution for each use case. Describing the use case allows to identify what is common between the use cases and then would help during the solution design phase. The first version of the document does not elaborate whether explicit authentication is enabled or not. 3. Use Case 1: CGN Several flavors of stateful CGN have been defined. A non-exhaustive list is provided below: 1. NAT44 2. DS-Lite NAT44 [RFC6333] 3. NAT64 [RFC6146] 4. NPTv6 [RFC6296] As discussed in [I-D.ietf-intarea-nat-reveal-analysis], remote servers are not able to distinguish between hosts sharing the same IP address (Figure 1). +-----------+ | HOST_1 |----+ +-----------+ | +--------------------+ +------------+ | | |------| server 1 | +-----------+ +-----+ | | +------------+ | HOST_2 |--| CGN |----| INTERNET | :: +-----------+ +-----+ | | +------------+ | | |------| server n | +-----------+ | +--------------------+ +------------+ | HOST_3 |-----+ +-----------+ Figure 1: CGN: Architecture Example 4. Use Case 2: A+P A+P [RFC6346] denotes a flavor of address sharing solutions which does not require any additional NAT function be enabled in the Boucadair, et al. Expires June 6, 2013 [Page 4] Internet-Draft Host ID Use Cases December 2012 service provider's network. A+P assumes subscribers are assigned with the same IPv4 address together with a port set. Subscribers assigned with the same IPv4 address should be assigned non overlapping port sets. Devices connected to an A+P-enabled network should be able to restrict the IPv4 source port to be within a configure range of ports. To forward incoming packets to the appropriate host, a dedicated entity called PRR (Port Range Router, [RFC6346]) is needed (Figure 2). Similar to the CGN case, the same issue to identify hosts sharing the same IP address is encountered by remote servers. +-----------+ | HOST_1 |----+ +-----------+ | +--------------------+ +------------+ | | |------| server 1 | +-----------+ +-----+ | | +------------+ | HOST_2 |--| PRR |----| INTERNET | :: +-----------+ +-----+ | | +------------+ | | |------| server n | +-----------+ | +--------------------+ +------------+ | HOST_3 |-----+ +-----------+ Figure 2: A+P: Architecture Example 5. Use Case 3: Application Proxies This scenario is similar to the CGN scenario. Remote servers are not able to distinguish hosts located behind the PROXY. Applying policies on the perceived external IP address as received from the PROXY will impact all hosts connected to that PROXY. Figure 3 illustrates a simple configuration involving a proxy. Note several (per-application) proxies may be deployed. Boucadair, et al. Expires June 6, 2013 [Page 5] Internet-Draft Host ID Use Cases December 2012 +-----------+ | HOST_1 |----+ +-----------+ | +--------------------+ +------------+ | | |------| server 1 | +-----------+ +-----+ | | +------------+ | HOST_2 |--|PROXY|----| INTERNET | :: +-----------+ +-----+ | | +------------+ | | |------| server n | +-----------+ | +--------------------+ +------------+ | HOST_3 |-----+ +-----------+ Figure 3: Proxy: Overview 6. Use Case 4: Open Wi-Fi or Provider Wi-Fi In the context of Provider Wi-Fi, a dedicated SSID can be configured and advertised by the RG (Residential Gateway) for visiting terminals. These visiting terminals can be mobile terminals, PCs, etc. Several deployment scenarios are envisaged: 1. Deploy a dedicated node in the service provider's network which will be responsible to intercept all the traffic issued from visiting terminals (see Figure 4). This node may be co-located with a CGN function if private IPv4 addresses are assigned to visiting terminals. Similar to the CGN case discussed in Section 3, remote servers may not be able to distinguish visiting hosts sharing the same IP address (see [RFC6269]). 2. Unlike the previous deployment scenario, IPv4 addresses are managed by the RG without requiring any additional NAT to be deployed in the service provider's network for handling traffic issued from visiting terminals. Concretely, a visiting terminal is assigned with a private IPv4 address from the pool managed by the RG. Packets issued form a visiting terminal are translated using the public IP address assigned to the RG (see Figure 5). This deployment scenario induces the following identification concerns: * The provider is not able to distinguish the traffic belonging to the visiting terminal from the traffic of the subscriber owning the RG. This is needed to apply some policies such as: accounting, DSCP remarking, black list, etc. Boucadair, et al. Expires June 6, 2013 [Page 6] Internet-Draft Host ID Use Cases December 2012 * Similar to the CGN case Section 3, a misbehaving visiting terminal is likely to have some impact on the experienced service by the customer owning the RG (e.g., some of the issues are discussed in [RFC6269]). +-------------+ |Local_HOST_1 |----+ +-------------+ | | | +-------------+ +-----+ | +-----------+ |Local_HOST_2 |--| RG |-|--|Border Node| +-------------+ +-----+ | +----NAT----+ | | +-------------+ | | Service Provider |Visiting Host|-----+ +-------------+ Figure 4: NAT enforced in a Service Provider's Node +-------------+ |Local_HOST_1 |----+ +-------------+ | | | +-------------+ +-----+ | +-----------+ |Local_HOST_2 |--| RG |-|--|Border Node| +-------------+ +-NAT-+ | +-----------+ | | +-------------+ | | Service Provider |Visiting Host|-----+ +-------------+ Figure 5: NAT located in the RG 7. Use Case 5: Policy and Charging Control Architecture This issue is related to the framework defined in [TS.23203] when a NAT is located between the PCEF (Policy and Charging Enforcement Function) and the AF (Application Function) as shown in Figure 6. The main issue is: PCEF, PCRF and AF all receive information bound to the same UE but without being able to correlate between the piece of data visible for each entity. Concretely, o PCEF is aware of the IMSI (International Mobile Subscriber Identity) and an internal IP address assigned to the UE. Boucadair, et al. Expires June 6, 2013 [Page 7] Internet-Draft Host ID Use Cases December 2012 o AF receives an external IP address and port as assigned by the NAT function. o PCRF is not able to correlate between the external IP address/port assigned by the NAT and the internal IP address and IMSI of the UE. +------+ | PCRF |-----------------+ +------+ | | | +----+ +------+ +-----+ +-----+ | UE |------| PCEF |---| NAT |----| AF | +----+ +------+ +-----+ +-----+ Figure 6 This scenario can be generalized as follows (Figure 7): o Policy Enforcement Point (PEP, [RFC2753]) o Policy Decision Point (PDP, [RFC2753]) +------+ | PDP |-----------------+ +------+ | | | +----+ +------+ +-----+ +------+ |Host|------| PEP |---| NAT |----|Server| +----+ +------+ +-----+ +------+ Figure 7 A similar issue is encounterd when the NAT is located before the PEP function (see Figure 8): +------+ | PDP |------+ +------+ | | | +----+ +------+ +-----+ +------+ |Host|------| NAT |---| PEP |----|Server| +----+ +------+ +-----+ +------+ Figure 8 Boucadair, et al. Expires June 6, 2013 [Page 8] Internet-Draft Host ID Use Cases December 2012 8. Use Case 6: Cellular Networks Cellular operators allocate private IPv4 addresses to mobile customers and deploy NAT44 function, generally co-located with firewalls, to access to public IP services. The NAT function is located at the boundaries of the PLMN. IPv6-only strategy, consisting in allocating IPv6 prefixes only to customers, is considered by various operators. A NAT64 function is also considered in order to preserve IPv4 service continuity for these customers. These NAT44 and NAT64 functions bring some issues very similar to those mentioned in Figure 1 and Section 7. This issue is particularly encountered if policies are to be applied on the Gi interface: a private IP address may be assigned to several UEs, no correlation between the internal IP address and the address:port assigned by the NAT function, etc. 9. Use Case 7: Femtocells This issue is discussed in [I-D.so-ipsecme-ikev2-cpext]. This use case can be seen as a combination of the use cases described in Section 6 and Section 7. The reference architecture, originally provided in [I-D.so-ipsecme-ikev2-cpext], is shown in Figure 8. +---------------------------+ | +----+ +--------+ +----+ | +-----------+ +-------------------+ | | UE | | Stand- |<=|====|=|===|===========|==|=>+--+ +--+ | | +----+ | alone | | RG | | | | | | | | | Mobile | | | FAP | +----+ | | | | |S | |F | Network| | +--------+ (NAPT) | | Broadband | | |e | |A | | +---------------------------+ | Fixed | | |G |-|P | +-----+| | Network | | |W | |G |-| Core|| +---------------------------+ | (BBF) | | | | |W | | Ntwk|| | +----+ +------------+ | | | | | | | | +-----+| | | UE | | Integrated |<====|===|===========|==|=>+--+ +--+ | | +----+ | FAP (NAPT) | | +-----------+ +-------------------+ | +------------+ | +---------------------------+ <=====> IPsec tunnel CoreNtwk Core Network FAPGW FAP Gateway SeGW Security Gateway Figure 9: Femtocell: Overall Architecture Boucadair, et al. Expires June 6, 2013 [Page 9] Internet-Draft Host ID Use Cases December 2012 UE is connected to the FAP at the residential gateway (RG), routed back to 3GPP Evolved Packet Core (EPC). UE is assigned IPv4 address by the Mobile Network. Mobile operator's FAP leverages the IPSec IKEv2 to interconnect FAP with the SeGW over the BBF network. Both the FAP and the SeGW are managed by the mobile operator which may be a different operator for the BBF network. An investigated scenario is the mobile network to pass on its mobile subscriber's policies to the BBF to support remote network management. But most of today's broadband fixed networks are relying on the private IPv4 addressing plan (+NAPT) to support its attached devices including the mobile operator's FAP. In this scenario, the mobile network needs to: o determine the FAP's public IPv4 address to identify the location of the FAP to ensure its legitimacy to operate on the license spectrum for a given mobile operator prior to the FAP be ready to serve its mobile devices. o determine the FAP's pubic IPv4 address together with the translated port number of the UDP header of the encapsulated IPsec tunnel for identifying the UE's traffic at the fixed broadband network. o determine the corresponding FAP's public IPv4 address associated with the UE's inner-IPv4 address which is assigned by the mobile network to identify the mobile UE to allow the PCRF to retrieve the UE's policy (e.g., QoS) to be passed onto the Broadband Policy Control Function (BPCF) at the BBF network. SecGW would have the complete knowledge of such mapping, but the reasons for unable to use SecGW for this purpose is explained in "Problem Statements" (section 2 of [I-D.so-ipsecme-ikev2-cpext]). This use case makes use of PCRF/BPCF but it is valid in other deployment scenarios making use of AAA servers. The issue of correlating the internal IP address and the public IP address is valid even if there is no NAT in the path. 10. Use Case 8: Overlay Network An overlay network is a network of machines distributed throughout multiple autonomous systems within the public Internet that can be used to improve the performance of data transport (see Figure 10). IP packets from the sender are delivered first to one of the machines that make up the overlay network. That machine then relays the IP Boucadair, et al. Expires June 6, 2013 [Page 10] Internet-Draft Host ID Use Cases December 2012 packets to the receiver via one or more machines in the overlay network, applying various performance enhancement methods. +------------------------------------+ | | | INTERNET | | | +-----------+ | +------------+ | | HOST_1 |-----| OVRLY_IN_1 |-----------+ | +-----------+ | +------------+ | | | | | +-----------+ | +------------+ +-----------+ | +--------+ | HOST_2 |-----| OVRLY_IN_2 |-----| OVRLY_OUT |-----| SERVER | +-----------+ | +------------+ +-----------+ | +--------+ | | | +-----------+ | +------------+ | | | HOST_3 |-----| OVRLY_IN_3 |-----------+ | +-----------+ | +------------+ | | | +------------------------------------+ Figure 10: Overlay Network Data transport using an overlay network requires network address translation for both the source and destination addresses in such a way that the public IP addresses of the true endpoint machines involved in data transport are invisible to each other (see Figure 11). In other words, the true sender and receiver use two completely different pairs of source and destination addresses to identify the connection on the sending and receiving networks. ip hdr contains: ip hdr contains: SENDER -> src = sender --> OVERLAY --> src = overlay2 --> RECEIVER dst = overlay1 dst = receiver Figure 11: NAT operations in an Overlay Network This scenario is similar to the CGN (Section 3) and proxy (Section 5) scenarios. The remote server is not able to distinguish among hosts using the overlay for transport. In addition, the remote server is not able to determine the overlay ingress point being used by the host, which can be useful for diagnosing host connectivity issues. More details about this use case are provided in [I-D.williams-overlaypath-ip-tcp-rfc]. Boucadair, et al. Expires June 6, 2013 [Page 11] Internet-Draft Host ID Use Cases December 2012 11. Security Considerations This document does not define an architecture nor a protocol; as such it does not raise any security concern. 12. IANA Considerations This document does not require any action from IANA. 13. Acknowledgments Many thanks to F. Klamm for the review. Figure 8 and part of the text in Section 9 are inspired from [I-D.so-ipsecme-ikev2-cpext]. 14. Informative References [I-D.ietf-intarea-nat-reveal-analysis] Boucadair, M., Touch, J., Levis, P., and R. Penno, "Analysis of Solution Candidates to Reveal a Host Identifier (HOST_ID) in Shared Address Deployments", draft-ietf-intarea-nat-reveal-analysis-04 (work in progress), August 2012. [I-D.so-ipsecme-ikev2-cpext] So, T., "IKEv2 Configuration Payload Extension for Private IPv4 Support for Fixed Mobile Convergence", draft-so-ipsecme-ikev2-cpext-02 (work in progress), June 2012. [I-D.williams-overlaypath-ip-tcp-rfc] Williams, B., "Overlay Path Option for IP and TCP", draft-williams-overlaypath-ip-tcp-rfc-02 (work in progress), September 2012. [RFC2753] Yavatkar, R., Pendarakis, D., and R. Guerin, "A Framework for Policy-based Admission Control", RFC 2753, January 2000. [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers", RFC 6146, April 2011. [RFC6269] Ford, M., Boucadair, M., Durand, A., Levis, P., and P. Boucadair, et al. Expires June 6, 2013 [Page 12] Internet-Draft Host ID Use Cases December 2012 Roberts, "Issues with IP Address Sharing", RFC 6269, June 2011. [RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix Translation", RFC 6296, June 2011. [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- Stack Lite Broadband Deployments Following IPv4 Exhaustion", RFC 6333, August 2011. [RFC6346] Bush, R., "The Address plus Port (A+P) Approach to the IPv4 Address Shortage", RFC 6346, August 2011. [TS.23203] 3GPP, "Policy and charging control architecture", September 2012. Authors' Addresses Mohamed Boucadair France Telecom Rennes, 35000 France Email: mohamed.boucadair@orange.com David Binet France Telecom Rennes, France Email: david.binet@orange.com Sophie Durel France Telecom Rennes France Email: sophie.durel@orange.com Boucadair, et al. Expires June 6, 2013 [Page 13] Internet-Draft Host ID Use Cases December 2012 Tirumaleswar Reddy Cisco Systems, Inc. Cessna Business Park, Varthur Hobli Sarjapur Marathalli Outer Ring Road Bangalore, Karnataka 560103 India Email: tireddy@cisco.com Brandon Williams Akamai, Inc. Cambridge, MA USA Phone: Fax: Email: brandon.williams@akamai.com URI: Boucadair, et al. Expires June 6, 2013 [Page 14]