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] A producer NF registers 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. A consumer NF 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). The SCP subscribes with the NRF and obtains reachability and service profile information about producer NF service instances. Consumer NFs connect to the Service Communication Proxy, which load balances traffic between producer NF service instances offering the required service or directly routes traffic to the destination producer NF instance.

[0007] In addition to the SCP, 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 the 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 assist with 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, and is used to deregister an NF from the NRF by deleting the NF profile of the NF stored by the NRF. One issue with the NFDeregister service operation is that this service operation can be exploited by hackers to mass deregister NFs and make 5G services unavailable. The result of a successful deregistration to the NRF is the deletion of the NF profile of the NF instance in the NF profile database of the NRF, 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 and a network outage occurs.

[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, i.e., a duplication mechanism to avoid mass NF deregistration attacks.

[0010] In light of these and other challenges, a need exists for improved methods, systems, and computer-readable media for protecting against Mass NF 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 an NF heartbeat time interval of the NF.

[0012] According to another aspect of the subject matter described in this specification, the step of classifying the NFDeregister request as suspicious based on application of the 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-defined threshold.

[0013] According to another aspect of the subject matter described in this specification, the step of 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 in this specification, the step of 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 a current traffic pattern 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 steps of receiving, classifying, determining, preventing processing, and blacklisting 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, an operator-defined policy that determines 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 a mass NF deregistration attack 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 in this specification, the steps of receiving, classifying, determining, preventing processing, and blacklisting are performed in an SCP, and the step of 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 a mass NF deregistration attack 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 for receiving an NFDeregister request to deregister an NF, classifying the NFDeregister request as suspicious based on application of a suspicious NFDeregister request classification rule, queuing the NFDeregister request in response to classifying the NFDeregister 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 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.

[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 an NFDeregister request as suspicious in response to a rate of the 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 in the SUSPECTED state, apply operator-defined policies 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 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 with an NFDeregister response on behalf of the NRF.

[0029] According to another aspect of the subject matter described herein, a non-transitory computer-readable medium having executable instructions stored thereon that, when executed by a processor of a computer, controls 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 an NF heartbeat time interval of the NF.

[0030] According to another aspect of the subject matter described herein, a method is provided for protecting against mass network function (NF) deregistration attacks. The method includes receiving an NFDeregister request to deregister an NF at an NRF including at least one processor and a memory. 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 registration of the NF using the stored copy of the NF profile.

[0031] The subject matter described herein may be implemented in a combination of software with hardware and / or firmware. For example, the subject matter described herein may be implemented in software executed by a processor. In one exemplary embodiment, the subject matter described herein may 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 a 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, application specific integrated circuits, and the like. In addition, computer-readable media implementing the subject matter described herein may be located on a single device or computing platform, or may 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 description of the drawings]

[0033] [Figure 1] FIG. 1 is a network diagram illustrating an example 5G system network architecture. [Diagram 2] A message flow diagram showing example messages exchanged for an NFDeregister service operation. [Diagram 3] A message flow diagram showing example messages exchanged for an NF heartbeat service operation. [Figure 4A] FIG. 13 is a message flow diagram showing example messages exchanged for a mass NFDeregister attack where messages do not pass through the SCP before reaching the NRF. [Figure 4B] FIG. 13 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. [Diagram 5] FIG. 13 is a message flow diagram illustrating example messages exchanged using NRF to protect against a mass NFDeregister attack. [Figure 6A] FIG. 13 is a message flow diagram illustrating example messages exchanged between an NF and an NRF for NF deregistration and shutdown without suspicious timers. [Figure 6B] FIG. 13 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. 13 is a message flow diagram showing example 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. 13 is a message flow diagram showing example 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] 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. 13 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] 13 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 NF deregistration attacks. [Figure 11] 1 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] 1 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 PREFERRED EMBODIMENTS

