A method, system, and computer-readable medium for automatically setting Category 1 message filtering rules by learning topology information from 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] Claims of Priority This application claims the benefit of priority of U.S. Patent Application No. 17 / 902,531, filed on September 2, 2022, the disclosure of which is incorporated herein by reference in its entirety.

[0002] Technical Field The subject matter described herein relates to automatically setting Category 1 message filtering rules. More particularly, the subject matter described herein relates to methods, systems, and computer-readable media for automatically setting Category 1 message filtering rules by learning topology information from an NRF.

Background Art

[0003] Background In a 5G communication network, network functions that provide services are called producer NFs or NF service producers. Network functions that consume services are called 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 consuming and producing services. The terms "producer NF" and "NF service producer" are used herein to have the same meaning. Similarly, the terms "consumer NF" and "NF service consumer" are used herein to have the same meaning.

[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. Service endpoints are identified by a combination of an Internet Protocol (IP) address and port number, or by 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 the producer NF that provides a service. A given producer NF may contain multiple NF instances. It should also be noted that multiple NF instances can share the same service endpoint.

[0005] An NF registers with the Network Functional Repository (NRF). The NRF maintains a profile of available NF instances, identifying the services supported by each NF instance. This NF instance profile is referred to as an NF profile in 3GPP® TS 29.510. An NF instance can obtain information about other NF instances registered with the NRF through an NF discovery service operation. Following the NF discovery service operation, a consumer NF sends an NF discovery request to the NRF. The NF discovery request includes query parameters, which the NRF uses to find the NF profiles of producer NFs capable of providing 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, as well as contact and capacity information about the NF instance.

[0006] A Service Communications 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, this is called delegated discovery. The consumer NF connects to the SCP, which load balances the traffic among producer NF service instances that provide the required services, or routes the traffic directly to the desired producer NF instance.

[0007] In addition to SCPs, another example of an intermediate proxy that forwards traffic between producer and consumer NFs is the Security Edge Protection Proxy (SEPP). SEPP is a network function used to protect control plane traffic exchanged between different 5G public land mobile communication networks (PLMNs). Therefore, SEPP performs message filtering, policing, and topology concealment on all application programming interface (API) messages sent between PLMNs. [Overview of the Initiative] [Problems that the invention aims to solve]

[0008] One of the problems that can arise with 5G and other types of networks is the need for Category 1 message filtering in SEPP or SCP, and the manual configuration of Category 1 message filtering rules is laborious 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 in custom operation screening within N32fReformattedReqMsg and N32fRefirnatttedRespMsg to secure 5GC networks. FS.36 defines Category 1 message filtering as malicious packet filtering at the interface level (see Section 3.4.3). The purpose of Category 1 message filtering is to prevent unauthorized access from the outside to the internal interface. Messages that can be filtered using Category 1 message filtering rules in SEPP or SCP include service-based interface (SBI) messages requesting access to services provided by the NF.

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

[0010] Whitelists can be deployed at various levels of precision. For example, they 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 higher the precision of the whitelist, the more difficult it is to launch an attack. More precise filtering requires more detailed management.

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

[0012] Therefore, in light of these problems and other difficulties, improved methods, systems, and computer-readable media are needed for setting Category 1 message filtering rules. [Means for solving the problem]

[0013] overview A method is provided for the automatic configuration and use of Category 1 message filtering rules. This method includes subscribing to the NF Repository (NRF) in a Network Function (NF) to receive notifications of NF profile changes. This method further includes receiving notifications of NF profile changes from the NRF as a result of the subscription. This method further includes automatically configuring at least one Category 1 message filtering rule based on the notifications of NF profile changes. This method further includes performing Category 1 message filtering of service-based interface (SBI) messages in the NF using at least one Category 1 message filtering rule.

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

[0015] According to another aspect of the subject matter described herein, NF includes a Service Communications Proxy (SCP).

[0016] According to another aspect of the subject matter described herein, subscribing to an 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 containing 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, an NF profile includes authentication attributes, and automatically setting at least one Category 1 message filtering rule includes adding or updating a Category 1 message filtering rule to allow SBI messages containing Hypertext Transfer Protocol (HTTP) methods corresponding to the permitted scope of entities defined in the authentication attributes.

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

[0021] According to another aspect of the subject matter described herein, automatically setting up at least one Category 1 message filtering rule includes automatically adding a 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 involves permitting or blocking SBI messages arriving at a public land mobile network (PLMN) based on the hypertext transfer protocol (HTTP) method type and resource uniform resource identifier (URI) parameters within the messages.

[0023] According to another aspect of the subject matter described herein, a system for automatic configuration and use of Category 1 message filtering rules is provided. The system includes a network function (NF) including at least one processor and memory. The system further includes a Category 1 message filtering rule database stored in the memory. The system further subscribes using a network function repository function (NRF) to receive notifications of NF profile changes, receives from the NRF, as a result of the subscription, notifications of NF profile changes, automatically configures at least one Category 1 message filtering rule within the Category 1 message filtering rule database based on the notifications of NF profile changes, and includes a Category 1 message filtering rule manager executable by at least one processor for filtering service-based interface (SBI) messages using at least one Category 1 message filtering rule.

[0024] According to another aspect of the subject matter described herein, the Category 1 message filtering rule 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, the Category 1 message filtering rule manager is configured to receive notifications of NF profile changes within an nfStatusNotify message including 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 notifications of NF profile changes in response to NFRegister, NFUpdate, or NFDeregister service operations.

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

[0028] According to another aspect of the subject matter described herein, the Category 1 message filtering rule manager is configured to permit or block messages arriving at a Public Land Mobile Network (PLMN) based on the Hypertext Transfer Protocol (HTTP) method type and resource Uniform Resource Identifier (URI) parameters within the message.

[0029] According to another aspect of the subject matter described herein, a non-temporary computer-readable medium is provided which stores executable instructions that, when executed by the computer's processor, control the computer to perform multiple steps. These multiple steps are performed in a network function (NF). These multiple steps include subscribing to an NF repository function (NRF) to receive notifications of NF profile changes. These multiple steps further include receiving notifications of NF profile changes from the NRF as a result of subscribing. These multiple steps further include automatically setting at least one category 1 message filtering rule based on the notifications of NF profile changes. These multiple steps further include filtering service-based interface (SBI) messages using 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 one exemplary embodiment, the subject matter described herein can be implemented using a non-temporary computer-readable medium that stores executable instructions that control the computer to perform steps when executed by a computer processor. Exemplary computer-readable mediums suitable for implementing the subject matter described herein include non-temporary computer-readable media such as disk memory devices, chip memory devices, programmable logic devices, and application-specific integrated circuits. Furthermore, the computer-readable medium for implementing the subject matter described herein may be located on a single device or computing platform, or distributed across multiple devices or computing platforms.

[0031] Next, exemplary embodiments of the subject matter described herein will be explained with reference to the accompanying drawings. [Brief explanation of the drawing]

[0032] [Figure 1] This is a network diagram illustrating an exemplary 5G system network architecture. [Figure 2] This is a message flowchart demonstrating the manual configuration of Category 1 message filtering rules in SEPP. [Figure 3] This message flowchart demonstrates the automatic configuration of Category 1 message filtering rules in SEPP by learning topology information from NRF. [Figure 4] This message flowchart demonstrates the automatic configuration of Category 1 message filtering rules in SCP by learning topology information from NRF. [Figure 5] This block diagram shows an exemplary architecture for SEPP or SCP to perform automatic configuration of Category 1 message filtering rules. [Figure 6] This flowchart illustrates an exemplary process for automatically configuring and using Category 1 message filtering rules. [Modes for carrying out the invention]

[0033] Detailed explanation Figure 1 is a block diagram illustrating an exemplary 5G system network architecture. The architecture in Figure 1 includes an NRF100 and an SCP101, which may be located on the same Home Public Land Mobile Communications Network (HPLMN). As described above, the NRF100 maintains profiles of available NF instances and their supported services, and can enable consumer NFs or SCPs to subscribe to registrations of new / updated NF instances and be notified about them. The SCP101 may also support service discovery and selection of NF instances. The SCP101 may perform load balancing of connections between consumer NFs and producer NFs.

[0034] NRF100 is a repository of NF instance profiles. To communicate with a producer NF instance, a consumer NF or SCP must obtain the producer NF instance's NF profile from NRF100. An NF profile is a JavaScript object notation (JSON) data structure defined in 3GPP TS 29.510. An NF profile includes attributes indicating the type of service provided, the capacity of the NF instance, and information for contacting the NF instance.

[0035] In Figure 1, any of the network functions can be a consumer NF, a producer NF, or both, depending on whether they request, provide, or both request and provide services. In the illustrated example, the NF includes 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] The NF shown in Figure 1 further includes a Session Management Function (SMF) 108 that manages sessions between the 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 a 4G network. The Authentication Server Function (AUSF) 112 performs authentication services for user devices (UEs), such as user devices (UEs) 114, that request access to the network.

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

