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

Abstract

A method for automatic configuration and use of Category 1 message filtering includes, at a Network Function (NF), subscribing with an NF Repository Function (NRF) to receive notifications of NF profile changes. The method further includes receiving, from the NRF, notifications of the NF profile changes as a result of the subscribing. The method further includes automatically configuring at least one Category 1 message filtering rule to be implemented based on the notifications of the NF profile changes. The method further includes filtering Service-Based Interface (SBI) messages using the at least one Category 1 message filtering rule.

Description

[Technical Field]

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

[0002] Technical Field The subject matter described herein relates to automatically configuring 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 an NRF. [Background technology]

[0003] background In a 5G communication network, a network function that provides a service is called a producer NF or an NF service producer. A network function that consumes a service is called a consumer NF or an NF service consumer. A network function can be a producer NF, a consumer NF, or both, depending on whether the network function consumes, produces, or consumes and produces a service. 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.

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

[0005] NFs register with a Network Capability Repository Function (NRF). The NRF maintains profiles of available NF instances, which identify the services supported by each NF instance. NF instance profiles are referred to as NF profiles in 3GPP TS 29.510. NF instances can obtain information about other NF instances 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 contains query parameters, which the NRF uses to find the NF profiles of producer NFs that can provide the services identified by the query parameters. An NF profile is a data structure that defines the types of services provided by an NF instance and contact and capacity information about the NF instance.

[0006] A Service Communication Proxy (SCP) can also invoke NF discovery service operations to learn about available producer NF instances. When an SCP uses NF discovery service operations to obtain information about producer NF instances on behalf of a consumer NF, it is called delegated discovery. Consumer NFs contact the SCP, which then load balances traffic among producer NF service instances that offer the required service, or routes traffic directly to the desired producer NF instance.

[0007] In addition to SCPs, another example of an intermediate proxy forwarding traffic between producer and consumer NFs is the 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). To that end, a SEPP performs message filtering, policing, and topology hiding for all application programming interface (API) messages sent between PLMNs. Summary of the Invention [Problem to be solved by the invention]

[0008] One potential issue in 5G and other types of networks is the need for Category 1 message filtering in the SEPP or SCP, and the manual configuration of Category 1 message filtering rules is labor-intensive and prone to human error. GSMA FS.36, 5G Interconnect Security Version 2.0 Section 3.4.5, proposes Category 1 message filtering for resource URIs and HTTP methods for custom operation screening in N32fReformattedReqMsg and N32fRefirnatttedRespMsg to secure 5G networks. FS.36 defines Category 1 message filtering as filtering unauthorized packets at the interface level (see Section 3.4.3). The purpose of Category 1 message filtering is to prevent unauthorized access to internal interfaces from the outside. Messages that can be filtered using Category 1 message filtering rules in the SEPP or SCP include service-based interface (SBI) messages that request access to services provided by the NF.

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

[0010] Whitelists can be deployed with varying levels of granularity. For example, whitelists can be deployed based on roaming partners, peer SEPPs, resource URIs, HTTP methods / custom operations, or even at the information element (IE) level and flags. The more granular the whitelist, the more difficult it is to launch an attack. More precise filtering also requires more granular control.

[0011] Category 1 message filtering can be implemented in the SEPP since it is the entry point into the PLMN. One of the challenges is keeping the SEPP configuration synchronized with the resource URIs and HTTP methods supported by the PLMN's producers.

[0012] Therefore, 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. [Means for solving the problem]

[0013] overview A method for automatically configuring and using Category 1 message filtering rules is provided. The method includes subscribing at a Network Function (NF) with an NF Repository Function (NRF) to receive notifications of NF profile changes. The method further includes receiving, from the NRF, notifications of the NF profile changes as a result of the subscribing. The method further includes automatically configuring at least one Category 1 message filtering rule based on the notifications of the NF profile changes. The method further includes performing Category 1 message filtering of Service-Based Interface (SBI) messages using the at least one Category 1 message filtering rule at the NF.

[0014] According to another aspect of the subject matter described herein, the NF includes a Security Edge Protection Proxy (SEPP).

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

[0016] According to another aspect of the subject matter described herein, subscribing to the NRF includes sending an nfStatusSubscribe message to the NRF.

