RFC 7620

Scenarios with Host Identification Complications

📅 published August 2015, from ietf

Part 1 of 6 💖

RFC 7620: Scenarios with Host Identification Complications 🎀

Okay bestie, let's get into it. This one is RFC 7620, titled Scenarios with Host Identification Complications. It was published in August 2015, and it's an Independent Submission in the Informational category, so it's just here to share info and isn't an Internet Standard. 🧚 The ISSN is 2070-1721.

The authors are M. Boucadair (Ed.) from Orange, B. Chatras (also Orange), T. Reddy from Cisco Systems, B. Williams from Akamai, Inc., and B. Sarikaya from Huawei. The title block doesn't list any RFCs that it obsoletes or updates, so it's standing on its own. 🌸

Abstract

okay so this doc describes a bunch of scenarios where it gets messy to figure out which policy should apply to a host. 👀 The problem gets nicknamed "host identification." Writing all the scenarios down helps everyone spot what they have in common, which is super useful when it's time to design solutions. ✨

Also, this doc does NOT talk about any specific solution. It's purely about the problems. 💅

IESG Note

this one's giving important vibes 🫶 The IESG basically says that these use cases show IP addresses being overloaded with both location and identity jobs. That kind of semantic overloading contributes to a bunch of problems in the routing system, and the reference for that is [RFC4984].

They also point out that these use cases could be used to justify solutions that don't line up with IETF Best Current Practices on protecting privacy, which are [BCP160] and [BCP188]. So, handle with care, babe 🔥

Status of This Memo

This document isn't an Internet Standards Track specification. It's published just for information. 🌈

It's a contribution to the RFC Series, separate from any other RFC stream. The RFC Editor picked to publish it at their discretion, and they aren't making any claims about whether it's worth implementing or deploying. Docs approved by the RFC Editor aren't candidates for any level of Internet Standard, see Section 2 of RFC 5741. 💅

You can find info about this document's current status, any errata, and how to send feedback at http://www.rfc-editor.org/info/rfc7620. ✨

The copyright line reads Copyright (c) 2015 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, which you can find at http://trustee.ietf.org/license-info as they stood on the publication date. Please read those carefully, because they explain your rights and restrictions for this document. 🎀

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Scenario 1: Carrier-Grade NAT (CGN) . . . . . . . . . . . . .   4
   4.  Scenario 2: Address plus Port (A+P) . . . . . . . . . . . . .   5
   5.  Scenario 3: On-Premise Application Proxy Deployment . . . . .   6
   6.  Scenario 4: Distributed Proxy Deployment  . . . . . . . . . .   7
   7.  Scenario 5: Overlay Network . . . . . . . . . . . . . . . . .   8
   8.  Scenario 6: Policy and Charging Control Architecture (PCC)  .  10
   9.  Scenario 7: Emergency Calls . . . . . . . . . . . . . . . . .  12
   10. Other Deployment Scenarios  . . . . . . . . . . . . . . . . .  13
     10.1.  Open WLAN or Provider WLAN . . . . . . . . . . . . . . .  13
     10.2.  Cellular Networks  . . . . . . . . . . . . . . . . . . .  14
     10.3.  Femtocells . . . . . . . . . . . . . . . . . . . . . . .  14
     10.4.  Traffic Detection Function (TDF) . . . . . . . . . . . .  17
     10.5.  Fixed and Mobile Network Convergence . . . . . . . . . .  18
   11. Synthesis . . . . . . . . . . . . . . . . . . . . . . . . . .  21
   12. Privacy Considerations  . . . . . . . . . . . . . . . . . . .  21
   13. Security Considerations . . . . . . . . . . . . . . . . . . .  22
   14. Informative References  . . . . . . . . . . . . . . . . . . .  22
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  25
   Contributors  . . . . . . . . . . . . . . . . . . . . . . . . . .  25
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  26

1. Introduction ✨

The goal here is to list scenarios where you run into the problem of uniquely identifying a host when a bunch of hosts share the same IP address. In this doc, a host can be any device connected directly to a network run by a network provider, a Home Gateway, or a roaming device sitting behind a Home Gateway. 🏠

There's already an exhaustive list of issues for the Carrier-Grade NAT (CGN), Address plus Port (A+P), and application proxy scenarios in [RFC6269]. But some of the scenarios in this doc have extra problems on top of those, like:

  • Figuring out which policy to enforce for a host (for example, limiting access to a service based on counters, like volume-based service offerings). Enforcing the policy affects every host sharing the same IP address. 😭
  • Needing to correlate the internal address:port with the external address:port in order to generate and enforce policies.
  • Querying a location server for the location of an emergency caller based on the source IP address. 🚨

