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

Abstract

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

Description

[0001] Priority claim

[0002] This application claims the benefit of priority to U.S. patent application serial number 17 / 902,531, filed on September 2, 2022, the disclosure of which is incorporated herein by reference in its entirety. Technical Field

[0003] 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 NRFs. Background Art

[0004] In 5G telecommunication networks, a network function that provides a service is referred to as a producer NF or NF service producer. A network function that consumes a service is referred to as a consumer NF or 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.

[0005] A given producer NF may 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 may include more than one NF instance. It should also be noted that multiple NF instances may share the same service endpoint.

[0006] NF registers with the Network Function Repository Function (NRF). NRF maintains profiles of available NF instances identifying the services supported by each NF instance. The profile of an NF instance is referred to as NF profile in 3GPP TS29.510. NF instances can obtain information about other NF instances registered with NRF through NF discovery service operations. According to the NF discovery service operation, the consumer NF sends an NF discovery request to the NRF. The NF discovery request includes query parameters, which the NRF uses to locate the NF profile of the producer NF that can provide the service identified by the query parameters. NF profile is a data structure that defines the type of service provided by the NF instance and contact and capacity information about the NF instance.

[0007] The Service Communication Proxy (SCP) can also call NF Discovery service operations to learn about available producer NF instances. The case where SCP uses NF Discovery service operations to obtain information about producer NF instances on behalf of consumer NFs is called delegated discovery. Consumer NFs connect to SCP, and SCP load balances traffic between producer NF service instances that provide the required service or routes traffic directly to the destination producer NF instance.

[0008] In addition to SCP, 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 Networks (PLMNs). Thus, SEPP performs message filtering, policing, and topology hiding on all Application Programming Interface (API) messages transmitted between PLMNs.

[0009] One issue that will arise in 5G and other types of networks is that Category 1 message filtering is required at the SEPP or SCP, and 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 recommends customizing Category 1 message filtering on resource URIs and HTTP methods for action filtering within N32fReformattedReqMsg and N32fRefirnatttedRespMsg to protect 5GC networks. FS.36 defines Category 1 message filtering as unauthorized packet filtering at the interface level (see Section 3.4.3). The purpose of Category 1 message filtering is to prevent unauthorized external access to internal interfaces. Messages that can be filtered using Category 1 message filtering rules at the SEPP or SCP include Service-Based Interface (SBI) messages that seek access to services provided by the NF.

[0010] One approach to Category 1 message filtering is to create a whitelist with specific interfaces as well as resource URIs and HTTP methods / custom actions. The recommended practice for Category 1 filtering is to block all 5G interconnect messages except those explicitly required for a given interface and only allow / activate the required (one or more) interfaces for the mobile network operator (MNO) usage scenario on the SEPP. This also avoids the risk of roaming partners unilaterally extending roaming services or features by using interfaces and sending messages that are 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] Whitelists can be deployed at different levels of precision. For example, whitelists can be deployed based on roaming partners, peer SEPPs, resource URIs, HTTP methods / custom operations, or even based on information element (IE) levels and flags. The more precise the whitelist, the more difficult it is to launch an attack. More precise filtering also requires more detailed management.

[0012] Category 1 message filtering can be implemented at the SEPP since the SEPP is the entry point to the PLMN. One of the challenges is to keep the SEPP configuration in sync 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 of the invention

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

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

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

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

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

[0019] According to another aspect of the subject matter described herein, receiving notification of a NF profile change includes receiving a 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 at least one Category 1 message filtering rule includes adding or updating the Category 1 message filtering rule to allow SBI messages containing a Hypertext Transfer Protocol (HTTP) method corresponding to an allowed scope of an entity defined in the authorization attribute.

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

[0022] According to another aspect of the subject matter described herein, automatically configuring 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.