[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 in the same Home Public Land Mobile Network (HPLMN). As described above, the NRF 100 can maintain profiles of available producer NF service instances and their supported services, and 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 NF or service profiles of producer NF instances. 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 Notification (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] In Figure 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 in the network, a User Defined Manager (UDM) 104 that manages user data, and an Application Function (AF) 106 that provides application services.

[0037] The NF shown in Figure 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 4G networks. 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 that are attached to the network. The NEF 118 performs functions 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 wireless links. The Radio Access Network 120 may be accessed using a gNodeB (gNB) (not shown in FIG. 1) or other wireless access points. The User Plane Function (UPF) 122 may support various proxy functionalities for user plane services. One example of such proxy functionality is a Multi-Path Transmission Control Protocol (MPTCP) proxy functionality. The UPF 122 may also support performance measurement functionality that may 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 traffic coming from another PLMN and provides topology hiding for traffic going out from 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 the other for the foreign PLMN.

[0041] As described above, one problem in 5G networks is the vulnerability of the network to mass NF deregistration attacks, in which an attacker attempts to deregister some or all of the NF instances that provide one or more critical services to the network. FIG. 2 is a message flow diagram illustrating exemplary messages exchanged for an 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 a hacker who wishes to deregister an NF sends an NFDeregister request to the NRF. In FIG. 2, in line 1, the NFDeregister request is an HTTP DELETE message that identifies that an NF instance is to be deregistered by an NF instance ID. The NRF 100 receives the NFDeregister request, and if the request is successfully processed, in line 2a, the NRF 100 returns a 204 No Content message. 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 removal 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 especially required 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 services. 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 that 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 NoContent message if the NF heartbeat service operation is successful. At line 2b, the NRF 100 returns a 3xx, 4xx, or 5xx message if the NF heartbeat service operation is not successful or if a redirection has occurred. 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 TS 29.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 may be used to protect against mass NF deregistration attacks are described below.

[0047] As can be seen, one possible issue within 5G networks is a mass NF deregistration attack, where a hacker deregisters some or all instances of NFs of a given type. 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 a hacker to bulk deregister producer NFs, causing a network outage. Normal rate limits that limit the number of SBI requests based on HTTP method and Uniform Resource Identifier (URI) are not sufficient to protect against mass NFDeregister attacks, as 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, as 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. There is a need to detect or mitigate the possibility of a successful mass NF deregistration attack.

[0048] FIG. 4A is a message flow diagram illustrating example messages that may be exchanged in a mass NF deregistration attack where 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 of 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 the NRF 100. The 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-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, UDM services are still available in the network because UDM1 104A and UDM2 104B are still registered.

[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] At step 13, the hacker 400 sends an NFDeregister request to the NRF 100 to deregister UDM1 104A. At step 14, the NRF 100 accepts the NFDeregister request for UDM1 104A and deletes the NF profile. At step 15, the NRF 100 sends an NFDeregister response to the hacker 400. After step 15, the UDM service is no longer available. Since 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 even 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] FIG. 4B is a message flow diagram showing exemplary messages exchanged for a mass NFDeregister attack, where messages pass through the SCP before reaching the NRF. The NFDeregister request message in step 1, step 5, and step 9 of FIG. 4B is the same as that in step 7, 10, and 13 of FIG. 4A, except that in FIG. 4B, the NFDeregister request message is proxied by the SCP 101 and forwarded to the NRF 100 in steps 2, 6, and 10 of FIG. 4B. The corresponding NFDeregister response is also proxied by the SCP 101, as shown in steps 3, 4, 7, 8, 11, and 12 of FIG. 4B. The end result in FIG. 4B is the same as in FIG. 4A, i.e., when all of the UDMs are deregistered, a network outage occurs, as shown in step 13 of FIG. 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 as per operator configured policy. If an NFDeregister service request is marked as suspicious, NFs that have subscribed to receive notifications of changes in the status of the NF on 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 on 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 when it does not receive an NF heartbeat (NFUpdate) before the expiration of an NF heartbeat timer. The failure to receive an NF heartbeat confirms that the deregistration has occurred 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 informed of the possible attack. If an NF heartbeat is received for a deregistered profile that has been 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, the 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 a NF heartbeat message is received for a deregistered NF, the NRF 100 can restore the NF profile of the NF using the saved copy. If mass NF deregistration attack mitigation functionality is implemented in the SCP, the NRF 100 can send a NF heartbeat error message to the deregistered NF via the SCP when a NF heartbeat request is received for a deregistered NF. The SCP can forward the NF heartbeat error message to the NF, and the NF can reregister itself with the NRF. When a NFRegister request is received for an NF with a suspect NFDeregister request queued, the NF can be deregistered and then registered with a new profile. FIG. 5 is a message flow diagram illustrating example messages exchanged when the NRF 100 utilizes the method described herein to detect and protect against successful mass NF deregistration attacks.5, 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 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 the NRF 100. The 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-UDM104C can all be discovered and can provide services in the network.