The goal is to identify the scenarios the authors know about that share these same complications when figuring out which policy to apply to a host. That whole problem gets abstracted as the host identification problem. 🦋

The analysis of the scenarios in this doc points to a few root causes for the host identification issue:

  1. Presence of address sharing (CGN, A+P, application proxies, etc.).
  2. Use of tunnels between two administrative domains.
  3. Combination of address sharing and presence of tunnels in the path.

Even though these scenarios share the same root causes, describing each one lets you see what's common between them. That info then helps during the solution design phase. 💜

2. Scope 🌸

This doc can be used as a tool for designing solutions that fix the issues it describes. Note that [RFC6967] only focuses on the CGN, A+P, and application proxy cases. The analysis in [RFC6967] may not be accurate for some scenarios that don't span multiple administrative domains (for example, Section 10.1). 👀

This doc doesn't target means that would expose a host beyond what the original packet, sent from that host, would already have exposed. Those means aren't desirable, and they aren't needed to solve the issues in these scenarios. The focus is only on means that restore the information carried in the original packet a host sent. These means are meant to help identify which policy applies to a given flow, and they may rely on some bits of the source IP address and/or the port number(s) the host used to send packets. ✨

To prevent side effects and misuse of those means where privacy is concerned, a solution specification document should explain the following, on top of what's already covered in [RFC6967]:

  • To what extent the solution could be used to cancel out the effect of address sharing used to preserve privacy (see, for example, [EFFOpenWireless]). Note that this concern can be eased if the address-sharing platform is under the responsibility of the host's owner, and the host doesn't leak information that would get in the way of the host's privacy protection tool. 🫶
  • To what extent the solution could be used to expose privacy information beyond what the original packet would already have exposed. Note that the solutions discussed in [RFC6967] don't let any extra information be revealed beyond what's in the original packet. 🔐

This doc covers both IPv4 and IPv6. 🌈

This doc doesn't include any solution-specific discussions. In particular, it doesn't go into whether explicit authentication is enabled. 💅

It also doesn't discuss whether specific information needs to be leaked in packets, or whether that's done out of band, and so on. Those things are out of scope. 🙈

3. Scenario 1: Carrier-Grade NAT (CGN) 🍓

Several flavors of stateful CGN have been defined. Here's a non-exhaustive list:

  1. IPv4-to-IPv4 NAT (NAT44) [RFC6888] [STATELESS-NAT44]
  2. DS-Lite NAT44 [RFC6333]
  3. Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers (NAT64) [RFC6146]
  4. IPv6-to-IPv6 Network Prefix Translation (NPTv6) [RFC6296]

As [RFC6967] explains, remote servers can't tell apart hosts that share the same IP address (see Figure 1). Quick reminder: remote servers rely on the source IP address for things like access control or abuse management. Losing host identification leads to the issues discussed in [RFC6269]. 😭

+-----------+
|  HOST_1   |----+
+-----------+    |        +--------------------+      +------------+
                 |        |                    |------|  Server 1  |
+-----------+  +-----+    |                    |      +------------+
|  HOST_2   |--| CGN |----|      INTERNET      |            ::
+-----------+  +-----+    |                    |      +------------+
                  |       |                    |------|  Server n  |
+-----------+     |       +--------------------+      +------------+
|  HOST_3   |-----+
+-----------+

                Figure 1: CGN Reference Architecture

Some of the CGN scenarios above will be solved once the transition to IPv6 across the Internet is eventually complete (for example, NAT64). But that's not true for every CGN scenario (for example, NPTv6 [RFC6296]), so some of the issues in [RFC6269] will still show up there (for example, an impact on geolocation). 🌍

The privacy considerations in [RFC6967] apply to this scenario too. 🔐

Part 1 is wrapped up, and there's more of this to come 💖 Stay tuned!

  1. Scenario 2: Address plus Port (A+P) 🎀

Okay so A+P (see [RFC6346] [RFC7596] [RFC7597]) is a flavor of address-sharing that does NOT need any extra NAT function turned on in the service provider's network. Lowkey genius 🧚 Here's the vibe: subscribers get the same IPv4 address plus a port set, and everyone sharing that IPv4 address SHOULD get port sets that don't overlap. Devices on an A+P network SHOULD be able to restrict their IPv4 source port to a configured range of ports. 💅

To get incoming packets to the right host, you need a dedicated entity called the Port-Range Router (PRR) [RFC6346]. It's literally the bouncer making sure every packet ends up at the right door 🚪✨ (see Figure 2).

