2 Security Edge Protection Proxy (SEPP) Architecture

This section explains the Security Edge Protection Proxy (SEPP) Architecture.

Security Edge Protection Proxy (SEPP) is a proxy network function (NF) which is used for secured communication between inter-Public Land Mobile Network (PLMN) messages.

Security Edge Protection Proxy Interfaces

This section explains the Security Edge Protection Proxy (SEPP) interfaces.

Figure 2-1 Security Edge Protection Proxy Interfaces

Security Edge Protection Proxy Interfaces
SEPP provides two interfaces, N32c and N32f:
  • N32c: A control plane interface between the SEPPs for performing initial handshake and negotiating the parameters to be applied for the actual N32 message forwarding.
  • N32f: A forwarding interface between the SEPPs for forwarding the communication between the NF service consumer and the NF service producer after applying application level security protection.

Security Edge Protection Proxy Architecture

Figure 2-2 Security Edge Protection Proxy Architecture

Security Edge Protection Proxy Architecture

SEPP Architecture and Microservices Overview

This section explains the Security Edge Protection Proxy (SEPP) microservices:

Table 2-1 Microservices

Microservice Description
config-mgr-svc This microservice is an interface between CNC Console GUI and SEPP database which takes user configurations of Remote SEPP, Remote SEPP Set, and SEPP features and saves them in SEPP database. The microservice shares SEPP peer details to Gateway for creating routes. This microservice is used for configuring Remote SEPPs and retrieving handshake status. It also initiates a notification towards cN32c service to initiate handshake as soon as profile is enabled and notification to delete N32 context as soon as profile is disabled. Audit to re-initiate handshake notification in case of change in local profile is also handled by config-mgr.
cn32c-svc This microservice performs context management and initiation of security capability negotiation. It creates an n32 context and maintains its state and negotiated security capability based on handshake procedure.
pn32c-svc This microservice is used for context management and responds to security capability negotiation. It creates an n32 context and maintains its state and negotiated security capability based on handshake procedure.
cn32f-svc

This microservice receives messages from consumer NF and determines Remote SEPP address to forward the message over n32f interface to SEPP of producer NF network. Many SEPP features are implemented on this microservice.

Example: Security Countermeasure, Topology hiding for header and body, Mediation etc.
pn32f-svc

This microservice receives inter-PLAN messages on N32 Interface from the Remote SEPP of consumer network over TLS connection and forwards to Producer NF.

Example: Security Countermeasure, Topology hiding for header and body, Mediation etc.
plmn-ingress-gateway Entry point for consumer NF to SEPP messages. PLMN Ingress Gateway exposes HTTP and HTTPs interfaces towards consumer NF network to receive messages required to be forwarded over inter-PLMN n32f interface.
plmn-egress-gateway Exit point for SEPP to producer NF messages. PLMN Egress gateway exposes HTTP and HTTPs interface towards producer NF network to forward inter-PLMN messages received over inter-PLMN n32f interface.
n32-ingress-gateway Entry point for N32 Ingress messages. N32 Ingress gateway exposes HTTP over TLS interface on producer SEPP to receive n32c and n32f inter-PLMN messages.
n32-egress-gateway Exit point for N32 Egress messages. N32 Egress gateway exposes HTTP over TLS interface on consumer SEPP to forward n32c and n32f inter-PLMN messages.
alternate-route-service Exposes the Rest API to call DNS SRV requests to core-dns kubernetes service. Responsible for handling the static and dynamic retrieval of DNS records for defined virtual FQDN.
nrf-client-nfdiscovery or nrf-client-nfmanagement NRF client application is responsible for performing NfRegistration, NfSubscription and NfDiscovery. The NRF Client interacts with the Appinfo and PerfInfo to check the status of the registered services as well as monitor the performance of the services.
ocpm-config (Performance Monitor Service)

It is responsible for monitoring and analyzing the services to probe performance data and provide analysis output, including load and capacity. NRF-Client periodically gets the performance data from this service using the exposed REST APIs.