[0059] In step 7, the hacker 400 sends a 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 may accept the NFDeregister request by classifying the NFDeregister request as normal based on application of suspicious NFDeregister request classification rules. For example, one rule may be that a UDM service in a network must be provided by at least two UDMs. Since the NFDeregister request in step 7 only deregisters one of the three UDMs, the NFDeregister request in step 7 may be classified as normal or non-suspicious. Even if the NFDeregister request is classified as normal, the NRF 100 may store a copy of the NF profile of the NRF 100 for subsequent restoration of the NF's registration in case a mass NF deregistration attack is detected.

[0060] In step 9, the NRF 100 sends a 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 services are still available in the network.

[0061] At step 10, the hacker 400 sends an NFDeregister request to the NRF 100 that identifies UDM2 104B. At step 11, the NRF 100 applies suspicious NFDeregister request classification rules and classifies the NFDeregister request at 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 a 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 a suspicious NFDeregister response without a timer, and FIG. 6B shows the processing of a suspicious NFDeregister response with a timer. In FIG. 6A, in step 1, the NF 200 sends a NFDeregister request to the NRF 100. In step 2, the NRF 100 sends a suspicious NFDeregister response without a timer. Upon receiving the suspicious NFDeresitter response without a timer, the NF 200 shuts down as shown in step 3.

[0063] FIG. 6B shows the same message flow as FIG. 6A, except that in step 2, the NFDeregister response includes a suspicious timer. In step 3 of FIG. 6B, the NF 200 delays processing of 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 has legitimately deregistered itself.

[0064] Returning to the message flow of Figure 5, at step 13, the hacker 400 sends a NFDeregister request to the NRF 100 to deregister UDM1 104A. At step 14, the NRF 100 applies suspicious NFDeregister 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, UDMs 104A and 104B send NF heartbeat request messages to the NRF 100. Since the NF requesting deregistration should not send NF heartbeat requests, in step 19, the 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, the 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 may be blacklisted to prevent further SBI service request messages from the source from being processed. Thus, using the steps of FIG. 5, a successful Mass NF deregistration attack is thwarted.

[0066] FIG. 7A 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. The SCP tracks NFDeregister requests and NF heartbeat messages that are proxied through the SCP. The SCP uses the NF heartbeat timer to determine whether an NFDeregister request that is identified as suspicious (or non-suspicious) was valid or invalid. As in the NRF embodiment 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 as per the network operator's set policy or rules. For NFDeregister requests that are identified as suspicious, the SCP sends NFDeregister responses to the client NFs, each of which includes a suspicious timer, which gives the impression that the deregistration worked, and therefore 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 that 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 an NF that has a suspicious NFDeregister request 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 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 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 for a predetermined time interval (i.e., prevents the NFDeregister request from being forwarded to the NRF 100), 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 NFDeregister response to the hacker 400 on behalf of the NRF 100. The SCP 101 may include a suspicious timer in the NFDeregister 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 Figures 8A and 8B. The messages exchanged in Figures 8A and 8B are the same as those shown in Figures 6A and 6B, except that the NFDeregister request is terminated and queued by the SCP, rather than the NRF and the 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 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. 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 heatbeat timer. Failure to receive an NF heartbeat confirms that the deregistration has been made by the NF owning the profile. If an NF heartbeat is received for an NF with a queued suspect deregistration request, the source of the deregistration request may be blacklisted and the network operator may be informed of a possible attack. If an NF heartbeat request is received for a profile that is being deregistered, 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 may re-register with the NRF.

