INTAREA Working Group M. Boucadair
Internet-Draft D. Binet
Intended status: Informational S. Durel
Expires: April 20, 2013 France Telecom
T. Reddy
Cisco
October 17, 2012
HOST_ID: Use Cases
draft-boucadair-intarea-host-identifier-scenarios-01
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 April 20, 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
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Boucadair, et al. Expires April 20, 2013 [Page 1]
Internet-Draft Host ID Use Cases October 2012
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 . . . . . . . . . . . . . . . . 8
9. Use Case 7: Femtocells . . . . . . . . . . . . . . . . . . . . 9
10. Security Considerations . . . . . . . . . . . . . . . . . . . 10
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10
13. Informative References . . . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
Boucadair, et al. Expires April 20, 2013 [Page 2]
Internet-Draft Host ID Use Cases October 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.
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.
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
Boucadair, et al. Expires April 20, 2013 [Page 3]
Internet-Draft Host ID Use Cases October 2012
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
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
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
Boucadair, et al. Expires April 20, 2013 [Page 4]
Internet-Draft Host ID Use Cases October 2012
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
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.
+-----------+
| HOST_1 |----+
+-----------+ | +--------------------+ +------------+
| | |------| server 1 |
+-----------+ +-----+ | | +------------+
| HOST_2 |--|PROXY|----| INTERNET | ::
+-----------+ +-----+ | | +------------+
| | |------| server n |
+-----------+ | +--------------------+ +------------+
| HOST_3 |-----+
+-----------+
Boucadair, et al. Expires April 20, 2013 [Page 5]
Internet-Draft Host ID Use Cases October 2012
Figure 3
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.
* 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]).
Boucadair, et al. Expires April 20, 2013 [Page 6]
Internet-Draft Host ID Use Cases October 2012
+-----------+
| TV |----+
+-----------+ |
| |
+-----------+ +-----+ | +-----------+
| HOST |--| RG |-|--|Border Node|
+-----------+ +-----+ | +----NAT----+
| |
+-----------+ | | Service Provider
|Visiting UE|-----+
+-----------+
Figure 4
+-----------+
| TV |----+
+-----------+ |
| |
+-----------+ +-----+ | +-----------+
| HOST |--| RG |-|--|Border Node|
+-----------+ +-NAT-+ | +-----------+
| |
+-----------+ | | Service Provider
|Visiting UE|-----+
+-----------+
Figure 5
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.
o AF receives an external IP address and port as assigned by the NAT
function.
Boucadair, et al. Expires April 20, 2013 [Page 7]
Internet-Draft Host ID Use Cases October 2012
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
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.
Boucadair, et al. Expires April 20, 2013 [Page 8]
Internet-Draft Host ID Use Cases October 2012
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 8
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
Boucadair, et al. Expires April 20, 2013 [Page 9]
Internet-Draft Host ID Use Cases October 2012
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. Security Considerations
This document does not define an architecture nor a protocol; as such
it does not raise any security concern.
11. IANA Considerations
This document does not require any action from IANA.
12. 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].
13. 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
Boucadair, et al. Expires April 20, 2013 [Page 10]
Internet-Draft Host ID Use Cases October 2012
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.
[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.
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
Boucadair, et al. Expires April 20, 2013 [Page 11]
Internet-Draft Host ID Use Cases October 2012
David Binet
France Telecom
Rennes,
France
Email: david.binet@orange.com
Sophie Durel
France Telecom
Rennes
France
Email: sophie.durel@orange.com
Tirumaleswar Reddy
Cisco Systems, Inc.
Cessna Business Park, Varthur Hobli
Sarjapur Marathalli Outer Ring Road
Bangalore, Karnataka 560103
India
Email: tireddy@cisco.com
Boucadair, et al. Expires April 20, 2013 [Page 12]