Pages

▼

Tuesday, June 9, 2020

5G Roaming with SEPP (Security Edge Protection Proxy)

SEPP (Security Edge Protection Proxy) is part of the roaming security architecture as shown in the figure above. Ericsson's article, "An overview of the 3GPP 5G security standard" describes the use of SEPP as follows:

The use of SBA has also pushed for protection at higher protocol layers (i.e. transport and application), in addition to protection of the communication between core network entities at the internet protocol (IP) layer (typically by IPsec). Therefore, the 5G core network functions support state-of-the-art security protocols like TLS 1.2 and 1.3 to protect the communication at the transport layer and the OAuth 2.0 framework at the application layer to ensure that only authorized network functions are granted access to a service offered by another function.

 The improvement provided by 3GPP SA3 to the interconnect security (i.e. security between different operator networks) consists of three building blocks:

  • Firstly, a new network function called security edge protection proxy (SEPP) was introduced in the 5G architecture (as shown in figure 2). All signaling traffic across operator networks is expected to transit through these security proxies
  • Secondly, authentication between SEPPs is required. This enables effective filtering of traffic coming from the interconnect
  • Thirdly, a new application layer security solution on the N32 interface between the SEPPs was designed to provide protection of sensitive data attributes while still allowing mediation services throughout the interconnect

The main components of SBA security are authentication and transport protection between network functions using TLS, authorization framework using OAuth2, and improved interconnect security using a new security protocol designed by 3GPP.

NG.113 5G Roaming Guidelines v2.0 clarifies:

4.2 Inter PLMN (N32) Interface

 The Inter-PLMN specification 3GPP TS 29.573 has been produced by 3GPP to specify the protocol definitions and message flows, and also the APIs for the procedures on the PLMN (Public Land Mobile Network) interconnection interface (i.e. N32)

 As stated in 3GPP TS 29.573 the N32 interface is used between the SEPPs of a VPLMN and a HPLMN in roaming scenarios. Furthermore, 3GPP has specified N32 to be considered as two separate interfaces: N32-c and N32-f.

 N32-c is the Control Plane interface between the SEPPs for performing the initial handshake and negotiating the parameters to be applied for the actual N32 message forwarding. See section 4.2.2 of 3GPP TS 29.573.

 Once the initial HTTP/2 handshake is completed the N32-c connection is torn down. This connection is End-to-End between SEPPs and does not involve IPX to intercept the HTTP/2 connection; although the IPX may be involved for IP level routing.

 N32-f is the Forwarding interface between the SEPPs, that is used for forwarding the communication between the Network Function (NF) service consumer and the NF service producer after applying the application level security protection. See section 4.2.3 of 3GPP TS 29.573.

 N32-f can provide Application Level Security (ALS) as specified in 3GPP TS 33.501 between SEPPs, if negotiated using N32-c. ALS provides the following protection functionalities: -

  • Message protection of the information exchanged between NF service consumer and producer
  • Forwarding of the application layer protected message from a SEPP in one PLMN to another PLMN by way of using IPX providers on the path. The IPX providers on the path may involve the insertion of content modification instructions which the receiving SEPP applies after verifying the integrity of such modification instructions.

The HTTP/2 connection used on N32-f is long lived; and when a SEPP establishes a connection towards another PLMN via IPX, the HTTP/2 connection from a SEPP terminates at the next hop IPX.

 N32-f makes use of the HTTP/2 connection management requirements specified in 3GPP TS 29.500. Confidentiality protection shall apply to all IE’s for the JOSE protected message forwarding procedure, such that hop-by-hop security between SEPP and the IPXs should be established using an IPSec or TLS VPN.

 If an IPX is not in the path between SEPPs, then an IPSec of Transport Layer Security, TLS VPN will be established directly.

 Note: N32-f shall use “http” connections generated by a SEPP, and not “https”

 The SEPP will act as a non-transparent Proxy for the NF’s when service based interfaces are used across PLMNs, however inside IPX service providers, an HTTP proxy may also be used to modify information elements (IE’s) inside the HTTP/2 request and response messages.

 Acting in a similar manner to the IPX Diameter Proxy used in EPC roaming, the HTTP/2 Proxy can be used for inspection of messages, and modification of parameters. 


The picture in the tweet above shows how SEPP will play a role in Local Break Out (LBO) roaming as well as Home Routed (HR) roaming.

Related Posts:
at

No comments:

Post a Comment