Just like the CGN case, remote servers rely on the source IP address for stuff like access control or abuse management 👀. Losing host identification leads to the issues discussed in [RFC6269], and it's giving chaos: remote servers won't be able to tell apart hosts sharing the same IP address. 💀

   +-----------+
   |  HOST_1   |----+
   +-----------+    |        +--------------------+      +------------+
                    |        |                    |------|  Server 1  |
   +-----------+  +-----+    |                    |      +------------+
   |  HOST_2   |--| PRR |----|      INTERNET      |            ::
   +-----------+  +-----+    |                    |      +------------+
                     |       |                    |------|  Server n  |
   +-----------+     |       +--------------------+      +------------+
   |  HOST_3   |-----+
   +-----------+

                   Figure 2: A+P Reference Architecture

Privacy-related considerations discussed in [RFC6967] apply for this scenario 🫶.

  1. Scenario 3: On-Premise Application Proxy Deployment 🌸

This scenario is giving CGN vibes (see Section 3) 💖.

Remote servers can't tell apart the hosts sitting behind the proxy 😭. So any policy applied to the external IP address the proxy shows will hit EVERY host connected to that proxy. Not me… 🙈

Figure 3 shows a simple setup with a proxy. Heads up that several (per-application) proxies may be deployed 🍓. This is a super typical approach in enterprise networks, iykyk 👑.

   +-----------+
   |  HOST_1   |----+
   +-----------+    |        +--------------------+      +------------+
                    |        |                    |------|  Server 1  |
   +-----------+  +-----+    |                    |      +------------+
   |  HOST_2   |--|Proxy|----|      INTERNET      |            ::
   +-----------+  +-----+    |                    |      +------------+
                     |       |                    |------|  Server n  |
   +-----------+     |       +--------------------+      +------------+
   |  HOST_3   |-----+
   +-----------+

                  Figure 3: Proxy Reference Architecture

The proxy admin can have lots of reasons to proxy traffic 🦋: caching, policy enforcement, malware scanning, reporting on network or user behavior for compliance, or security monitoring. Iconic energy 👑.

That same admin may also want to selectively hide or expose the internal host identity to servers. He/she may want to hide it to protect end-user privacy or to make it harder for a rogue agent to learn the internal structure of the network 🕵️‍♀️. They may also want upstream servers to identify hosts so they can enforce access policies (for example, on documents or online databases), enable account identification (on subscription-based services), or avoid spurious misidentification of high-traffic patterns as a DoS attack 🧚. Some application-specific protocols already do this forwarding on plaintext protocols, like Forwarded headers on HTTP [RFC7239] or time-stamp-line headers in SMTP [RFC5321] ✨.

Servers that don't get those notifications but still want host- or user-specific processing have to use other application-specific ways of identifying, like cookies [RFC6265] 🍪.

Packets/connections MUST be received by the proxy regardless of the IP address family in use. Eventual completion of the transition to IPv6 across the Internet will NOT satisfy the requirements of this scenario, and complications will show up for both IPv4 and IPv6 😬.

Privacy-related considerations discussed in [RFC6967] apply for this scenario 🫶.

  1. Scenario 4: Distributed Proxy Deployment 🧚

This scenario is similar to the proxy deployment scenario (Section 5) with the same use cases 💜. The difference is that part of the application proxy's functionality lives at a remote site. That can be desirable to cut infrastructure and admin costs, or because the hosts are mobile or roaming hosts tied to a particular administrative zone of control but not to a particular network 🌈.

Sometimes a distributed proxy needs to identify the host it's acting for (caching, filtering, or another service), for example to know which policies to enforce 🎯. Usually IP addresses are used as a surrogate. But with CGN in the picture, that identification gets really hard 😩. Alternatives include cookies (which only work for HTTP traffic), tunnels, or proprietary extensions to existing protocols 🔥.

      +-----------+             +----------+
      |  HOST_1   |-------------|          |
      +-----------+             |          |   +-------+    +----------+
                                |          |   |       |----| Server 1 |
      +-----------+             |          |   |       |    +----------+
      |  HOST_2   |----+        | INTERNET |---| Proxy |         ::
      +-----------+  +-----+    |          |   |       |    +----------+
                     |Proxy|----|          |   |       |----| Server n |
      +-----------+  +-----+    |          |   +-------+    +----------+
      |  HOST_3   |----+        +----------+
      +-----------+

          Figure 4: Distributed Proxy Reference Architecture (1)

       +-----------+         +---+         +---+  +----------+
       |  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 |
       +-----------+  +---+  +---+         +---+  +----------+

          Figure 5: Distributed Proxy Reference Architecture (2)

