Methods, systems, and computer-readable media for automatic category 1 message filtering rule configuration by learning topology information from a network function (NF) repository function (NRF)

Abstract

A method for automatically configuring and using category 1 message filtering rules includes subscribing, at a network function (NF), to a network function repository function (NRF) to receive notifications of NF profile changes. The method also includes receiving, from the NRF and as a result of the subscribing, a notification of an NF profile change. The method also includes automatically configuring at least one implemented category 1 message filtering rule based on the notification of the NF profile change. The method also includes filtering a service-based interface (SBI) message using the at least one category 1 message filtering rule.

Description

[0001] CLAIM OF PRIORITY

[0002] This application claims priority to U.S. Patent Application Serial No. 17 / 902,531, filed September 2, 2022, the disclosure of which is incorporated herein in its entirety by reference. TECHNICAL FIELD

[0003] The subject matter described herein relates to automatic configuration of category 1 message filtering rules. More particularly, the subject matter described herein relates to methods, systems, and computer readable media for automatic category 1 message filtering rule configuration by learning topology information from the NRF. BACKGROUND

[0004] In 5G telecommunications networks, network functions that provide services are referred to as producer NFs or NF service producers. Network functions that consume services are referred to as consumer NFs or NF service consumers. A network function can be a producer NF, a consumer NF, or both, depending on whether the network function is consuming, producing, or both consuming and producing services. The terms “producer NF” and “NF service producer” are used interchangeably herein. Similarly, the terms “consumer NF” and “NF service consumer” are used interchangeably herein.

[0005] A given producer NF can have many service endpoints, where a service endpoint is a contact point for one or more NF instances hosted by the producer NF. A service endpoint is identified by a combination of an Internet Protocol (IP) address and a port number or a fully qualified domain name (FQDN) that resolves to an IP address and a port number on a network node hosting the producer NF. An NF instance is an instance of a producer NF that provides a service. A given producer NF can include more than one NF instance. It should also be noted that multiple NF instances can share the same service endpoint.

[0006] NFs register with a Network Function Repository Function (NRF). The NRF maintains profiles of available NF instances that identify services supported by each NF instance. The profile of an NF instance is referred to as an NF profile in 3GPP TS 29.510. An NF instance can obtain information about other NF instances that have registered with the NRF through an NF discovery service operation. According to the NF discovery service operation, a consumer NF sends an NF discovery request to the NRF. The NF discovery request includes query parameters that the NRF uses to locate NF profiles of producer NFs that are capable of providing services identified by the query parameters. An NF profile is a data structure that defines a type of service provided by an NF instance as well as contact and capacity information about the NF instance.

[0007] A service communication proxy (SCP) can also invoke NF discovery service operations to learn about available producer NF instances. The case where the SCP uses the NF discovery service operation on behalf of a consumer NF to obtain information about producer NF instances is referred to as delegated discovery. The consumer NF connects to the SCP, and the SCP load balances or directly routes traffic to the destination producer NF instance between producer NF service instances that provide the required service.

[0008] In addition to SCPs, another example of an intermediary proxy that forwards traffic between producer and consumer NFs is a security edge protection proxy (SEPP). A SEPP is a network function used to protect control plane traffic exchanged between different 5G public land mobile networks (PLMNs). As such, a SEPP performs message filtering, policing, and topology hiding on all application programming interface (API) messages transmitted between PLMNs.

[0009] One issue that arises in 5G and other types of networks is that class 1 message filtering needs to be performed at the SEPP or SCP, and manual configuration of class 1 message filtering rules is labor intensive and prone to human error. GSMA FS.36, 5G Interconnect Security Release 2.0 Section 3.4.5, recommends customizing class 1 message filtering on resource URIs and HTTP methods for operation screening within N32fReformattedReqMsg and N32fReformattedRespMsg to protect 5GC networks. FS.36 defines class 1 message filtering as unauthorized packet filtering at the interface level (see Section 3.4.3). The purpose of class 1 message filtering is to prevent unauthorized external access to internal interfaces. Messages that can be filtered at the SEPP or SCP using class 1 message filtering rules include service-based interface (SBI) messages seeking access to services provided by NFs.

[0010] One approach to class 1 message filtering is to create a whitelist with specific interfaces and resource URIs and HTTP methods / custom operations. The recommended practice for class 1 filtering is to block all 5G interconnect messages except those explicitly required by a given interface and only allow / activate the interface(s) needed by the mobile network operator (MNO) use case on the SEPP. This also avoids the risk of roaming partners unilaterally extending roaming services or functions by using interfaces and sending messages not covered by existing roaming agreements. In general, the SEPP needs to be able to distinguish between different interfaces and methods encapsulated in N32-f packets and treat them separately.

