To protect messages that are sent over the N32 interface, the 5G system architecture implements Security Edge Protection Proxy (SEPP) at the perimeter of the Public Land Mobile Network (PLMN) network. SEPP receives all service layer messages from the Network Function (NF) and protects them before sending them out of the network on the N32 interface. Additionally, it receives all messages on the N32 interface and after verifying security where present, it forwards them to the appropriate network function. The SEPP implements application layer security for all the layer information exchanged between two NFs across two different PLMNs. Figure above illustrates the SEPP’s role

ROLE OF THE SEPP IN THE SECURITY ARCHITECTURE

The application layer traffic comprises all the IEs in the HyperText Transfer Protocol (HTTP) message
payload, sensitive information in HTTP message header and Request URI. Not all IEs get the same security treatment in SEPP. Some IEs require end-to-end (e2e) encryption, while others require only E2E integrity protection. Still, others may require E2E integrity protection but modifiable by an intermediate Internetwork Packet Exchange (IPX) provider while in-transit.

To enable the trusted intermediary IPX nodes to see and modify specific IEs in the HTTP message, while simultaneously protecting all sensitive information end-to-end between SEPPs. The SEPP implements application layer security in such a way that:

• Sensitive information such as authentication vectors are fully E2E, and confidentiality protected between two SEPPs. This ensures that no node in the IPX network shall be able to view such information while in-transit
• IEs that are subject to modification by intermediary IPX nodes are integrity protected and can only be modified in a verifiable way by authorized IPX nodes
• Receiving SEPP can detect modification by unauthorized IPX nodes

The SEPP shall support the following requirements:

• Act as a non-transparent proxy node
• Protect application layer control plane messages between two NFs belonging to different PLMNs that use the N32 interface to communicate with each other
• Perform mutual authentication and negotiation of cipher suites with the SEPP in the roaming network
• Handle key management aspects that involve setting up the required cryptographic keys needed for securing messages on the N32 interface between two SEPPs
• Perform topology hiding by limiting the internal topology information visible to external parties
• Provide a single point of access and control to internal NFs as a reverse proxy
• Verify whether the sending SEPP is authorized to use the PLMN ID in the received N32 message as the receiving SEPP
• Clearly differentiate between certificates used for authentication of peer SEPPs and certificates used for authentication of intermediates performing message modifications
• Discard malformed N32 signaling messages
• Implement rate-limiting functionalities to defend itself and subsequent NFs against excessive CP signaling; this includes SEPP-to-SEPP signaling messages
• Implement anti-spoofing mechanisms that enable cross-layer validation of source and destination
• address and identifiers (for example, FQDNs or PLMN IDs)