Packets/connections MUST be received by the proxy regardless of the IP address family in use. Eventual completion of the transition to IPv6 across the Internet will NOT satisfy the requirements of this scenario, and complications will show up for both IPv4 and IPv6 😬.

If the proxy and the servers are run by the same administrative entity (Figure 4), no privacy concerns are raised 🙌. But if the proxy and the servers are NOT managed by the same administrative entity (Figure 5), the privacy-related considerations discussed in [RFC6967] DO apply 🔒.

7. Scenario 5: Overlay Network ✨

Okay so an overlay network is a bunch of machines spread across multiple autonomous systems on the public Internet, and their whole job is to make data transport faster 🚀 (see Figure 6). Packets from the sender get delivered first to one of the overlay machines. That machine then relays them to the receiver through one or more other overlay machines, 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 6: Overlay Network Reference Architecture

Overlay networks are used to boost content delivery [IEEE1344002] 🎀. They're also used for peer-to-peer data transport [RFC5694], and people have suggested them for improved scalability of the Internet routing infrastructure [RFC6179] and for provisioning security services (intrusion detection, anti-virus software, etc.) over the public Internet [IEEE101109] 🧚

Here's the lowkey tricky part 👀. 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 that isn't the case, packets may be routed around the overlay and sent directly to the receiving host, presumably without the advanced service functions the overlay offers 😭

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. The result is that the public IP addresses of the true endpoint hosts are invisible to each other 🙈 (see Figure 7). For example, when both the ingress and egress hosts are on the public Internet, the actual sender and receiver can 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 7: NAT Operations in an Overlay Network

In this scenario, the remote server can't tell apart the hosts using the overlay for transport 👀. It also can't figure out which overlay ingress point the host is using, which would otherwise be super handy for diagnosing host connectivity issues 🔍

In some of these scenarios, IP packets go through the overlay network totally unchanged, and the overlay basically acts like a CGN (Section 3) 💁. In other cases, the overlay terminates connection-oriented data flows (e.g., TCP) so it can do object caching and other transport and application-layer optimizations, which is similar to the proxy scenario (Section 5) 🧁. In both cases, address sharing is a requirement for packet/connection interception. That means the requirements for this scenario aren't satisfied by the eventual completion of the transition to IPv6 across the Internet 😤

More details about this scenario are provided in [OVERLAYPATH] 📚

This scenario doesn't introduce privacy concerns 🫶. The host's identification is local to a single administrative domain (i.e., Content Delivery Network (CDN) Overlay Network) or it's passed to a remote server so the response can be forwarded back to the right host. The host identification information isn't publicly available and can't be disclosed to other hosts connected to the Internet 🔒

8. Scenario 6: Policy and Charging Control Architecture (PCC) 🎀

This issue is related to the PCC framework defined by 3GPP in [TS23.203] when a NAT is located between the Policy and Charging Enforcement Function (PCEF) and the Application Function (AF), as shown in Figure 8 💖

The main issue is that PCEF, the Policy and Charging Rule Function (PCRF), and AF all receive information bound to the same User Equipment (UE), but none of them can correlate the piece of data visible to each entity 😵‍💫 Concretely:

  • PCEF is aware of the International Mobile Subscriber Identity (IMSI) and an internal IP address assigned to the UE.
  • AF receives an external IP address and port as assigned by the NAT function.
  • 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).
           +------+
           | PCRF |-----------------+
           +------+                 |
              |                     |
+----+      +------+   +-----+    +-----+
| UE |------| PCEF |---| NAT |----|  AF |
+----+      +------+   +-----+    +-----+

Figure 8: NAT Located between AF and PCEF

This scenario can be generalized like this (Figure 9) 🧠:

  • Policy Enforcement Point (PEP) [RFC2753]
  • Policy Decision Point (PDP) [RFC2753]
           +------+
           | PDP  |-----------------+
           +------+                 |
              |                     |
+----+      +------+   +-----+    +------+
| UE |------| PEP  |---| NAT |----|Server|
+----+      +------+   +-----+    +------+

Figure 9: NAT Located between PEP and the Server

Note that there's an issue when it comes to enforcing per-UE policies if the NAT is located before the PEP function (see Figure 10) ⚠️:

                      +------+
                      | PDP  |------+
                      +------+      |
                         |          |
+----+      +------+   +-----+    +------+
| UE |------| NAT  |---| PEP |----|Server|
+----+      +------+   +-----+    +------+

Figure 10: NAT Located before PEP

This scenario doesn't introduce privacy concerns either 💅. The host's identification is local to a single administrative domain, and it's only there to help identify which policy to select for a UE ✨