[0011] White lists can be deployed at different levels of precision. For example, white lists can be deployed based on roaming partners, peer SEPPs, resource URIs, HTTP methods / customized operations, or even based on information element (IE) level and flags. The more precise the white list, the more difficult it is to launch an attack. The more precise the filtering, the more detailed the administration required.

[0012] Category 1 message filtering can be implemented at the SEPP because the SEPP is the entry point for the PLMN. One challenge is keeping the SEPP configuration synchronized with the resource URIs and HTTP methods supported by the producer of the PLMN.

[0013] Thus, in view of these and other difficulties, there is a need for improved methods, systems, and computer readable media for configuring category 1 message filtering rules. SUMMARY

[0014] A method for automatically configuring and using category 1 message filtering rules is provided. The method includes subscribing, at a network function (NF), to a NF repository function (NRF) to receive notifications of NF profile changes. The method also includes receiving, from the NRF and as a result of the subscribing, a notification of a NF profile change. The method further includes automatically configuring at least one category 1 message filtering rule based on the notification of the NF profile change. The method also includes using, at the NF, the at least one category 1 message filtering rule to perform category 1 message filtering of service-based interface (SBI) messages.

[0015] According to another aspect of the subject matter described herein, the NF comprises a security edge protection proxy (SEPP).

[0016] According to another aspect of the subject matter described herein, the NF comprises a service communication proxy (SCP).

[0017] According to another aspect of the subject matter described herein, subscribing to the NRF comprises transmitting an nfStatusSubscribe message to the NRF.

[0018] According to another aspect of the subject matter described herein, receiving the notification of the NF profile change comprises receiving an nfStatusNotify message containing the NF profile.

[0019] According to another aspect of the subject matter described herein, receiving the notification of the NF profile change comprises receiving the notification in response to a NFRegister, NFUpdate, or NFDeregister service operation.

[0020] According to another aspect of the subject matter described herein, the NF profile includes an authorization attribute and automatically configuring the at least one category 1 message filter rule includes adding or updating a category 1 message filter rule to allow SBI messages containing a Hypertext Transfer Protocol (HTTP) method corresponding to an allowed range of entities defined in the authorization attribute.

[0021] According to another aspect of the subject matter described herein, the authorization attribute range specifies allowed operations of the entity.

[0022] According to another aspect of the subject matter described herein, automatically configuring the at least one category 1 message filter rule includes automatically adding a category 1 message filter rule to a category 1 message filter rule database maintained by the NF.

[0023] According to another aspect of the subject matter described herein, filtering the SBI message using the category 1 message filter rule includes allowing or blocking the SBI message from reaching a public land mobile network (PLMN) based on a Hypertext Transfer Protocol (HTTP) method type and a resource uniform resource identifier (URI) parameter in the message.

[0024] According to another aspect of the subject matter described herein, a system for automatically configuring and using category 1 message filter rules is provided. The system includes a network function (NF) including at least one processor and a memory. The system also includes a category 1 message filter rule database stored in the memory. The system further includes a category 1 message filter rule manager executable by the at least one processor to subscribe to a network function repository function (NRF) to receive notifications of NF profile changes from the NRF and as a result of the subscription, receive a notification of an NF profile change from the NRF, automatically configure at least one category 1 message filter rule in the category 1 message filter rule database based on the notification of the NF profile change, and filter service-based interface (SBI) messages using the at least one category 1 message filter rule.

[0025] According to another aspect of the subject matter described herein, the category 1 message filter rule manager is configured to subscribe to the NRF by transmitting an nfStatusSubscribe message to the NRF.

[0026] According to another aspect of the subject matter described herein, the category 1 message filter rule manager is configured to receive the notification of the NF profile change in an nfStatusNotify message containing the NF profile.

[0027] According to another aspect of the subject matter described herein, the category 1 message filter rule manager is configured to receive the notification of the NF profile change in response to an NFRegister, NFUpdate, or NFDeregister service operation.

[0028] According to another aspect of the subject matter described herein, the NF profile includes an authorization attribute, and wherein the Category 1 message filter rule manager is configured to automatically add or update the Category 1 message filter rule to allow a Hypertext Transfer Protocol (HTTP) method corresponding to an allowed range of entities defined in the authorization attribute.

[0029] According to another aspect of the subject matter described herein, the Category 1 message filter rule manager is configured to allow or block a message from reaching a Public Land Mobile Network (PLMN) based on a Hypertext Transfer Protocol (HTTP) method type and a resource Uniform Resource Identifier (URI) parameter in the message.

