Security Edge Protection Proxy (SEPP) Architecture

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

The Security Edge Protection Proxy is a decentralized solution and composed of control plane (N32-C) and forwarding plane (N32-F). This solution is deployed between two NFs belonging to different PLMNs that use the N32 interface to communicate with each other.

Figure 2-1 Security Edge Protection Proxy Architecture

The above architecture diagram shows an overview of SEPP deployment and functionality:

• The SEPP communicates with remote SEPP over N32 interface
• N32-C is used to negotiate security capability between Local SEPP and Remote SEPP
• N32-F is the data plane, which performs encryption/decryption on the messages to/from other PLMN's SEPP based on negotiated capability
• N32-C Client & Server functionalities are designed to run in separate PODs
• Envoy is used as a proxy to facilitate both N32-C & N32-F messaging
  • It works as point of TLS origination as well as TLS termination for all external messages (exchanged with remote SEPP)
• Certificate manager is responsible to store certificates, as well handle certificate lifecycle
• Config manager shall be responsible for handling all configuration related tasks (add/mod/delete)
  • Save configuration data in CRDs/mysql DB
  • Retrieve run time status of SEPP connections etc and provide back to user when requested

For information on installing SEPP, see the OCSEPP Cloud Native Installation Guide.