[0017] According to another aspect of the subject matter described herein, receiving notification of an NF profile change includes receiving an nfStatusNotify message including the NF profile.

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

[0019] According to another aspect of the subject matter described herein, the NF profile includes an authentication attribute, and automatically configuring the at least one Category 1 message filtering rule includes adding or updating the Category 1 message filtering rule to allow SBI messages including a Hypertext Transfer Protocol (HTTP) method that corresponds to an allowed scope of the entity defined in the authentication attribute.

[0020] According to another aspect of the subject matter described herein, an authorization attribute scope specifies an entity's permitted operations.

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

[0022] According to another aspect of the subject matter described herein, filtering SBI messages using Category 1 message filtering rules includes allowing or blocking SBI messages arriving at 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.

[0023] According to another aspect of the subject matter described herein, there is provided a system for automatically configuring and using Category 1 message filtering rules. The system includes a Network Function (NF) including at least one processor and a memory. The system further includes a Category 1 message filtering rule database stored in the memory. The system further includes a Category 1 message filtering rule manager executable by the at least one processor to subscribe with an NF Repository Function (NRF) to receive notifications of NF profile changes, receive from the NRF the notification of the NF profile changes as a result of the subscription, automatically configure at least one Category 1 message filtering rule in the Category 1 message filtering 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 filtering rule.

[0024] According to another aspect of the subject matter described herein, the category 1 message filtering rules manager is configured to subscribe to the NRF by sending an nfStatusSubscribe message to the NRF.

[0025] According to another aspect of the subject matter described herein, a Category 1 message filtering rules manager is configured to receive a notification of an NF profile change in an nfStatusNotify message that includes the NF profile.

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

[0027] According to another aspect of the subject matter described herein, the NF profile includes an authentication attribute, and the Category 1 message filtering rule manager is configured to automatically add or update Category 1 message filtering rules to allow Hypertext Transfer Protocol (HTTP) methods corresponding to an allowed scope of the entity defined in the authentication attribute.

[0028] According to another aspect of the subject matter described herein, a Category 1 message filtering rules manager is configured to allow or block messages arriving at 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.

[0029] According to another aspect of the subject matter described herein, 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 a plurality of steps. The plurality of steps are performed in a Network Function (NF). The plurality of steps include subscribing with an NF Repository Function (NRF) to receive notifications of NF profile changes. The plurality of steps further include receiving, from the NRF as a result of the subscribing, notifications of the NF profile changes. The plurality of steps further include automatically configuring at least one Category 1 message filtering rule based on the notifications of the NF profile changes. The plurality of steps further include filtering Service-Based Interface (SBI) messages using the at least one Category 1 message filtering rule.

[0030] 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 an exemplary embodiment, the subject matter described herein can be implemented using a non-transitory computer-readable medium storing executable instructions that, when executed by a computer processor, control a computer to perform 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. Furthermore, computer-readable media implementing the subject matter described herein can be located on a single device or computing platform or distributed across multiple devices or computing platforms.

[0031] Exemplary embodiments of the subject matter described herein will now be described with reference to the accompanying drawings. [Brief explanation of the drawings]

[0032] [Figure 1] FIG. 1 is a network diagram illustrating an example 5G system network architecture. [Figure 2] 10 is a message flow diagram illustrating manual configuration of category 1 message filtering rules in the SEPP. [Figure 3] 10 is a message flow diagram illustrating the automatic configuration of Category 1 message filtering rules in SEPP by learning topology information from NRF. [Figure 4] 10 is a message flow chart illustrating the automatic configuration of category 1 message filtering rules in SCP by learning topology information from NRF. [Figure 5] FIG. 2 is a block diagram illustrating an example architecture of a SEPP or SCP for performing automatic configuration of category 1 message filtering rules. [Figure 6] 10 is a flowchart illustrating an exemplary process for the automatic configuration and use of category 1 message filtering rules. DETAILED DESCRIPTION OF THE INVENTION