9. Scenario 7: Emergency Calls 🚨

Voice Service Providers (VSPs) operating under certain jurisdictions are required to route emergency calls from their subscribers. They have to include information about the caller's location in signaling messages they send towards Public Safety Answering Points (PSAPs) [RFC6443] via an Emergency Service Routing Proxy (ESRP) [RFC6443]. This information is used both to determine the correct PSAP and to reveal the caller's location to the selected PSAP 📍

In many countries, regulation bodies require this information to be provided by the network rather than the user equipment. In that case, the VSP needs to retrieve it (by reference or by value) from the access network where the caller is attached 🛰️

This means the VSP call server that receives an emergency call request has to identify the relevant access network and query a Location Information Server (LIS) in that network using a suitable lookup 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 lookup 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, since the access network doesn't know it 🙃

The above mechanism breaks when there's a NAT between the user and the VSP and/or when the emergency call is established over a VPN tunnel. For example, an employee who's remotely connected to a company Voice over IP (VoIP) server through a tunnel and wants to make an emergency call 😬. In those cases, the source IP address received by the VSP call server identifies either the NAT or the address the VSP assigned to the caller equipment (i.e., the address inside the tunnel). This is similar to the CGN case in (Section 3) and the overlay network case (Section 7), and it applies regardless of the IP versions used on both sides of the NAT and/or inside and outside the tunnel 💀

So the VSP needs to receive an additional piece of information that can be used both to identify the access network where the caller is attached and to query the LIS for their 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 the access network assigned to the caller's equipment with some form of identification of that access network 🧩

However, it has to be possible to set up an emergency call regardless of the actual call control protocol used between the user and the VSP. That includes SIP [RFC3261], Inter-Asterisk eXchange (IAX) [RFC5456], protocols tunneled over HTTP, or a proprietary protocol (possibly encrypted). So this extra information has to be conveyed outside the call request, in the header of lower-layer protocols 🫠

Privacy-related considerations discussed in [RFC6967] apply to this scenario 🔐

10. Other Deployment Scenarios 🌈

This section lists deployment scenarios that are variants of the scenarios described in previous sections 🦋

10.1. Open WLAN or Provider WLAN 📶

okay so in the Provider WLAN world, the Residential Gateway (RG) can configure and advertise a dedicated Service Set Identifier (SSID) just for visiting terminals 🧚. Those visitors can be mobile terminals, PCs, etc. 💅

Several deployment scenarios are envisaged:

  1. Deploy a dedicated node in the service provider's network that intercepts all the traffic coming from visiting terminals (see Figure 11) 🔥. This node may be co-located with a CGN function if private IPv4 addresses are assigned to visiting terminals. Just like the CGN case in Section 3, remote servers may not be able to tell apart visiting hosts that share the same IP address (see [RFC6269]) 🙈.
  2. This one is different from the previous scenario. The IPv4 addresses are managed by the RG, and no extra NAT is needed in the service provider's network to handle traffic from visiting terminals ✨. Concretely, a visiting terminal gets a private IPv4 address from the IPv4 address pool the RG manages. Packets from a visiting terminal are translated using the public IP address assigned to the RG (see Figure 12). This scenario brings up these identification concerns 💀:
    • The provider can't tell the visitor's traffic apart from the traffic of the subscriber who owns the RG. That matters because the provider needs to know which policies to enforce, like accounting, Differentiated Services Code Point (DSCP) remarking, black lists, etc. 🎀
    • Just like the CGN case in Section 3, a misbehaving visiting terminal can easily affect the service the subscriber who owns the RG experiences (some of these issues are discussed in [RFC6269]) 😭.
   +-------------+
   |Local_HOST_1 |----+
   +-------------+    |
                      |     |
   +-------------+  +-----+ |  +-----------+
   |Local_HOST_2 |--| RG  |-|--|Border Node|
   +-------------+  +-----+ |  +----NAT----+
                       |    |
   +-------------+     |    |  Service Provider
   |Visiting Host|-----+
   +-------------+

           Figure 11: NAT Enforced in a Service Provider's Node
   +-------------+
   |Local_HOST_1 |----+
   +-------------+    |
                      |     |
   +-------------+  +-----+ |  +-----------+
   |Local_HOST_2 |--| RG  |-|--|Border Node|
   +-------------+  +-NAT-+ |  +-----------+
                       |    |
   +-------------+     |    |  Service Provider
   |Visiting Host|-----+
   +-------------+

                     Figure 12: NAT Located in the RG