[0030] According to another aspect of the subject matter described herein, a non-transitory computer-readable medium is provided having stored thereon executable instructions that, as a result of being executed by a processor of a computer, cause the computer to perform steps. The steps are performed at a Network Function (NF). The steps include subscribing, at the NF, to a Network Function Repository Function (NRF) to receive notifications of NF profile changes. The steps also include receiving, from the NRF and as a result of the subscribing, a notification of an NF profile change. The steps further include automatically configuring at least one Category 1 message filter rule based on the notification of the NF profile change. The steps also include filtering a Service Based Interface (SBI) message using the at least one Category 1 message filter rule.

[0031] The subject matter described herein can be implemented in software in combination with hardware and / or firmware. For example, the subject matter described herein can be implemented in software executed by a processor. In one exemplary implementation, the subject matter described herein can be implemented using a non-transitory computer readable medium having stored thereon computer executable instructions that, as a result of being executed by a computer, cause the computer to perform the steps. Exemplary computer readable media suitable for implementing the subject matter described herein include non-transitory computer readable media, such as disk memory devices, chip memory devices, programmable logic devices, and application specific integrated circuits. In addition, a computer readable medium that implements the subject matter described herein can reside on a single device or computing platform or can be distributed across multiple devices or computing platforms. BRIEF DESCRIPTION OF DRAWINGS

[0032] Exemplary implementations of the subject matter described herein will now be explained with reference to the drawings, wherein:

[0033] Figure 1 is a network diagram illustrating an exemplary 5G system network architecture;

[0034] Figure 2 is a message flow diagram illustrating manual configuration of Category 1 message filter rules at a SEPP;

[0035] Figure 3is a message flow diagram illustrating automatic configuration of Category 1 message filtering rules at a SEPP by learning topology information from the NRF;

[0036] Figure 4 is a message flow diagram illustrating automatic configuration of Category 1 message filtering rules at a SCP by learning topology information from the NRF;

[0037] Figure 5 is a block diagram illustrating an exemplary architecture of a SEPP or SCP for performing automatic configuration of Category 1 message filtering rules; and

[0038] Figure 6 is a flow diagram illustrating an exemplary process for automatic configuration and use of Category 1 message filtering rules. DETAILED DESCRIPTION

[0039] Figure 1 is a block diagram illustrating an exemplary 5G system network architecture. Figure 1 The architecture in FIG. 1 includes an NRF 100 and a SCP 101, which can be located in the same home public land mobile network (HPLMN). As described above, the NRF 100 can maintain profiles of available NF instances and their supported services, and allow consumer NFs or SCPs to subscribe to registration of new / updated NF instances and be notified of registration of new / updated instances. The SCP 101 can also support service discovery and selection of NF instances. The SCP 101 can perform load balancing of connections between consumer and producer NFs.

[0040] The NRF 100 is a repository of profiles of NF instances. In order to communicate with a producer NF instance, a consumer NF or SCP must obtain the NF profile of the producer NF instance from the NRF 100. The NF profile is a JavaScript Object Notation (JSON) data structure defined in 3GPP TS 29.510. The NF profile includes attributes indicating the type of service provided, the capacity of the NF instance, and information for contacting the NF instance.

[0041] In Figure 1 In the example shown, the NFs include a policy control function (PCF) 102 that performs policy-related operations in the network, a unified data management function (UDM) 104 that manages user data, and an application function (AF) 106 that provides application services.

[0042] Figure 1The NFs shown in the middle also include a session management function (SMF) 108, which manages sessions between an application and a mobility management function (AMF) 110 and the PCF 102. The AMF 110 performs mobility management operations similar to the mobility management operations performed by a mobility management entity (MME) in a 4G network. An authentication server function (AUSF) 112 performs authentication services for user equipment (UE) such as user equipment (UE) 114 seeking access to the network.

[0043] A network slice selection function (NSSF) 116 provides network slice services for devices seeking to access particular network capabilities and characteristics associated with a network slice. A network exposure function (NEF) 118 provides application programming interfaces (APIs) for application functions seeking to obtain information about Internet of Things (IoT) devices and other UEs attached to the network. The NEF 118 performs similar functions to a service capability exposure function (SCEF) in a 4G network.

[0044] A radio access network (RAN) 120 connects the user equipment (UE) 114 to the network via a wireless link. The radio access network 120 can be accessed using a g-Node B (gNB) (not shown in the middle) or other wireless access point. Figure 1 A user plane function (UPF) 122 can support various proxy functions for user plane services. One example of such a proxy function is a multi-path transmission control protocol (MPTCP) proxy function. The UPF 122 can also support a performance measurement function that can be used by the UE 114 to obtain network performance measurements. Figure 1 Also shown in the middle is a data network (DN) 124 through which the UE accesses data network services, such as Internet services.