[0033] Detailed Description FIG. 1 is a block diagram illustrating an example 5G system network architecture. The architecture of FIG. 1 includes an NRF 100 and an SCP 101, which may be located in the same Home Public Land Mobile Network (HPLMN). As described above, the NRF 100 maintains profiles of available NF instances and their supported services, allowing consumer NFs or SCPs to subscribe to and be notified of new / updated NF instance registrations. The SCP 101 may also support service discovery and selection of NF instances. The SCP 101 may perform load balancing of connections between consumer NFs and producer NFs.

[0034] The NRF 100 is a repository of profiles of NF instances. 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. An NF profile is a JavaScript Object Notation (JSON) data structure defined in 3GPP TS 29.510. The NF profile contains attributes that indicate the type of service provided, the capacity of the NF instance, and information for contacting the NF instance.

[0035] 1, any of the network functions can be a consumer NF, a producer NF, or both, depending on whether it requests, provides, or both requests and provides a service. In the illustrated example, the NFs include a Policy Control Function (PCF) 102 that performs policy-related operations within the network, a Unified Data Management Function (UDM) 104 that manages user data, and an Application Function (AF) 106 that provides application services.

[0036] 1 further includes a Session Management Function (SMF) 108 that manages sessions between an Application and Mobility Management Function (AMF) 110 and the PCF 102. The AMF 110 performs mobility management operations similar to those performed by a Mobility Management Entity (MME) in 4G networks. An Authentication Server Function (AUSF) 112 performs authentication services for user equipment (UE), such as user equipment (UE) 114, that seeks access to the network.

[0037] The Network Slice Selection Function (NSSF) 116 provides network slice services to devices that want to access specific network capabilities and features associated with a network slice. The Network Exposure Function (NEF) 118 provides an application programming interface (API) to application functions that want to obtain information about Internet of Things (IoT) devices and other UEs connected to the network. The NEF 118 performs functions similar to the Service Capability Exposure Function (SCEF) in 4G networks.

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

[0039] The SEPP 126 filters incoming traffic from other PLMNs and performs topology hiding for traffic egressing from the home PLMN. The SEPP 126 may communicate with an SEPP of a foreign PLMN that manages security for the foreign PLMN. Thus, traffic between NFs in different PLMNs may pass through two SEPP functions: one for the home PLMN and one for the foreign PLMN.

[0040] As mentioned above, one of the current challenges with filtering in 5G and other networks is that manually configuring Category 1 message filtering rules in a SEPP or SCP is labor-intensive and prone to human error. GSMA FS.36 Version 2 Section 3.4.5 proposes Category 1 message filtering with custom operations to secure networks. Category 1 message filtering is based on resource URIs and HTTP method types and can be implemented in the SEPP because it is the entry point to the PLMN. Category 1 message filtering can also be implemented in the SCP because it is the routing node used to deliver messages within the 5G network.

[0041] The subject matter described herein includes a mechanism for automatically configuring Category 1 message filtering in a SEPP or SCP by learning producer NF profiles registered with the NRF and extracting necessary information from the profiles to configure Category 1 message filtering rules, thereby reducing operational overhead and improving security of 5GC networks by reducing the possibility of human error.

[0042] As described above, a producer NF registers an NF profile with the NRF. The NF profile contains authorization attributes that can be used as topology information for configuring 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 the allowedOperationsPerNfType and allowedOperationsPerNfInstance attributes, which define an array of allowed scopes. Scopes, which can be mapped to resource URIs and methods, can be used to create Category 1 message filtering rules. Scopes are defined in the individual API specifications and are described in more detail below. Table 1 below from 3GPP TS 29.510 defines the allowedOperationsPerNfType and allowedOperationsPerNfInstance attributes.

[0043] [Table 1] TIFF2025531735000003.tif180162

[0044] From Table 1, the allowedOperationsPerNfType attribute stores values ​​that define the operations or scopes that are allowed 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 value carried in the message, such as PUT, POST, PATCH, GET, etc. The allowedOperationsPerNfInstance attribute stores values ​​that define the operations or scopes that are allowed 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 value at the NF instance level.

[0045] Other authorization attributes that can be used to define the operations or scopes allowed for an entity include allowedPlmns, allowedNfTypes, allowedNfDomains, allowedNssais, etc. Additionally, there can be vendor-specific (i.e., attributes not defined by 3GPP) attributes that can be defined for authorization. Any authorization attributes specified in an NF profile can be used to automatically provision and / or update Category 1 message filtering rules.