[0071] Referring to the message flow of FIG. 7B, in step 12, UDM3 104C sends a NF heartbeat request to SCP 101. In step 13, SCP 101 forwards the NF heartbeat request to NRF 100. Since the NF instance identified in the NF heartbeat request has been deregistered, in step 14, NRF 100 sends a NF heartbeat error response to SCP 101. In step 15, SCP 101 sends a 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 a NF heartbeat request to SCP 101. The NF heartbeat request shall be within the NF heartbeat interval of UDM2 104B. Since SCP 101 should not receive NF heartbeat requests for NFs for which NFDeregister messages are being received, SCP 101 blocks or refrains from sending NFDeregister requests for UDM2 104B to NRF 100, blacklists the source of the NFDeregister 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 a 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 a NF heartbeat request to SCP 101. The NF heartbeat request shall be within the NF heartbeat interval of UDM1 104A. Since SCP 101 should not receive NF heartbeat requests for NFs for which NFDeregister messages are being received, SCP 101 blocks or refrains from sending NFDeregister requests for UDM1 104A to NRF 100, blacklists the source of the NFDeregister requests 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 a NF heartbeat response to SCP 101. In step 24, SCP 101 sends a 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, where 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 in FIG. 7C using the suspicious NFDeregister request classification rules. However, as shown in FIG. 7D, which is a continuation of the message flow in FIG. 7C, the SCP 101 sends the queued NFDeregister requests to the NRF when the 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, the 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 NFHeartbeat request is received from a blacklisted NF, the NFRegister, NFUpdate, or NFHeartbeat request may be forwarded to the NRF and the NF that sent the NFRegister, NFUpdate, or NFHeartbeat 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 the 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 FIG. 7C.

[0076] As described above, the NFDeregister request may be classified as suspicious based on operator-defined suspicious NFDeregister request identification rules or policies. The following are examples of policies that may be applied by the NRF 100 or SCP 101 in 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 would result in the number of registered UDMs falling below 2, the NFDeregister request is classified as suspicious and is queued for at least the NF Heartbeat time interval to decide whether to process or not process the NFDeregister request.

[0078] · Max Rate: Operators can specify a maximum allowed rate of NFDeregister requests. NFDeregister requests that would cause the maximum rate to be exceeded are classified as suspicious. For example, if an operator sets the maximum rate to 100 requests per minute, any NFDeregister request that would cause the rate to exceed 100 requests per minute is 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 will learn past traffic patterns and classify the 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 the 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, then any NFDeregister request that would cause the number of deregistrations to exceed the average number plus one standard deviation will 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 would cause the rate of deregistration to exceed a maximum rate threshold and would cause 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 defined by 3GPP, and the mass NFDeregister attack mitigation procedures described herein. In FIG. 9, the REGISTERED, SUSPENDED, and UNDISCOVERABLE states are the same as those defined in 3GPP TS 29.510. The UNREGISTERED and SUSPENDED states are newly defined states that implement the mass deregistration attack mitigation procedures described herein. The NF DELETED state is the state that occurs when an NF profile is deleted. The arrows between the 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. When in the SUSPECTED state, if an NF Heartbeat message for the NF profile is received within a configured period of time, the source 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. When in the SUSPECTED state, if an NF Heartbeat message for the NF is not received within a configured period of time, the NRF deregisters the NF by deleting the NF profile from the NF profile database and transitions to the NFDELETED state.

[0083] Returning to the REGISTERED state, if an NFDeregister request is received that does not match the suspect NF deregistration policy, the NRF transitions to an 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 an NF DELETED state. In the UNREGISTERED state, if an NF heartbeat message is received within a configured time interval, the NRF transitions to a REGISTERED state for the NF profile. The remaining state transitions in Figure 9 implement the standard NFUpdate and NF heartbeat service operations as specified in 3GPP TS 29.510.