[0038] The Wireless Access Network (RAN) 120 connects the User Equipment (UE) 114 to the network via a wireless link. The Wireless Access Network 120 may also be accessed using a g-Node B (gNB) or other wireless access point (not shown in Figure 1). The User Plane Function (UPF) 122 can support various proxy functions for user plane services. One example of such a proxy function is the Multipath Forwarding Control Protocol (MPTCP) proxy function. The UPF 122 may support performance measurement functions that the UE 114 can use to obtain network performance measurements. Figure 1 also shows the Data Network (DN) 124 through which the UE accesses data network services such as Internet services.

[0039] SEPP126 filters incoming traffic from other PLMNs and performs topology concealment for traffic leaving the home PLMN. SEPP126 may communicate with the SEPP of the external PLMN, which manages the security of the external PLMN. Therefore, traffic between NFs of different PLMNs may pass through two SEPP functions: one for the home PLMN and one for the external PLMN.

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

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

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

[0043] [Table 1] TIFF0007870403000002.tif180162

[0044] As shown in Table 1, the allowedOperationsPerNfType attribute stores a value that defines the operations or scope allowed for a given NF type. Such attribute values ​​can be used in Category 1 message filtering rules that filter SBI messages based on HTTP method attribute values ​​transmitted in messages such as PUT, POST, PATCH, and GET. The allowedOperationsPerNfInstance attribute stores a value that defines the operations or scope allowed for an NF instance. These values ​​can also be used in Category 1 message filtering rules that filter SBI messages based on HTTP method attribute values ​​at the NF instance level.

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