[0046] Below are examples of allowed NF scopes that may be defined for various NF types attempting to access a UDM. The NF Open API specification can be used to define the scopes allowed on interfaces such as the N32 interface that use OAuth2 authentication. Scopes are the access rights that control whether a consumer NF is allowed to make the necessary calls to a producer NF. In the examples below, the values ​​of the keys in the scope map are obscured using three dots for clarity. Additional information on OAuth2 scopes can be found below. https: / / swagger.io / docs / specification / authentication / oauth2 / An example scope is: components: securitySchemes: oAuth2ClientCredentials: type: oauth2 flows: clientCredentials: tokenUrl: '{nrfApiRoot} / oauth2 / token' scopes: nudm-uecm:Access to the nudm-uecm API c:write: ... nudm_uecm:smf-registration:write: ... nudm_uecm:smsf-registration:write: ... nudm_uecm:ip-sm-gw-registration:write: ... nudm_uecm:nwdaf-registration:write: ... In the above example, allowed scopes are defined for different NF types of the nudm-uecm API. The scopes allow write access to the nudm-uecm API for registration procedures for AMF, SMF, Short Message Service Function (SMSF), IP Short Message Gateway (IP-SM-GW), and Network Data Analysis Function (NWDAF). The SEPP or SCP performing the automatic configuration of the Category 1 message filtering rules described herein may map the write access to an HTTP method such as POST so that the identified NF type can send SBI messages containing the HTTP POST method within the PLMN. The following table shows an example of Category 1 message filtering rules that may be automatically configured based on the above allowed OAuth2 scopes.

[0047] [Table 2]

[0048] In Table 2, the Category 1 message filtering rule defined for the nudm-uecm registration API allows HTTP POST operations. It should be understood that any HTTP operation other than those explicitly allowed will be rejected. For example, a message attempting an HTTP GET operation on the nudm_uecm:smf-registration interface will be rejected.

[0049] The configuration of Category 1 message filtering rules needs to be kept synchronized with the resource URIs and HTTP methods supported by producers in the PLMN. This manual procedure is error-prone and increases operational overhead. The configuration of Category 1 message filtering rules in the SEPP needs to be automated to reduce operational overhead. Operators must configure Category 1 message filtering rules, and as NF profile configurations are updated to allow additional operations on an interface, the Category 1 message filtering rules in the SEPP must also be updated. According to aspects of the subject matter described herein, the SEPP subscribes with the NRF for NF profile changes. Any NF profile changes are notified to the SEPP, and upon receiving such notifications, the SEPP creates one or more Category 1 message filtering rules using the scope details provided in the NF profile.

[0050] Before describing messaging associated with automatically configuring a Category 1 message filter, exemplary messaging associated with manually configuring a Category 1 message filter will be described with respect to Figure 2. Referring to Figure 2, in line 1, a user manually configures NF profiles for NF producers 200 and 202 and also manually configures Category 1 message filtering rules for NF producers 200 and 202 in SEPP 126.

[0051] In line 2, the NF producer 202 sends an NF registration request to the NRF 100 to register the NF profile with the NRF 100. If the NF registration service operation is successful, the NRF 100 responds with a 201 Created message in line 3.

[0052] In line 4, the NF producer 200 sends an NF registration request to the NRF 100 and registers the NF profile with the NRF 100. If the NF registration service operation is successful, the NRF 100 responds with a 201 Created message in line 5.

[0053] In line 6, the external PLMN 204 sends an SBI request message requesting service from one of the NFs in the PLMN protected by the SEPP 126. In this example, it is assumed that the message is blocked by a Category 1 message filtering rule. The SEPP 126 responds with an SBI response message indicating that the message was blocked, as shown in line 7.

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

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

[0056] In line 4, the NF producer 202 sends an NF registration request to the NRF 100 to register the NF profile with the NRF 100. If the NF registration service operation is successful, the NRF 100 responds with a 201 Created message in line 5.

[0057] In line 6, the NF producer 200 sends an NF registration request to the NRF 100 and registers the NF profile with the NRF 100. If the NF registration service operation is successful, the NRF 100 responds with a 201 Created message in line 7.