[0045] The SEPP 126 filters incoming traffic from another PLMN and performs topology hiding for traffic leaving the home PLMN. The SEPP 126 can communicate with an SEPP in a foreign PLMN that manages security for the foreign PLMN. Thus, traffic between NFs in different PLMNs can traverse two SEPP functions, one for the home PLMN and one for the foreign PLMN.

[0046] As mentioned above, one issue with current filtering in 5G and other networks is that manually configuring category 1 message filtering rules at the SEPP or SCP is labor intensive and prone to human error. GSMA FS.36 version 2 section 3.4.5 recommends using category 1 message filtering on custom operations to protect the network. Category 1 message filtering is based on resource URI and HTTP method type and can be implemented at the SEPP as the SEPP is the entry point for the PLMN. Category 1 message filtering can also be implemented at the SCP as the SCP is a routing node for distributing messages within the 5G network.

[0047] The subject matter described herein includes a mechanism to automate the configuration for category 1 message filtering at the SEPP or SCP by learning the producer NF profiles registered with the NRF and extracting the required information from the profiles to configure the category 1 message filtering rules to reduce operational overhead and improve the security of the 5GC network by reducing the likelihood of human error.

[0048] As mentioned above, producer NFs register their NF profiles with the NRF. The NF profile includes authorization attributes that can be used as topology information to configure category 1 message filtering rules. Two of these authorization attributes are the allowedOperationsPerNfType attribute and the allowedOperationsPerNfInstance attribute. 3GPP TS 29.510 version 17.5.0 section 6.1.6.2.3 defines allowedOperationsPerNfType and allowedOperationsPerNfInstance which define an array of allowed scopes. The scopes that can be mapped to resource URIs and methods can be used to create category 1 message filtering rules. The scopes are defined in the various API specifications and are further detailed below. Table 1 shown below from 3GPP TS 29.510 defines the AllowedOperationsPerNfType and allowedOperationsPerNfInstance attributes:

[0049]

[0050] Table 1: NF Profile attributes that can be used to configure Category 1 message filtering rules According to Table 1, the allowedOperationsPerNfType attribute stores values that define the allowed operations or scopes for a given NF type. Such attribute values can be used in Category 1 message filtering rules that filter SBI messages based on the HTTP method attribute values (such as PUT, POST, PATCH, GET, etc.) carried in the message. The allowedOperationsPerNfInstance attribute stores values that define the allowed operations or scopes for an NF instance. These values can also be used in Category 1 message filtering rules that filter SBI messages based on the HTTP method attribute values at the NF instance level.

[0051] Other authorization attributes that can be used to define the allowed operations or scopes for an entity include allowedPlmns, allowedNfTypes, allowedNfDomains, allowedNssais, etc. In addition, vendor-specific (i.e., non-3GPP defined attributes) can also be defined for authorization. Any authorization attribute specified in the NF Profile can be used to automatically provision and / or update Category 1 message filtering rules.

[0052] The following are examples of allowed NF scopes that can be defined for different NF types seeking access to the UDM. The NF Open API specification can be used to define the allowed scopes on interfaces that use OAuth2 authentication (such as the N32 interface). Scopes are access rights that control whether a consumer NF is allowed to perform the required invocation on a producer NF. In the following examples, the values of the keys in the scope map are hidden using three dots for clarity. Additional information on OAuth2 scopes can be found at:

[0053] https: / / swagger.io / docs / specification / authentication / oauth2 / ScopesExample:

[0054] components:

[0055] securitySchemes:

[0056] oAuth2ClientCredentials:

[0057] type: oauth2

[0058] flows:

[0059] clientCredentials:

[0060] tokenUrl: '{nrfApiRoot} / oauth2 / token'

[0061] scopes:

[0062] nudm-uecm:Access to the nudm-uecm API

[0063] c:write:...

[0064] nudm_uecm:smf-registration:write:...

[0065] nudm_uecm:smsf-registration:write:...

[0066] nudm_uecm:ip-sm-gw-registration:write:...

[0067] nudm_uecm:nwdaf-registration:write:...

[0068] In the above example, allowed scopes are defined for different NF types of the nudm-uecm API. These scopes allow write access to the nudm-uecm API for the AMF, SMF, Short Message Service Function (SMSF), IP Short Message Gateway (IP-SM-GW), and Network Data Analytics Function (NWDAF) registration procedures. An SEPP or SCP that performs automatic Category 1 message filtering rule configuration as described herein can map the write access to an HTTP method (such as POST) to allow the identified NF types to send SBI messages containing the HTTP POST method in the PLMN. The following table illustrates an example of Category 1 message filtering rules that can be automatically configured based on the allowed OAuth2 scopes described above:

[0069] Interface Name Allowed HTTP Method(s) nudm_uecm:smf-registration POST nudm_uecm:smsf-registration POST nudm_uecm:ip-sm-gw-registration POST nudm_uecm:nwdaf-registration POST

[0070] Table 2: Category 1 message filtering rule example In Table 2, the Category 1 message filtering rules defined for the nudm-uecm registration API allow the HTTP POST operation. It can be appreciated that HTTP operations other than the explicitly allowed HTTP operation will be rejected. For example, a message attempting to perform an HTTP GET operation on the nudm_uecm:smf-registration interface will be rejected.

[0071] Category 1 message filter rule configuration needs to be kept in sync with the resource URIs and HTTP methods supported by the PLMN producer. Manual process is error prone and increases the operational overhead. There is a need to reduce the operational overhead by automating the category 1 message filter rule configuration at the SEPP. The operator has to configure the category 1 message filter rules and also has to update the category 1 message filter rules on the SEPP when the NF profile configuration is updated to add the allowed operations on the interface. According to an aspect of the subject matter described herein, the SEPP subscribes to the NF profile changes with the NRF. Any changes in the NF profile are communicated to the SEPP, which upon receiving such a notification uses the scope details provided in the NF profile to create one or more category 1 message filter rules.

[0072] Before describing the messaging associated with the automatic configuration of the category 1 message filter, a description of Figure 2 An exemplary messaging associated with the manual configuration of the category 1 message filter is described. Reference is made to Figure 2 In line 1, the user manually configures the NF profiles of the NF producers 200 and 202 and also manually configures the category 1 message filter rules for the NF producers 200 and 202 with the SEPP 126.

[0073] In line 2, the NF producer 202 transmits an NF registration request to the NRF 100 to register its NF profile with the NRF 100. The NF registration service operation is successful and the NRF 100 responds with a 201 Created message in line 3.

[0074] In line 4, the NF producer 200 transmits an NF registration request to the NRF 100 to register its NF profile with the NRF 100. The NF registration service operation is successful and the NRF 100 responds with a 201 Created message in line 5.

[0075] In line 6, the foreign PLMN 204 transmits an SBI request message requesting a service from one of the NFs in the PLMN protected by the SEPP 126. In this example, assume that the message is blocked by the category 1 message filter rules. The SEPP 126 responds with an SBI response message indicating that the message has been blocked as indicated in line 7.

[0076] In line 8, the network operator manually updates the NF profiles of the NF producers 200 and 202. The network operator is also required to manually update the category 1 message filter rules based on the changes to the NF profiles. This manual configuration of the category 1 message filter rules is error prone and therefore undesirable.

[0077] Figure 3is a message flow diagram illustrating automatic configuration of Category 1 message filtering rules at the SEPP by learning topology information from the NRF. Referring to Figure 3 In line 1, the operator configures NFs 200 and 202 with their NF profiles. In line 2, SEPP 126 transmits a nfStatusSubscribe message to NRF 100 to subscribe to receive notifications of NF profile changes maintained by NRF 100. In line 3, NRF 100 responds with a 201 Created message indicating successful creation of the subscription.

[0078] In line 4, NF producer 202 transmits a NF registration request to NRF 100 to register its NF profile to NRF 100. The NF registration service operation is successful, and NRF 100 responds with a 201 Created message in line 5.

[0079] In line 6, NF producer 200 transmits a NF registration request to NRF 100 to register its NF profile to NRF 100. The NF registration service operation is successful, and NRF 100 responds with a 201 Created message in line 7.

[0080] In line 8, NRF 100 transmits a nfStatusNotify message to SEPP 126 to notify SEPP 126 of the NF profile registration. SEPP 126 receives the nfStatusNotify message, reads the NF profile information from the nfStatusNotify message, and automatically creates one or more Category 1 message filtering rules based on the NF profile information. For example, if the NF profile includes per-NF type parameters of allowed information, then SEPP 126 can automatically create Category 1 message filtering rules to allow specified operations to be performed for the identified NF types.

[0081] In line 6, NF producer 200 transmits a NF registration request to NRF 100 to register its NF profile to NRF 100. The NF registration service operation is successful, and NRF 100 responds with a 201 Created message in line 7.

[0082] In line 8, NRF 100 transmits an nfStatusNotify message to SEPP to notify SEPP 126 of NF profile registration. SEPP 126 receives the nfStatusNotify message, reads the NF profile information from it, and automatically creates Category 1 message filtering rules based on the NF profile information. For example, if the NF profile information includes the allowedOperationsPerNfType attribute defined for either producer NF 200 or 202, then SEPP 126 can automatically create one or more Category 1 message filtering rules to allow specified operations to be performed for the identified NF(s) type(s). In line 9, SEPP 126 responds to the notification request with a 200 OK message.

