One document matched: draft-boucadair-intarea-host-identifier-scenarios-11.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="yes"?>
<rfc category="info"
docName="draft-boucadair-intarea-host-identifier-scenarios-11"
ipr="trust200902">
<front>
<title abbrev="Host Identification: Scenarios">Scenarios with Host
Identification Complications</title>
<author fullname="Mohamed Boucadair" initials="M." role="editor"
surname="Boucadair">
<organization>France Telecom</organization>
<address>
<postal>
<street></street>
<city>Rennes</city>
<region></region>
<code>35000</code>
<country>France</country>
</postal>
<email>mohamed.boucadair@orange.com</email>
</address>
</author>
<author fullname="David Binet" initials="D." surname="Binet">
<organization>France Telecom</organization>
<address>
<postal>
<street></street>
<city>Rennes</city>
<region></region>
<code></code>
<country>France</country>
</postal>
<email>david.binet@orange.com</email>
</address>
</author>
<author fullname="Sophie Durel" initials="S." surname="Durel">
<organization>France Telecom</organization>
<address>
<postal>
<street></street>
<city>Rennes</city>
<country>France</country>
</postal>
<email>sophie.durel@orange.com</email>
</address>
</author>
<author fullname="Bruno Chatras" initials="B." surname="Chatras">
<organization>France Telecom</organization>
<address>
<postal>
<street></street>
<city>Paris</city>
<region></region>
<code></code>
<country>France</country>
</postal>
<phone></phone>
<email>bruno.chatras@orange.com</email>
</address>
</author>
<author fullname="Tirumaleswar Reddy" initials="T." surname="Reddy">
<organization>Cisco Systems</organization>
<address>
<postal>
<street>Cessna Business Park, Varthur Hobli</street>
<street>Sarjapur Marathalli Outer Ring Road</street>
<city>Bangalore</city>
<region>Karnataka</region>
<code>560103</code>
<country>India</country>
</postal>
<email>tireddy@cisco.com</email>
</address>
</author>
<author fullname="Brandon Williams" initials="B." surname="Williams">
<organization>Akamai, Inc.</organization>
<address>
<postal>
<street></street>
<city>Cambridge</city>
<region></region>
<code>MA</code>
<country>USA</country>
</postal>
<phone></phone>
<facsimile></facsimile>
<email>brandon.williams@akamai.com</email>
<uri></uri>
</address>
</author>
<author fullname="Behcet Sarikaya" initials="B.S." surname="Sarikaya">
<organization>Huawei</organization>
<address>
<postal>
<street>5340 Legacy Dr. Building 3,</street>
<city>Plano</city>
<region>TX</region>
<code>75024</code>
<country>USA</country>
</postal>
<email>sarikaya@ieee.org</email>
</address>
</author>
<author fullname="Li Xue" initials="L." surname="Xue">
<organization>Huawei</organization>
<address>
<postal>
<street></street>
<city>Beijing</city>
<region></region>
<code></code>
<country>China</country>
</postal>
<email>xueli@huawei.com</email>
</address>
</author>
<author fullname="Richard Stewart Wheeldon" initials="R.S."
surname="Wheeldon">
<organization></organization>
<address>
<postal>
<street></street>
<city></city>
<region></region>
<code></code>
<country>UK</country>
</postal>
<email>richard@rswheeldon.com</email>
</address>
</author>
<date day="" month="" year="" />
<abstract>
<t>This document describes a set of scenarios in which complications to
identify which policy to apply for a host are encountered. This problem
is abstracted as "host identification". Describing these scenarios
allows to identify what is common and then would help during the
solution design phase.</t>
<t>The document does not include any solution-specific discussion.</t>
</abstract>
</front>
<middle>
<section anchor="introduction" title="Introduction">
<t>The goal of this document is to enumerate scenarios which encounter
the issue of uniquely identifying a host among those sharing the same IP
address. Within this document, a host can be any device directly
connected to a network operated by a network provider, a Home Gateway,
or a roaming device located behind a Home Gateway.</t>
<t>An exhaustive list of encountered issues for the Carrier Grade NAT
(CGN), Address plus Port (A+P), and Application Proxies scenarios are
documented in <xref target="RFC6269"></xref>. In addition to those
issues, some of the scenarios described in this document suffer from
additional issues such as:<!--I suggest to add a litte bit on increasing possibilities to connect to multiple networks and new types and amounts of end devices
(machine type, sensors) which may/will require new ways for identifications beyond IP addresses. --><?rfc subcompact="yes" ?><list
style="symbols">
<t>Identify which policy to enforce for a host (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.</t>
<t>Need to correlate between the internal address:port and external
address:port to generate and therefore to enforce policies.</t>
<t>Query a location server for the location of an emergency caller
based on the source IP address.<?rfc subcompact="no" ?></t>
</list></t>
<t>The goal of this document is to identify scenarios the authors are
aware of and which share the same complications to identify which policy
to apply for a host. This problem is abstracted as host identification
problem.</t>
<t>The analysis of the scenarios listed in this document indicates
several root causes for the host identification issue:<?rfc subcompact="yes" ?><list
style="numbers">
<t>Presence of address sharing (CGN, A+P, application proxies,
etc.).</t>
<t>Use of tunnels between two administrative domains.</t>
<t>Combination of address sharing and presence of tunnels in the
path.<?rfc subcompact="no" ?></t>
</list>Even if these scenarios share the same root causes, describing
the scenario allows to identify what is common between the scenarios and
then would help during the solution design phase. </t>
</section>
<section title="Scope">
<t>This document can be used as a tool to design solution(s) mitigating
the encountered issues. Note, <xref target="RFC6967"></xref> focuses
only on the CGN, A+P, and application proxies cases. The analysis in
<xref target="RFC6967"></xref> may not be accurate for some of the
scenarios that do not span multiple administrative domains (e.g., <xref
target="providerwifi"></xref>).</t>
<t>This document does not target means that would lead to expose a host
beyond what the original packet, issued from that host, would have
already exposed. Such means are not desirable, nor required to solve the
issues encountered in the scenarios discussed in this document. The
focus is exclusively on means to restore the information conveyed in the
original packet issued by a given host. These means are intended to help
in identifying which policy to apply for a given flow. These means may
rely on some bits of the source IP address and/or port number(s) used by
the host to issue packets. </t>
<t>To prevent side effects and mis-uses of such means on privacy,
solution specification document(s) should explain, in addition to what
is already documented in <xref target="RFC6967"></xref>, the
following:<list style="symbols">
<t>To what extent the solution can be used to nullify the effect of
using address sharing to preserve privacy (see for example <xref
target="EFFOpenWireless"></xref>). Note, this concern can be
mitigated if the address sharing platform is under the
responsibility of the host's owner and the host does not leak
information that would interfere with the host's privacy protection
tool.</t>
<t>To what extent the solution can be used to expose privacy
information beyond what the original packet would have already
exposed. Note, the solutions discussed in <xref
target="RFC6967"></xref> do not allow to reveal extra information
than what is conveyed in the original packet.</t>
</list></t>
<t>This document covers both IPv4 and IPv6.</t>
<t>This document does not include any solution-specific discussion. In
particular, the document does not elaborate whether explicit
authentication is enabled or not. </t>
<t>This document does not discuss whether specific information is needed
to be leaked in packets, whether this is achieved out-of-band, etc.
Those considerations are out of scope.</t>
</section>
<section anchor="CGN" title="Scenario 1: Carrier-Grade NAT (CGN)">
<t>Several flavors of stateful CGN have been defined. A non-exhaustive
list is provided below:<list style="numbers">
<t>NAT44 (<xref target="RFC6888"></xref>, <xref
target="I-D.tsou-stateless-nat44"></xref>)</t>
<t>DS-Lite NAT44 <xref target="RFC6333"></xref></t>
<t>NAT64 <xref target="RFC6146"></xref></t>
<t>NPTv6 <xref target="RFC6296"></xref></t>
</list></t>
<t>As discussed in <xref target="RFC6967"></xref>, remote servers are
not able to distinguish between hosts sharing the same IP address (<xref
target="cgn"></xref>). As a reminder, remote servers rely on the source
IP address for various purposes such as access control or abuse
management. The loss of the host identification will lead to issues
discussed in <xref target="RFC6269"></xref>.<figure align="center"
anchor="cgn" title="CGN Reference Architecture">
<artwork><![CDATA[+-----------+
| HOST_1 |----+
+-----------+ | +--------------------+ +------------+
| | |------| server 1 |
+-----------+ +-----+ | | +------------+
| HOST_2 |--| CGN |----| INTERNET | ::
+-----------+ +-----+ | | +------------+
| | |------| server n |
+-----------+ | +--------------------+ +------------+
| HOST_3 |-----+
+-----------+
]]></artwork>
</figure></t>
<t>Some of the above referenced CGN scenarios will be satisfied by
eventual completion of the transition to IPv6 across the Internet (e.g.,
NAT64), but this is not true of all CGN scenarios (e.g. NPTv6 <xref
target="RFC6296"></xref>) for which some of the issues discussed in
<xref target="RFC6269"></xref> will be encountered (e.g., impact on
geolocation).</t>
<t>Privacy-related considerations discussed in <xref
target="RFC6967"></xref> apply for this scenario.</t>
</section>
<section anchor="aplusp" title="Scenario 2: Address plus Port (A+P)">
<t>A+P <xref target="RFC6346"></xref><xref
target="I-D.ietf-softwire-map"></xref><xref
target="I-D.ietf-softwire-lw4over6"></xref> 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
overlapping port sets. Devices connected to an A+P-enabled network
should be able to restrict the IPv4 source port to be within a
configured range of ports. To forward incoming packets to the
appropriate host, a dedicated entity called PRR (Port-Range Router,
<xref target="RFC6346"></xref>) is needed (<xref
target="ap"></xref>).</t>
<t>Similar to the CGN case, remote servers rely on the source IP address
for various purposes such as access control or abuse management. The
loss of the host identification will lead to the issues discussed in
<xref target="RFC6269"></xref>. In particular, it will be impossible to
identify hosts sharing the same IP address by remote servers.</t>
<t><figure align="center" anchor="ap" title="A+P Reference Architecture">
<artwork><![CDATA[+-----------+
| HOST_1 |----+
+-----------+ | +--------------------+ +------------+
| | |------| server 1 |
+-----------+ +-----+ | | +------------+
| HOST_2 |--| PRR |----| INTERNET | ::
+-----------+ +-----+ | | +------------+
| | |------| server n |
+-----------+ | +--------------------+ +------------+
| HOST_3 |-----+
+-----------+
]]></artwork>
</figure></t>
<t>Privacy-related considerations discussed in <xref
target="RFC6967"></xref> apply for this scenario.</t>
</section>
<section anchor="aproxy"
title="Scenario 3: On-Premise Application Proxy Deployment">
<t>This scenario is similar to the CGN scenario (<xref
target="CGN"></xref>). </t>
<t>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.</t>
<t><xref target="proxy"></xref> illustrates a simple configuration
involving a proxy. Note several (per-application) proxies may be
deployed. This scenario is a typical deployment approach used within
enterprise networks.</t>
<t><figure align="left" anchor="proxy"
title="Proxy Reference Architecture">
<artwork><![CDATA[+-----------+
| HOST_1 |----+
+-----------+ | +--------------------+ +------------+
| | |------| server 1 |
+-----------+ +-----+ | | +------------+
| HOST_2 |--|PROXY|----| INTERNET | ::
+-----------+ +-----+ | | +------------+
| | |------| server n |
+-----------+ | +--------------------+ +------------+
| HOST_3 |-----+
+-----------+
]]></artwork>
</figure></t>
<t>The administrator of the proxy may have many reasons for wanting to
proxy traffic - including caching, policy enforcement, malware scanning,
reporting on network or user behavior for compliance or security
monitoring. </t>
<t>The same administrator may also wish to selectively hide or expose
the internal host identity to servers. He/she may wish to hide the
identity to protect end-user privacy or to reduce the ability of a rogue
agent to learn the internal structure of the network. He/she may wish to
allow upstream servers to identify hosts to enforce access policies (for
example on documents or online databases), to enable account
identification (on subscription-based services) or to prevent spurious
misidentification of high traffic patterns as a DoS attack.
Application-specific protocols exist for enabling such forwarding on
some plain-text protocols (e.g., Forwarded headers on HTTP <xref
target="RFC7239"></xref> or time-stamp-line headers in SMTP <xref
target="RFC5321"></xref>).</t>
<t>Servers not receiving such notifications but wishing to perform host
or user-specific processing are obliged to use other
application-specific means of identification (e.g., Cookies <xref
target="RFC6265"></xref>).</t>
<t>Packets/connections must be received by the proxy regardless of the
IP address family in use. The requirements of this scenario are not
satisfied by eventual completion of the transition to IPv6 across the
Internet. Complications will arise for both IPv4 and IPv6.</t>
<t>Privacy-related considerations discussed in <xref
target="RFC6967"></xref> apply for this scenario.</t>
</section>
<section anchor="dproxy" title="Scenario 4: Distributed Proxy Deployment">
<t>This scenario is similar to the proxy deployment scenario (<xref
target="aproxy"></xref>) with the same use-cases. However, in this
instance part of the functionality of the application proxy is located
in a remote site. This may be desirable to reduce infrastructure and
administration costs or because the hosts in question are mobile or
roaming hosts tied to a particular administrative zone of control but
not to a particular network.</t>
<t>In some cases, a distributed proxy is required to identify a host on
whose behalf it is performing the caching, filtering or other desired
service – for example to know which policies to enforce.
Typically, IP addresses are used as a surrogate. However, in the
presence of CGN, this identification becomes difficult. Alternative
solutions include the use of cookies, which only work for HTTP traffic,
tunnels or proprietary extensions to existing protocols.</t>
<t><figure anchor="disproxy"
title="Distributed Proxy Reference Architecture (1)">
<artwork><![CDATA[ +-----------+ +----------+
| HOST_1 |-------------| |
+-----------+ | | +-------+ +------------+
| | | |-----| server 1 |
+-----------+ | | | | +------------+
| HOST_2 |----+ | INTERNET |---| Proxy | ::
+-----------+ +-----+ | | | | +------------+
|Proxy|----| | | |-----| server n |
+-----------+ +-----+ | | +-------+ +------------+
| HOST_3 |----+ +----------+
+-----------+
]]></artwork>
</figure><figure anchor="disproxy2"
title="Distributed Proxy Reference Architecture (2)">
<artwork><![CDATA[
+-----------+ +---+ +---+ +----------+
| Host 1 +---------+ I | | I +--+ Server 1 |
+-----------+ | n | +---+ | n | +----------+
| t | | P | | t |
+-----------+ +---+ | e | | r | | e | +----------+
| Host 2 +--+ P | | r +--+ o +--+ r +--+ Server 2 |
+-----------+ | r | | n | | x | | n | +----------+
| o |--+ e | | y | | e | ::
+-----------+ | x | | t | +---+ | t | +----------+
| Host 3 +--+ y | | | | +--+ Server N |
+-----------+ +---+ +---+ +---+ +----------+
]]></artwork>
</figure></t>
<t>Packets/connections must be received by the proxy regardless of the
IP address family in use. The requirements of this scenario are not
satisfied by eventual completion of the transition to IPv6 across the
Internet. Complications will arise for both IPv4 and IPv6.</t>
<t>If the proxy and the servers are under the responsibility of the same
administrative entity (<xref target="disproxy"></xref>), no privacy
concerns are raised. Nevertheless, privacy-related considerations
discussed in <xref target="RFC6967"></xref> apply if the proxy and the
servers are not managed by the same administrative entity (<xref
target="disproxy2"></xref>).</t>
</section>
<section anchor="cdn" title="Scenario 5: Overlay Network">
<t>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 <xref
target="overlay_fig"></xref>). 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 packets to the receiver via one or more
machines in the overlay network, applying various performance
enhancement methods.</t>
<t><figure align="center" anchor="overlay_fig"
title="Overlay Network Reference Architecture">
<artwork><![CDATA[
+------------------------------------+
| |
| INTERNET |
| |
+-----------+ | +------------+ |
| HOST_1 |-----| OVRLY_IN_1 |-----------+ |
+-----------+ | +------------+ | |
| | |
+-----------+ | +------------+ +-----------+ | +--------+
| HOST_2 |-----| OVRLY_IN_2 |-----| OVRLY_OUT |-----| SERVER |
+-----------+ | +------------+ +-----------+ | +--------+
| | |
+-----------+ | +------------+ | |
| HOST_3 |-----| OVRLY_IN_3 |-----------+ |
+-----------+ | +------------+ |
| |
+------------------------------------+]]></artwork>
</figure></t>
<t>Such overlay networks are used to improve the performance of content
delivery <xref target="IEEE1344002"></xref>. Overlay networks are also
used for peer-to-peer data transport <xref target="RFC5694"></xref>, and
they have been suggested for use in both improved scalability for the
Internet routing infrastructure <xref target="RFC6179"></xref> and
provisioning of security services (intrusion detection, anti-virus
software, etc.) over the public Internet <xref
target="IEEE101109"></xref>.</t>
<t>In order for an overlay network to intercept packets and/or
connections transparently via base Internet connectivity infrastructure,
the overlay ingress and egress hosts (OVERLAY_IN and OVERLAY_OUT) must
be reliably in-path in both directions between the connection-initiating
HOST and the SERVER. When this is not the case, packets may be routed
around the overlay and sent directly to the receiving host, presumably
without invoking some of the advanced service functions offered by the
overlay.</t>
<t>For public overlay networks, where the ingress and/or egress hosts
are on the public Internet, packet interception commonly uses network
address translation for the source (SNAT) or destination (DNAT)
addresses in such a way that the public IP addresses of the true
endpoint hosts involved in the data transport are invisible to each
other (see <xref target="overlay_ex"></xref>). For example, the actual
sender and receiver may use two completely different pairs of source and
destination addresses to identify the connection on the sending and
receiving networks in cases where both the ingress and egress hosts are
on the public Internet.</t>
<t><figure align="center" anchor="overlay_ex"
title="NAT operations in an Overlay Network">
<artwork><![CDATA[
ip hdr contains: ip hdr contains:
SENDER -> src = sender --> OVERLAY --> src = overlay2 --> RECEIVER
dst = overlay1 dst = receiver
]]></artwork>
</figure></t>
<t>In this scenario, 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.</t>
<t>In some of the above referenced scenarios, IP packets traverse the
overlay network fundamentally unchanged, with the overlay network
functioning much like a CGN (<xref target="CGN"></xref>). In other
cases, connection-oriented data flows (e.g. TCP) are terminated by the
overlay in order to perform object caching and other such transport and
application layer optimizations, similar to the proxy scenario (<xref
target="aproxy"></xref>). In both cases, address sharing is a
requirement for packet/connection interception, which means that the
requirements for this scenario are not satisfied by the eventual
completion of the transition to IPv6 across the Internet.</t>
<t>More details about this scenario are provided in <xref
target="I-D.williams-overlaypath-ip-tcp-rfc"></xref>.</t>
<t>This scenario does not introduce privacy concerns since the
identification of the host is local to a single administrative domain
(i.e., CDN Overlay Network) or passed to a remote server to help
forwarding back the response to the appropriate host. The host
identification information is not publically available nor it can be
disclosed to other hosts connected to the Internet.</t>
</section>
<section anchor="pcc"
title="Scenario 6: Policy and Charging Control Architecture (PCC)">
<t>This issue is related to the Policy and Charging Control (PCC)
framework defined by 3GPP in <xref target="TS23.203"></xref> when a NAT
is located between the PCEF (Policy and Charging Enforcement Function)
and the AF (Application Function) as shown in <xref
target="policy"></xref>.</t>
<t>The main issue is: PCEF, PCRF and AF all receive information bound to
the same UE ( User Equipment) but without being able to correlate
between the piece of data visible for each entity. Concretely,<list
style="symbols">
<t>PCEF is aware of the IMSI (International Mobile Subscriber
Identity) and an internal IP address assigned to the UE.</t>
<t>AF receives an external IP address and port as assigned by the
NAT function.</t>
<t>PCRF is not able to correlate between the external IP
address/port assigned by the NAT (received from the AF) and the
internal IP address and IMSI of the UE (received from the PCEF).</t>
</list><figure align="center" anchor="policy"
title="NAT located between AF and PCEF">
<artwork><![CDATA[ +------+
| PCRF |-----------------+
+------+ |
| |
+----+ +------+ +-----+ +-----+
| UE |------| PCEF |---| NAT |----| AF |
+----+ +------+ +-----+ +-----+
]]></artwork>
</figure></t>
<t>This scenario can be generalized as follows (<xref
target="PEP"></xref>):</t>
<t><list style="symbols">
<t>Policy Enforcement Point (PEP, <xref
target="RFC2753"></xref>)</t>
<t>Policy Decision Point (PDP, <xref target="RFC2753"></xref>)</t>
</list></t>
<t><figure align="center" anchor="PEP"
title="NAT located between PEP and Server">
<artwork><![CDATA[ +------+
| PDP |-----------------+
+------+ |
| |
+----+ +------+ +-----+ +------+
| UE |------| PEP |---| NAT |----|Server|
+----+ +------+ +-----+ +------+
]]></artwork>
</figure></t>
<t>Note that an issue is encountered to enforce per-UE policies when the
NAT is located before the PEP function (see <xref
target="natpep"></xref>):</t>
<t><figure align="center" anchor="natpep" title="NAT located before PEP">
<artwork><![CDATA[ +------+
| PDP |------+
+------+ |
| |
+----+ +------+ +-----+ +------+
| UE |------| NAT |---| PEP |----|Server|
+----+ +------+ +-----+ +------+
]]></artwork>
</figure></t>
<t>This scenario does not introduce privacy concerns since the
identification of the host is local to a single administrative domain
and is meant to help identifying which policy to select for a UE.</t>
</section>
<section anchor="psap" title="Scenario 7: Emergency Calls">
<t>Voice service providers (VSPs) operating under certain jurisdictions
are required to route emergency calls from their subscribers and have to
include information about the caller's location in signaling messages
they send towards PSAPs (Public Safety Answering Points, <xref
target="RFC6443"></xref>), via an Emergency Service Routing Proxy (ESRP,
<xref target="RFC6443"></xref>). This information is used both for the
determination of the correct PSAP and to reveal the caller's location to
the selected PSAP.</t>
<t>In many countries, regulation bodies require that this information be
provided by the network rather than the user equipment, in which case
the VSP needs to retrieve this information (by reference or by value)
from the access network where the caller is attached.</t>
<t>This requires the VSP call server receiving an emergency call request
to identify the relevant access network and to query a Location
Information Server (LIS) in this network using a suitable look-up key.
In the simplest case, the source IP address of the IP packet carrying
the call request is used both for identifying the access network (thanks
to a reverse DNS query) and as a look-up key to query the LIS. Obviously
the user-id as known by the VSP (e.g., telephone number, or
email-formatted URI) can't be used as it is not known by the access
network.</t>
<t>The above mechanism is broken when there is a NAT between the user
and the VSP and/or if the emergency call is established over a VPN
tunnel (e.g., an employee remotely connected to a company VoIP server
through a tunnel wishes to make an emergency call). In such cases, the
source IP address received by the VSP call server will identify the NAT
or the address assigned to the caller equipment by the VSP (i.e., the
address inside the tunnel). This is similar to the CGN case (<xref
target="CGN"></xref>) and overlay network case (<xref
target="cdn"></xref>) and applies irrespective of the IP versions used
on both sides of the NAT and/or inside and outside the tunnel.</t>
<t>Therefore, the VSP needs to receive an additional piece of
information that can be used to both identify the access network where
the caller is attached and query the LIS for his/her location. This
would require the NAT or the Tunnel Endpoint to insert this extra
information in the call requests delivered to the VSP call servers. For
example, this extra information could be a combination of the local IP
address assigned by the access network to the caller's equipment with
some form of identification of this access network.</t>
<t>However, because it shall be possible to setup an emergency call
regardless of the actual call control protocol used between the user and
the VSP (e.g., SIP <xref target="RFC3261"></xref>, IAX <xref
target="RFC5456"></xref>, tunneled over HTTP, or proprietary protocol,
possibly encrypted), this extra information has to be conveyed outside
the call request, in the header of lower layers protocols.</t>
<t>Privacy-related considerations discussed in <xref
target="RFC6967"></xref> apply for this scenario.</t>
</section>
<section title="Other Deployment Scenarios">
<t>This section lists deployment scenarios that are variants of
scenarios described in previous sections.</t>
<section anchor="providerwifi" title="Open WLAN or Provider WLAN">
<t>In the context of Provider WLAN, 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.</t>
<t>Several deployment scenarios are envisaged:<list style="numbers">
<t>Deploy a dedicated node in the service provider's network which
will be responsible to intercept all the traffic issued from
visiting terminals (see <xref target="ueid"></xref>). 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 <xref target="CGN"></xref>, remote servers may not be
able to distinguish visiting hosts sharing the same IP address
(see <xref target="RFC6269"></xref>).</t>
<t>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 IPv4 address pool
managed by the RG. Packets issued form a visiting terminal are
translated using the public IP address assigned to the RG (see
<xref target="ueid2"></xref>). This deployment scenario induces
the following identification concerns:<list style="symbols">
<t>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 identify which
policies are to be enforced such as: accounting, DSCP
remarking, black list, etc.</t>
<t>Similar to the CGN case <xref target="CGN"></xref>, a
misbehaving visiting terminal is likely to have some impact on
the experienced service by the subscriber owning the RG (e.g.,
some of the issues are discussed in <xref
target="RFC6269"></xref>).</t>
</list></t>
</list></t>
<t><figure align="center" anchor="ueid"
title="NAT enforced in a Service Provider's Node">
<artwork><![CDATA[+-------------+
|Local_HOST_1 |----+
+-------------+ |
| |
+-------------+ +-----+ | +-----------+
|Local_HOST_2 |--| RG |-|--|Border Node|
+-------------+ +-----+ | +----NAT----+
| |
+-------------+ | | Service Provider
|Visiting Host|-----+
+-------------+
]]></artwork>
</figure></t>
<t><figure align="center" anchor="ueid2" title="NAT located in the RG">
<artwork><![CDATA[+-------------+
|Local_HOST_1 |----+
+-------------+ |
| |
+-------------+ +-----+ | +-----------+
|Local_HOST_2 |--| RG |-|--|Border Node|
+-------------+ +-NAT-+ | +-----------+
| |
+-------------+ | | Service Provider
|Visiting Host|-----+
+-------------+
]]></artwork>
</figure></t>
<t>This scenario does not introduce privacy concerns since the
identification of the host is local to a single administrative domain
and is meant to help identifying which policy to select for a visiting
UE.</t>
</section>
<section anchor="mobile" title="Cellular Networks">
<t>Cellular operators allocate private IPv4 addresses to mobile
terminals 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 (Public Land Mobile Network).
IPv6-only strategy, consisting in allocating IPv6 prefixes only to
mobile terminals, is considered by various operators. A NAT64 function
is also considered in order to preserve IPv4 service continuity for
these customers.</t>
<t>These NAT44 and NAT64 functions bring some issues very similar to
those mentioned in <xref target="cgn"></xref> and <xref
target="pcc"></xref>. This issue is particularly encountered if
policies are to be applied on the Gi interface. <list style="empty">
<t>Note: 3GPP defines the Gi interface as the reference point
between the GGSN (Gateway GPRS Support Node) and an external PDN
(Packet Domain Network). This interface reference point is called
SGi in 4G networks (i.e., between the PDN Gateway and an external
PDN).</t>
</list></t>
<t>Because private IP addresses are assigned to the mobile terminals,
there is no correlation between the internal IP address and the
external address:port assigned by the NAT function, etc.</t>
<t>Privacy-related considerations discussed in <xref
target="RFC6967"></xref> apply for this scenario.</t>
</section>
<section anchor="FMC" title="Femtocells">
<t>This scenario can be seen as a combination of the scenarios
described in <xref target="providerwifi"></xref> and <xref
target="pcc"></xref>.</t>
<t>The reference architecture is shown in <xref
target="Femtocell"></xref>.</t>
<t>A FAP (Femto Access Point) is defined as a home base station used
to graft a local (femto) cell within a users home to a mobile
network.</t>
<t><figure align="center" anchor="Femtocell"
title="Femtocell Reference Architecture">
<artwork><![CDATA[+---------------------------+
| +----+ +--------+ +----+ | +-----------+ +-------------------+
| | 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
]]></artwork>
</figure></t>
<t>UE is connected to the FAP at the residential gateway (RG), routed
back to 3GPP Evolved Packet Core (EPC). It is assumed that each UE is
assigned an IPv4 address by the Mobile Network. Mobile operator's FAP
leverages the IPsec IKEv2 to interconnect FAP with the SeGW over the
Broadband Fixed Network (BBF). Both the FAP and the SeGW are managed
by the mobile operator which may be a different operator for the BBF
network.</t>
<t>An investigated scenario is the mobile operator to pass on its
mobile subscriber's policies to the BBF to support traffic policy
control . 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:</t>
<t><list style="symbols">
<t>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.</t>
<t>determine the FAP's public 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.</t>
<t>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 special UE's policy (e.g., QoS) to be passed onto the
Broadband Policy Control Function (BPCF) at the BBF network.</t>
</list></t>
<t>SeGW would have the complete knowledge of such mapping, but the
reasons for being unable to use SeGW for this purpose are explained in
Section 2 of <xref target="I-D.so-ipsecme-ikev2-cpext"></xref>.</t>
<t>This scenario involves PCRF/BPCF but it is valid in other
deployment scenarios making use of AAA servers.</t>
<t>The issue of correlating the internal IP address and the public IP
address is valid even if there is no NAT in the path.</t>
<t>This scenario does not introduce privacy concerns since the
identification of the host is local to a single administrative domain
and is meant to help identifying which policy to select for a UE.</t>
</section>
<section anchor="tdf" title="Traffic Detection Function (TDF)">
<t>Operators expect that the traffic subject to the packet inspection
is routed via the Traffic Detection Function (TDF) function as
requirement specified in <xref target="TS29.212"></xref>; otherwise,
the traffic may bypass the TDF. This assumption only holds if it is
possible to identify individual UEs behind NA(P)T invoked in the RG
connected to the fixed broadband network, shown in <xref
target="tdf-pic"></xref>. As a result, additional mechanisms are
needed to enable this requirement.</t>
<t><figure align="center" anchor="tdf-pic"
title="UE's Traffic Routed with TDF">
<artwork><![CDATA[
+--------+
| |
+-------+ PCRF |
| | |
| +--------+
+--------+ +--------+ +--------+ +----+----+
| | | | | +-----+ |
| ------------------------------------------------------------------
| | | | | | | TDF | / \
| ****************************************************************** |
+--------+ +--------+ +--------+ +----+----+ | |
| | | +-------+ | | |Service|
| | | | | | | \ /
| | | | | | | +--------+
| | | | | | +--------+ PDN |
| >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> |
| UE | | RG | | BNG +------------------+ Gateway|
+--------+ +--------+ +--------+ +--------+
Legends:
--------- 3GPP UE User Plane Traffic Offloaded subject to packet
inspection
********* 3GPP UE User Plane Traffic Offloaded not subject to packet
inspection
>>>>>>>>> 3GPP UE User Plane Traffic Home Routed
BNG (Broadband Network Gateway)
]]></artwork>
</figure>This scenario does not introduce privacy concerns since the
identification of the host is local to a single administrative domain
and is meant to help identifying which policy to select for a UE.</t>
</section>
<section anchor="fmc" title="Fixed and Mobile Network Convergence">
<t>In the Policy for Convergence of Fixed Mobile Convergence (FMC)
scenario, the fixed broadband network must partner with the mobile
network to acquire the policies for the terminals or hosts attaching
to the fixed broadband network, shown in <xref
target="fmc-pic"></xref> so that host-specific QoS and accounting
policies can be applied.</t>
<t>A UE is connected to the RG, routed back to the mobile network. The
mobile operator's PCRF needs to maintain the interconnect with the
Broadband Policy Control Function (BPCF) in the BBF network for PCC
(<xref target="pcc"></xref>). The hosts (i.e., UEs) attaching to fixed
broadband network with a NA(P)T deployed should be identified. Based
on the UE identification, the BPCF can acquire the associated policy
rules of the identified UE from the PCRF in the mobile network so that
it can enforce policy rules in the fixed broadband network. Note, this
scenario assumes private IPv4 address are assigned in the fixed
broadband network. Similar requirements are raised in this scenario as
<xref target="FMC"></xref>.</t>
<t><figure align="center" anchor="fmc-pic"
title="Reference Architecture for Policy for Convergence in Fixed and Mobile Network Convergence (1)">
<artwork><![CDATA[ +------------------------------+ +-------------+
| | | |
| +------+ | | +------+ |
| | BPCF +---+---+-+ PCRF | |
| +--+---+ | | +---+--+ |
+-------+ | | | | | |
|HOST_1 |Private IP1 +--+---+ | | +---+--+ |
+-------+ | +----+ | | | | | | |
| | RG | | | | | | | |
| |with+-------------+ BNG +--------+ PGW | |
+-------+ | | NAT| | | | | | | |
|HOST_2 | | +----+ | | | | | | |
+-------+Private IP2 +------+ | | +------+ |
| | | |
| | | |
| Fixed | | Mobile |
| Broadband | | Network |
| Network | | |
| | | |
+------------------------------+ +-------------+
]]></artwork>
</figure></t>
<t>In IPv6 network, the similar issues exists when the IPv6 prefix is
shared between multiple UEs attaching to the RG (see <xref
target="fmc-pic2"></xref>). The case applies when RG is assigned a
single prefix, the home network prefix, e.g. using DHCPv6 Prefix
Delegation <xref target="RFC3633"></xref> with the edge router, BNG
acting as the Delegating Router (DR). RG uses the home network prefix
in the address configuration using stateful (DHCPv6) or stateless
address assignment (SLAAC) techniques.</t>
<t><figure align="center" anchor="fmc-pic2"
title="Reference Architecture for Policy for Convergence in Fixed and Mobile Network Convergence (2)">
<artwork><![CDATA[
+------------------------------+ +-------------+
| | | |
| | | +------+ |
| +-------------+ PCRF | |
| | | | +---+--+ |
+-------+ | | | | | |
|HOST_1 |--+ +--+---+ | | +---+--+ |
+-------+ | +----+ | | | | | | |
| | RG | | | | | | | |
| | +------------+ BNG +---------+ PGW | |
+-------+ | | | | | | | | | |
|HOST_2 |--+ +----+ | | | | | | |
+-------+ | +------+ | | +------+ |
| | | |
| | | |
| Fixed | | Mobile |
| Broadband | | Network |
| Network | | |
| | | |
+------------------------------+ +-------------+
]]></artwork>
</figure></t>
<t>BNG acting as PCEF initiates an IP Connectivity Access Network
(IP-CAN) session with the policy server, a.k.a. Policy and Charging
Rules Function (PCRF), to receive the Quality of Service (QoS)
parameters and Charging rules. BNG provides to the PCRF the IPv6
Prefix assigned to the host, in this case the home network prefix and
an ID which in this case has to be equal to the RG specific home
network line ID.</t>
<t>HOST_1 in <xref target="fmc-pic2"></xref> creates an 128-bit IPv6
address using this prefix and adding its interface id. Having
completed the address configuration, the host can start communication
with a remote host over Internet. However, no specific IP-CAN session
can be assigned to HOST_1, and consequently the QoS and accounting
performed will be based on RG subscription.</t>
<t>Another host, e.g. HOST_2, attaches to RG and also establishes an
IPv6 address using the home network prefix. Edge router, the BNG, is
not involved with this and all other such address assignments.</t>
<t>This leads to the case where no specific IP-CAN session/sub-session
can be assigned to the hosts, HOST_1, HOST_2, etc., and consequently
the QoS and accounting performed can only be based on RG subscription
and not host specific. Therefore IPv6 prefix sharing in Policy for
Convergence scenario leads to similar issues as the address sharing as
explained in the previous scenarios in this document.</t>
</section>
</section>
<section title="Synthesis">
<t>The following table shows whether each scenario is valid for
IPv4/IPv6 and if it is within one single administrative domain or spans
multiple domains. The table also identifies the root cause of the
identification issues.</t>
<t>The IPv6 column indicates for each scenario whether IPv6 is supported
at the client's side and/or server's side.</t>
<t><figure>
<artwork><![CDATA[
+-------------------+----+-------------+------+-----------------+
| | | IPv6 |Single| Root Cause |
| Scenario | |------+------|Domain+-------+---------+
| |IPv4|Client|Server| |Address|Tunneling|
| | | | | |sharing| |
+-------------------+----+------+------+------+-------+---------+
| CGN |Yes |Yes(1)| No | No | Yes | No |
| A+P |Yes | No | No | No | Yes | No |
| Application Proxy |Yes | Yes | Yes | No | Yes | No |
| Distributed Proxy |Yes | Yes | Yes |Yes/No| Yes | No |
| Overlay Networks |Yes |Yes(2)|Yes(2)| No | Yes | No |
| PCC |Yes |Yes(1)| No | Yes | Yes | No |
| Emergency Calls |Yes | Yes | Yes | No | Yes | No |
| Provider WLAN |Yes | No | No | Yes | Yes | No |
| Cellular Networks |Yes |Yes(1)| No | Yes | Yes | No |
| Femtocells |Yes | No | No | No | Yes | Yes |
| TDF |Yes | Yes | No | Yes | Yes | No |
| FMC |Yes |Yes(1)| No | No | Yes | No |
+-------------------+----+------+------+------+-------+---------+
Notes:
(1) e.g., NAT64
(2) This scenario is a combination of CGN and Application Proxies.
Table 1: Synthesis]]></artwork>
</figure></t>
<t></t>
</section>
<section title="Privacy Considerations">
<t>Privacy-related considerations that apply to means to reveal a host
identifier are discussed in <xref target="RFC6967"></xref>. This
document does not introduce additional privacy issues than those
discussed in <xref target="RFC6967"></xref>.</t>
<t>None of the scenarios inventoried in this document aims at revealing
a Customer Identifier, account Identifier, profile Identifier, etc.
Particularly, none of these scenarios is endorsing the functionality
provided by the following proprietary headers (but not limited to) that
are known to be used to leak subscription-related information:
HTTP_MSISDN, HTTP_X_MSISDN, HTTP_X_UP_CALLING_LINE_ID,
HTTP_X_NOKIA_MSISDN, HTTP_X_HTS_CLID, HTTP_X_MSP_CLID, HTTP_X_NX_CLID,
HTTP__RAPMIN, HTTP_X_WAP_MSISDN, HTTP_COOKIE, HTTP_X_UP_LSID,
HTTP_X_H3G_MSISDN, HTTP_X_JINNY_CID, HTTP_X_NETWORK_INFO, etc.</t>
</section>
<section anchor="security" title="Security Considerations">
<t>This document does not define an architecture nor a protocol; as such
it does not raise any security concern. Host identifier related security
considerations are discussed in <xref target="RFC6967"></xref>.</t>
</section>
<section anchor="iana" title="IANA Considerations">
<t>This document does not require any action from IANA.</t>
</section>
<section title="Acknowledgments">
<t>Many thanks to F. Klamm, D. Wing, D. von Hugo, G. Li, D. Liu, and Y.
Lee for their review.</t>
<t>J. Touch, S. Farrel, and S. Moonesamy provided useful comments in the
intarea mailing list.</t>
<t>Figure 8 and part of the text in <xref target="FMC"></xref> are
inspired from <xref target="I-D.so-ipsecme-ikev2-cpext"></xref>.</t>
</section>
</middle>
<back>
<references title="Informative References">
<?rfc include='reference.RFC.6346'?>
<?rfc include='reference.RFC.6269'?>
<?rfc include='reference.RFC.2753'?>
<?rfc include='reference.RFC.6296'?>
<?rfc include='reference.RFC.6146'?>
<?rfc include='reference.RFC.3261'?>
<?rfc include='reference.RFC.3633'?>
<?rfc include='reference.RFC.5456'?>
<?rfc include='reference.RFC.6443'?>
<?rfc include='reference.RFC.6179'?>
<?rfc include='reference.RFC.5694'?>
<?rfc include='reference.RFC.6265'?>
<?rfc include='reference.RFC.6888'?>
<?rfc include='reference.RFC.5321'?>
<?rfc include='reference.RFC.7239'?>
<?rfc include='reference.I-D.ietf-softwire-map'?>
<?rfc include='reference.I-D.ietf-softwire-lw4over6'?>
<?rfc include='reference.RFC.6967'?>
<?rfc include='reference.I-D.so-ipsecme-ikev2-cpext'?>
<?rfc include='reference.I-D.williams-overlaypath-ip-tcp-rfc'?>
<?rfc include='reference.I-D.tsou-stateless-nat44'?>
<?rfc include='reference.RFC.6333'?>
<reference anchor="TS23.203" target="">
<front>
<title>Policy and charging control architecture (Release 11)</title>
<author fullname="3GPP TS23.203" surname="">
<organization>3GPP TS23.203</organization>
</author>
<date day="0" month="September" year="2012" />
</front>
</reference>
<reference anchor="EFFOpenWireless">
<front>
<title>Open Wireless,
https://www.eff.org/issues/open-wireless</title>
<author fullname="EFF" surname="EFF">
<organization></organization>
</author>
<date year="2014" />
</front>
</reference>
<reference anchor="TS29.212">
<front>
<title>Policy and Charging Control (PCC) over Gx/Sd reference point
(Release 11)</title>
<author fullname="3GPP TS29.212" surname="">
<organization>3GPP TS29.212</organization>
</author>
<date month="December" year="2013" />
</front>
</reference>
<reference anchor="IEEE1344002">
<front>
<title abbrev="Informed content delivery">Informed content delivery
across adaptive overlay networks: IEEE/ACM Transactions on
Networking, Vol 12, Issue 5, ppg 767-780</title>
<author fullname="John Byers" initials="J.W." surname="Byers">
<organization abbrev="Boston University">Boston University, Dept.
of Computer Science</organization>
</author>
<author fullname="Jeffrey Considine" initials="J."
surname="Considine">
<organization abbrev="Boston University">Boston University, Dept.
of Computer Science</organization>
</author>
<author fullname="Michael Mitzenmacher" initials="M."
surname="Mitzenmacher">
<organization abbrev="Harvard University">Harvard University,
EECS</organization>
</author>
<author fullname="Stanislav Rost" initials="S." surname="Rost">
<organization abbrev="MIT">MIT Laboratory for Computer
Science</organization>
</author>
<date month="October" year="2004" />
</front>
</reference>
<reference anchor="IEEE101109">
<front>
<title abbrev="Security Overlay Network">Using Cloud Computing to
Implement a Security Overlay Network, IEEE Security & Privacy,
21 June 2012. IEEE Computer Society Digital Library.</title>
<author fullname="Khaled Salah" initials="K." surname="Salah">
<organization abbrev="Khalifa University">Khalifa University of
Science Technology and Research</organization>
</author>
<author fullname="Jose Maria Alcaraz Calero" initials="J.M.A."
surname="Calero">
<organization abbrev="Universidad de Murcia">Universidad de
Murcia</organization>
</author>
<author fullname="Sherali Zeadally" initials="S." surname="Zeadally">
<organization
abbrev="University of the District of Columbia">University of the
District of Columbia</organization>
</author>
<author fullname="Sameera Almulla" initials="S." surname="Almulla">
<organization abbrev="Khalifa University">Khalifa University of
Science Technology and Research</organization>
</author>
<author fullname="Mohammed ZAaabi" initials="M." surname="ZAaabi">
<organization abbrev="Khalifa University">Khalifa University of
Science Technology and Research</organization>
</author>
<date month="June" year="2012" />
</front>
</reference>
</references>
<!--
-->
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 04:15:23 |