[0058] In line 8, the NRF 100 sends an nfStatusNotify message to the SEPP 126 to notify the SEPP 126 of the NF profile registration. The 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 allowed information per NF type parameter, the SEPP 126 may automatically create Category 1 message filtering rules to allow the specified operations for the identified NF type.

[0059] In line 6, the NF producer 200 sends an NF registration request to the NRF 100 and registers the NF profile with the NRF 100. If the NF registration service operation is successful, the NRF 100 responds with a 201 Created message in line 7.

[0060] In line 8, the NRF 100 sends an nfStatusNotify message to the SEPP to notify the SEPP 126 of the NF profile registration. The SEPP 126 receives the nfStatusNotify message, reads the NF profile information from the NfStatusNotify message, and automatically creates Category 1 message filtering rules based on the NF profile information. For example, if the NF profile information includes an allowedOperationsPerNfType attribute defined for either the producer NF 200 or 202, the SEPP 126 may automatically create one or more Category 1 message filtering rules that allow the specified operations for the identified NF type. In line 9, the SEPP 126 responds to the notification request with a 200 OK message.

[0061] In line 10, the external PLMN 204 sends an SBI request message requesting service from one of the NFs in the PLMN protected by the SEPP 126. In this example, it is assumed that the message is blocked by a Category 1 message filtering rule. The SEPP 126 responds with an SBI response message indicating that the message was blocked, as shown in line 11.

[0062] In line 12, the operator updates the profiles of NFs 200 and 202. NFs 200 and 202 update their profiles with NRF 100 using the NFUpdate service operation (not shown in FIG. 3 ). In line 13, NRF 100 sends an nfStatusNotify request message containing the updated NF profile information to SEPP 126. In response to receiving the updated NF profile information, SEPP 126 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 further allow operations for an NF type or NF instance, SEPP 126 may add the corresponding message filtering rule to its database of Category 1 message filtering rules and allow HTTP messages of the corresponding HTTP method type. In line 14, SEPP 126 responds to the notify request message of line 13.

[0063] The subject matter described herein is not limited to automatically configuring and using Category 1 message filtering rules in a SEPP. In an alternative embodiment, an SCP may automatically configure and use Category 1 message filtering rules. FIG. 4 is a message flow diagram illustrating the automatic configuration of Category 1 message filtering rules in an SCP by learning topology information from an NRF. Referring to FIG. 4, in line 1, a network operator manually configures NF profiles for NF producers 200 and 202. In line 2, the SCP 101 sends an nfStatusSubscribe message to the NRF 100 to subscribe to receive notifications of changes to the NF profiles maintained by the NRF 100. In line 3, the NRF 100 responds with a 201 Created message indicating successful creation of the subscription.

[0064] In line 4, the NF producer 202 sends an NF registration request to the NRF 100 to register the NF profile with the NRF 100. If the NF registration service operation is successful, the NRF 100 responds with a 201 Created message in line 5.

[0065] In line 6, the NF producer 200 sends an NF registration request to the NRF 100 and registers the NF profile with the NRF 100. If the NF registration service operation is successful, the NRF 100 responds with a 201 Created message in line 7.

[0066] In line 8, the NRF 100 sends an nfStatusNotify message to the SCP 101 to notify the SCP 101 of the NF profile registration. The SCP 101 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 information includes an allowedOperationsPerNfType attribute, the SCP 101 may automatically create one or more Category 1 message filtering rules to allow the specified operations for the identified NF type.

[0067] In line 6, the NF producer 200 sends an NF registration request to the NRF 100 and registers the NF profile with the NRF 100. If the NF registration service operation is successful, the NRF 100 responds with a 201 Created message in line 7.

[0068] In line 8, the NRF 100 sends an nfStatusNotify message to the SCP 101, notifying the SCP 101 of the NF profile registration in line 6. The SCP 101 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 an allowedOperationsPerNfType attribute, the SCP 101 may automatically create Category 1 message filtering rules to allow the specified operations for the identified NF type. In line 9, the SCP 101 responds to the notification request with a 200 OK message.

