By Yousif Targali (Verizon), Anja Jerichow (Nokia), Andreas Pashalidis (German Federal Office for Information Security)

First published December 2024, in Highlights Issue 09

The 5G-Standalone (5G SA) roaming security, as specified by SA3, marks a substantial enhancement over the roaming mechanisms of previous generations. This is because it aims to address the root cause of a wide range of attacks that have taken and continue to take place over the roaming infrastructure in the past decades: the lack of attribution. More precisely, 5G SA roaming aims to increase the transparency how the signalling infrastructure is interconnected by enabling a form of trace back of each signalling message to its originator, without the need for complex procedures that require the collaboration of players, typically spanning multiple jurisdictions.

This is possible because 5G SA roaming requires that:

(a) Operators and roaming intermediaries be equipped with cryptographic credentials, bound to their unique identity, and that they use these credentials to digitally sign the messages they generate.

(b) Security associations be established end-to-end between the Secure Edge Protection Proxies (SEPPs) of the two roaming partners, i.e. without terminating at roaming intermediaries such as IPX service (hub) or roaming hubs providers.

This article summarises the work done within the SA3 WG since Release 15 to provide end-to-end security for the different 5G Roaming deployment models and to address the gaps that existed in the legacy networks.

5G Roaming security architecture  

The 5G roaming security architecture, as defined by SA3 WG, introduces the SEPP as an architectural element and defines N32 as the interconnect interface, to allow end-to-end secured communication between service-consuming and service-producing NFs in the different PLMNs. The SEPPs are located at the perimeter of each operator network and communicate via the N32 interface. This interface is split into two constituent sub-protocols: N32-c and N32-f. The purpose of N32-c is to verify that the SEPPs of the roaming partners are configured in a compatible manner, and the purpose of N32-f is to exchange the signalling messages.

Initially, the SEPPs authenticate themselves mutually via N32-c and negotiate the security mechanism for N32-f end-to-end protection matching the needs for the deployment scenario. This can be either the Transport Layer Security (TLS) protocol for bilateral/direct roaming solutions between operators or the Protocol for N32 Interconnect application layer Security (PRINS) for mediated roaming solutions.

N32-c is also used for control signalling, such as for error reporting and closing of N32-f. When the PRINS mode is selected for N32-f, N32-c is further used to negotiate protection policies ensuring integrity and confidentiality protection for certain information elements, and modification policies, that define which elements are allowed to be modified by the Roaming Intermediaries between the two operators. The functionality of the SEPP includes message filtering and policing the Inter-PLMN control plane interface as well as topology hiding by limiting the internal topology information visibility to entities external to operator network.

The different roaming models and their security are described below.

Direct roaming model

The direct roaming model refers to a direct bilateral roaming deployment model between two operators PLMN-A and PLMN-B, depicted in Figure 1. The interconnection between PLMN-A and PLMN-B could be direct or through Roaming Intermediaries (RIs) which only offer IP routing service.

TLS with mutual authentication is used in the direct roaming model. N32-c is used to negotiate TLS as the security method for N32-f. The termination points for the N32-f and N32-c are the SEPPs located at the border of each operator network. Assuming a globally trusted PKI for the management of the TLS certificates, this architecture ensures the security of the HTTP/2 roaming signalling messages over the N32-f interface, through mutual authentication, encryption, integrity, and replay-protection.

Mediated roaming model

While some roaming relations are direct bilateral, others are mediated. In the latter case Roaming Intermediaries, i.e. IPX service (hub) providers and/or roaming hub providers are involved in the establishment of the relation and the routing of the signalling traffic with an interest in having access to the HTTP/2 roaming signalling messages to offer more than just IP routing.

Figure 2 illustrates the mediated roaming model. The maximum of two Roaming Intermediaries (RI), each of them in a contractual relationship with one SEPP’s PLMN, is allowed if the RI is not only for IP routing.

The logical security associations of the constituents of the N32 interface in this hubbing context are as follows: N32-c/TLS, which terminates at the SEPPs is used, among other things, to exchange keying material for PRINS, and N32-f/PRINS, which is used to exchange the actual signalling while enabling intermediaries (RIs) to offer services.

In more detail, N32-c is used to negotiate PRINS as the security method for N32-f, and to exchange the information necessary to proceed with exchanging N32-f signalling securely. In mediated roaming, a cascade of TLS connections is setup between SEPPs and RIs providing transport layer security of the links between each hop, as shown in the figure, and PRINS is used as the application layer security protocol over this cascade allowing the RI to read those HTTP/2 message elements that are unencrypted per operator policy and selectively modify if allowed.

Support for additional features

The support of additional features for Roaming Hubs by SEPPs was introduced in Release 18 and back ported to Releases 16 and 17. Applicability from Release 16 onwards is recommended and technically possible.

These features enable Roaming Hubs to originate error messages to either PLMN SEPPs or adjacent Roaming Hubs, in an identifiable/traceable way, and Roaming Intermediaries to determine the intention of using PRINS as the security method for the N32-f protocol.

The mechanism used by the SEPP for setting up N32-c over TLS via a chain of Roaming Intermediaries makes use of the HTTP CONNECT method and contains sufficient information such that the target PLMN and the Roaming Intermediaries can determine the identities of the initiating PLMN and the target PLMN. .

In addition, Release 18 defines that a Roaming Hubs can generate application layer control plane messages to trigger a Network Function to reject registration attempts and/or deregister the UE.

In this case, such messages are transparent to the SEPP and the SEPP acts on them as any other message on the N32-f interface not making use of Roaming Intermediaries. How the SEPP authorises such messages is left to implementation.

Support for RVAS

In its simplest form, a Roaming Value Added Service (RVAS) merely needs to observe certain fields in order to generate statistics or reports. Such an RVAS can be implemented in a straight-forward manner since all that is required is to ensure that suitable PRINS protection policies are used at the SEPPs (e.g. by avoiding to encrypt the required data). Other RVAS require an on-the-fly modification of the values in certain fields in the signalling. Such RVAS are supported since PRINS enables intermediaries to modify signalling messages in a traceable manner; again, a suitable protection policy at the SEPPs is required.

More complex RVAS require intermediaries to generate signalling triggered by their own application logic. Such support has been included since R18. It should be noted that PRINS is not the only way in which an RVAS may be implemented in 5G: instead of being placed on the route between the two roaming partners, an RVAS provider may choose to integrate its service directly in the 5G core or to connect it via the Network Exposure Function. Several RVAS services are specified in TS.22.261.

Outlook

Despite the flexibility and options provided by the 5G roaming protocols, it must be said that the end-to-end security approach introduced in 5G represents a fundamental change in how roaming security is approached. The roaming ecosystem, with its diverse set of players and stakeholders, still needs to fully embrace this approach at the time of writing.

While the migration of some existing RVAS into the 5GSA roaming framework is straight-forward, other RVAS are likely to require substantial development and perhaps further standardisation. 3GPP SA3 firmly believes that these efforts are a valuable investment for the industry as a whole.

3GPP SA3 and CT4 specifications on 5GSA roaming (TS 33.501 and TS 29.573) have evolved significantly over the last two years. One of the driving forces behind this is the collaboration between 3GPP and GSMA. While the information exchanged via Liaison Statements has been valuable and has led to the identification and closure of a series of gaps, direct participation in 3GPP by players that so far are active only in GSMA would be desirable, for example to avoid market fragmentation that may occur if GSMA and 3GPP specifications are not fully aligned. The effort required to make 5G SA roaming a reality is a collective and an orchestrated one.

For more on WG SA3:  www.3gpp.org/3gpp-groups