The SEPP as described in clause 4.2.1 is the entity that sits at the perimeter of the network and performs application layer security on the HTTP message before it is sent externally over the roaming interface. The application layer traffic comprises all the IEs in the HTTP message payload, sensitive information in HTTP message header and Request URI. Not all the IEs get the same security treatment in SEPP. Some IEs require e2e encryption, some only require e2e integrity protection, while other IEs may require e2e integrity protection but modifiable by intermediate IPX provider while in-transit.

In the above Figure, an example is shown where the AMF NF in the visited PLM network (vPLMN) invokes an API request on the AUSF NF in the home PLM network (hPLMN) using the following message flow:

• The AMF NF first sends the HTTP Request message to its local SEPP (i.e. vSEPP).
• The vSEPP applies application layer security (PRINS) and sends the secure message on the N32 interface to AUSF NF of the hPLMN.
• The hSEPP at the edge of the hPLMN, receives all incoming HTTP messages from its roaming partners. It verifies the message, removes the protection mechanism applied at the application layer, and forwards the resulting HTTP message to the corresponding AUSF NF.

To allow for the trusted roaming intermediary IPX nodes to see and possibly modify specific IEs in the HTTP message, while completely 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 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 roaming 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.

Following is a typical structure of the HTTP Message:

It consists of:

• HTTP Message payload with JSON based IEs
• HTTP Headers with or without sensitive elements
• HTTP Request-URI with or without sensitive elements such as SUPI.

In the outgoing direction, i.e. towards the N32 interface, the SEPP shall parse the HTTP message fully and apply protection on each part as required. In the incoming direction, i.e. towards the Network Function, the SEPP shall verify the message, and if successful reassemble the original message and send it to the destined Network Function.