This scenario is privacy-safe 🦋 because the identification of the host stays local to a single administrative domain, and it's only there to help pick the right policy for a visiting UE.

10.2. Cellular Networks 📱

Cellular operators give mobile terminals private IPv4 addresses and deploy a NAT44 function, usually co-located with firewalls, to reach public IP services 🌸. The NAT function sits at the boundaries of the Public Land Mobile Network (PLMN). Some operators are also looking at an IPv6-only strategy, where mobile terminals only get IPv6 prefixes 🌈. To keep IPv4 service continuity for these customers, a NAT64 function is also being considered 💜.

These NAT44 and NAT64 functions bring issues that are very similar to the ones in Figure 1 and Section 8 🥺. These issues show up especially when policies need to be applied on the Gi interface.

Note: 3GPP defines the Gi interface as the reference point between the Gateway GPRS Support Node (GGSN) and an external Packet Domain Network (PDN). This interface reference point is called SGi in 4G networks (i.e., between the PDN Gateway and an external PDN).

Since the mobile terminals get private IP addresses, there's no correlation between the internal IP address and the external address:port the NAT function assigns, etc. 🙃

Privacy-related considerations discussed in [RFC6967] apply to this scenario 🔒.

10.3. Femtocells 🏠

This scenario can be seen as a mix of the scenarios described in Sections 8 and 10.1 🍓.

The reference architecture is shown in Figure 13.

A Femto Access Point (FAP) is a home base station that grafts a local (femto) cell inside a user's home onto a mobile network 🏡.

   +---------------------------+
   | +----+ +--------+  +----+ |   +-----------+  +-------------------+
   | | UE | | Stand- |<=|====|=|===|===========|==|=>+--+ +--+        |
   | +----+ | Alone  |  | RG | |   |           |  |  |  | |  | Mobile |
   |        |  FAP   |  +----+ |   |           |  |  |S | |F | Network|
   |        +--------+  (NAPT) |   | Broadband |  |  |e | |A |        |
   +---------------------------+   |   Fixed   |  |  |G |-|P | +-----+|
                                   |   (BBF)   |  |  |W | |G |-| Core||
   +---------------------------+   |  Network  |  |  |  | |W | | Ntwk||
   | +----+ +------------+     |   |           |  |  |  | |  | +-----+|
   | | UE | | Integrated |<====|===|===========|==|=>+--+ +--+        |
   | +----+ | FAP (NAPT) |     |   +-----------+  +-------------------+
   |        +------------+     |
   +---------------------------+

       <=====>   IPsec Tunnel
       CoreNtwk  Core Network
       FAPGW     FAP Gateway
       NAPT      Network Address Port Translator
       SeGW      Security Gateway

                Figure 13: Femtocell Reference Architecture

The UE is connected to the FAP at the RG, and that traffic is routed back to the 3GPP Evolved Packet Core (EPC) 🛰️. Each UE is assumed to get an IPv4 address from the mobile network. A mobile operator's FAP uses the IPsec Internet Key Exchange Protocol Version 2 (IKEv2) to interconnect with the SeGW over the Broadband Fixed (BBF) network 🔐. Both the FAP and the SeGW are managed by the mobile operator, which may be a different operator from the one running the BBF network.

One scenario being investigated is when the mobile operator passes its mobile subscriber's policies on to the BBF so it can support traffic policy control 🎯. The catch is that most of today's broadband fixed networks rely on a private IPv4 addressing plan (+NAPT) for their attached devices, including the mobile operator's FAP 🫠. In this scenario, the mobile network needs to:

  • determine the FAP's public IPv4 address, to find out where the FAP is located and confirm it's legit to operate on the licensed spectrum for a given mobile operator before the FAP is ready to serve its mobile devices 📍.
  • determine the FAP's public IPv4 address together with the translated port number of the UDP header of the encapsulated IPsec tunnel, so it can identify the UE's traffic on the fixed broadband network 🧩.
  • determine the FAP's public IPv4 address associated with the UE's inner IPv4 address (the one the mobile network assigned), so it can identify the mobile UE. That lets the PCRF fetch the UE's special policy (e.g., QoS) and pass it on to the Broadband Policy Control Function (BPCF) in the BBF network 💅.

The SeGW would have the complete knowledge of this mapping, but the reasons it can't be used for this purpose are explained in Section 2 of [IKEv2-CP-EXT] 🤓.

This scenario involves PCRF/BPCF, but it's valid in other deployment scenarios that use Authentication, Authorization, and Accounting (AAA) servers too ✨.

The issue of correlating the internal IP address with the public IP address is still valid even if there's no NAT in the path 👀.

