The security mechanisms for service based interfaces are specified in clause 13 of TS 33.501.
Security Protection Edge Proxy (SEPP), as specified in TS 33.501, shall be used between service based interfaces across PLMNs. The NFs in a PLMN shall use the SEPP as a HTTP/2 proxy for the HTTP/2 messages that carry ":authority" pseudo header with a uri-host formatted as specified in clause 188.8.131.52.
As specified in clause 13.1 of TS 33.501, TLS shall be used for the security protection of messages at the transport layer for the service based interfaces if network security is not provided by other means.
As specified in clause 13.4.1 of TS 33.501 OAuth 2.0 (see IETF RFC 6749 ) may be used for authorization of NF service access. All NFs and the NRF shall support the OAuth 2.0 authorization framework with "Client Credentials" grant type as specified in clause 4.4 of IETF RFC 6749  , except that there is no "Authorization" HTTP request header in the access token request.
The NRF shall act as the Authorization Server providing "Bearer" access tokens (IETF RFC 6750 ) to the NF service consumers to access the services provided by the NF service providers.
If an NF service (i.e API) receives an OAuth 2.0 access token in the "Authorization" HTTP request header field, the NF service shall validate the access token, its expiry and its access scope before allowing access to the requested resource, as specified in clause 7 of IETF RFC 6749 .
The access scope required to get access to a given resource may be, based on local configuration of the NF service producer, either:
the service name of the NF Service; this scope grants generic access to a given API, for those operations on resources that don't require a specific authorization, or
both, the service name of the NF Service, and a string that uniquely represents the type of operation (e.g. create/modify/read), the resource and the service; those two scopes, together, grant access to those operations on resources that require a specific authorization.
An NF service consumer shall support OAuth 2.0.
For request/response semantics service operations and for the subscribe and unsubscribe operations of subscribe/notify semantics service operations, an NF service consumer may use OAuth 2.0 for the authorization of the API access, based on local configuration. The NF service consumer discovers the additional scopes (resource/operation-level scopes) that might be required to invoke a certain service operation, based on the authorization information registered in NRF by the NF service producer in its NF profile.
When Oauth2 authorization is used, the NF service consumer shall use the token received from NRF as a "Bearer" token and include it in the Authorization header of the HTTP service requests, as described in IETF RFC 6750  clause 2.1.
An NF service producer shall decide to accept or reject an API request without the OAuth2.0 access token in the "Authorization" HTTP request header field, based on local configuration.
If an NF service producer rejects an API request without the OAuth2.0 access token or an API request with an invalid OAuth2.0 access token, it shall return the HTTP "401 Unauthorized" status code together with the "WWW-Authenticate" header as specified in IETF RFC 7235 , where:
the scheme for challenge in the "WWW-Authenticate" header shall be set to "Bearer" (IETF RFC 6750 ),
the "realm" attribute shall be set to the URI of the service (i.e API URI) for which the access failed, in the case of request / response service operations,
the "error" attribute shall be set to "invalid_token", as described in IETF RFC 6750 , if the request contained a token which was deemed as invalid by the NF service producer (e.g. it is expired, malformed...); if the request did not contain a token, the "error" attribute shall not be included.
If an NF service producer rejects an API request with an OAuth2.0 access token not having the required scopes to invoke the service operation, it shall return the HTTP "403 Forbidden" status code together with the "WWW-Authenticate" header, where:
the scheme for challenge in the "WWW-Authenticate" header shall be set to "Bearer",
the "realm" attribute shall be set to the URI of the service (i.e API URI) for which the access failed, in the case of request / response service operations,
the "error" attribute shall be set to "insufficient_scope" as described in IETF RFC 6750 ,
the "scope" attribute shall be set with the scope(s) necessary to access the protected resource.
For the notify operation of subscribe/notify semantics service operations, in this release of this specification OAuth 2.0 access token is not used.
When an NF service consumer receives a "401 Unauthorized" or a "403 Forbidden" status code with a "WWW-Authenticate" header containing "Bearer" as the scheme for challenge it shall not repeat the same request without an OAuth2.0 access token or with an access token that has been already used. The NF service consumer may repeat the same request with a new OAuth 2.0 access token.
As specified in clause 13.2 of TS 33.501, the following procedures shall be supported across N32
Capability Negotiation Request and Response;
Parameter Exchange Request and Response;
forwarding of the JOSE (see IETF RFC 7516  and IETF RFC 7515 ) protected messages over N32.
Based on the capability negotiation and parameters exchanged between the SEPPs, the service based interface messages sent across N32 interface shall be subjected to JOSE based protection (see IETF RFC 7516  and IETF RFC 7515 ) as specified in clause 13.2.4 of TS 33.501.
3GPP TS 29.573 specifies protocol for the exchange of the messages described above over N32, the format of the JOSE (see IETF RFC 7516  and IETF RFC 7515 ) protected messages and the procedure for forwarding of the JOSE protected messages over N32.
The client credentials assertion and authentication procedure specified in clause 13.3.8 of TS 33.501 may be used to enable the NRF or the NF Service Producer to authenticate the NF Service Consumer, when using indirect communication.
If so, an HTTP request shall include the 3gpp-Sbi-Client-Credentials header (see clause 184.108.40.206.11) containing the client credentials assertion. The verification of the client credentials assertion shall be performed by the receiving entity as specified in clause 220.127.116.11 of TS 33.501.
The primary usage of SBI Message Priority (SMP) is to provide guidance to 5GC NF acting as HTTP/2 clients or servers and HTTP/2 proxies when making throttling decisions related to overload control. The priority information may also be used for routing in proxies. Eventually a server may use the priority information to process higher-priority requests before lower-priority requests.
The SMP mechanism defined in this clause uses the "3gpp-Sbi-Message-Priority" custom HTTP header defined in clause 18.104.22.168.1 to set and carry the message priority between the client and the server.
The SMP mechanism should also use the stream priority mechanism specified in IETF RFC 7540  clause 5.3.
HTTP/2 clients, servers and proxies implementing SBIs shall support the custom HTTP header and should support the stream priority.
A client, proxy and server shall use the "3gpp-Sbi-Message-Priority" value (see clause 22.214.171.124.1) when setting or evaluating the priority of a message.
The client shall assign the request priority by adding the "3gpp-Sbi-Message-Priority" custom HTTP header (see clause 126.96.36.199.1) to the message and setting its value.
If the "3gpp-Sbi-Message-Priority" custom HTTP header is not present in a response message then the HTTP nodes shall use the priority indicated in the "3gpp-Sbi-Message-Priority" of the associated request message.
If the server wants to assign a different priority to the response message than the request one then the server shall assign the response priority by adding the "3gpp-Sbi-Message-Priority" custom HTTP header to the message and setting its value.
The purpose of HTTP/2 stream priority is to allow an endpoint to prioritize streams for transmitting frames when there is limited capacity for sending and to express how it would prefer its peer to allocate resources when managing concurrent streams. Setting the stream priority ensures a priority treatment to a message between the two endpoints of an HTTP/2 connection.
The stream priority applies to all frames in both directions. If it is not changed until the stream is closed then all frames of the request and response messages will have the same priority. A client assigns a priority for a request and the correspondent response by including dependency and Weight information in the HEADERS frame that opens the stream carrying the message.
The stream dependency shall be set to 0.
If the stream priority is used then the stream priority Weight is mapped from the custom HTTP header. The mapping algorithm shall respect the ordering of the priority. If message 1 has a priority of "x" and message 2 has a priority of "y" where "x" is lower than "y" then the Weight of the stream carrying the message 1 shall be higher than the Weight of the stream carrying the message 2.
If the server wants to change the priority of the response, it shall send a PRIORITY frame after the stream state became "half-closed (remote)" or shall send the priority information in the HEADERS frame.
The recommendations provided in this clause are compliant with clause 10 of IETF RFC 7944 . The priority value range defined over SBIs spans from 0 to 31 (decimal), where 0 indicates the highest priority, while 31 indicates the lowest priority. They have been adapted to 5G services and Service Based Architecture.
The priorities defined for all messages across all SBIs used in an HTTP/2 administrative domain must be defined in a consistent and coordinated fashion, taking the default priority (see below for default priority values) into account.
The following are some guidelines to be considered when defining the SMPs to be used in SBA networks that support HTTP/2 nodes handling multiple services.
As with any prioritization scheme, it is possible for higher-priority messages to block lower-priority messages from ever being handled. In 5GC, this will often result in the messages being retried. This may result in more traffic than the network would have handled without use of the SMP mechanism.
One potential guideline to prevent unwanted starving of lower-priority messages is to have higher-priority messages represent a relatively small portion of messages handled by the 5GC under normal scenarios. Multimedia Priority Service (see TS 23.501, clause 5.16.5) and Mission Critical Service (see TS 23.501, clause 5.16.6) typically generate little traffic compared to the total traffic of a 5GC.
Multimedia Priority Service (MPS) or Mission Critical Service (MCX) requires the blocking of lower-priority services.
When setting priorities for Multimedia Priority Services, Mission Critical Services or Emergency calls, it is important to use the same priority values across all APIs and services exposed by the 5GC. For instance, if it is defined that the MPS priority level of [1; n] shall be assigned the priority of [k; k+n-1] in the same order then it shall be the same on all SBIs.
Messages related to MPS, MCX and Emergency calls may be ranked according to their priority (e.g., based on ARP priority level, 5QI priority level, MPS Priority) based on regional/national regulatory and operator policies when it is known by the application sending the message. Otherwise MPS and MCX should have higher priorities than Emergency calls. Emergency call related messages should have higher priority than the rest of the messages.
Requests without the "3gpp-Sbi-Message-Priority" header shall be assigned the default priority value of "24".
Streams without priority shall be assigned a Stream Dependency of 0x0 and the default Weight of 16.
When defining priorities of the messages of a service it is needed to follow the same rules independently of the application, the SBI and the service.
When there is a series of request/response required to complete a procedure, it is appropriate to mark request/response occurrences that occur later in the series at a higher priority than those that occur early in the series.
The requests that establish new sessions should have a lower priority than the ones that update or end a session.
The requests that will result on deregistering users if they failed (authentication vector retrieval, update location…) shall have a higher priority than the ones of a non-registered user.
Request/response of optional procedure and delay tolerant services should have lower priority than those of mandatory procedures.
The client sending a request shall determine its required priority according to 6.8.4. It shall include a "3gpp-Sbi-Message-Priority" header (see clause 188.8.131.52.1) indicating the required priority level in the request and shall prioritise the requests according to the required priority level. If the client also uses the stream priority at the HTTP/2 connection level then it shall map the header value into a Weight and include it in the HEADERS of the request message.
When the client receives a response with the "3gpp-Sbi-Message-Priority" header, it shall prioritise the received response according to the priority level received, otherwise according to the priority level of the corresponding request. This includes determining the order in which responses are handled and resources that are applied to the handling of the responses. The client may use the stream priority to determine how to prioritize the response at the HTTP/2 connection level.
The server should use the "3gpp-Sbi-Message-Priority" header (see clause 184.108.40.206.1) and may use the stream priority information to determine how to handle the request. This includes determining the order in which requests are handled and resources that are applied to the handling of the request.
Servers should use "3gpp-Sbi-Message-Priority" value when making overload throttling decisions.
Servers should use stream priority information when making overload throttling decisions at the connection level.
When the priority of the response message needs to have a different value than the request, a server shall include a "3gpp-Sbi-Message-Priority" header in the response message which value is set to the response required priority level.
If a server has included "3gpp-Sbi-Message-Priority" header in the response message it may also set the stream priority as described in IETF RFC 7540 , via priority information in the HEADERS frame or in a PRIORITY frame. In both cases the priority Weight value shall be mapped from the 3gpp-Sbi-Message-Priority" header value. When sending the priority information with a PRIORITY frame the server shall send it before sending the HEADERS frame of the response message. A server shall not send a PRIORITY frame after the HEADER one.
A proxy should forward request and response without removing the "3gpp-Sbi-Message-Priority" header or changing its value.
While done only in exceptional circumstances, a proxy may modify priority information when relaying request and response by changing the "3gpp-Sbi-Message-Priority" value. For example, a SEPP may modify the priority set by a roaming partner.
Proxies should use the request priority information (respectively response priority information) according to the "3gpp-Sbi-Message-Priority" value and may use the stream priority Weight value when making overload throttling decisions to a request (respectively a response).
Proxies may use the priority information according to the "3gpp-Sbi-Message-Priority" value and may use the stream priority Weight value when relaying a request or a response messages. This includes the selection of routes (only for the requests) and the ordering of messages relayed.
A client, proxy or server may prioritize traffic at IP level by placing messages into different traffic classes and marking them with an appropriate Differentiated Services Code Point (DSCP).
Multiple HTTP/2 connections between two HTTP/2 end points are necessary: one per DSCP value. All messages sent over a connection are assigned the same traffic class and receive the same DSCP marking. The "3gpp-Sbi-Message-Priority" value shall be considered in the selection of the appropriate connection to send the message.
The OPTIONS method, as described in clause 4.3.7 of IETF RFC 7231 , may be used by a NF Service Consumer to determine the communication options supported by a NF Service Producer for a target resource.
Clause 220.127.116.11 describes example communication options that may be discovered using the OPTIONS method.
The Accept-Encoding header, as described in clause 5.3.4 of IETF RFC 7231 , may be used by a NF Service Producer to determine the communication options supported by a NF Service Consumer.
Clause 18.104.22.168 describes example communication options that may be discovered using the Accept-Encoding header.
Certain service operations may result in large HTTP request payloads, e.g. to register NF profiles in the NRF (see TS 29.510) or to update the NSSF with the available S-NSSAIs supported by Tracking Areas (see TS 29.531). Gzip coding (see IETF RFC 1952 ) may be supported to optimally reduce the payload size of HTTP requests in this case.
A NF Service Consumer may determine the content-encodings supported by the NF Service Producer in HTTP requests targeting a particular resource by:
sending an HTTP OPTIONS request targeting the resource of the NF Service Producer; and/or
receiving an "Accept-Encoding" header in HTTP responses from the NF Service Producer for requests targeting the resource.
A NF Service Producer that receives an HTTP OPTIONS request for a target resource shall include an "Accept-Encoding" header in the HTTP 200 OK response (see IETF RFC 7694 ), if specific content-encodings, e.g. Gzip coding (e.g. see IETF RFC 1952 ) are supported in HTTP requests targeting the resource.
A NF Service Producer that receives an HTTP request with a content-encoding that it does not support shall reject the request with the status code "415 Unsupported Media Type" and include an "Accept-Encoding" header in the response indicating the supported encodings in HTTP requests, as described in clause 3 of IETF RFC 7694 .
A NF Service Producer may include an "Accept-Encoding" header in the HTTP 2xx response for requests other than HTTP OPTIONS if specific content-encodings, e.g. Gzip coding (e.g. see IETF RFC 1952 ), are supported in HTTP requests targeting the resource, to optimize future interactions, e.g. when the request payload was big enough to justify use of a compression coding but the client did not do so.
Certain service operations may result in large HTTP response payloads, e.g. to send NF profiles by the NRF (see TS 29.510) or to send the available S-NSSAIs supported by Tracking Areas by the NSSF (see TS 29.531). Gzip coding (see IETF RFC 1952 ) may be supported to optimally reduce the payload size of HTTP responses in this case (see "Content-Encoding" header in Table 22.214.171.124-2).
A NF Service Consumer may include an "Accept-Encoding" header in HTTP requests to indicate the content-encodings, e.g. Gzip coding (e.g. see IETF RFC 1952 ), that are supported for the associated HTTP responses, as specified in Table 126.96.36.199-1 and in clause 5.3.4 of IETF RFC 7231 .
A NF Service Producer may determine the content-encodings supported by the NF Service Consumer in HTTP responses by receiving an "Accept-Encoding" header in the associated HTTP requests from the NF Service Consumer.