[0046] The following are examples of permitted NF scopes that can be defined for various NF types attempting to access a UDM. The NF Open API specification can be used to define permitted scopes on interfaces such as the N32 interface, which uses OAuth2 authentication. Scopes are access rights that control whether a consumer NF is allowed to perform the necessary calls to a producer NF. In the following examples, the key values ​​in the scope map are hidden using three dots for clarity. Additional information on OAuth2 scopes can be found below. https: / / swagger.io / docs / specification / authentication / oauth2 / Examples of scopes are as follows: components: securitySchemes: oAuth2ClientCredentials: type: oauth2 flows: rentalCredentials: 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 example above, the permitted scopes are defined for different NF types in the nudm-uecm API. The scopes grant 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). SEPP or SCP performing automatic configuration of the Category 1 message filtering rules described herein may map write access to HTTP methods such as POST so that the identified NF types can send SBI messages containing the HTTP POST method within PLMN. The following table shows examples of Category 1 message filtering rules that can be automatically configured based on the permitted OAuth2 scopes described above.

[0047] [Table 2]

[0048] In Table 2, the Category 1 message filtering rules defined for the nudm-uecm registration API allow HTTP POST operations. HTTP operations other than those explicitly permitted will be rejected. For example, messages attempting HTTP GET operations on the nudm_uecm:smf-registration interface will be rejected.

[0049] The configuration of Category 1 message filtering rules must be kept in sync with the resource URIs and HTTP methods supported by the PLMN producer. Manual procedures are prone to errors and increase operational overhead. Automating the configuration of Category 1 message filtering rules in SEPP should reduce operational overhead. Operators must configure Category 1 message filtering rules, and when NF profile settings are updated and additional operations are permitted on the interface, the Category 1 message filtering rules in SEPP must also be updated. According to aspects of the subject matter described herein, SEPP subscribes to changes in the NF profile using NRF. All changes in the NF profile are notified to SEPP, and upon receiving such notification, SEPP creates one or more Category 1 message filtering rules using the scope details provided in the NF profile.

[0050] Before describing the messaging related to the automatic configuration of Category 1 message filters, we will describe the exemplary messaging related to the manual configuration of Category 1 message filters with reference to Figure 2. Referring to Figure 2, the first line shows that the user manually configures the NF profiles for NF producers 200 and 202, and also manually configures the Category 1 message filtering rules for NF producers 200 and 202 in SEPP126.

[0051] In the second line, NF Producer 202 sends an NF registration request to NRF100 to register the NF profile with NRF100. If the NF registration service operation is successful, NRF100 responds with the 201 Created message in the third line.

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

[0053] In line 6, the external PLMN204 sends an SBI request message requesting service from one of the NFs within the PLMN protected by SEPP126. In this example, it is assumed that the message is blocked by a Category 1 message filtering rule. SEPP126 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 for NF producers 200 and 202. The network operator is also required to manually update the Category 1 message filtering rules based on the changes to the NF profiles. Such manual configuration of Category 1 message filtering rules is error-prone and therefore undesirable.