[0083] In line 10, a foreign PLMN 204 transport request is received from an SBI request message for a service within one of the NFs in the PLMN protected by SEPP 126. In this example, it is assumed that the message is blocked by a Category 1 message filtering rule. SEPP 126 responds with an SBI response message indicating that the message has been blocked, as indicated in line 11.

[0084] In line 12, the operator updates the profiles for NF 200 and 202. NF 200 and 202 use the NFUpdate service for operation. Figure 3 (Not shown in the image) The NRF 100 updates its profile. In line 13, the NRF 100 transmits an nfStatusNotify request message containing the updated NF profile information to the SEPP 126. In response to receiving the updated NF profile information, the SEPP 126 automatically updates one or more Category 1 message filtering rules using the updated NF profile information. For example, if the updated NF profile information adds additional allowed operations for an NF type or NF instance, then the SEPP 126 can add the corresponding message filtering rule to its Category 1 message filtering rule database to allow HTTP messages of the corresponding HTTP method type. In line 14, the SEPP 126 responds to the notification request message in line 13.

[0085] The topics described herein are not limited to automatically configuring and using Category 1 message filtering rules at SEPP. In alternative implementations, SCP can automatically configure and use Category 1 message filtering rules. Figure 4 This is a message flow diagram illustrating the automatic configuration of Category 1 message filtering rules at the SCP by learning topology information from the NRF. (Reference) Figure 4In line 1, the network operator manually configures the NF profiles of NF producers 200 and 202. In line 2, SCP 101 transmits a nfStatusSubscribe message to NRF 100 to subscribe to receive notifications of NF profile changes maintained by NRF 100. In line 3, NRF 100 responds with a 201 Created message indicating successful creation of the subscription.

[0086] In line 4, NF producer 202 transmits an NF registration request to NRF 100 to register its NF profile with NRF 100. The NF registration service operation is successful, and NRF 100 responds with a 201 Created message in line 5.

[0087] In line 6, NF producer 200 transmits an NF registration request to NRF 100 to register its NF profile with NRF 100. The NF registration service operation is successful, and NRF 100 responds with a 201 Created message in line 7.

[0088] In line 8, NRF 100 transmits an nfStatusNotify message to SCP 101 to notify SCP 101 of the NF profile registration. SCP 101 receives the nfStatusNotify message, reads the NF profile information from the nfStatusNotify message, and automatically creates one or more category 1 message filter rules based on the NF profile information. For example, if the NF profile information includes an allowedOperationsPerNfType attribute, then SCP 101 can automatically create one or more category 1 message filter rules to allow specified operations for the identified NF type(s).

[0089] In line 6, NF producer 200 transmits an NF registration request to NRF 100 to register its NF profile with NRF 100. The NF registration service operation is successful, and NRF 100 responds with a 201 Created message in line 7.

[0090] In line 8, NRF 100 transmits an nfStatusNotify message to SCP 101 to notify SCP 101 of the NF profile registration in line 6. SCP 101 receives the nfStatusNotify message, reads the NF profile information from it, and automatically creates one or more Category 1 message filtering rules based on the NF profile information. For example, if the NF profile includes the allowedOperationsPerNfType attribute, then SCP 101 can automatically create Category 1 message filtering rules to allow specified operations for the identified NF(one or more) types. In line 9, SCP 101 responds to the notification request with a 200 OK message.

[0091] In line 10, the foreign PLMN 204 transmits an SBI request message from one of the NFs within the PLMN protected by SEPP 126. In line 11, SEPP 126 forwards the message to SCP 101 for routing within the PLMN. SCP 101 applies its Category 1 message filtering rules to determine whether to allow or block the message. In this example, it is assumed that the message is blocked by a Category 1 message filtering rule (or not allowed due to the existence of a Category 1 message filtering rule with an "allow" action). SCP 101 responds with an SBI response message indicating that the message has been blocked, as indicated in line 12. In line 13, SEPP 126 sends the response to the foreign PLMN 204.

[0092] In line 14, the operator updates the profiles for NF 200 and 202. NF 200 and 202 use the NFUpdate service for operation. Figure 4 (Not shown in the image) Updates its profile to NRF 100. In line 15, NRF 100 transmits an nfStatusNotify request message containing the updated NF profile information to SCP 101. In response to receiving the updated NF profile information, SCP 101 automatically updates one or more Category 1 message filtering rules with the updated NF profile information. For example, if the updated NF profile information adds additional allowed operations for an NF type or NF instance, then SCP 101 can add the corresponding message filtering rule to its Category 1 message filtering rule database to allow HTTP messages of the corresponding method type. In line 16, SCP 101 responds to the notification message in line 15.

