Content for  TS 29.500  Word version:  18.4.0

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 6.1.4.3.

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.

Clause 13 in TS 33.501 specifies two alternative authorization mechanisms:

• Static authorization, which is based on local authorization policy at the NRF and the NF Service Producer (see clause 13.3.0);
• Token based authorization, when NRF acts as the Authorization Server and provides access (see clause 13.3.1).

As specified in clause 13.4.1 of TS 33.501 OAuth 2.0 (see 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 Section 4.4 of 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 (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 Section 7 of 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 Section 2.1 of RFC 6750. 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 RFC 9110, where:

• the scheme for challenge in the "WWW-Authenticate" header shall be set to "Bearer" (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 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 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.

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 5.2.3.2.1 to set and carry the message priority between the client and the server. The SMP mechanism should not use the stream priority mechanism, because that is deprecated in Section 5.3 of RFC 9113. HTTP/2 clients, servers and proxies implementing SBIs shall support the custom HTTP header and may support the stream priority.

A client, proxy and server shall use the "3gpp-Sbi-Message-Priority" value (see clause 5.2.3.2.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 5.2.3.2.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 indicates a priority treatment to a message between the two endpoints of an HTTP/2 connection. Section 5.3 of the RFC 9113 deprecates the HTTP/2 stream priority signaling. For interoperability with implementations complying with earlier releases, 5GC NFs shall support receiving priority info in HEADER or PRIORITY frames to the extent that headers or frames containing stream priority information shall not be rejected, but processed as if they contained no stream priority information, i.e. the stream priority information is ignored.

The recommendations provided in this clause are compliant with Section 10 of RFC 7944]. The priority value range defined over SBIs spans from 0 to 31 (decimal), where 0 indicates the highest priority and 31 indicates the lowest priority. The recommendations 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. The Multimedia Priority Service (see clause 5.16.5 of TS 23.501) and the Mission Critical Service (see clause 5.16.6 of TS 23.501) typically generate little traffic compared to the total traffic of a 5GC. The Multimedia Priority Service (MPS) and the Mission Critical Service (MCX) require the blocking of lower-priority services.

• A network entity (e.g., the AMF) that has received an RRC Establishment Cause associated with priority service (e.g., mps-PriorityAccess, mcs-PriorityAccess, or highPriorityAccess) or has determined that the UE has a priority subscription (e.g., MPS, MCX) in the UDM/UDR, shall select an SMP value appropriate for the priority service (e.g., MPS, MCX) for use in requests and responses.
• 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 the MPS priority levels of [1; n] are assigned the values of [k; k+n-1], then the same values shall be defined in the same order on all SBIs for the same service.
• 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. The ranking can be used to select SMP values.

The following are general requirements:

• Requests without the "3gpp-Sbi-Message-Priority" header shall be assigned the default priority value of "24".
• When defining priorities of the messages of a service, the same rules apply 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/responses 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 requests that update or end a session.
  • The requests that will result in deregistering users if they failed (e.g., due to authentication vector retrieval, or update location) shall have a higher priority than the requests of a non-registered user.
  • Request/responses of optional procedures and of delay tolerant services should have lower priority than those of mandatory procedures.

The client sending a request shall determine its required priority according to clause 6.8.4. It shall include a "3gpp-Sbi-Message-Priority" header (see clause 5.2.3.2.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 server should use the "3gpp-Sbi-Message-Priority" header (see clause 5.2.3.2.1) 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 not 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. A server should not set the stream priority as described in RFC 9113, via priority information in the HEADERS frame or in a PRIORITY frame.

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 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 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 Section 9.3.7 of RFC 9110, may be used by a NF Service Consumer to determine the communication options supported by a NF Service Producer for a target resource. Clause 6.9.2.1 describes example communication options that may be discovered using the OPTIONS method. The Accept-Encoding header, as described in Section 12.5.3 of RFC 9110, may be used by a NF Service Producer to determine the communication options supported by a NF Service Consumer. Clause 6.9.2.2 describes example communication options that may be discovered using the Accept-Encoding header.