Search for:

Product Description

SEPP (Security Edge Protection Proxy) is an important part of the 5G roaming security architecture, used for user roaming, communication with other operators, and responsible for message filtering and policy management on the control plane interface between operators It is used as the border gateway between the control plane of the operator’s core network.

As a non-transparent proxy node, SEPP can provide application-layer control plane security and realize secure communication between NF consumers and NF providers across operators.

The SEPPs establish connections and implement protection policies between them through the N32 interface for each control-plane message in cross-network signaling. the N32 interface can be divided into two sub-interfaces, N32-c and N32-f, according to their uses, where N32-c is used to provide the initial handshake process between two SEPPs, including capability negotiation, parameter exchange, etc.; N32-f is used to send security-protected SBI messages.

Product Specification


N32-c part feature:

  • Key Agreement: SEPPs independently export the key information associated with the N32-c connection established between them and use it as a pre-shared key for generating the required shared session key.
  • Parameter Exchange: The SEPP exchanges the security-related configuration parameters required by the SEPP to protect the HTTP messages exchanged between the two Network Functions (NFs) in their respective networks.
  • Error Handling: The receiving SEPP sends an error signaling message to the opposite SEPP when it detects an error on the N32 interface.

N32-f part feature:

  • Parse incoming message: If the message is found to contain an extended FQDN, remove its own FQDN part from the extended FQDN of the receiving NF to obtain the original FQDN.
  • Reconstruct the message: Generate the input for JSON Web Encryption (JWE).
  • Encrypting the message: encrypting the message to generate protected state in a JWE-based manner.
  • Encapsulate JWE objects: Encapsulate the generated JWE objects in HTTP/2 message bodies and send the messages to the SEPP on the other side through the N32-f interface.
  • SEPP shall conduct mutual authentication and negotiation of cipher suites with SEPP in the roaming network.
  • When SEPP handles key management, it should set the encryption key required to protect the message on the N32 interface between the two SEPPs.
  • SEPP should perform topology hiding by restricting internal topology information visible to external parties.
  • As a reverse proxy, SEPP should provide a single point of access and control the internal NF.
  • pSEPP should be able to verify whether cSEPP is authorized to use the operator network ID in the received N32 message.
  • SEPP should be able to clearly distinguish between the certificate used to authenticate the peer SEPP and the certificate used to authenticate the intermediate that performs message modification.
  • SEPP should implement a rate limiting function to protect itself and subsequent NFs from excessive CP signals. This includes SEPP to SEPP signaling messages.
  • SEPP should implement an anti-spoofing mechanism to achieve cross-layer verification of source and destination addresses and identifiers (such as FQDN or operator network ID). If there is a mismatch between the different layers of the message or the destination address does not belong to SEPP’s own operator network, the message is discarded.