[0055] Figure 3 is a message flowchart illustrating the automatic configuration of Category 1 message filtering rules in SEPP by learning topology information from the NRF. Referring to Figure 3, in the first line, the operator configures NF200 and 202 using the NF profile. In the second line, SEPP126 sends an nfStatusSubscribe message to NRF100 to subscribe to receive notifications of changes to the NF profile held by NRF100. In the third line, NRF100 responds with a 201 Created message indicating successful subscription creation.

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

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

[0058] In line 8, NRF100 sends an nfStatusNotify message to SEPP126 to notify SEPP126 of the NF profile registration. SEPP126 receives the nfStatusNotify message, reads the NF profile information from the message, and automatically creates one or more Category 1 message filtering rules based on the NF profile information. For example, if the NF profile contains information that is permitted for each NF type parameter, SEPP126 may automatically create Category 1 message filtering rules to permit the specified operations for the identified NF types.

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

[0060] In line 8, NRF100 sends an nfStatusNotify message to SEPP to notify SEPP126 of the NF profile registration. SEPP126 receives the nfStatusNotify message, reads the NF profile information from the message, 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 NF200 or 202, SEPP126 may automatically create one or more Category 1 message filtering rules that allow the specified operations for the identified NF type. In line 9, SEPP126 responds to the notification request with a 200 OK message.

[0061] In line 10, the external PLMN204 sends an SBI request message requesting service from one of the NFs within the PLMN protected by SEPP126. In this example, it is assumed that the message is blocked by a Category 1 message filtering rule. SEPP126 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 NF200 and 202. NF200 and 202 update their profiles using NRF100 with the NFUpdate service operation (not shown in Figure 3). In line 13, NRF100 sends an nfStatusNotify request message containing the updated NF profile information to SEPP126. In response to receiving the updated NF profile information, SEPP126 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 authorization operations for an NF type or NF instance, SEPP126 may add the corresponding message filtering rule to the Category 1 message filtering rule database and authorize HTTP messages of the corresponding HTTP method type. In line 14, SEPP126 responds to the notification request message in line 13.

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

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

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

[0066] In line 8, NRF100 sends an nfStatusNotify message to SCP101 to notify SCP101 of the NF profile registration. SCP101 receives the nfStatusNotify message, reads the NF profile information from the 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 the allowedOperationsPerNfType attribute, SCP101 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, NF Producer 200 sends an NF registration request to NRF100 and registers the NF profile with NRF100. If the NF registration service operation is successful, NRF100 responds with the 201 Created message in line 7.

[0068] In line 8, NRF100 sends an nfStatusNotify message to SCP101 to notify SCP101 of the NF profile registration in line 6. SCP101 receives the nfStatusNotify message, reads the NF profile information from the 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 the allowedOperationsPerNfType attribute, SCP101 may automatically create a Category 1 message filtering rule to allow the specified operation for the identified NF type. In line 9, SCP101 responds to the notification request with a 200 OK message.

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

[0070] In line 14, the operator updates the profiles of NF200 and 202. NF200 and 202 update their profiles using NRF100 with the NFUpdate service operation (not shown in Figure 4). In line 15, NRF100 sends an nfStatusNotify request message containing the updated NF profile information to SCP101. In response to receiving the updated NF profile information, SCP101 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 authorization operations for an NF type or NF instance, SCP101 may add the corresponding message filtering rule to the Category 1 message filtering rule database and authorize HTTP messages of the corresponding method type. In line 16, SCP101 responds to the notification message in line 15.

[0071] 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. In Figure 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 which subscribes using 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] Figure 6 is a flowchart illustrating an exemplary process for automatically configuring Category 1 message filtering rules using topology information learned from the NRF. Referring to Figure 6, in step 600, the process includes subscribing to the NRF in an NF to receive notifications of NF profile changes. For example, SEPP126 or SCP101 may send an nfStatusSubscribe message to NRF100 containing subscription data for the NF or NF group that SEPP126 or SCP101 wishes to receive notifications of NF profile changes. In one example, SEPP126 or SCP101 may subscribe to receive notifications of NF profile changes for all producer NFs in the PLMN.

[0073] In step 602, the process further includes receiving notification of NF profile changes from the NRF as a result of the subscription. For example, SEPP126 or SCP101 may receive an nfStatusNotify request from NRF100 in response to an NFRegister, NFUpdate, or NFDeregister service operation performed by an NF in the PLMN. The nfStatusNotify request may contain new or updated NF profile information for an NF or NF group.