[0093] Figure 5 This is a block diagram illustrating an exemplary architecture for the SEPP or SCP used to automatically configure Category 1 message filtering rules. Figure 5In particular embodiments, the SEPP or SCP 126 or 101 includes at least one processor 500 and memory 502. The SEPP or SCP 126 or 101 also includes a Class 1 message filtering rules database 504, which can be stored in memory 502. The SEPP or SCP 126 or 101 also includes a Class 1 message filtering rules manager 506, which performs the steps described herein for subscribing with the NRF to receive notifications of NF profile updates, automatically generating Class 1 message filtering rules, and filtering SBI messages using those rules. In one example, the Class 1 message filtering rules manager 506 can be implemented using computer-executable instructions stored in memory 502 and executed by processor 500.

[0094] Figure 6 is a flowchart illustrating an example process of automatic configuration of Class 1 message filtering rules using topology information learned from the NRF. Referring to Figure 6 In step 600, the process includes subscribing at the NF with the NRF to receive notifications of NF profile changes. For example, the SEPP 126 or SCP 101 can transmit an nfStatusSubscribe message to the NRF 100 with subscription data for NFs or groups of NFs for which the SEPP 126 or SCP 101 wishes to receive notifications of NF profile changes. In one example, the SEPP 126 or SCP 101 can subscribe to receive notifications of NF profile changes for all producer NFs within the PLMN.

[0095] In step 602, the process includes receiving notifications of NF profile changes from the NRF and as a result of the subscription. For example, the SEPP 126 or SCP 101 can receive an nfStatusNotify request from the NRF 100 in response to a NFRegister, NFUpdate, or NFDeregister service operation performed by a NF within the PLMN. The nfStatusNotify request can include new or updated NF profile information for the NF or group of NFs.

[0096] In step 604, the process includes automatically configuring at least one category 1 message filtering rule implemented at the NF based on the notification of NF profile changes. For example, the SEPP 126 or SCP 101 can extract allowed scopes from allowedOperationsPerNfType, allowedOperationsPerNfInstance, or other authorization attributes and generate category 1 message filtering rules to allow messages with scopes defined for the authorized entities. For example, if the allowed scope is write access on a given interface for an AMF, then the category 1 message filtering rule can indicate that HTTP POST, PUT, or PATCH methods are allowed for NF Type = AMF.

[0097] In step 606, the process includes filtering SBI messages at the NF using the at least one category 1 message filtering rule. For example, the SEPP 126 or SCP 101 can receive an SBI request, compare the NF instance and / or NF type information and the HTTP method type of the SBI request to the category 1 message filtering rules. When the SEPP 126 or SCP 101 detects that the SBI request message parameters match one of the rules, the SEPP 126 or SCP 101 can perform the corresponding rule action, which can be to allow or block the message.

[0098] In comparison to manual category 1 message filtering rule configuration, example advantages of the subject matter described herein include a reduction in operational overhead. Category 1 message filtering rules are automatically kept in sync with the resource URIs and HTTP method types provided by the producer NFs. The subject matter described herein also improves security by reducing manual errors in rule configuration. Another advantage is that obtaining updated category 1 message filtering rules through the nfStatusSubscribe service operation is easily implemented because it is an existing 3GPP service operation.

[0099] The disclosure of each of the following references is hereby incorporated by reference herein in its entirety.

[0100] REFERENCES

[0101] 1.3 rd Generation Partnership Project; Technical Specification

[0102] Group Core Network and Terminals; 5G System; Network

[0103] Function Repository Services; Stage 3 (Release 17) 3GPP TS

[0104] 29.510 V17.6.0 (2022-06)

[0105] 2.3 rd Generation Partnership Project; Technical Specification

[0106] Group Services and System Aspects; System architecture for the

[0107] 5G System (5GS); Stage 2; (Release 17) 3GPP TS 23.501 V17.5.0

[0108] (2022-06)

[0109] 3.3 rd Generation Partnership Project; Technical Specification

[0110] Group Services and System Aspects; Procedures for the 5G

[0111] System (5GS); Stage 2; (Release 17) 3GPP TS 23.502 V17.5.0

[0112] (2022-06)

[0113] 4.3 rd Generation Partnership Project; Technical Specification

[0114] Group Core Network and Terminals; 5G System, Public Land

[0115] Mobile Network (PLMN) Interconnection; Stage 3 (Release 17)

[0116] 3GPP TS 29.573 v17.5.0 (2022-06)

[0117] 5.5G Interconnect Security, Version 2.0 GSMA FS.36 (3 June 2021)

[0119] 6. OAuth 2.0;

[0120] https: / / swagger.io / docs / specification / authentication / oauth2 / (2022).