[0023] According to another aspect of the subject matter described herein, filtering SBI messages using a category 1 message filtering rule includes allowing or blocking SBI messages to 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 filtering rules is provided. The system includes a network function (NF), the network function including at least one processor and a memory. The system also includes a category 1 message filtering rule database stored in the memory. The system also includes a category 1 message filtering rule manager, which can be executed by at least one processor, for subscribing to a 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 in the category 1 message filtering rule database based on the notification of the NF profile change; and using at least one category 1 message filtering rule to filter service-based interface (SBI) messages.

[0025] 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 transmitting an nfStatusSubscribe message to the NRF.

[0026] According to another aspect of the subject matter described herein, a Category 1 message filtering rules manager is configured to receive a notification of a 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 filtering rules manager is configured to receive notification of NF profile changes in response to a 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 filtering rule manager is configured to automatically add or update the category 1 message filtering rule to allow a Hypertext Transfer Protocol (HTTP) method corresponding to an allowed scope of an entity defined in the authorization attribute.

[0029] According to another aspect of the subject matter described herein, a 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 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 executable instructions stored thereon, which when executed by a processor of a computer, controls the computer to perform steps. The steps are performed at a network function (NF). The steps include subscribing to a NF repository function (NRF) to receive notifications of NF profile changes. The steps also include receiving notifications of NF profile changes from the NRF as a result of the subscription. The steps also include automatically configuring at least one category 1 message filtering rule based on the notification of the NF profile change. The steps also include filtering a service-based interface (SBI) message using at least one category 1 message filtering rule.

[0031] The subject matter described herein can be implemented with software combined with hardware and / or firmware. For example, the subject matter described herein can be implemented with software executed by a processor. In an exemplary embodiment, the subject matter described herein can be implemented using a non-transient computer-readable medium having computer executable instructions stored thereon, which controls the computer to perform steps when executed by the processor of the computer. Exemplary computer-readable media suitable for implementing the subject matter described herein include non-transient computer-readable media, such as disk memory devices, chip memory devices, programmable logic devices, and application-specific integrated circuits. In addition, the computer-readable medium implementing the subject matter described herein can be located on a single device or computing platform or can be distributed on multiple devices or computing platforms. BRIEF DESCRIPTION OF THE DRAWINGS

[0032] Exemplary embodiments of the subject matter described herein will now be explained with reference to the accompanying drawings, in which:

[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 filtering 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 an NRF;

[0036] Figure 4 is a message flow diagram illustrating automatic configuration of category 1 message filtering rules at the 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 chart 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 includes NRF 100 and SCP 101, which can be located in the same home public land mobile network (HPLMN). As described above, NRF 100 can maintain profiles of available NF instances and the services they support, and allow consumer NFs or SCPs to subscribe to and be notified of registrations of new / updated NF instances. SCP 101 can also support service discovery and selection of NF instances. SCP 101 can perform load balancing of connections between consumer and producer NFs.

[0040] NRF 100 is a repository for 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 NRF 100. NF profile is a JavaScript Object Notation (JSON) data structure defined in 3GPP TS29.510. NF profile includes attributes indicating the type of service provided, the capacity of the NF instance, and information for contacting the NF instance.

[0041] exist Figure 1 In the example shown, any network function can be a consumer NF, a producer NF, or both, depending on whether they are requesting services, providing services, or requesting and providing services. 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 NF shown in FIG. 1 also includes a session management function (SMF) 108 that manages sessions between applications and a 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. An authentication server function (AUSF) 112 performs authentication services for user equipment (UE) such as user equipment (UE) 114 that seeks to access the network.

[0043] The Network Slice Selection Function (NSSF) 116 provides network slicing services to devices seeking to access specific network capabilities and features associated with a network slice. The Network Exposure Function (NEF) 118 provides an Application Programming Interface (API) for application functions seeking to obtain information about Internet of Things (IoT) devices and other UEs attached to the network. The NEF 118 performs functions similar to the Service Capability Exposure Function (SCEF) in 4G networks.

[0044] Radio access network (RAN) 120 connects user equipment (UE) 114 to the network via wireless links. g-Node B (gNB) ( Figure 1 The UE 114 may use a wireless access point (not shown) or other wireless access point to access the radio access network 120. The user plane function (UPF) 122 may support various proxy functions for user plane services. An example of such a proxy function is a multipath transmission control protocol (MPTCP) proxy function. The UPF 122 may also support a performance measurement function that the UE 114 may use to obtain network performance measurements. Figure 1 Also shown 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 a SEPP in a foreign PLMN that manages the security of the foreign PLMN. Thus, traffic between NFs in different PLMNs can traverse two SEPP functions, one for the home PLMN and the other for the foreign PLMN.

[0046] As mentioned above, one problem 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 because the SEPP is the entry point to the PLMN. Category 1 message filtering can also be implemented at the SCP because the SCP is the routing node used to distribute messages within the 5G network.

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

[0048] As mentioned above, the producer NF registers its NF profile 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 TS29.510 Version 17.5.0 Section 6.1.6.2.3 defines allowedOperationsPerNfType and allowedOperationsPerNfInstance, which define arrays 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 various API specifications and are further detailed below. Table 1 from 3GPP TS29.510 shown below 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 ranges 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 ​​(such as PUT, POST, PATCH, GET, etc.) carried in the message. The allowedOperationsPerNfInstance attribute stores values ​​that define the allowed operations or ranges for a 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.

[0051] Other authorization attributes that can be used to define the allowed operations or scopes of 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 the 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 allowed scopes on interfaces that use OAuth2 authentication, such as the N32 interface. Scopes are access permissions that control whether a consumer NF is allowed to perform a desired call 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 for 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 Analysis Function (NWDAF) registration processes. A SEPP or SCP performing automatic Category 1 message filtering rule configuration as described herein may map write access to HTTP methods such as POST to allow the identified NF types to send SBI messages containing HTTP POST methods in the PLMN. The following table illustrates an example of Category 1 message filtering rules that may be automatically configured based on the above allowed OAuth2 scopes:

[0069] Interface Name (One or more) allowed HTTP methods 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: Example of Category 1 Message Filtering Rules In Table 2, the Category 1 message filtering rule defined for the nudm-uecm registration API allows HTTP POST operations. It is understood that HTTP operations other than those explicitly allowed 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 filtering rule configuration needs to be kept in sync with the resource URIs and HTTP methods supported by the PLMN producer. The manual process is prone to errors and increases operational overhead. There is a need to reduce operational overhead by automating the configuration of Category 1 message filtering rules at the SEPP. The operator must configure the Category 1 message filtering rules, and when the NF profile configuration is updated to add operations allowed on the interface, the Category 1 message filtering rules on the SEPP must also be updated. According to one aspect of the subject matter described herein, the SEPP subscribes to NF profile changes to the NRF. Any changes in the NF profile are communicated to the SEPP, which, upon receipt of such notification, creates one or more Category 1 message filtering rules using the scope details provided in the NF profile.

[0072] Before describing the messaging associated with automatic configuration of Category 1 message filters, Figure 2 Describes exemplary messaging associated with manually configuring a Category 1 message filter. Figure 2 , in row 1, the user manually configures the NF profiles of NF producers 200 and 202, and also manually configures the Category 1 message filtering rules for NF producers 200 and 202 using SEPP 126.

[0073] In line 2, the NF Producer 202 transmits a NF Registration Request to the NRF 100 to register its NF profile to 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 a NF Registration Request to the NRF 100 to register its NF profile to 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 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 the category 1 message filtering rule. The SEPP 126 responds as indicated in line 7 with an SBI response message indicating that the message has been blocked.

[0076] In row 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 changes to the NF profiles. Such manual configuration of Category 1 message filtering 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. Figure 3 , in line 1, the operator configures NFs 200 and 202 with their NF profiles. In line 2, SEPP 126 transmits an 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 201Created message indicating the successful creation of the subscription.

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

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

[0080] In line 8, the NRF 100 transmits 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 permission information for each NF type parameter, the SEPP 126 may automatically create a Category 1 message filtering rule to allow a specified operation to be performed for the identified NF type.

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

[0082] In line 8, the NRF 100 transmits 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 a category 1 message filtering rule based on the NF profile information. For example, if the NF profile information includes an allowedOperationsPerNfType attribute defined for either of the producer NFs 200 or 202, the SEPP 126 may automatically create one or more category 1 message filtering rules to allow the specified operations to be performed for the identified NF type(s). In line 9, the SEPP 126 responds to the notification request with a 200OK message.

[0083] In line 10, the foreign PLMN 204 transmits 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 the category 1 message filtering rule. The SEPP 126 responds as indicated in line 11 with an SBI response message indicating that the message has been blocked.

[0084] In line 12, the operator updates the profiles of NFs 200 and 202. NFs 200 and 202 use the NFUpdate service operation ( Figure 3 In line 14, SEPP 126 responds to the notification request message in line 13.

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

[0086] In line 4, the NF Producer 202 transmits a NF Registration Request to the NRF 100 to register its NF profile to the NRF 100. The NF Registration service operation is successful, and the NRF 100 responds with a 201 Created message in line 5.

[0087] In line 6, the NF Producer 200 transmits a NF Registration Request to the NRF 100 to register its NF profile to the NRF 100. The NF Registration service operation is successful, and the 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 filtering rules based on the NF profile information. For example, if the NF profile information includes the allowedOperationsPerNfType attribute, SCP 101 may automatically create one or more category 1 message filtering rules to allow specified operations for the identified NF type(s).

[0089] In line 6, the NF Producer 200 transmits a NF Registration Request to the NRF 100 to register its NF profile to the NRF 100. The NF Registration service operation is successful, and the 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 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 the allowedOperationsPerNfType attribute, SCP 101 can automatically create a category 1 message filtering rule to allow specified operations for the identified (one or more) NF types. In line 9, SCP 101 responds to the notification request with a 200OK message.

[0091] In line 10, the foreign PLMN 204 transmits 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 the category 1 message filtering rules (or is not allowed due to the presence of a category 1 message filtering rule with an "allow" action). The SCP 101 responds with an SBI response message indicating that the message has been blocked as indicated in line 12. In line 13, the SEPP 126 sends a response to the foreign PLMN 204.

[0092] In line 14, the operator updates the profiles of NFs 200 and 202. NFs 200 and 202 use the NFUpdate service operation ( Figure 4 In the embodiment of the present invention, the NRF 100 (not shown) updates its profile to the NRF 100. In the 15th line, the NRF 100 transmits the nfStatusNotify request message containing the updated NF profile information to the SCP 101. In response to receiving the updated NF profile information, the 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 the NF type or NF instance, the SCP 101 can add the corresponding message filtering rule to its database of category 1 message filtering rules to allow HTTP messages of the corresponding method type. In the 16th line, the SCP 101 responds to the notification message in the 15th line.

[0093] 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. Figure 5In the embodiment, the SEPP or SCP 126 or 101 includes at least one processor 500 and a memory 502. The SEPP or SCP 126 or 101 also includes a category 1 message filtering rule database 504 that can be stored in the memory 502. The SEPP or SEPP 126 or 101 also includes a category 1 message filtering rule manager 506 that performs the steps described herein for subscribing to the NRF to receive notifications of NF profile updates, automatically generating category 1 message filtering rules, and filtering SBI messages using these rules. In one example, the category 1 message filtering rule manager 506 can be implemented using computer executable instructions stored in the memory 502 and executed by the processor 500.

[0094] Figure 6 is a flow chart illustrating an exemplary process for automatically configuring category 1 message filtering rules using topology information learned from NRF. Figure 6 In step 600, the process includes subscribing at the NF to the NRF to receive notifications of NF profile changes. For example, the SEPP 126 or SCP 101 may transmit an nfStatusSubscribe message to the NRF 100 with subscription data of the NF or NF group 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 within the PLMN.

[0095] In step 602, the process includes receiving a notification of a NF profile change from the NRF and as a result of a subscription. For example, the SEPP 126 or SCP 101 may 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 may include new or updated NF profile information for a NF or NF Group.

[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 the NF profile change. For example, the SEPP 126 or SCP 101 may extract the allowed scope from allowedOperationsPerNfType, allowedOperationsPerNfInstance or other authorization attributes and generate a category 1 message filtering rule to allow messages with the scope defined for the authorized entity. For example, if the allowed scope is write access for 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.

[0097] In step 606, the process includes filtering the SBI message using at least one category 1 message filtering rule at the NF. For example, the SEPP 126 or SCP 101 may receive the SBI request, compare the NF instance and / or NF type information and the HTTP method type of the SBI request with 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 may perform the corresponding rule action, which may be to allow or block the message.

[0098] Exemplary advantages of the subject matter described herein include a reduction in operational overhead compared to manual category 1 message filtering rule configuration. Category 1 message filtering rules are automatically synchronized with 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 easy to implement because this is an existing 3GPP service operation.

[0099] The disclosure of each of the following references is hereby incorporated by reference 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.510V17.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 TS23.501V17.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 TS23.502V17.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 TS29.573v17.5.0(2022-06)

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

[0119] 6.OAuth2.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 by the claims set forth below.

Claims

1. A method for automatically configuring and using category 1 message filtering rules, the method comprising: At the Network Function (NF): Subscribe to 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 subscription; automatically configuring at least one category 1 message filtering rule based on notification of NF profile changes; as well as The at least one category 1 message filtering rule is used at the NF to filter a service based interface (SBI) message.

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. A method as claimed in any preceding claim, wherein subscribing to the NRF comprises transmitting an nfStatusSubscribe message to the NRF.

5. A method as claimed in any of the preceding claims, wherein receiving a notification of a NF profile change comprises receiving an nfStatusNotify message containing the NF profile.

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

7. A method as described in any of the preceding claims, wherein the NF profile includes an authorization attribute and wherein 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 containing Hypertext Transfer Protocol (HTTP) methods corresponding to the allowed scope of the entity defined in the authorization attribute. The method of claim 7 , wherein the scope defines allowed operations of the entity.

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

10. The method of any of the preceding claims, wherein filtering SBI messages using Category 1 message filtering rules comprises allowing or blocking messages to 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.

11. A system for automatically configuring and using category 1 message filtering rules, the system comprising: A network function (NF), the network function comprising at least one processor and a memory; a category 1 message filtering rules database, wherein the category 1 message filtering rules database is stored in a memory; as well as A category 1 message filtering rule manager, the category 1 message filtering rule manager can be executed 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 rule database based on the notification of NF profile changes; and use the at least one category 1 message filtering rule to filter service-based interface (SBI) messages.

12. The system of claim 11, wherein the NF includes 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 rule 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 14, wherein the category 1 message filtering rules manager is configured to receive notification of NF profile changes in an nfStatusNotify message containing the NF profile.

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

17. A system as described in any one of claims 11 to 16, wherein the NF profile includes an authorization attribute, and wherein the category 1 message filtering rule manager is configured to automatically add or update the category 1 message filtering rule to allow SBI messages containing a Hypertext Transfer Protocol (HTTP) method corresponding to an allowed scope of an entity defined in the authorization attribute.

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

19. The system of any one of claims 11 to 18, wherein the category 1 message filtering rules manager is configured to allow or block messages 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.

20. A non-transitory computer readable medium having executable instructions stored thereon, wherein the executable instructions, when executed by a processor of a computer, control the computer to perform steps, the steps comprising: At the Network Function (NF): Subscribe to 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 subscription; automatically configuring at least one category 1 message filtering rule based on notification of NF profile changes; as well as Service based interface (SBI) messages are filtered using the at least one category 1 message filtering rule.

Images