It is responsible for monitoring and analysis of the services to probe performance data, and provide analysis output including load, capacity. NRF-Client gets the performance data periodically from this service using the exposed REST APIs.
appinfo (Application Info Service) It is responsible for checking the status of the NF's registered services (Deregistration or Running or Not_Running) and periodically monitoring the status. NRF-Client gets the service status of the services periodically from the AppInfo using its REST API.
Mediation Service
  • Mediation service allows to perform HTTP/2 signaling API message mediation between NFs. It resolves interoperability issues for 5GC inter-NF communication when there are vendor-specific implementations in NFs. It provides configuration framework to configure the mediation policy rules to be applied on the HTTP signaling messages. It allows dynamic configuration on mediation policies which will be applied on both request and response.
  • In SEPP mediation service allows MNOs to resolve the inter-op issues between PLMNs by manipulating the inter PLMN messages. The MNO shall rely on mediation service capabilities to provision the mediation rules.
  • This is a common microservice provided by SCP.
Coherence Service
  • Coherence Service is responsible for storing UE Authentication status and UDR Profile data.
  • PN32F gets the UE Authentication status from UDR, and UDR Profile data from NRF Client using UDR Discovery request.
  • This service is used for stateful security countermeasure.

2.1 N32c and N32f Call flows

The following are the N32c and N32f call flows of SEPP:

N32c Call flow

Following diagram illustrates the N32c Call flow:

Figure 2-3 N32c Call flow

N32c Call flow
  • The initiating SEPP issues a HTTP POST request towards the responding SEPP with the request body containing the "SecNegotiateReqData" with supporting security capabilities that is, PRotocol for N32 INterconnect Security (PRINS) and/or Transport Layer Security (TLS).
  • On successful processing of the request, the responding SEPP responds to the initiating SEPP1 with “200 OK” status code and a POST response body with selected security capability i.e. PRotocol for N32 INterconnect Security (PRINS) and/or Transport Layer Security(TLS).

N32f Call flow: HTTP scheme is used by NF to communicate to SEPP

Following diagram illustrates the HTTP scheme is used by NF to communicate to SEPP in N32f Call flow:

Figure 2-4 N32f Call flow: HTTP scheme is used by NF to communicate to SEPP

N32f Call flow: HTTP scheme is used by NF to communicate to SEPP
  • The SEPP on the NF service consumer (c-SEPP) and the SEPP on the NF service producer (p-SEPP) negotiate the security capabilities using the procedure defined in Handshake call flow. The SEPPs mutually negotiate to use Transport Layer Security (TLS) as the security policy.
  • The NF service consumer is configured to route all HTTP messages with inter-PLMN FQDN as the "authority" part of the URI via the c-SEPP. The c-SEPP acts as a HTTP proxy.
  • The c-SEPP forwards the HTTP service request within the N32-f TLS tunnel established.
  • The p-SEPP forwards the HTTP service request to the NF service producer.
  • The NF service producer sends the HTTP service response.
  • The p-SEPP forwards the HTTP service response within TLS tunnel to the c-SEPP.
  • The c-SEPP forwards the HTTP service response to the NF service consumer.

N32f Call flow: HTTPS with 3gpp-Sbi-Target-apiRoot header is used by NF to communicate with SEPP

Following diagram illustrates the HTTPS with 3gpp-Sbi-Target-apiRoot header is used by NF to communicate with SEPP in N32f Call flow:

Figure 2-5 N32f Call flow: HTTPS with 3gpp-Sbi-Target-apiRoot header is used by NF to communicate with SEPP

N32f Call flow: HTTPS with 3gpp-Sbi-Target-apiRoot header is used by NF to communicate with SEPP
  • The SEPP on the NF service consumer (c-SEPP) and the SEPP on the NF service producer (p-SEPP) negotiate the security capabilities using the procedure defined in the handshake call flow. The SEPPs mutually negotiate to use TLS as the security policy.
  • NF service consumer is configured with c-SEPP FQDN and sets up a TLS connection with c-SEPP.
  • The NF service consumer sends the HTTP service request within the TLS connection to the c-SEPP, including a 3pp-Sbi-Target-apiRoot header set to the apiRoot of the p-NF.
  • The c-SEPP forwards the HTTP service request within the N32-f TLS tunnel established.
  • The p-SEPP extracts the HTTP message received on the TLS connection, and then seeing that the URI scheme of the NF service producer is "https" in 3gpp-sbi-target-apiRoot header, the p-SEPP sets up a TLS connection with the NF service producer.
  • The p-SEPP forwards the HTTP service request to the NF service producer.
  • The NF service producer sends the HTTP service response.
  • The p-SEPP forwards the HTTP service response within TLS tunnel to the c-SEPP.
  • The c-SEPP upon receiving the HTTP response message within the TLS tunnel, forwards the response to the NF service consumer.