1 Overview

The Security Edge Protection Proxy (SEPP) is a non-transparent proxy that sits at the perimeter of the PLMN network and enables secured communication between inter-PLMN network messages. The OCSEPP supports the following functions:

• Implements separate security negotiation interface (N32-c) and an end-to-end application interface (N32-f)
  • N32-C: Uses for context management for security capability negotiation.
  • N32-F: Uses for forwarding of inter-NF signaling across PLMN.
• Secure communication
  • Secure communication of Inter PLMN messages from Consumer NF to Producer NF using TLS protection mode (HTTP over TLS).

  • HTTPS and 3gpp-Sbi-Target-Apiroot header for secure Intra-PLMN communication to Network Functions.

• Rest API based configurations
  • APIs for configuration of roaming partner profiles.
  • APIs retrieval of Handshake status for each roaming partner.
• Resiliency
  • Implements retry mechanism for N32-C handshake failure.
• Observability
  • PLMN based Metrics and KPI.
  • Alarms for failure and threshold events.
  • Logging and tracing capabilities.

Security Edge Protection Proxy (SEPP) Architecture

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

Oracle Communications Security Edge Protection Proxy (OCSEPP) 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

SEPP provides two interfaces, N32-c and N32-f .

• N32-c: A control plane interface between the SEPPs for performing initial handshake and negotiating the parameters to be applied for the actual N32 message forwarding.
• N32-f: A forwarding interface between the SEPPs which is used 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

SEPP Architecture and the Microservices Overview

ocsepp-config-mgr Microservice

This microservice is used for configuration of roaming partner profile 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 handshake failure is also handled by config-mgr.

ocsepp-cn32c Microservice

This microservice is used for context management and initiation of security capability negotiation. It create an n32 context and maintain its state and negotiated security capability based on handshake procedure.

ocsepp-pn32c Microservice

This microservice is used for context management and respond to security capability negotiation. It create an n32 context and maintain its state and negotiated security capability based on handshake procedure.

ocsepp-cn32f Microservice

This microservice receives messages from consumer NF and determine remote SEPP address to forward message over n32f interface to SEPP of producer NF network.

ocsepp-pn32f Microservice

This microservice is receives inter-PLMN messages from remote SEPP of consumer network over TLS connection and forward to Producer NF.

ocsepp-plmn-Ingress-gateway

This is the entry point for comsumer NF to SEPP messages. PLMN Ingress Gateway exposes http and https interfaces towards consumer NF network to receives messages required to be forwarded over inter-PLMN n32f interface.

ocsepp-plmn-egress-gateway

This is the 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.

ocsepp-n32-ingress-gateway

Entry point for N32 Ingress messages. N32 Ingress gateway exposes HTTP over TLS interface on prouder SEPP to receive n32c and n32f inter-PLMN messages.

ocsepp-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.

nrf-client

NRF client (nrfc) is used for NRF registration. NRF client supporting services are not shown.

N32c and N32f Call flows

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

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 i.e. PRINS and/or TLS.
• On successful processing of the request, the responding SEPP shall respond to the initiating SEPP1 with “200 OK” status code and a POST response body with selected security capability i.e. PRINS or TLS.

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

• The SEPP on the NF service consumer side (c-SEPP) and the SEPP on the NF service producer side (p-SEPP) negotiate the security capabilities using the procedure defined in Handshake call flow. The SEPPs mutually negotiate to use 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

• The SEPP on the NF service consumer side (c-SEPP) and the SEPP on the NF service producer side (p-SEPP) negotiate the security capabilities using the procedure defined in 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.

SEPP Microservices

The following are the microservices of SEPP

Name	Description
cN32c	Initiates N32-c handshake to remote PLMNs
pN32c	Responds to N32-c handshake from remote PLMNs
cN32f	Initiates inter PLMN messages to remote PLMNs
pN32f	Responds to inter PLMN messages from remote PLMNs
config	SEPP configuration micro service
PLMN IGW, PLMN EGW	PLMN Ingress and Egress GW micro services
N32 IGW, N32 EGW	N32 Ingress and Egress GW micro services
nrfc,config-server, app-info	NRF Client and supporting services used for SEPP registration

Acronyms

The following table provides information about the acronyms used in the document.

Table 1-1 Acronyms

Fields	Description
CNE	Cloud Native Environment
DNS	Domain Name System
FQDN	Fully Qualified Domain Name
NF	Network Function
OHC	Oracle Help Center
OSDC	Oracle Software Delivery Cloud
PLMN	Public Land Mobile Network
SEPP	Security Edge Protection Proxy
SVC	Services
TLS	Transport Layer Security

References

• Cloud Native Environment (OCCNE) Installation Guide
• Security Edge Protection Proxy (SEPP) Cloud Native Installation Guide