[0084] When in the SUSPECTED state, the NRF may implement operator-defined procedures to handle 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 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 not to send an NF deregistration notification but to include the NF profile in the discovery response. It should be noted that the example policies in Table 2 are illustrative and that 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 implementing the mass NF deregistration attack mitigation procedures described herein. With reference to FIG. 10, the NRF or SCP 100 or 101 includes at least one processor 1000 and a memory 1002. If 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. If the NRF or SCP 100 or 101 is an SCP, the NF profile database and the NF profile manager may be implemented on an NRF that is 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 flow chart 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. With reference to FIG. 11, in step 1100, the process includes receiving an NFDeregister request to deregister an NF. For example, the NRF or SCP 100 or 101 may receive an 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 implementation, the SCP 101 can queue the NFDeregister request and refrain from forwarding the NFDegister request to the NRF 100. In one NRF implementation, the NRF 100 can store the NFDeregister request in a 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 an 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 an 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 implementation, the NRF may prevent processing of a queued NFDeregister request by dropping the request, ignoring the request, or overwriting the request. The NRF may blacklist the source of the request by refusing to process other communications from the source. In one SCP implementation, the SCP may 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 may blacklist the source of the request by refusing to process or forward other communications from the source.

[0094] 12 is a flow chart illustrating an example process performed by an NRF to restore a deregistered NF profile after detecting a mass NF deregistration attack. With reference 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, an 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 an NF with its NF instance ID, indicating that the NF is available to provide services.

[0098] At step 1208, the process includes determining that the NF heartbeat message is received within an 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 an 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 result in network services being unavailable, which can result in a network outage. 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 perform a mass NF deregistration attack, it is easy to implement adding security features to hide such messages.

[0103] · It can be carried out 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 TS 23.501 V17.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 TS 29.510 V17.1.0 (2021-03).

[0106] It will be understood that various details of the subject matter described herein may be changed without departing from the scope of the subject matter described herein. Moreover, the foregoing description is intended to be illustrative only and not limiting, as the subject matter described herein is defined by the claims hereinafter.

Claims

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

5. The method of claim 1 , wherein classifying the NFDelegister request as suspicious based on application of suspicious NFDelegister request classification rules comprises classifying the NFDelegister 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 NFDelegister request as suspicious; and applying, in the SUSPECTED state, an operator-defined policy that determines whether to send an NFDelegister response and whether to respond to an NFDiscover request.

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

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

9. 9. The method of claim 8, comprising the step of, at the SCP, responding on behalf of the NRF to the NFDelegister request with an NFDelegister 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 NFDeregister request to deregister an NF; storing in the memory a copy of a NF profile of the NF; processing the NFDeregister 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 a Service Communication Proxy (SCP) including at least one processor and a memory; and a mass NF deregistration attack mitigation module implemented by the at least one processor to receive an NFDelegister request to deregister an NF, classify the NFDelegister request as suspicious based on application of suspicious NFDelegister request classification rules, queue the NFDelegister request in response to classifying the NFDelegister 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 NFDelegister request and blacklist a source of the NFDelegister request in response to determining that the NF heartbeat message is received within the NF heartbeat time interval for the NF.

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-defined threshold.

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

14. 12. The system of claim 11, wherein the mass NF deregistration attack mitigation module is configured to classify the NFDelegister request as suspicious based on a detected difference between learned historical traffic patterns and a current traffic pattern of which the NFDelegister 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. The system of any one of claims 11 to 15, wherein the NRF or the 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 NFDelegister request as suspicious, and to apply an operator-defined policy in the SUSPECTED state that determines whether to send an NFDelegister response and whether to respond to an NFDiscover request.

17. The mass NF deregistration attack mitigation module includes: Responding to the NFDelegister request with an NFDelegister response; The system according to any one of claims 11 to 15, configured to insert a suspicious timer in the NFDelegister 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 on behalf of the NRF with an NFDelegister response.

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

Images