[0069] In line 10, the external PLMN 204 sends an SBI request message requesting service from one of the NFs in the PLMN protected by the SEPP 126. In line 11, the SEPP 126 forwards the message to the SCP 101 for routing within the PLMN. The 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 presence of a Category 1 message filtering rule with an action of "allow"). The SCP 101 responds with an SBI response message indicating that the message was blocked, as shown in line 12. In line 13, the SEPP 126 sends the response to the external PLMN 204.

[0070] In line 14, the operator updates the profiles of NFs 200 and 202. NFs 200 and 202 update their profiles with NRF 100 using the NFUpdate service operation (not shown in FIG. 4). In line 15, NRF 100 sends 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 further allow operations for an NF type or NF instance, SCP 101 may add the corresponding message filtering rule to its database of Category 1 message filtering rules and allow HTTP messages of the corresponding method type. In line 16, SCP 101 responds to the notification message in line 15.

[0071] 5 is a block diagram illustrating an example architecture of a SEPP or SCP for performing automatic configuration of Category 1 message filtering rules. In FIG. 5, the SEPP or SCP 126 or 101 includes at least one processor 500 and memory 502. The SEPP or SCP 126 or 101 further includes a Category 1 message filtering rule database 504, which may be stored in memory 502. The SEPP or SEPP 126 or 101 further includes a Category 1 message filtering rule manager 506 that subscribes with the NRF to receive notifications of NF profile updates, automatically generates Category 1 message filtering rules, and performs the steps described herein to filter SBI messages using the rules. In one example, the Category 1 message filtering rule manager 506 may be implemented using computer-executable instructions stored in memory 502 and executed by the processor 500.

[0072] 6 is a flowchart illustrating an example process for automatic configuration of Category 1 message filtering rules using topology information learned from an NRF. Referring to FIG. 6, in step 600, the process includes, at an NF, subscribing with the NRF to receive notifications of NF profile changes. For example, the SEPP 126 or SCP 101 may send 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 may subscribe to receive notifications of NF profile changes for all producer NFs in a PLMN.

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

[0074] In step 604, the process includes automatically configuring at least one Category 1 message filtering rule implemented in the NF based on the notification of the NF profile change. For example, the SEPP 126 or SCP 101 can extract the allowed scope from allowedOperationsPerNfType, allowedOperationsPerNfInstance, or other authentication attributes and generate a Category 1 message filtering rule to allow messages with the defined scope for the authenticated entity. For example, if the allowed scope is write access to the AMF on a given interface, the Category 1 message filtering rule may indicate that an HTTP POST, PUT, or PATCH method is allowed for NF type=AMF.

[0075] In step 606, the process includes filtering the SBI message at the NF using at least one Category 1 message filtering rule. For example, the SEPP 126 or SCP 101 may receive the SBI request and compare the SBI request's NF instance and / or NF type information and HTTP method type with the Category 1 message filtering rules. When the SEPP 126 or SCP 101 detects a match between the SBI request message parameters and one of the rules, the SEPP 126 or SCP 101 may execute the corresponding rule action and allow or block the message.

[0076] Example advantages of the subject matter described herein include reduced operational overhead over manual Category 1 message filtering rule configuration. Category 1 message filtering rules are automatically kept synchronized with the resource URIs and HTTP method types provided by the producer NF. 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 an existing 3GPP service operation, making it easy to implement.

[0077] The disclosure of each of the following documents is incorporated herein by reference in its entirety: References 1.3 rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; 5G System; Network Function Repository Services; Stage 3 (Release 17) 3GPP TS 29.510 V17.6.0 (2022-06)' twenty three rd Generation Partnership Project; Technical Specification Group Services and System Aspects; System architecture for the 5G System (5GS); Stage 2; (Release 17) 3GPP TS 23.501 V17.5.0 (2022-06) 3.3 rdGeneration Partnership Project; Technical Specification Group Services and System Aspects; Procedures for the 5G System (5GS); Stage 2; (Release 17) 3GPP TS 23.502 V17.5.0 (2022-06) 4.3 rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; 5G System, Public Land Mobile Network (PLMN) Interconnection; Stage 3 (Release 17) 3GPP TS 29.573v17.5.0 (2022-06) 5. 5G Interconnect Security, Version 2.0 GSMA FS.36 (3 June 2021) 6. OAuth2.0; https: / / swagger.io / docs / specification / authentication / oauth2 / (2022). It will be understood that various details of the subject matter described herein may be changed without departing from the scope of the subject matter described herein. Moreover, the foregoing description is by way of example only, and not by way of limitation, as the subject matter described herein is defined by the claims set forth below.