[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, SEPP126 or SCP101 may extract the allowed scope from allowedOperationsPerNfType, allowedOperationsPerNfInstance, or other authentication attributes, generate a Category 1 message filtering rule, and 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 HTTP POST, PUT, or PATCH methods are allowed for NF type=AMF.

[0075] In step 606, the process includes filtering SBI messages in the NF using at least one Category 1 message filtering rule. For example, SEPP126 or SCP101 may receive an SBI request and compare the NF instance and / or NF type information and HTTP method type of the SBI request with a Category 1 message filtering rule. If SEPP126 or SCP101 finds a match between the SBI request message parameters and one of the rules, SEPP126 or SCP101 may perform the corresponding rule action to allow or block the message.

[0076] Exemplary advantages of the subject matter described herein include reduced operational overhead compared to manual configuration of Category 1 message filtering rules. Category 1 message filtering rules remain automatically 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 the ease of implementation, as obtaining updated Category 1 message filtering rules through the nfStatusSubscribe service operation is an existing 3GPP service operation.

[0077] Each of the disclosures in 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 modified without departing from the scope of the subject matter described herein. Furthermore, since the subject matter described herein is defined by the claims set forth below, the foregoing description is for illustrative purposes only and not intended to limit it.

Claims

1. A method for automatically setting and using Category 1 message filtering rules, wherein the method is: In network functions (NF), To receive notifications of changes to the NF profile, subscribe using the NF Repository function (NRF), As a result of the subscription, the NRF will receive notification of changes to the NF profile, Based on the notification of the change in the NF profile, at least one Category 1 message filtering rule is automatically set. A method comprising filtering Filter Service-Based Interface (SBI) messages in the NF using the at least one Category 1 message filtering rule.

2. The method according to claim 1, wherein the NF includes a Security Edge Protection Proxy (SEPP).

3. The method according to claim 1, wherein the NF includes a service communication proxy (SCP).

4. The method according to any one of claims 1 to 3, wherein the subscription using the NRF includes sending an nfStatusSubscribe message to the NRF.

5. The method according to any one of claims 1 to 3, wherein receiving notification of a change in the NF profile includes receiving an nfStatusNotify message containing the NF profile.

6. The method according to any one of claims 1 to 3, wherein receiving notification of a change in the NF profile includes receiving the notification in response to an NFRegister, NFUpdate, or NFDregister service operation.

7. The method according to any one of claims 1 to 3, wherein the NF profile includes authentication attributes, and the automatic configuration of 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 corresponding to the authorization scope of the entity defined in the authentication attribute.

8. The method according to claim 7, wherein the scope defines the operations permitted to the entity.

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

10. The method according to any one of claims 1 to 3, wherein filtering SBI messages using a Category 1 message filtering rule includes allowing or blocking messages arriving in a Public Land Mobile Communications Network (PLMN) based on the Hypertext Transfer Protocol (HTTP) method type and Unified Resource Identifier (URI) parameters in the message.

11. A system for the automatic configuration and use of Category 1 message filtering rules, wherein the system is Network functionality (NF) including at least one processor and memory, The Category 1 message filtering rule database stored in the aforementioned memory, A system comprising: a Category 1 message filtering rule manager executable by at least one processor for subscribing to an NF repository function (NRF) to receive notifications of changes to NF profiles; receiving notifications of changes to NF profiles from the NRF as a result of the subscription; automatically setting at least one Category 1 message filtering rule in the Category 1 message filtering rule database based on the notifications of changes to NF profiles; and filtering service-based interface (SBI) messages using the at least one Category 1 message filtering rule.

12. The system according to claim 11, wherein the NF includes a Security Edge Protection Proxy (SEPP).

13. The system according to claim 11, wherein the NF includes a service communication proxy (SCP).

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

15. The system according to any one of claims 11 to 13, wherein the Category 1 message filtering rule manager is configured to receive the notification of a change in the NF profile in an nfStatusNotify message which includes the NF profile.

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

17. The system according to any one of claims 11 to 13, wherein the NF profile includes authentication attributes, and the Category 1 message filtering rule manager is configured to automatically add or update Category 1 message filtering rules and permit SBI messages that include hypertext transfer protocol (HTTP) methods corresponding to the authorization scope of entities defined in the authentication attributes.

18. The system according to claim 17, wherein the scope defines the operations permitted to the entity.

19. The method according to any one of claims 11 to 13, wherein the Category 1 message filtering rule manager is configured to allow or block messages arriving in a public land mobile communications network (PLMN) based on the hypertext transfer protocol (HTTP) method type and resource unified resource identifier (URI) parameters in the message.

20. A computer program for causing a computer processor to execute the method according to any one of claims 1 to 3.

Images