For more details, please see ourCookie Policy.

Service Providers

Use Cases for Encryption in the Evolved Packet Core (EPC)

by pmoyer ‎03-20-2015 08:42 AM - edited ‎03-20-2015 08:52 AM (5,505 Views)

In my last blog I wrote about some of the challenges and requirements for Data Privacy in Mobile Provider networks. In this blog I will discuss in more detail the associated use cases for encryption services in the Mobile EPC.


While I talked about the roaming subscriber, and specifically the direct inter-PLMN use case that may require encryption services on the S8 external interface, a more interesting mobility roaming scenario is when a GPRS Roaming Exchange (GRX) is involved. The GRX network connects many Mobile Network Operators (MNO) together and provides a hub inter-connection service for the aggregation of roaming subscribers. In this use case, the roaming subscribers’ data traffic does not traverse a dedicated inter-PLMN link as in the use case from the previous blog. Another example of an exchange service between MNOs is the IP Exchange (IPX); which is a multi-service, enhanced IP exchange service that provides inter-domain connectivity for not only the MNOs but also for Fixed Network Operators. [It is an interesting side note that the IPX provides a similar service for connecting mobile networks together as the Internet Exchange Point (IXP) does for connecting ISPs together.] The widespread use of these roaming exchanges raises yet another question: How does the security posture change when the roaming exchanges are in the middle, as compared to the direct inter-PLMN connections?




When comparing this IPX-based interconnection to the simpler direct inter-PLMN use case, the addition of the IPX cloud in the middle poses some interesting security questions. The Stream Control Transmission Protocol (SCTP) [IETF RFC 4960] based Diameter Base Protocol [IETF RFC 6733] for control plane traffic and the GPRS Tunneling Protocol for user data plane traffic must both be secured through the external IPX network. In the Diameter traffic scenario depicted above, each MNO network aggregates its traffic into a Diameter Edge Agent (DEA) to support scalability, resilience and maintainability. The DEA is the only point of contact for traffic entering and exiting the operator’s network. If the assumption is that the external interface from the DEA to the IPX is not trusted, then security policies and enforcement mechanisms should be applied here.


To add an additional layer of complexity, there are four types of Diameter agents:


  1. Relay Agent
  2. Proxy Agent
  3. Redirect Agent
  4. Translation Agent

Two of these agents are particularly interesting: the Diameter Relay agent and the Diameter Proxy agent. The Diameter Relay agent does not inspect the actual contents of the message stream, it merely routes the messages based on a routing table lookup. However, the Diameter Proxy agent can inspect the actual contents of the message to perform additional services, such as admission control, policy control and other special handling. So, in the relay scenario it would be possible to encrypt the payload of the message from MNO to MNO since the relay agent is merely routing the traffic based on an external header lookup. However, in the proxy scenario it may not be possible to provide the same MNO to MNO encryption since the proxy agent may need to examine the message payload for additional handling. These are tough topics that must be addressed from a security perspective.


So, what does the IP network domain security specification [3GPP Technical Specification 33.102] actually require for encryption services? The 3GPP security architecture specifically calls out IPsec [IETF RFC 4301] for providing IP level security in the EPS. IPsec provides a wide set of security services; such as, data integrity, data origin authentication, anti-replay protection, and confidentiality. The NDS specifically requires IPsec with Encapsulating Security Payload (ESP) in tunnel mode, where the entire original IP packet is encapsulated with a new packet header added. The Internet Key Exchange (IKE) v2 protocol [IETF RFC 5996] is required to set up the security associations between the nodes in the EPS.


In addition to the inter-domain communications that may require IPsec encryption services, the internal mobile backhaul links also require integrity and confidentiality protection. The NDS specifies that all traffic in the mobile network requires security services; including control / management and user data plane traffic. There is one exception to this rule; that is, when the network interfaces for user data plane traffic are within the same domain and are trusted (e.g. physically protected), then IPsec is not mandatory. However, ‘not mandatory’ should not be mistaken for ‘not beneficial’. Encryption is always beneficial; the question is one of “What are the trade-offs for providing encryption services in the mobile EPC network when they are not outright required”?


One particular EPC interface, the SGi, would benefit from the encryption services that IPsec provides. This is the external interface that connects the mobile EPC to the Internet and other external domains and this interface should not be considered a trusted interface.




Well, I hope part two of this blog series provides additional information on the requirements for security services in the mobile EPC network; specifically around the inter-domain roaming use cases. Stay tuned for the next blog of this series which will focus on the Brocade technologies that deliver carrier class encryption at the industry’s highest performance.