This scenario is privacy-safe 🦋 because the identification of the host stays local to a single administrative domain, and it's only there to help pick the right policy for a UE.

10.4. Traffic Detection Function (TDF) 🕵️‍♀️

Operators expect the traffic subject to packet inspection to be routed via the Traffic Detection Function (TDF), as the requirement in [TS29.212] specifies. Otherwise, the traffic may bypass the TDF 🚧. This assumption only holds if it's possible to identify individual UEs behind the Basic NAT or NAPT invoked in the RG connected to the fixed broadband network, as shown in Figure 14. So additional mechanisms are needed to make this requirement work 🫶.

                                                              +--------+
                                                              |        |
                                                      +-------+  PCRF  |
                                                      |       |        |
                                                      |       +--------+
 +--------+      +--------+       +--------+     +----+----+
 |        |      |        |       |        +-----+         |
 |  ------------------------------------------------------------------
 |        |      |        |       |        |     |  TDF    |    /      \
 |  ****************************************************************** |
 +--------+      +--------+       +--------+     +----+----+   |       |
 |        |      |        +-------+        |         |         |Service|
 |        |      |        |       |        |         |          \      /
 |        |      |        |       |        |         |        +--------+
 |        |      |        |       |        |         +--------+  PDN   |
 |  >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> |
 |  UE    |      |   RG   |       | BNG    +------------------+ Gateway|
 +--------+      +--------+       +--------+                  +--------+

 Legend:
 ---------   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

                  Figure 14: UE's Traffic Routed with TDF

This scenario is privacy-safe 🦋 for the same reason as the others: the identification of the host stays local to a single administrative domain, and it's only meant to help pick which policy to select for a UE 💖.

10.5. Fixed and Mobile Network Convergence ✨

okay so this is the Policy for Convergence of Fixed Mobile Convergence (FMC) scenario 💖 the fixed broadband network has to team up with the mobile network to get the policies for any terminals or hosts plugged into the fixed side (see Figure 15). that way host-specific QoS and accounting policies can actually be applied 🎀

a UE is connected to the RG, and its traffic gets routed back to the mobile network 🦋 the mobile operator's PCRF needs to stay connected with the BPCF in the BBF network for PCC (Section 8) 🫶 the hosts (aka the UEs) attaching to a fixed broadband network with a Basic NAT or NAPT deployed should be identified. once the UE is identified, the BPCF can grab the matching policy rules for that UE from the PCRF in the mobile network and enforce them on the fixed side 👑 heads up, this scenario assumes private IPv4 addresses are assigned in the fixed broadband network 🙈 and requirements similar to the ones in Section 10.3 come up here too 💅

             +------------------------------+   +-------------+
             |                              |   |             |
             |                   +------+   |   | +------+    |
             |                   | BPCF +---+---+-+ PCRF |    |
             |                   +--+---+   |   | +---+--+    |
  +-------+  |                      |       |   |     |       |
  |HOST_1 | Private IP1          +--+---+   |   | +---+--+    |
  +-------+  | +----+            |      |   |   | |      |    |
             | | RG |            |      |   |   | |      |    |
             | |with+-------------+ BNG  +--------+ PGW  |    |
  +-------+  | | NAT|            |      |   |   | |      |    |
  |HOST_2 |  | +----+            |      |   |   | |      |    |
  +-------+ Private IP2          +------+   |   | +------+    |
             |                              |   |             |
             |                              |   |             |
             |                       Fixed  |   | Mobile      |
             |                   Broadband  |   | Network     |
             |                     Network  |   |             |
             |                              |   |             |
             +------------------------------+   +-------------+

   Figure 15: Reference Architecture for Policy for Convergence in Fixed
                 and Mobile Network Convergence (1)

now the IPv6 version, where the same kind of mess shows up when the IPv6 prefix gets shared between multiple UEs behind the RG (see Figure 16) 🌸 this case happens when the RG gets a single prefix, the home network prefix, for example through DHCPv6 Prefix Delegation [RFC3633] with the edge router, and the BNG acts as the Delegating Router (DR). the RG then uses the home network prefix for its address configuration, either with stateful (DHCPv6) or stateless address autoconfiguration (SLAAC) 🧚

             +------------------------------+   +-------------+
             |                              |   |             |
             |                              |   | +------+    |
             |                      +-------------+ PCRF |    |
             |                      |       |   | +---+--+    |
  +-------+  |                      |       |   |     |       |
  |HOST_1 |--+                   +--+---+   |   | +---+--+    |
  +-------+  | +----+            |      |   |   | |      |    |
             | | RG |            |      |   |   | |      |    |
             | |    +------------+ BNG  +---------+ PGW  |    |
  +-------+  | |    |            |      |   |   | |      |    |
  |HOST_2 |--+ +----+            |      |   |   | |      |    |
  +-------+  |                   +------+   |   | +------+    |
             |                              |   |             |
             |                              |   |             |
             |                       Fixed  |   | Mobile      |
             |                   Broadband  |   | Network     |
             |                     Network  |   |             |
             |                              |   |             |
             +------------------------------+   +-------------+

   Figure 16: Reference Architecture for Policy for Convergence in Fixed
                 and Mobile Network Convergence (2)