[0122] It should be understood that various details of the subject matter described herein can be changed without departing from the scope of the subject matter described herein. Furthermore, the foregoing description is for the purpose of illustration only, and not for the purpose of limitation, as the subject matter described herein is defined with the claims as set forth herein.

Claims

1. A method for automatically configuring and using category 1 message filtering rules, the method comprising: at a network function (NF): subscribing to a NF repository function (NRF) to receive notifications of NF profile changes; receiving a notification of a NF profile change from the NRF and as a result of the subscription; automatically configuring at least one category 1 message filtering rule based on the notification of the NF profile change; and using the at least one category 1 message filtering rule at the NF to filter service based interface (SBI) messages.

2. The method of claim 1, wherein the NF comprises a security edge protection proxy (SEPP).

3. The method of claim 1, wherein the NF comprises a service communication proxy (SCP).

4. The method of any of claims 1 to 3, wherein subscribing to the NRF comprises transmitting a nfStatusSubscribe message to the NRF.

5. The method of any of claims 1 to 3, wherein receiving the notification of the NF profile change comprises receiving a nfStatusNotify message containing the NF profile.

6. The method of any of claims 1 to 3, wherein receiving the notification of the NF profile change comprises receiving the notification in response to a NFRegister, NFUpdate, or NFDeregister service operation.

7. The method of any of claims 1 to 3, wherein the NF profile comprises an authorization attribute and wherein automatically configuring the at least one category 1 message filtering rule comprises adding or updating a category 1 message filtering rule to allow a service based interface (SBI) message containing a hypertext transfer protocol (HTTP) method corresponding to an allowed range of entities defined in the authorization attribute.

8. The method of claim 7, wherein the range defines allowed operations of the entity.

9. The method of any of claims 1 to 3, wherein automatically configuring the at least one category 1 message filtering rule comprises automatically adding a category 1 message filtering rule to a category 1 message filtering rule database maintained by the NF.

10. The method of any of claims 1 to 3, wherein using the category 1 message filtering rule to filter SBI messages comprises allowing or blocking messages from reaching a public land mobile network (PLMN) based on a hypertext transfer protocol (HTTP) method type and resource uniform resource identifier (URI) parameters in the message.

11. A system for automatically configuring and using category 1 message filtering rules, the system comprising: a network function (NF) comprising at least one processor and memory; a category 1 message filtering rule database stored in the memory; and ​ a Category 1 message filtering rules manager executable by the at least one processor to subscribe to an NF Repository Function (NRF) to receive notifications of NF profile changes, receive notifications of NF profile changes from the NRF and as a result of the subscription, automatically configure at least one Category 1 message filtering rule in a Category 1 message filtering rules database based on the notifications of NF profile changes; and filter service-based interface (SBI) messages using the at least one Category 1 message filtering rule.

12. The system of claim 11, wherein the NF comprises a Security Edge Protection Proxy (SEPP).

13. The system of claim 11, wherein the NF comprises a Service Communication Proxy (SCP).

14. The system of any one of claims 11 to 13, wherein the Category 1 message filtering rules manager is configured to subscribe to the NRF by transmitting an nfStatusSubscribe message to the NRF.

15. The system of any one of claims 11 to 13, wherein the Category 1 message filtering rules manager is configured to receive the notifications of NF profile changes in an nfStatusNotify message containing a NF profile.

16. The system of any one of claims 11 to 13, the Category 1 message filtering rules manager is configured to receive the notifications of NF profile changes in response to a NFRegister, NFUpdate, or NFDeregister service operation.

17. The system of any one of claims 11 to 13, wherein the NF profile comprises an authorization attribute, and wherein the Category 1 message filtering rules manager is configured to automatically add or update a Category 1 message filtering rule to allow a service-based interface (SBI) message containing a Hypertext Transfer Protocol (HTTP) method corresponding to an allowed range of entities defined in the authorization attribute.

18. The system of claim 17, wherein the range defines allowed operations of the entity.

19. The system of any one of claims 11 to 13, wherein the Category 1 message filtering rules manager is configured to allow or block a message from reaching a Public Land Mobile Network (PLMN) based on a Hypertext Transfer Protocol (HTTP) method type and resource Uniform Resource Identifier (URI) parameters in the message.

20. A non-transitory computer readable medium having stored thereon executable instructions that, when executed by a processor of a computer, control the computer to perform steps comprising: at a network function (NF): subscribing to an NF Repository Function (NRF) to receive notifications of NF profile changes; receiving notifications of NF profile changes from the NRF and as a result of the subscription; automatically configuring at least one Category 1 message filtering rule based on the notifications of NF profile changes; and filtering service-based interface (SBI) messages using the at least one Category 1 message filtering rule. ​

Images