Claims

1. 1. A method for automated configuration and use of Category 1 message filtering rules, said method comprising: In the network function (NF), Subscribing with an NF Repository Function (NRF) to receive notifications of NF profile changes; receiving notification of an NF profile change from the NRF as a result of the subscribing; automatically configuring at least one Category 1 message filtering rule based on the notification of the NF profile change; and at the NF, filtering Service Based Interface (SBI) messages using the at least one Category 1 message filtering rule.

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. 10. The method of claim 1, wherein the subscribing with the NRF comprises sending an nfStatusSubscribe message to the NRF.

5. 10. The method of claim 1, wherein receiving notification of an NF profile change comprises receiving an nfStatusNotify message including an NF profile.

6. 10. The method of claim 1, wherein receiving notification of the NF profile change comprises receiving the notification in response to an NFRegister, NFUpdate, or NFDeregister service operation.

7. 10. The method of claim 1, wherein the NF profile includes an authentication attribute, and wherein automatically configuring the at least one Category 1 message filtering rule includes adding or updating a Category 1 message filtering rule to allow SBI messages that include a Hypertext Transfer Protocol (HTTP) method that corresponds to an allowed scope of an entity defined in the authentication attribute.

8. The method of claim 7 , wherein the scope defines operations permitted for the entity.

9. 10. The method of claim 1, wherein automatically configuring 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. 10. The method of any one of the preceding claims, wherein using Category 1 message filtering rules to filter SBI messages includes allowing or blocking messages arriving at a public land mobile network (PLMN) based on Hypertext Transfer Protocol (HTTP) method type and resource Uniform Resource Identifier (URI) parameters in the messages.

11. 1. A system for automated configuration and use of Category 1 message filtering rules, said system comprising: a network function (NF) including at least one processor and a memory; a category 1 message filtering rules database stored in said memory; a Category 1 message filtering rule manager executable by the at least one processor to subscribe with a NF Repository Function (NRF) to receive notifications of NF profile changes, receive notifications of NF profile changes from the NRF as a result of the subscribing, automatically configure at least one Category 1 message filtering rule in the Category 1 message filtering 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 filtering rule; Including, the system.

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 sending an nfStatusSubscribe message to the NRF.

15. The system of any one of claims 11 to 14, wherein the Category 1 message filtering rules manager is configured to receive the notification of the NF profile change in an nfStatusNotify message that includes the NF profile.

16. The system of any one of claims 11 to 15, wherein the Category 1 message filtering rule manager is configured to receive the notification of the NF profile change in response to an NFRegister, NFUpdate, or NFDeregister service operation.

17. The system of any one of claims 11 to 16, wherein the NF profile includes an authentication attribute, and the Category 1 message filtering rule manager is configured to automatically add or update Category 1 message filtering rules to allow SBI messages that include a Hypertext Transfer Protocol (HTTP) method that corresponds to an allowed scope of an entity defined in the authentication attribute.

18. The system of claim 17 , wherein the scope defines operations permitted for the entity.

19. 19. The method of claim 11, wherein the Category 1 message filtering rules manager is configured to allow or block messages arriving at a public land mobile network (PLMN) based on Hypertext Transfer Protocol (HTTP) method type and resource Uniform Resource Identifier (URI) parameters in the message.

20. A non-transitory computer-readable medium storing executable instructions that, when executed by a processor of a computer, cause the computer to perform a number of steps, the number of steps including: In the network function (NF), Subscribing with an NF Repository Function (NRF) to receive notifications of NF profile changes; receiving notification of an NF profile change from the NRF as a result of the subscribing; automatically configuring at least one Category 1 message filtering rule based on the notification of the NF profile change; and filtering Service Based Interface (SBI) messages using the at least one Category 1 message filtering rule.

Images