so the BNG is acting as the PCEF and kicks off an IP Connectivity Access Network (IP-CAN) session with the policy server, a.k.a. the Policy and Charging Rules Function (PCRF) 💜 it wants the Quality of Service (QoS) parameters and charging rules. the BNG gives the PCRF the IPv6 prefix assigned to the host, which in this case is the home network prefix, plus an ID that has to match the RG-specific home network line ID ✨

HOST_1 in Figure 16 builds its 128-bit IPv6 address from this prefix by adding its interface ID 🦋 once that address config is done, the host can start talking to a remote host over the Internet. the catch? no specific IP-CAN session can be assigned to HOST_1, so the QoS and accounting end up based on the RG subscription 🙈

then HOST_2 shows up, attaches to the RG, and also gets an IPv6 address from the home network prefix 💅 the edge router (aka the BNG) isn't involved in this one or any of the other address assignments 💀

which means no specific IP-CAN session or sub-session can be assigned to HOST_1, HOST_2, or any of the other hosts. so the QoS and accounting can only be based on the RG subscription and aren't host specific 😭 this is literally the address sharing problem from the earlier scenarios in this document, just with prefixes 🫠

11. Synthesis 📊

the table below shows whether each scenario is valid for IPv4/IPv6 and whether it lives inside one single administrative domain or spans multiple domains 💖 it also calls out the root cause of the identification issues 🎀

the IPv6 column shows, for each scenario, whether IPv6 is supported on the client's side and/or the server's side ✨

+-------------------+----+-------------+------+-----------------+
|                   |    |    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) For example, NAT64
    (2) This scenario is a combination of CGN and application proxies

                      Table 1: Synthesis

12. Privacy Considerations 🔒

privacy stuff about ways to reveal a host identifier is covered in [RFC6967] 🫶 this document doesn't bring in any privacy issues beyond the ones discussed in [RFC6967] 💜

none of the scenarios inventoried in this document are trying to reveal a customer identifier, account identifier, profile identifier, etc. 🌈

and to be super clear, none of these scenarios endorse the functionality of the proprietary headers below (the list isn't exhaustive). they're known for leaking subscription-related info, so yeah, big no 🙅‍♀️

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.

13. Security Considerations 🛡️

okay, serious moment 🥺 this document doesn't define an architecture or a protocol, so it doesn't raise any security concerns. security considerations related to the host identifier are discussed in [RFC6967] 🔐

14. Informative References 📚✨

Okay bestie, this is the reading list 🎀 Every reference the doc leans on is here, with the full details, so you can go find the originals. Some are BCPs (best current practice), some are RFCs, some are still drafts, and a couple are 3GPP specs.

Acknowledgments 💜

Huge thank-yous to F. Klamm, D. Wing, D. von Hugo, G. Li, D. Liu, and Y. Lee for reviewing this 🫶

J. Touch, S. Farrel, and S. Moonesamy also dropped useful comments on the intarea mailing list, which is giving collaboration energy 🌸

Figure 8 and part of the text in Section 10.3 were inspired by [IKEv2-CP-EXT]. Iconic 🦋

Contributors 🎀

Many thanks to these people for contributing text and comments to the document:

  • David Binet
  • Sophie Durel
  • Li Xue
  • Richard Stewart Wheeldon

Authors' Addresses 🧚

Mohamed Boucadair (editor)
Orange
Rennes  35000
France

Email: mohamed.boucadair@orange.com


Bruno Chatras
Orange
Paris
France

Email: bruno.chatras@orange.com


Tirumaleswar Reddy
Cisco Systems
Cessna Business Park, Varthur Hobli
Sarjapur Marathalli Outer Ring Road
Bangalore, Karnataka  560103
India

Email: tireddy@cisco.com


Brandon Williams
Akamai, Inc.
Cambridge  MA
United States

Email: brandon.williams@akamai.com


Behcet Sarikaya
Huawei
5340 Legacy Dr. Building 3,
Plano, TX  75024
United States

Email: sarikaya@ieee.org
📦 where this page comes from