Method, system, and computer-readable medium for protecting against mass network function (NF) deregistration attacks

Abstract

A method for protecting against mass NF deregistration attacks may be performed in an NRF or an SCP. The method includes receiving an NFDeregister request to deregister an NF. The method further includes classifying the NFDeregister request as suspicious based on application of a suspicious NFDeregister request classification rule. The method further includes queuing the NFDeregister request in response to classifying the NFDeregister request as suspicious. The method further includes receiving an NF heartbeat message for the NF. The method further includes determining that the NF heartbeat message is received within an NF heartbeat time interval of the NF. The method further includes preventing processing of the NFDeregister request and blacklisting a source of the NFDeregister request in response to determining that the NF heartbeat message is received within an NF heartbeat time interval of the NF.

Description

[Technical Field]

[0001] Priority claim This application claims the benefit of priority to U.S. Patent Application No. 17 / 314,329, filed May 7, 2021, the disclosure of which is incorporated herein by reference in its entirety.

[0002] Technical Field The subject matter described herein relates to security in communication networks. More particularly, the subject matter described herein relates to a method, system, and computer-readable medium for protecting against mass NF deregistration attacks. [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 is consuming, producing, or consuming and producing 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 can 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 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 can contain multiple NF instances. Note also that multiple NF instances can share the same service endpoint.

[0005] Producer NFs register with a Network Function Repository Function (NRF). The NRF maintains service profiles of available NF instances that identify the services supported by each NF instance. The terms "service profile" and "NF profile" are used interchangeably herein. Consumer NFs can subscribe to receive information about producer NF instances that have registered with the NRF.

[0006] In addition to consumer NFs, another type of network node that can subscribe to receive information about NF service instances is the Service Communication Proxy (SCP). An SCP subscribes with the NRF to obtain reachability and service profile information about producer NF service instances. A consumer NF: SCP Connect, SCP-144 The node balances the traffic among the producer NF service instances offering the required service or routes the traffic directly to the destination producer NF instance.

[0007] In addition to SCPs, another example of an intermediate proxy node that routes traffic between producer and consumer NFs is the Security Edge Protection Proxy (SEPP). A SEPP is a network node used to protect control plane traffic exchanged between different 5G public land mobile networks (PLMNs). As such, the SEPP performs message filtering, policing, and topology hiding for all application programming interface (API) messages transmitted between PLMNs.

[0008] One issue in 5G communication networks is vulnerability to mass NF deregistration attacks. 3GPP TS 29.510 specifies the NRF to support service discovery functions in 5G core networks. Producer NFs register with the NRF, so that consumer NFs can discover producer NFs and send service-based interface (SBI) requests. The NRF also provides an NRF management API to register, update, and deregister NFs to manage the NF lifecycle. The service operation used to deregister an NF is called the NFDeregister service operation, which is used to deregister an NF from the NRF by deleting the NF profile stored by the NRF. One issue with the NFDeregister service operation is that it can be exploited by hackers to mass deregister NFs and render 5G services unavailable. The result of successful deregistration from the NRF is the deletion of the NF profile of the NF instance in the NRF's NF profile database, making the NF instance undiscoverable. If all NF instances of a given type are deregistered, access to the services provided by the NF becomes unavailable, resulting in a network outage.

[0009] Although the NRF authenticates users during the NFDeregister service operation, hackers can find weaknesses in the authentication mechanism. As a result, a stronger defense is needed, namely a duplication mechanism to avoid mass NF deregistration attacks.

[0010] In light of these and other challenges, there is a need for improved methods, systems, and computer-readable media for protecting against MassNF deregistration attacks. Summary of the Invention

[0011] overview A method for protecting against mass NF deregistration attacks may be performed in an NRF or an SCP. The method includes receiving an NFDeregister request to deregister an NF. The method further includes classifying the NFDeregister request as suspicious based on application of a suspicious NFDeregister request classification rule. The method further includes queuing the NFDeregister request in response to classifying the NFDeregister request as suspicious. The method further includes receiving an NF heartbeat message for the NF. The method further includes determining that the NF heartbeat message is received within an NF heartbeat time interval of the NF. The method further includes preventing processing of the NFDeregister request and blacklisting a source of the NFDeregister request in response to determining that the NF heartbeat message is received within the NF heartbeat time interval of the NF.

[0012] According to another aspect of the subject matter described herein, classifying the NFDeregister request as suspicious based on application of suspicious NFDeregister request classification rules includes classifying the NFDeregister request as suspicious in response to determining that processing the NFDeregister request will cause the number of available NFs of the same type as the NF to fall below a minimum operator-specified threshold.

[0013] According to another aspect of the subject matter described herein, classifying the NFDeregister request as suspicious based on application of suspicious NFDeregister request classification rules includes classifying the NFDeregister request as suspicious in response to a rate of NFDeregister requests exceeding an operator-specified threshold.

[0014] According to another aspect of the subject matter described herein, classifying the NFDeregister request as suspicious based on application of suspicious NFDeregister request classification rules includes classifying the NFDeregister request as suspicious based on detected differences between learned historical traffic patterns and current traffic patterns of which the NFDeregister request is a part.

[0015] According to another aspect of the subject matter described herein, classifying the NFDeregister request as suspicious based on application of suspicious NFDeregister request classification rules includes classifying the NFDeregister request as suspicious by default.

[0016] According to another aspect of the subject matter described herein, the receiving, classifying, determining, preventing processing, and blacklisting steps are performed in an NRF, and the method for protecting against mass NF deregistration attacks further includes, in response to classifying the NFDeregister request as suspicious, transitioning to a SUSPECTED state, and applying, in the SUSPECTED state, operator-defined policies that determine whether to send an NFDeregister response and whether to respond to an NFDiscover request.

[0017] According to another aspect of the subject matter described herein, a method for protecting against mass NF deregistration attacks includes responding to an NFDeregister request with an NFDeregister response, and inserting a suspicious timer in the NFDeregister response to instruct the NF to delay shutdown until expiration of the suspicious timer.

[0018] According to another aspect of the subject matter described herein, the receiving, classifying, determining, preventing processing, and blacklisting steps are performed at an SCP, and the preventing processing of the NFDeregister request includes refraining from forwarding the NFDeregister request to the NRF.

[0019] According to another aspect of the subject matter described herein, a method for protecting against mass NF deregistration attacks includes, at an SCP, responding to an NFDeregister request on behalf of an NRF with an NFDeregister response.

[0020] According to another aspect of the subject matter described herein, a system for protecting against mass network function (NF) deregistration attacks is provided. The system includes an NRF or SCP including at least one processor and a memory. The system further includes a mass NF deregistration attack mitigation module implemented by the at least one processor to receive an NFDeregister request to deregister an NF, classify the NFDeregister request as suspicious based on application of suspicious NFDeregister request classification rules, queue the NFDeregister request in response to classifying the NFDeregister request as suspicious, receive an NF heartbeat message for the NF, determine that the NF heartbeat message is received within an NF heartbeat time interval of the NF, and prevent processing of the NFDeregister request and blacklist a source of the NFDeregister request in response to determining that the NF heartbeat message is received within the NF heartbeat time interval of the NF.

[0021] According to another aspect of the subject matter described herein, the mass NF deregistration attack mitigation module is configured to classify the NFDeregister request as suspicious in response to determining that processing the NFDeregister request would cause the number of available NFs of the same type as the NF to fall below a minimum operator-specified threshold.

[0022] According to another aspect of the subject matter described herein, the mass NF deregistration attack mitigation module is configured to classify NFDeregister requests as suspicious in response to a rate of NFDeregister requests exceeding an operator-specified threshold.

[0023] According to another aspect of the subject matter described herein, the mass NF deregistration attack mitigation module is configured to classify the NFDeregister request as suspicious based on a detected difference between a learned historical traffic pattern and a current traffic pattern of which the NFDeregister request is a part.

[0024] According to another aspect of the subject matter described herein, the mass NF deregistration attack mitigation module is configured to classify NFDeregister requests as suspicious by default.

[0025] According to another aspect of the subject matter described herein, the NRF or SCP comprises an NRF, and the mass NF deregistration attack mitigation module is configured to transition to a SUSPECTED state in response to classifying the NFDeregister request as suspicious, and to apply operator-defined policies in the SUSPECTED state that determine whether to send an NFDeregister response and whether to respond to an NFDiscover request.

[0026] According to another aspect of the subject matter described herein, the mass NF deregistration attack mitigation module is configured to respond to the NFDeregister request with an NFDeregister response and insert a suspicious timer in the NFDeregister response to instruct the NF to delay shutdown until expiration of the suspicious timer.

[0027] According to another aspect of the subject matter described herein, the NRF or the SCP comprises an SCP, and the mass NF deregistration attack mitigation module is configured to prevent processing of the NFDeregister request by refraining from forwarding the NFDeregister request to the NRF.

[0028] According to another aspect of the subject matter described herein, the mass NF deregistration attack mitigation module is configured to respond to the NFDeregister request on behalf of the NRF with an NFDeregister response.

[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 steps being performed in an NRF or an SCP. The steps include receiving an NFDeregister request to deregister an NF. The steps further include classifying the NFDeregister request as suspicious based on application of a suspicious NFDeregister request classification rule. The steps further include queuing the NFDeregister request in response to classifying the NFDeregister request as suspicious. The steps further include receiving an NF heartbeat message for the NF. The steps further include determining that the NF heartbeat message is received within an NF heartbeat time interval of the NF. The steps further include preventing processing of the NFDeregister request and blacklisting a source of the NFDeregister request in response to determining that the NF heartbeat message is received within the NF heartbeat time interval of the NF.

[0030] According to another aspect of the subject matter described herein, a method for protecting against mass network function (NF) deregistration attacks is provided. The method includes receiving, at an NRF including at least one processor and a memory, a NFDeregister request to deregister the NF. The method further includes storing, in the memory, a copy of an NF profile for the NF. The method further includes processing or forwarding the NFDeregister request to deregister the NF. The method further includes receiving an NF heartbeat message for the NF. The method further includes determining that the NF heartbeat message is received within an NF heartbeat time interval for the NF. The method further includes, in response to determining that the NF heartbeat message is received within the NF heartbeat time interval, restoring the registration of the NF using the stored copy of the NF profile.

[0031] The subject matter described herein can be implemented using a combination of software, 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-transitory computer-readable medium having stored thereon computer-executable instructions that, when executed by a processor of a computer, control the computer to perform a number of steps. Exemplary computer-readable media suitable for implementing the subject matter described herein include non-transitory computer-readable media such as disk memory devices, chip memory devices, programmable logic devices, and application-specific integrated circuits. In addition, computer-readable media embodying the subject matter described herein can be located on a single device or computing platform, or can be distributed across multiple devices or computing platforms.

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

[0033] [Figure 1] FIG. 1 is a network diagram illustrating an example 5G system network architecture. [Figure 2] A message flow diagram showing example messages exchanged for an NFDeregister service operation. [Figure 3] FIG. 10 is a message flow diagram illustrating example messages exchanged for an NF heartbeat service operation. [Figure 4A] FIG. 10 is a message flow diagram illustrating example messages exchanged for a mass NFDeregister attack where messages do not pass through the SCP before reaching the NRF. [Figure 4B] FIG. 10 is a message flow diagram illustrating exemplary messages exchanged for a mass NFDeregister attack in which messages pass through an SCP before reaching the NRF. [Figure 5] FIG. 10 is a message flow diagram illustrating exemplary messages exchanged using NRF to protect against mass NFDeregister attacks. [Figure 6A] FIG. 10 is a message flow diagram illustrating example messages exchanged between an NF and an NRF for NF deregistration and shutdown without a suspicious timer. [Figure 6B] FIG. 10 is a message flow diagram illustrating example messages exchanged between an NF and an NRF for NF deregistration, including a suspicious timer that enables graceful shutdown of the deregistering NF. [Figure 7A] FIG. 10 is a message flow diagram showing exemplary messages exchanged using an SCP to protect against mass NFDeregister attacks, where the SCP classifies NFDeregister requests that match operator-specified criteria as suspicious and queues the suspicious requests. [Figure 7B]7B is a continuation of the message flow of FIG. 7A , in which the SCP refrains from sending a queued suspect NFDeregister request to the NRF when an NF heartbeat message is received for the NF during the NF heartbeat time interval of the NF. [Figure 7C] FIG. 10 is a message flow diagram showing exemplary messages exchanged using an SCP to protect against mass NFDeregister attacks, where the SCP classifies NFDeregister requests that match operator-specified criteria as suspicious and queues the suspicious requests. [Figure 7D] 7D is a continuation of the message flow of FIG. 7C, in which the SCP sends a queued NFDeregister request to the NRF when an NF heartbeat request is not received within the NF heartbeat time interval of the NF. [Figure 8A] FIG. 10 is a message flow diagram illustrating example messages exchanged between an NF and an SCP for NF deregistration and shutdown without suspicious timers. [Figure 8B] FIG. 10 is a message flow diagram illustrating example messages exchanged between an NF and an SCP for NF deregistration, including a suspicious timer that enables graceful shutdown of the deregistering NF. [Figure 9] FIG. 1 is a state transition diagram illustrating example state transitions associated with deregistering an NF to protect against mass NF deregistration attacks. [Figure 10] FIG. 1 is a block diagram illustrating an example architecture of an NRF or SCP for protecting against mass NRF deregistration attacks. [Figure 11] 10 is a flowchart illustrating an example process performed by an NRF or SCP to classify an NFDeregister request as suspicious and to protect against mass NF deregistration attacks using NF heartbeat messages. [Figure 12] 10 is a flowchart illustrating an example process performed by the NRF to restore a deregistered NF profile after detecting a mass NF deregistration attack. DETAILED DESCRIPTION OF THE INVENTION

[0034] 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 within the same Home Public Land Mobile Network (HPLMN). As described above, the NRF 100 maintains profiles of available producer NF service instances and the supported services of these NF service instances, and can enable consumer NFs or SCPs to apply for and be notified of new / updated producer NF service instances. The SCP 101 can also assist in service discovery and selection of producer NF instances. The SCP 101 can perform load balancing of connections between consumer NFs and producer NFs.

[0035] The NRF 100 is a repository for the NF or service profile of a producer NF instance. To communicate with a producer NF instance, a consumer NF or SCP must obtain the NF or service profile of the producer NF instance from the NRF 100. The NF or service profile is a JavaScript Object Notation (JSON) data structure specified in 3GPP TS 29.510. The NF or service profile definition includes at least one of a fully qualified domain name (FQDN), an Internet Protocol (IP) version 4 (IPv4) address, or an IP version 6 (IPv6) address.

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

[0037] 1 further includes a Session Management Function (SMF) 108 that manages sessions between an Access 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. An Authentication Server Function (AUSF) 112 performs authentication services for user equipment (UE), such as user equipment (UE) 114, seeking access to the network.

[0038] The Network Slice Selection Function (NSSF) 116 provides network slicing services to devices that want to access specific network capabilities and characteristics associated with a network slice. The Network Publish 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 attached to the network. The NEF 118 performs a function similar to the Service Capability Publish Function (SCEF) in 4G networks.

[0039] The radio access network (RAN) 120 connects the user equipment (UE) 114 to the network via a wireless link. The radio access network 120 can be accessed using a gNodeB (gNB) (not shown in FIG. 1) or other wireless access point. The user plane function (UPF) 122 can support various proxy functionalities for user plane services. One example of such proxy functionality is multipath transmission control protocol (MPTCP) proxy functionality. The UPF 122 can also support performance measurement functionality that can be used by the UE 114 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.

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

[0041] As described above, one issue in 5G networks is the network's vulnerability to mass NF deregistration attacks, in which an attacker attempts to deregister some or all NF instances that provide one or more critical services to the network. Figure 2 is a message flow diagram illustrating exemplary messages exchanged for the NFDeregister service operation. The NFDeregister service operation is a management API defined by 3GPP TS29.510. According to the NFDeregister service operation, an NF service consumer or hacker who wishes to deregister an NF sends an NFDeregister request to the NRF. In Figure 2, the NFDeregister request is an HTTP DELETE message (line 1) that identifies the NF instance to be deregistered by its NF instance ID. The NRF 100 receives the NFDeregister request, and if the request is successfully processed, the NRF 100 returns a 204 No Content message (line 2a). If the deregistration request is not successful or if the deregistration request is redirected to another NRF, the NRF 100 returns a 4xx or 5xx message with details of the problem, or a 3xx message indicating redirection. The result of successful processing of the NFDeregister request is the deletion of the NF profile in the NRF's NF profile database, which makes the NF undiscoverable by other NFs. Note that the NFDeregister service operation is particularly needed in cloud-native environments where NF instances are frequently allocated and deallocated as cloud resource requirements change.

[0042] Another service operation defined in 3GPP TS 29.510 is the NF Heartbeat service operation. The NF Heartbeat service operation is used by an NF to periodically indicate to the NRF that the NF is still available to provide service. The NF Heartbeat service operation is performed by having the NF periodically contact the NRF with an NFUpdate request message indicating that the NF is still available. If the NF is unable to send an NFUpdate request within the NF Heartbeat interval defined by the NRF in the Registration Response, the NRF marks the NF profile of the NF as unavailable.

[0043] FIG. 3 is a message flow diagram illustrating example messages exchanged in an NF heartbeat service operation. Referring to FIG. 3, at line 1, the NF service consumer 200 sends an NF heartbeat request message to the NRF 100, which identifies the NF instance to which the NF heartbeat request message applies. At line 2a, the NRF 100 responds to the NF heartbeat request with a 200 OK message or a 204 No Content message if the NF heartbeat service operation is successful. If the NF heartbeat service operation is not successful or if a redirection occurs, at line 2b, the NRF 100 returns a 3xx message, a 4xx message, or a 5xx message. Thus, the NF heartbeat procedure provides a way for the NRF 100 to ensure that NFs registered with the NRF 100 are still available for use.

[0044] When an NF is registered with an NRF, 3GPP TS29.510 specifies the following states for the NF:

[0045] [Table 1]

[0046] In Table 1, registered NF states include REGISTERED (NF profile can be discovered by other NFs), SUSPENDED (NF instance is registered but not operational or discoverable), and UNDISCOVERABLE (NF instance is registered but not discoverable by other NFs). Additional states that can be used to protect against mass NF deregistration attacks are described below.

[0047] As discussed above, one potential issue within 5G networks is a mass NF deregistration attack, in which a hacker deregisters some or all instances of a given type of NF. The NFDeregister service operation is available to deregister already registered NFs and is a necessary service for NFs to manage resource utilization. However, the NFDeregister service operation can be exploited by hackers to bulk deregister producer NFs, causing network outages. Normal rate limits, which limit the number of SBI requests based on HTTP method and uniform resource identifier (URI), are not sufficient to protect against mass NFDeregister attacks because an attacker can stagger NFDeregister requests to pass the rate limit check. Setting a low rate limit for a given type of HTTP message is not ideal because valid NFDeregister requests will be throttled. 5G networks are designed to be cloud-native, which requires frequent NF registrations and deregistrations to create and remove network slices. The possibility of a successful mass NF deregistration attack must be detected or mitigated.

[0048] FIG. 4A is a message flow diagram illustrating example messages that may be exchanged in a mass NF deregistration attack in which messages do not pass through an SCP before reaching the NRF. In FIG. 4A, the network includes three UDM instances: UDM1 104A, UDM2 104B, and UDM3 104C. A hacker 400 attempts to deregister all three UDM instances by sending an NFDeregister message to the NRF 100 for each UDM instance. Referring to the message flow in FIG. 4A, in step 1, UDM1 104A sends an NFRegister request to the NRF 100. The NRF 100 registers UDM1 104A by storing the NF profile of UDM1 104A in the NF profile database maintained by the NRF 100, and in step 2, responds with an NFRegister response message. After being registered with the NRF, UDM1 104A can be discovered by other NFs.

[0049] In step 3 of the message flow diagram, UDM2 104B sends an NFRegister request to NRF 100. NRF 100 registers UDM2 104B by storing the NF profile of UDM2 104B in the NF profile database and responds in step 4 with an NFRegister response message.

[0050] In step 5 of the message flow diagram, UDM3 104C sends an NFRegister request to NRF 100. NRF 100 registers UDM3 104C by storing the NF profile of UDM3 104C in the NF profile database and responds with an NFRegister response message in step 6. Thus, after step 6, UDM104A to UDM104C can all be discovered and can provide services in the network.

[0051] In step 7, the hacker 400 sends an NFDeregister request to the NRF 100, identifying UDM3 104C. In step 8, the NRF 100 accepts the NFDeregister request for UDM3 104C and deletes the NF profile. In step 9, the NRF 100 sends an NFDeregister response to the hacker 400. After step 9, UDM3 104C is no longer registered and therefore cannot be discovered in the network. However, because UDM1 104A and UDM2 104B are still registered, UDM services are still available in the network.

[0052] In step 10, the hacker 400 sends an NFDeregister request to the NRF 100, identifying UDM2 104B. In step 11, the NRF 100 accepts the NFDeregister request for UDM2 104B and deletes the NF profile. In step 12, the NRF 100 sends an NFDeregister response to the hacker 400. After step 11, UDM2 104B is deregistered and therefore cannot be discovered by other NFs in the network. However, UDM services are still available because UDM1 104A is still registered.

[0053] In step 13, the hacker 400 sends an NFDeregister request to the NRF 100 to deregister UDM1 104A. In step 14, the NRF 100 accepts the NFDeregister request for UDM1 104A and deletes the NF profile. In step 15, the NRF 100 sends an NFDeregister response to the hacker 400. After step 15, the UDM service is no longer available. Because the UDM service is essential for the network to function properly, a network outage occurs, as indicated by step 16. Enhanced security measures should be implemented before allowing all or a majority of NFs of a given type from being deregistered. The subject matter described herein provides such enhanced security measures, including classifying some NFDeregister requests as suspicious, reversing the NF deregistration operation using NF heartbeat messaging, and saving a copy of the NF profile being deregistered for subsequent restoration of NF registration.

[0054] Figure 4B is a message flow diagram showing example messages exchanged for a mass NFDeregister attack, in which messages pass through an SCP before reaching the NRF. The NFDeregister request message in steps 1, 5, and 9 of Figure 4B is the same as that in steps 7, 10, and 13 of Figure 4A, except that in Figure 4B, the NFDeregister request message is proxied by SCP 101 and forwarded to NRF 100 in steps 2, 6, and 10 of Figure 4B. The corresponding NFDeregister response is also proxied by SCP 101, as shown in steps 3, 4, 7, 8, 11, and 12 of Figure 4B. The end result in Figure 4B is the same as in Figure 4A: when all of the UDMs are deregistered, a network outage occurs, as shown in step 13 of Figure 4B.

[0055] One enhanced security measure provided by the subject matter described herein is to mark an NFDeregister service request as suspicious or classify the NFDeregister service request as suspicious and queue the NFDeregister service request for later processing when several criteria are met according to operator-configured policy. If an NFDeregister service request is marked as suspicious, NFs subscribed to receive notification of changes in the status of the NF from which the suspicious NFDeregister request is received may or may not be notified of deregistration, depending on operator configuration. The discovery response may or may not include the NF profile of the NF from which the suspicious NFDeregister request is received, depending on operator configuration. The NFDeregister response sent to the client NF may include a suspicious timer that indicates to the client that the deregistration worked. The suspicious timer indicates to the client NF that the NFDeregister request does not need to be retried.

[0056] In another security enhancement, a queued NFDeregister service request is subsequently processed only if an NF heartbeat (NFUpdate) is not received before the expiration of the NF heartbeat timer. Failure to receive an NF heartbeat confirms deregistration by deregistering the NF that owns the NF profile. If an NF heartbeat is received for an NF with a queued suspicious deregistration request, the NF that sent the NFDeregister request may be marked as blacklisted, and the network operator may be notified of the possible attack. If an NF heartbeat is received for a deregistered profile that was deregistered based on an NFDeregister request being classified as normal or non-suspicious, the NF profile may be restored. If mass NF deregistration attack mitigation functionality is implemented in the NRF, restoration of the NF profile may be performed by keeping a copy of the NF profile upon processing a normal (non-suspicious) NFDeregister request. The copy may be stored by the NRF 100 for at least the NF heartbeat timer period. When an NF heartbeat message is received for a deregistered NF, the NRF 100 can restore the NF's NF profile using the saved copy. If mass NF deregistration attack mitigation functionality is implemented in the SCP, when an NF heartbeat request is received for a deregistered NF, the NRF 100 can send an NF heartbeat error message to the deregistered NF via the SCP. The SCP can forward the NF heartbeat error message to the NF, and the NF can re-register itself with the NRF. When an NFRegister request is received for an NF with a suspicious NFDeregister request queued, the NF can be deregistered and then registered with a new profile. Figure 5 is a message flow diagram illustrating example messages exchanged when the NRF 100 utilizes the methods described herein to detect and protect against successful mass NF deregistration attacks.5, in step 1, UDM1 104A sends an NFRegister request to NRF 100. NRF 100 registers UDM1 104A by storing the NF profile of UDM1 104A in the NF profile database maintained by NRF 100, and responds with an NFRegister response message in step 2. After being registered with the NRF, UDM1 104A can be discovered by other NFs.

[0057] In step 3 of the message flow diagram, UDM2 104B sends an NFRegister request to NRF 100. NRF 100 registers UDM2 104B by storing the NF profile of UDM2 104B in the NF profile database and responds in step 4 with an NFRegister response message.

[0058] In step 5 of the message flow diagram, UDM3 104C sends an NFRegister request to NRF 100. NRF 100 registers UDM3 104C by storing the NF profile of UDM3 104C in the NF profile database and responds with an NF Registration Response message in step 6. Thus, after step 6, UDM104A to UDM104C can all be discovered and can provide services within the network.

[0059] In step 7, the hacker 400 sends an NFDeregister request to the NRF 100 that identifies UDM3 104C. In step 8, the NRF 100 accepts the NFDeregister request and deletes the NF profile of UDM3 104C. The NRF 100 can accept the NFDeregister request by classifying it as normal based on application of suspicious NFDeregister request classification rules. For example, one rule may be that a UDM service in the network must be provided by at least two UDMs. Because the NFDeregister request in step 7 only deregisters one of the three UDMs, the NFDeregister request in step 7 can be classified as normal or non-suspicious. Even if the NFDeregister request is classified as normal, the NRF 100 can save a copy of the NF profile of the NRF 100 for subsequent restoration of the NF's registration if a mass NF deregistration attack is detected.

[0060] In step 9, the NRF 100 sends an NFDeregister response to the hacker 400. After step 9, UDM3 104C is no longer registered and therefore cannot be discovered in the network. However, UDM1 104A and UDM2 104B are still registered, so the UDM service is still available in the network.

[0061] In step 10, the hacker 400 sends an NFDeregister request identifying UDM2 104B to the NRF 100. In step 11, the NRF 100 applies suspicious NFDeregister request classification rules and classifies the NFDeregister request in step 10 as suspicious. In response to classifying the NFDeregister request as suspicious, the NRF 100 may queue the NFDeregister request or otherwise delay processing the NFDeregister request for a predetermined time interval, which may be at least equal to the NF heartbeat time interval for the NF instance, and the NF profile of the NF instance identified in the NFDeregister request.

[0062] In step 12, the NRF 100 sends an NFDeregister response to the hacker 400. The NRF 100 may include a suspicious timer in the NFDeregister response. The suspicious timer may be a timer or time to wait before shutting down and / or retransmitting the NFDeregister response. FIG. 6A shows the processing of an NFDeregister response without a suspicious timer, and FIG. 6B shows the processing of an NFDeregister response with a suspicious timer. In FIG. 6A, in step 1, the NF 200 sends an NFDeregister request to the NRF 100. In step 2, the NRF 100 sends an NFDeregister response without a suspicious timer. Upon receiving the NFDeresitter response without a suspicious timer, the NF 200 shuts down as shown in step 3.

[0063] Figure 6B shows the same message flow as Figure 6A, except that in step 2, the NFDeregister response includes a suspicious timer. In step 3 of Figure 6B, the NF 200 delays processing the NFDeregister response until the suspicious timer expires. While waiting for the suspicious timer to expire, the NF 200 can respond to service requests from other NFs. The NF 200 can also refrain from retransmitting the NFDeregister request. When the suspicious timer expires, the NF 200 shuts down. Thus, the suspicious timer enables the graceful shutdown of an NF that is legitimately deregistering itself.

[0064] Returning to the message flow of Figure 5, at step 13, the hacker 400 sends an NFDeregister request to the NRF 100 to deregister UDM1 104A. At step 14, the NRF 100 applies suspicious NF deregistration request classification rules to the NFDeregister request and classifies the request as suspicious. In response to classifying the NFDeregister request as suspicious, the NRF 100 queues the request and formulates and sends an NFDeregister response that includes the suspicious timer. At step 15, the NRF 100 sends the NFDeregister response with the suspicious timer to the hacker 400.

[0065] In steps 16-18 of the message flow diagram, UDM 104A and UDM 104B (UDMs 104A and 104B) send NF heartbeat request messages to NRF 100. Because NFs requesting deregistration should not send NF heartbeat requests, in step 19 NRF 100 blacklists the source of the deregistration for UDM1 104A and UDM2 104B for which the NFDeregister request was queued, classifies the NFDeregister request as a component of a mass NFDeregister attack, and notifies the network operator of the mass NFDeregister attack. In step 20, NRF 100 restores the NF profile for UDM3 104C using the copy of the NF profile saved in step 8. The source of the NFDeregister request in steps 7, 10, and 13 can be blacklisted to prevent further SBI service request messages from the source from being processed. Thus, using the steps of Figure 5, a successful MassNF deregistration attack is prevented.

[0066] FIG. 7A is a message flow diagram showing example messages exchanged using an SCP to protect against mass NFDeregister attacks. The SCP classifies NFDeregister requests that match operator-specified criteria as suspicious and queues the suspicious requests. The SCP tracks NFDeregister requests and NF heartbeat messages being proxied through the SCP. The SCP uses the NF heartbeat timer to determine whether an NFDeregister request identified as suspicious (or non-suspicious) was valid or invalid. As in the NRF implementation shown in FIG. 5, the SCP classifies an NFDeregister service request as suspicious and queues the NFDeregister service request for later processing when several criteria are met according to the network operator's established policy or rules. For NFDeregister requests identified as suspicious, the SCP sends NFDeregister responses to the client NFs, each containing a suspicious timer, which gives the impression that the deregistration worked, so the client NFs do not need to retry the request. The SCP forwards NFDeregister requests that are classified as normal to the NRF and queues (i.e., stores and does not forward to the NRF) NFDeregister requests that are classified as suspicious, so other NFs will not consider the NF to be deleted, i.e., NFs communicating with the NRF will be able to discover the service profile of NFs that have suspicious NFDeregister requests queued by the SCP.

[0067] Referring to the message flow of Figure 7A, in step 1, the hacker 400 sends an NFDeregister request to the SCP 101 that identifies the UDM3 104C. In step 2, the SCP 101 applies operator-specified suspicious NFDeregister request classification rules and classifies the request as non-suspicious, and in step 3, forwards the NFDeregister request to the NRF 100, which deletes the NF profile for the UDM3 104C. In step 4, the NRF 100 sends an NFDeregister response to the SCP 101. In step 5, the SCP 100 forwards the NFDeregister response to the hacker 400.

[0068] In step 6, the hacker 400 sends an NFDeregister request identifying UDM2 104B to the SCP 101. In step 7, the SCP 101 applies suspicious NFDeregister request classification rules and classifies the NFDeregister request in step 6 as suspicious. In response to classifying the NFDeregister request as suspicious, the SCP 101 queues the NFDeregister request (i.e., prevents the NFDeregister request from being forwarded to the NRF 100) for a predetermined time interval, where the predetermined time interval may be at least equal to the NF heartbeat time interval for the NF instance and the NF profile of the NF instance identified in the NFDeregister request.

[0069] In step 8, the SCP 101 sends an NF Deregister response to the hacker 400 on behalf of the NRF 100. The SCP 101 may include a suspicious timer in the NF Deregister response. The suspicious timer, in the case of a legitimate NF deregistering itself, instructs the NF to wait until the suspicious timer expires before shutting down. The messages exchanged between the SCP 101 and a legitimate NF deregistering itself are shown in FIGS. 8A and 8B. The messages exchanged in FIGS. 8A and 8B are the same as those shown in FIGS. 6A and 6B, except that the NF Deregister request is terminated and queued by the SCP, rather than the NRF and SCP sending the NF Deregistration responses to the NF on behalf of the NRF.

[0070] FIG. 7B is a continuation of the message flow of FIG. 7A, in which the SCP refrains from sending a queued suspicious NFDeregister request to the NRF when an NF heartbeat message is received for the NF during the NF heartbeat time interval of the NF. The queued NFDeregister service request is sent to the NRF only upon future failure to receive an NF heartbeat (NFUpdata) upon expiration of the NF heartbeat timer. Failure to receive an NF heartbeat confirms that the NF has deregistered by owning the profile. If an NF heartbeat is received for an NF with a queued suspicious deregistration request, the source of the deregistration request may be blacklisted and the network operator may be notified of a possible attack. If an NF heartbeat request is received for a deregistered profile, the NF heartbeat request is forwarded to the NRF. The NRF responds to the NF that sent the NF heartbeat request with an NF heartbeat response indicating an error. In response to receiving an NF heartbeat response indicating an error, the deregistered NF can re-register with the NRF.

[0071] Referring to the message flow of FIG. 7B, in step 12, UDM3 104C sends an NF heartbeat request to SCP 101. In step 13, SCP 101 forwards the NF heartbeat request to NRF 100. Because the NF instance identified in the NF heartbeat request has been deregistered, in step 14, NRF 100 sends an NF heartbeat error response to SCP 101. In step 15, SCP 101 sends an NF heartbeat error response to UDM3 104C. In step 16, UDM3 104C re-registers itself with NRF 100 based on the NF heartbeat error response.

[0072] In step 17, UDM2 104B transmits an NF heartbeat request to SCP 101. The NF heartbeat request shall be within the NF heartbeat interval of UDM2 104B. Because SCP 101 should not receive NF heartbeat requests for NFs for which an NF Deregister message has been received, SCP 101 blocks or refrains from sending NF Deregister requests for UDM2 104B to NRF 100, blacklists the source of the NF Deregister requests for UDM2 104B, and notifies the network operator of the existence of a possible mass NF deregistration attack. In step 18, SCP 101 forwards the NF heartbeat request to NRF 100. NRF 100 resets the NF heartbeat timer for UDM2 104B and, in step 19, sends an NF heartbeat response to SCP 101. In step 20, SCP 101 sends the NF heartbeat response to UDM2 104B.

[0073] In step 21, UDM1 104A transmits an NF heartbeat request to SCP 101. The NF heartbeat request shall be within the NF heartbeat interval of UDM1 104A. Because SCP 101 should not receive NF heartbeat requests for NFs for which an NF Deregister message has been received, SCP 101 blocks or refrains from sending NF Deregister requests for UDM1 104A to NRF 100, blacklists the sender of the NF Deregister request for UDM1 104A, and notifies the network operator of the existence of a possible mass NF deregistration attack. In step 22, SCP 101 forwards the NF heartbeat request to NRF 100. NRF 100 resets the NF heartbeat timer for UDM1 104A and in step 23 sends an NF heartbeat response to SCP 101. In step 24, SCP 101 sends the NF heartbeat response to UDM1 104A.

[0074] FIG. 7C is a message flow diagram illustrating exemplary messages exchanged using an SCP to protect against mass NFDeregister attacks. The SCP classifies NFDeregister requests that match operator-specified criteria as suspicious and queues the suspicious requests. The message flow in FIG. 7C is the same as that shown in FIG. 7A, except that the NFDeregister requests in steps 1, 6, and 9 of FIG. 7C originate from UDMs 104C, 104B, and 104A rather than hacker 400. The NFDeregister requests are classified as suspicious using the suspicious NFDeregister request classification rules in FIG. 7C. However, as shown in FIG. 7D, a continuation of the message flow in FIG. 7C, SCP 101 sends the queued NFDeregister requests to the NRF when an NF heartbeat request is not received within the NF heartbeat time interval of the NF. Referring to the message flow shown in FIG. 7D, in step 12, SCP 101 determines that the NF heartbeat timer has expired for UDM1 104A. In step 13, SCP 101 sends the queued NFDeregister request for UDM1 104A to NRF 100. In step 14, NRF 100 sends an NFDeregister response to SCP 101. Note that SCP 101 does not forward the NFDeregister response to UDM1 104A because SCP 101 already sent the NFDeregister response to UDM1 104A in step 9 of FIG. 7C. If an NFRegister, NFUpdate, or NF Heartbeat request is received from an NF that is on the blacklist, the NFRegister, NFUpdate, or NF Heartbeat request may be forwarded to the NRF, and the NF that sent the NFRegister, NFUpdate, or NF Heartbeat request may be moved out of the list of blacklisted NFs.

[0075] In step 15, SCP 101 determines that the NF heartbeat timer has expired for UDM2 104B. In step 16, SCP 101 sends the queued NFDeregister request for UDM2 104B to NRF 100. In step 17, NRF 100 sends an NFDeregister response to SCP 101. SCP 101 does not forward the NFDeregister response to UDM2 104B because SCP 101 already sent the NFDeregister response to UDM2 104B in step 11 of Figure 7C.

[0076] As described above, an NFDeregister request may be classified as suspicious based on operator-defined suspicious NFDeregister request identification rules or policies. The following are example policies that may be applied by the NRF 100 or SCP 101 when classifying an NFDeregister request as suspicious:

[0077] Minimum Registered: A deregistration that causes the number of registered NFs of a given type to fall below a configured minimum threshold is classified as suspicious. For example, an operator may select 2 as the minimum number of UDMs that should be registered in the network. If processing an NFDeregister request causes the number of registered UDMs to fall below 2, the NFDeregister request is classified as suspicious and is queued for at least the NF heartbeat time interval to determine whether or not to process the NFDeregister request.

[0078] Max Rate: The operator can specify the maximum allowed rate of NFDeregister requests. Any NFDeregister request that would cause the maximum rate to be exceeded will be classified as suspicious. For example, if the operator sets the maximum rate to 100 requests per minute, any NFDeregister request that would cause the rate to exceed 100 requests per minute will be classified as suspicious.

[0079] · Always: The operator can select "always" to classify all NFDeregister requests as suspicious by default. In such a case, all NFDeregister requests will be queued for a period of time to see if an NF Heartbeat message is received within the NF Heartbeat time interval for each NF for which deregistration is requested.

[0080] Auto: This means that the NRF learns past traffic patterns and classifies an NFDeregister request if the NFDeregister request is part of a traffic pattern that is statistically different from the learned past traffic pattern. The NRF 100 or SCP 101 can use a machine learning algorithm to learn past traffic patterns. For example, if the machine learning algorithm learns that there are an average of 5 deregistrations per hour, and the number of NF deregistrations in a given hour is above the average by more than one standard deviation, any NFDeregister request that would cause the number of deregistrations to exceed the average number plus one standard deviation would be classified as suspicious.

[0081] Policies may be logically combined, e.g., logically ANDed or ORed. An example of an ANDed policy is to classify an NFDeregister request as suspicious if the deregistration causes the rate of deregistrations to exceed a maximum rate threshold and causes the minimum number of available NFs to fall below a minimum threshold.

[0082] FIG. 9 is a state transition diagram illustrating example state transitions of an NRF when performing the NFUpdate, NFDeregister, and NF Heartbeat service operations specified by 3GPP and the mass NFDeregister attack mitigation procedure described herein. In FIG. 9, the REGISTERED, SUSPENDED, and UNDISCOVERABLE states are the same as those specified in 3GPP TS 29.510. The UNREGISTERED and SUSPENDED states are newly defined states that implement the mass deregistration attack mitigation procedure described herein. The NF DELETED state is the state that occurs when an NF profile is deleted. The arrows between states represent state transitions, and the boxes on each arrow represent the conditions that cause a transition from one state to another. For example, when the NRF registers an NF profile, the NRF is in the REGISTERED state for the newly registered NF profile. From the REGISTERED state, the NRF transitions to the SUSPECTED state when it receives an NFDeregister request and classifies the NFDeregister request as suspicious based on application of the NFDeregister request suspect classification rules. While in the SUSPECTED state, if an NF heartbeat message for the NF profile is received within a configured period, the sender of the NFDeregister request is marked as blacklisted and the NRF transitions to the REGISTERED state for the NF profile identified in the NF heartbeat message. While in the SUSPECTED state, if an NF heartbeat message for the NF is not received within a configured period, the NRF deregisters the NF by deleting the NF profile from the NF profile database and transitions to the NFDELETED state.

[0083] Upon returning to the REGISTERED state, if an NFDeregister request is received that does not match the suspected NF deregistration policy, the NRF transitions to the UNREGISTERED state for the NF profile. In the UNREGISTERED state, if an NF heartbeat message for the NF profile is not received within a configured time interval, the NRF deletes the NF profile and transitions to the NF DELETED state. In the UNREGISTERED state, if an NF heartbeat message is received within a configured time interval, the NRF transitions to the REGISTERED state for the NF profile. The remaining state transitions in Figure 9 implement the standard NFUpdate and NF heartbeat service operations specified in 3GPP TS 29.510.

[0084] When in the SUSPECTED state, the NRF may implement operator-defined procedures to process updates to subscribed NFs and discovery requests. Table 2, shown below, shows an example of an operator-configurable policy for NF deregistration notifications to subscribed NFs and discovery responses that may be implemented by the NRF when in the SUSPECTED state for a particular NF profile.

[0085] [Table 2]

[0086] From Table 2, the first policy indicates that if the NF type is UDM and the NRF is in a SUSPECTED state for a UDM NF profile, the NRF sends a deregistration notification to subscribed NFs and includes the UDM NF profile in the discovery response, i.e., the response to the NFDiscover request. The second policy indicates that for NF profiles for NFs in LOC1, the NRF sends a deregistration notification but does not include the NF profile in the discovery response. The third policy is a default policy indicating that if a particular NF profile does not match any of the other policy conditions, the default NRF behavior is to include the NF profile in the discovery response rather than sending an NF deregistration notification. Note that the example policies in Table 2 are illustrative, and different policies for NF deregistration notifications and discovery responses may be configured without departing from the scope of the subject matter described herein.

[0087] FIG. 10 is a block diagram illustrating an example architecture for an NRF or SCP 100 or 101 that implements the mass NF deregistration attack mitigation procedures described herein. Referring to FIG. 10 , the NRF or SCP 100 or 101 includes at least one processor 1000 and memory 1002. When the NRF or SCP 100 or 101 is an NRF, the NRF may include an NF profile database 1004 that stores NF profiles of registered NFs and an NF profile manager 1006 that manages normal NF profile registration, deregistration, and update operations. When the NRF or SCP 100 or 101 is an SCP, the NF profile database and NF profile manager may be implemented on the NRF separate from the SCP. The NRF or SCP 100 or 101 includes a mass NF deregistration attack mitigation module 1008 that implements the subject matter described herein to reduce the likelihood of a successful mass NF deregistration attack. The mass NF deregistration attack mitigation module 1008 may be implemented using computer-executable instructions stored in the memory 1002 and executed by the processor 1004.

[0088] FIG. 11 is a flowchart illustrating an example process performed by an NRF or SCP to classify an NFDeregister request as suspicious and to protect against mass NF deregistration attacks using NF heartbeat messages. The steps of FIG. 11 may be performed by the mass NF deregistration attack mitigation module 1008 shown in FIG. 10. Referring to FIG. 11, at step 1100, the process includes receiving an NFDeregister request to deregister an NF. For example, the NRF or SCP 100 or 101 may receive the NFDeregister request to deregister an NF.

[0089] In step 1102, the process includes classifying the NFDeregister request as suspicious based on application of a suspicious NFDeregister request classification rule. For example, the NRF or SCP 100 or 101 may classify the NFDeregister request as suspicious based on application of any of the suspicious NFDeregister request classification rules described herein.

[0090] In step 1104, the process includes queuing the NFDeregister request in response to classifying the NFDeregister request as suspicious. For example, in one SCP embodiment, the SCP 101 may queue the NFDeregister request and refrain from forwarding the NRF 100. In one NRF embodiment, the NRF 100 may store the NFDeregister request in memory of the NRF 100 and prevent processing of the NFDeregister request.

[0091] In step 1106, the process includes receiving an NF heartbeat message for the NF. For example, the NRF or SCP 100 or 101 may receive an NF heartbeat message for the same NF or NFs as the queued NFDeregister request.

[0092] In step 1108, the process includes determining that the NF heartbeat message is received within the NF heartbeat time interval of the NF. For example, the NRF or SCP 100 or 101 may determine that the NF heartbeat message is received within the NF heartbeat time interval of the NF identified in the NFDeregister request.

[0093] In step 1110, the process includes preventing processing of the NFDeregister request and blacklisting the source of the NFDeregister request in response to determining that the NF heartbeat message is received within the NF heartbeat time interval of the NF. For example, in one NRF embodiment, the NRF can prevent processing of a queued NFDeregister request by dropping the request, ignoring the request, or overwriting the request. The NRF can blacklist the source of the request by refusing to process other communications from the source. In one SCP embodiment, the SCP can prevent processing of a queued NFDeregister request by dropping, ignoring, or overwriting the NFDeregister request, or otherwise refraining from forwarding the NFDeregister request to the NRF. The SCP can blacklist the source of the request by refusing to process or forward other communications from the source.

[0094] 12 is a flowchart illustrating an example process performed by an NRF to restore a deregistered NF profile after detecting a mass NF deregistration attack. Referring to FIG. 12, at step 1200, the process includes receiving an NFDeregister request to deregister an NF. For example, the NRF 101 may receive an NFDeregister request from a hacker or from a real NF that seeks to deregister the hacker's NF profile.

[0095] A copy of the NF profile is saved in step 1202. Step 1202 may be performed if the NFDeregister request is classified as non-suspicious through application of suspicious NFDeregister request classification rules.

[0096] In step 1204, the NFDeregister request is processed to deregister the NF. For example, the NFDeregister may be processed, resulting in the deletion of the NF profile in the NF profile database maintained by the NRF and the deregistration of the NF.

[0097] At step 1206, the process includes receiving an NF heartbeat message for the NF. For example, the NRF 100 may receive an NF heartbeat message identifying the NF by its NF instance ID, indicating that the NF is available to provide service.

[0098] At step 1208, the process includes determining that the NF heartbeat message is received within the NF heartbeat time interval of the NF. For example, the NRF 100 may determine that the NF heartbeat message is received within the NF heartbeat time interval or before expiration of the NF heartbeat timer of the NF.

[0099] At step 1210, the process includes restoring the registration of the NF using the saved copy of the NF's NF profile. For example, the NRF 100 may restore the registration status of the NF by moving the saved copy of the NF's NF profile to an NF profile database and changing the registration status of the NF to REGISTERED.

[0100] The subject matter described herein can achieve at least the following advantages. Reduce the likelihood of a successful mass NF deregistration attack.

[0101] Mass deregistration can render network services unavailable, which can result in network outages. The subject matter described herein reduces the likelihood of a successful attack that would cause such an outage.

[0102] Easy to implement. Since the NRF or SCP already receives NFDeregister messages that can be used to conduct mass NF deregistration attacks, adding security features to hide such messages is easily implemented.

[0103] ·Can be implemented either by NRF or SCP. Together, the NRF and SCP provide a centralized place to hide NFDeregister messages to reduce the likelihood of a successful mass NF deregistration attack.

[0104] The disclosure of each of the following references is incorporated herein by reference in its entirety. References 1. 3rd Generation Partnership Project, Technical Specification Group Services and System Aspects, System architecture for the 5G System (5GS), Stage 2 (Release 17) 3GPP TS23.501V17.0.0 (2021-03).

[0105] 2. 3rd Generation Partnership Project, Technical Specification Group Core Network and Terminals, 5G System, Network Function Repository Services, Stage 3 (Release 17) 3GPP TS29.510V17.1.0 (2021-03).

[0106] It will 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. Moreover, the foregoing description is intended to be illustrative only, and not limiting, as the subject matter described herein is defined by the claims hereinafter set forth.

Claims

1. 1. A method for protecting against mass network function (NF) deregistration attacks, the method comprising: A Network Function Repository Function (NRF) or a Service Communication Proxy (SCP) including at least one processor and a memory, receiving an NFDelegister request to deregister an NF; classifying the NFDregister request as suspicious based on application of suspicious NFDregister request classification rules; queuing the NFDregister request in response to classifying the NFDregister request as suspicious; receiving an NF heartbeat message for the NF; determining that the NF heartbeat message is received within an NF heartbeat time interval of the NF; and in response to determining that the NF heartbeat message is received within the NF heartbeat time interval of the NF, preventing processing of the NFDregister request and blacklisting a source of the NFDregister request.

2. 2. The method of claim 1, wherein classifying the NFDregister request as suspicious based on application of suspicious NFDregister request classification rules comprises classifying the NFDregister request as suspicious in response to determining that processing the NFDregister request would cause a number of available NFs of the same type as the NF to fall below a minimum operator-specified threshold.

3. 2. The method of claim 1, wherein classifying the NFDregister request as suspicious based on application of suspicious NFDregister request classification rules comprises classifying the NFDregister request as suspicious in response to a rate of NFDregister requests exceeding an operator-specified threshold.

4. 2. The method of claim 1, wherein classifying the NFDregister request as suspicious based on application of suspicious NFDregister request classification rules comprises classifying the NFDregister request as suspicious based on detected differences between learned historical traffic patterns and current traffic patterns of which the NFDregister request is a part.

5. The method of claim 1 , wherein classifying the NFDregister request as suspicious based on application of suspicious NFDregister request classification rules comprises classifying the NFDregister request as suspicious by default.

6. 6. The method of claim 1, wherein the receiving, classifying, determining, preventing processing, and blacklisting steps are performed in the NRF, and the method further comprises: transitioning to a SUSPECTED state in response to classifying the NFDRegister request as suspicious; and applying, in the SUSPECTED state, an operator-defined policy that determines whether to send an NFDRegister response and whether to respond to an NFDiscover request.

7. Responding to the NFDRegister request with an NFDRegister response; and inserting a suspicious timer into the NFDelegister response to instruct the NF to delay shutdown until expiry of the suspicious timer.

8. The method of any one of claims 1 to 5, wherein the receiving, classifying, determining, preventing processing, and blacklisting steps are performed at the SCP, and the preventing processing of the NFDRegister request includes refraining from forwarding the NFDRegister request to the NRF.

9. 9. The method of claim 8, comprising responding at the SCP, on behalf of the NRF, to the NFDregister request with an NFDregister response.

10. 1. A method for protecting against mass network function (NF) deregistration attacks, the method comprising: A NF Repository Function (NRF) including at least one processor and a memory, receiving an NFDelegister request to deregister an NF; storing in said memory a copy of the NF profile of said NF; processing the NFDelegister request to deregister the NF; receiving an NF heartbeat message for the NF; determining that the NF heartbeat message is received within an NF heartbeat time interval of the NF; and in response to determining that the NF heartbeat message is received within the NF heartbeat time interval, restoring registration of the NF using the saved copy of the NF profile.

11. 1. A system for protecting against mass network function (NF) deregistration attacks, the system comprising: a NF Repository Function (NRF) or Service Communication Proxy (SCP) including at least one processor and a memory; a mass NF deregistration attack mitigation module implemented by the at least one processor to receive an NFDregister request to deregister an NF, classify the NFDregister request as suspicious based on application of suspicious NFDregister request classification rules, queue the NFDregister request in response to classifying the NFDregister request as suspicious, receive an NF heartbeat message for the NF, determine that the NF heartbeat message is received within an NF heartbeat time interval for the NF, and prevent processing of the NFDregister request and blacklist a source of the NFDregister request in response to determining that the NF heartbeat message is received within the NF heartbeat time interval for the NF.

12. 12. The system of claim 11, wherein the mass NF deregistration attack mitigation module is configured to classify the NFDelegister request as suspicious in response to determining that processing the NFDelegister request would cause a number of available NFs of the same type as the NF to fall below a minimum operator-specified threshold.

13. The system of claim 11 , wherein the mass NF deregistration attack mitigation module is configured to classify the NFDregister requests as suspicious in response to a rate of the NFDregister requests exceeding an operator-specified threshold.

14. 12. The system of claim 11, wherein the mass NF deregistration attack mitigation module is configured to classify the NFDregister request as suspicious based on a detected difference between learned historical traffic patterns and a current traffic pattern of which the NFDregister request is a part.

15. The system of claim 11 , wherein the mass NF deregistration attack mitigation module is configured to classify the NFDelegister request as suspicious by default.

16. 16. The system of claim 11, wherein the NRF or the SCP comprises an NRF, and wherein the mass NF deregistration attack mitigation module is configured to transition to a SUSPECTED state in response to classifying the NFDregister request as suspicious, and to apply, in the SUSPECTED state, operator-defined policies that determine whether to send an NFDregister response and whether to respond to an NFDiscover request.

17. The mass NF deregistration attack mitigation module includes: Responding to the NFDRegister request with an NFDRegister response; The system of any one of claims 11 to 15, configured to insert a suspicious timer in the NFDregister response to instruct the NF to delay shutdown until expiry of the suspicious timer.

18. The system of any one of claims 11 to 15, wherein the NRF or the SCP comprises an SCP, and the mass NF deregistration attack mitigation module is configured to prevent processing of the NFDelegister request by refraining from forwarding the NRF to the NRF.

19. 20. The system of claim 18, wherein the mass NF deregistration attack mitigation module is configured to respond to the NFDelegister request with an NFDelegister response on behalf of the NRF.

20. A program that causes a computer to execute the method described in any one of claims 1 to 5.

Images