Method, system, and computer-readable medium for defending against large-scale network function (NF) deregistration attacks

Abstract

A method for defending against a large-scale NF deregistration attack can be performed at an NRF or SCR. The method includes receiving an NFDeregister request to deregister an NF. The method also includes classifying the NFDeregister request as suspicious based on the application of a suspicious NFDeregister request classification rule. The method also includes queuing the NFDeregister request in response to classifying the NFDeregister request as suspicious. The method also includes receiving an NF heartbeat message about the NF. The method also includes determining that the NF heartbeat message is received within an NF heartbeat time interval for the NF. The method also includes blocking processing of the NFDeregister request and blacklisting the sender of the NFDeregister request in response to determining that the NF heartbeat message is received within the NF heartbeat time interval for the NF.

Description

[0001] Priority Claim

[0002] This application claims priority to U.S. patent application serial No. 17 / 314,329 filed on May 7, 2021, the disclosure of which is incorporated herein by reference in its entirety. Technical Field

[0003] The subject matter described herein relates to security in telecommunication networks. More specifically, the subject matter described herein relates to methods, systems, and computer-readable media for defending against large-scale NF deregistration attacks. Background Art

[0004] In a 5G telecommunication network, a network function that provides a service is referred to as a producer NF or NF service producer. A network function that consumes a service is referred to as a consumer NF or NF service consumer. A network function can be a producer NF, a consumer NF, or both, depending on whether the network function consumes a service, produces a service, or consumes and produces a service. The terms "producer NF" and "NF service producer" are used interchangeably herein. Similarly, the terms "consumer NF" and "NF service consumer" are used interchangeably herein.

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

[0006] The producer NF registers with the 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 in this article. Consumer NFs can subscribe to receive information about producer NF instances that have registered with the NRF.

[0007] 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 to the NRF and obtains reachability and service profile information about producer NF service instances. Consumer NFs connect to the SCP, and the SCP load balances traffic between producer NF service instances that provide the required service, or routes traffic directly to the destination producer NF instance.

[0008] In addition to SCP, another example of an intermediate proxy node that routes traffic between producer and consumer NFs is the Security Edge Protection Proxy (SEPP). SEPP is a network node used to protect control plane traffic exchanged between different 5G Public Land Mobile Networks (PLMNs). Thus, SEPP performs message filtering, policing, and topology hiding on all Application Programming Interface (API) messages transmitted between PLMNs.

[0009] One problem in 5G communication networks is that they are vulnerable to large-scale NF deregistration attacks. 3GPP TS29.510 defines NRF to support service discovery functions in 5G core networks. Producer NFs register with NRF so that consumer NFs can discover them and send service-based interface (SBI) requests. NRF also provides NRF management APIs to register, update, and deregister NFs to manage the NF lifecycle. The service operation for deregistering NFs is called the NFDeregister service operation and is used to deregister NFs with NRF by deleting the NF profile of the NF stored by NRF. One problem with the NFDeregister service operation is that it can be abused by hackers to deregister NFs on a large scale, resulting in unavailability of 5G services. The result of a successful deregistration with NRF is to delete the NF profile of the NF instance in the NF profile database of NRF, making the NF instance undiscoverable. If all NF instances of a given type are deregistered, the services provided by the NF will not be accessible and a network outage will occur.

[0010] Although NRF authenticates users during NFDeregister service operations, hackers can still find weaknesses in the authentication mechanism. Therefore, a more robust defense (i.e., a redundant mechanism) is needed to avoid large-scale NF deregistration attacks.

[0011] In view of these and other difficulties, there is a need for improved methods, systems, and computer-readable media for defending against large-scale NF deregistration attacks. Summary of the invention

[0012] A method for defending against a large-scale NF deregistration attack may be performed at an NRF or an SCP. The method includes receiving an NFDeregister request to deregister an NF. The method also includes classifying the NFDeregister request as suspicious based on the application of a suspicious NFDeregister request classification rule. The method also includes queuing the NFDeregister request in response to classifying the NFDeregister request as suspicious. The method also includes receiving an NF heartbeat message about the NF. The method also includes determining that the NF heartbeat message is received within an NF heartbeat time interval for the NF. The method also includes blocking processing of the NFDeregister request and blacklisting the sender of the NFDeregister request in response to determining that the NF heartbeat message is received within an NF heartbeat time interval for the NF.

[0013] According to another aspect of the subject matter described herein, classifying a NFDeregister request as suspicious based on application of a suspicious NFDeregister request classification rule 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 threshold defined by an operator.

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

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

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

[0017] According to another aspect of the subject matter described herein, receiving, classifying, determining, blocking processing, and blacklisting are performed at an NRF, and the method for defending against large-scale NF deregistration attacks also includes transitioning to a SUSPECTED state in response to classifying an NFDeregister request as suspicious, and applying an operator-defined policy in the SUSPECTED state that determines whether to send an NFDeregister response and respond to an NFDiscover request.

[0018] According to another aspect of the subject matter described herein, a method for defending against a large-scale NF deregistration attack includes responding to a NFDeregister request with a NFDeregister response, and inserting a suspect timer in the NFDeregister response for instructing the NF to delay shutdown until the suspect timer expires.

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

[0020] According to another aspect of the subject matter described herein, a method for defending against a large-scale NF deregistration attack includes responding, at an SCP, on behalf of an NRF, to a NFDeregister Request with a NFDeregister Response.

[0021] According to another aspect of the subject matter described herein, a system for defending against large-scale network function (NF) deregistration attacks is provided. The system includes an NRF or SCP, the NRF or SCP including at least one processor and a memory. The system also includes a large-scale NF deregistration attack mitigation module implemented by at least one processor, for receiving an NFDeregister request to deregister an NF, classifying the NFDeregister request as suspicious based on the application of a suspicious NFDeregister request classification rule, queuing the NFDeregister request in response to classifying the NFDeregister as suspicious, receiving an NF heartbeat message about the NF, determining that the NF heartbeat message is received within the NF heartbeat time interval for the NF, and blocking the processing of the NFDeregister request and blacklisting the sender of the NFDeregister request in response to determining that the NF heartbeat message is received within the NF heartbeat time interval for the NF.

[0022] According to another aspect of the subject matter described herein, the Mass NF Deregister Attack Mitigation Module is configured to classify a 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 an operator-defined minimum threshold.

[0023] According to another aspect of the subject matter described herein, the Massive NF Deregister Attack Mitigation Module is configured to classify NFDeregister requests as suspicious in response to a rate of NFDeregister requests exceeding an operator defined threshold.

[0024] According to another aspect of the subject matter described herein, the Massive NF Deregister Attack Mitigation Module is configured to classify a NFDeregister request as suspicious based on a detected difference between a learned past traffic pattern and a current traffic pattern of which the NFDeregister request is a part.

[0025] According to another aspect of the subject matter described herein, the Mass NF Deregister Attack Mitigation Module is configured to classify NFDeregister requests as suspicious by default.

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

[0027] According to another aspect of the subject matter described herein, the Mass NF Deregistration Attack Mitigation Module is configured to respond to a NFDeregister Request with a NFDeregister Response; and insert a suspect timer in the NFDeregister Response for instructing the NF to delay shutdown until the suspect timer expires.

[0028] According to another aspect of the subject matter described herein, the NRF or the SCP includes the SCP, and the Large NF Deregister Attack Mitigation Module is configured to prevent processing of NFDeregister requests by avoiding forwarding the NFDeregister requests to the NRF.

[0029] According to another aspect of the subject matter described herein, the Massive NF Deregistration Attack Mitigation Module is configured to respond to the NFDeregister Request with a NFDeregister Response on behalf of the NRF.

[0030] According to another aspect of the subject matter described herein, a non-transitory computer-readable medium having executable instructions stored thereon is provided, wherein the executable instructions, when executed by a processor of a computer, control the computer to perform steps. The steps are performed at an NRF or an SCP. The steps include receiving an NFDeregister request to deregister an NF. The steps also include classifying the NFDeregister request as suspicious based on the application of a suspicious NFDeregister request classification rule. The steps also include queuing the NFDeregister request in response to classifying the NFDeregister request as suspicious. The steps also include receiving an NF heartbeat message about the NF. The steps also include determining that an NF heartbeat message is received within an NF heartbeat time interval for the NF. The steps also include blocking processing of the NFDeregister request and blacklisting the sender of the NFDeregister request in response to determining that an NF heartbeat message is received within an NF heartbeat time interval for the NF.

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

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

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

[0034] Figure 1 is a network diagram illustrating an exemplary 5G system network architecture;

[0035] Figure 2 is a message flow diagram illustrating exemplary messages exchanged for a NFDeregister service operation;

[0036] Figure 3 is a message flow diagram illustrating exemplary messages exchanged for an NF heartbeat service operation;

[0037] Figure 4A is a message flow diagram illustrating exemplary messages exchanged for a large-scale NFDeregister attack, wherein the messages do not pass through the SCP before reaching the NRF;

[0038] Figure 4B is a message flow diagram illustrating exemplary messages exchanged for a large-scale NFDeregister attack, wherein the messages pass through the SCP before reaching the NRF;

[0039] Figure 5 is a message flow diagram illustrating exemplary messages exchanged using NRF for defending against large-scale NFDeregister attacks;

[0040] Fig. 6A is a message flow diagram illustrating exemplary messages exchanged between a NF and an NRF for NF deregistration and shutdown in the absence of a suspect timer;

[0041] Figure 6B is a message flow diagram illustrating exemplary messages exchanged between a NF and an NRF for NF deregistration, including a suspect timer that enables a graceful shutdown of the deregistered NF;

[0042] Fig. 7A is a message flow diagram illustrating exemplary messages exchanged using SCP for defending against large-scale NFDeregister attacks, wherein SCP classifies NFDeregister requests matching operator-specified criteria as suspicious and queues the suspicious requests;

[0043] Figure 7B yes Fig. 7A a continuation of the message flow in , wherein the SCP refrains from sending a queued suspicious NFDeregister request to the NRF when receiving an NF Heartbeat message for the NF during the NF Heartbeat time interval for the NF;

[0044] Figure 7Cis a message flow diagram illustrating exemplary messages exchanged using SCP for defending against large-scale NFDeregister attacks, wherein SCP classifies NFDeregister requests matching operator-specified criteria as suspicious and queues the suspicious requests;

[0045] Fig.7D yes Figure 7C a continuation of the message flow in , wherein the SCP sends a queued NFDeregister request to the NRF when no NF Heartbeat Request is received within the NF Heartbeat Time Interval for the NF;

[0046] Fig. 8A is a message flow diagram illustrating exemplary messages exchanged between a NF and an SCP for NF deregistration and shutdown in the absence of a suspect timer;

[0047] Figure 8B is a message flow diagram illustrating exemplary messages exchanged between a NF and an SCP for NF deregistration, including a suspect timer to enable a smooth shutdown of the deregistered NF;

[0048] Fig. 9 is a state transition diagram illustrating exemplary state transitions associated with deregistering a NF to defend against a large-scale NF deregistration attack;

[0049] Fig.10 is a block diagram illustrating an exemplary architecture of an NRF or SCP for defending against large-scale NF deregistration attacks;

[0050] Fig.11 is a flow chart illustrating an exemplary process performed by an NRF or SCP for classifying NFDeregister requests and suspicious requests and defending against large-scale NF deregistration attacks using NF heartbeat messages; and

[0051] Fig.12 is a flow chart illustrating an exemplary process performed by an NRF for restoring a deregistered NF profile after detecting a large-scale NF deregistration attack. DETAILED DESCRIPTION

[0052] Figure 1 is a block diagram illustrating an exemplary 5G system network architecture. Figure 1The architecture in includes NRF 100 and SCP 101, which may be located in the same Home Public Land Mobile Network (HPLMN). As described above, NRF 100 may maintain profiles of available producer NF service instances and the services they support, and allow consumer NF or SCP to subscribe to new / updated producer NF service instances and be notified of registrations of these instances. SCP 101 may also support service discovery and selection of producer NF instances. SCP 101 may perform load balancing of connections between consumer NFs and producer NFs.

[0053] The NRF 100 is a repository of the NF or service profile of the producer NF instance. In order to communicate with the producer NF instance, the 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 defined 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.

[0054] exist Figure 1 In the example shown, any network function can be a consumer NF, a producer NF, or both, depending on whether they are requesting services, providing services, or requesting and providing services. In the example shown, the NFs include a policy control function (PCF) 102 that performs policy-related operations in the network, a unified defined management (UDM) function 104 that manages user data, and an application function (AF) 106 that provides application services.

[0055] Figure 1 The NF shown in FIG. 1 also includes a session management function (SMF) 108, which 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 to access the network.

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

[0057] Radio access network (RAN) 120 connects user equipment (UE) 114 to the network via wireless links. gNode B (gNB) ( Figure 1 The UE 114 may use a wireless access point (not shown) or other wireless access point to access the radio access network 120. The user plane function (UPF) 122 may support various proxy functions for user plane services. An example of such a proxy function is a multipath transmission control protocol (MPTCP) proxy function. The UPF 122 may also support a performance measurement function that the UE 114 may use to obtain network performance measurements. Figure 1 Also illustrated in FIG. 1 is a data network (DN) 124 through which the UE accesses data network services, such as Internet services.

[0058] SEPP 126 filters incoming traffic from another PLMN and performs topology hiding for traffic leaving the home PLMN. SEPP 126 can communicate with a SEPP in a foreign PLMN, which manages security for that 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.

[0059] As mentioned above, one issue in 5G networks is that the network is vulnerable to large-scale NF deregistration attacks, where 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 TS 29.510. According to the NFDeregister service operation, a NF service consumer or hacker seeks to deregister and the NF sends a NFDeregister request to the NRF. Figure 2 In line 1 of , the NFDeregister request is an HTTP DELETE message that identifies the NF instance being deregistered by the NF instance ID. The NRF 100 receives the NFDeregister request, and if the request is successfully processed, then in line 2a, the NRF 100 returns a 204 No Content message. If the deregistration request is unsuccessful 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 a redirection. The result of successfully processing 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. It should be noted that the NFDeregister service operation is required, especially in a cloud native environment, where NF instances are frequently allocated and deallocated as cloud resource requirements change.

[0060] Another service operation defined in 3GPP TS 29.510 is the NF Heartbeat service operation. The NF Heartbeat service operation is used by the 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 fails to send an NFUpdate request within the NF Heartbeat interval defined by the NRF in the Registration Response, then the NRF marks the NF Profile of that NF as unavailable.

[0061] Figure 3 is a message flow diagram illustrating exemplary messages exchanged in NF Heartbeat service operations. Figure 3 , in line 1, the NF service consumer 200 sends a NF heartbeat request message to the NRF 100, thereby identifying the NF instance to which the NF heartbeat request message applies. In line 2a, if the NF heartbeat service operation is successful, then 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 unsuccessful or if a redirection occurs, then in line 2b, the NRF 100 returns a 3xx, 4xx, or 5xx message. Therefore, the NF heartbeat process provides a way for the NRF 100 to ensure that the NF registered with the NRF 100 is still operational.

[0062] When a NF registers with an NRF, 3GPP TS 29.510 defines the following states of the NF:

[0063]

[0064]

[0065] Table 1: 3GPP defined NF states In Table 1, the registered NF states include REGISTERED (where the NF profile is discoverable by other NFs), SUSPENDED (where the NF instance is registered but not operational or discoverable), and UNDISCOVERABLE (where the NF instance is registered but not discoverable by other NFs). Additional states that can be used to defend against large-scale NF deregistration attacks are described below.

[0066] As mentioned above, one problem that can occur in 5G networks is a large-scale NF deregistration attack, in which a hacker deregisters some or all instances of a given type of NF. The NFDeregister service operation can be used to deregister already registered NFs and is a service required by NFs to manage resource utilization. However, the NFDeregister service operation can be abused by hackers to deregister producer NFs on a large scale, causing network disruptions. Normal rate limits that limit the number of SBI requests based on HTTP methods and uniform resource identifiers (URIs) are not sufficient to defend against large-scale NFDeregister attacks because attackers can stagger NFDeregister requests to pass the rate limit check. Setting the rate limit for a given type of HTTP message to a lower value may not be ideal because valid NFDeregister requests will be limited. 5G networks are designed to be cloud-native, which requires frequent NF registration and deregistration to create and remove network slices. It is necessary to detect and reduce the likelihood of success of large-scale NF deregistration attacks.

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

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

[0069] In step 5 of the message flow diagram, UDM3 104C sends a NFRegister request to NRF 100. NRF 100 registers UDM3 104C by storing the NF profile of UDM2 104B in the NF profile database and responds with a NFRegister response message in step 6. Therefore, after step 6, UDMs 104A-104C are all discoverable and able to provide services in the network.

[0070] In step 7, the hacker 400 sends a NFDeregister request identifying UDM3 104C to the NRF 100. In step 8, the NRF 100 accepts the NFDeregister request and deletes the NF profile for UDM3 104C. 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 not discoverable in the network. However, because UDM1 104A and UDM2 104B are still registered, the UDM services are still available in the network.

[0071] In step 10, the hacker 400 sends a NFDeregister request identifying UDM2 104B to the NRF 100. In step 11, the NRF 100 accepts the NFDeregister request and deletes the NF profile for UDM2 104B. In step 12, the NRF 100 sends a 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, the UDM service is still available because UDM1 104A is still registered.

[0072] In step 13, the hacker 400 sends a NFDeregister request to the NRF 100 for deregistering UDM1 104A. In step 14, the NRF 100 accepts the NFDeregister request and deletes the NF profile for UDM1 104A. In step 15, the NRF 100 sends a NFDeregister response to the hacker 400. After step 15, the UDM service is no longer available. Because the UDM service is critical to the normal operation of the network, a network outage occurs, as indicated in step 16. Enhanced security measures should be implemented before allowing all or even most NFs of a given type to be deregistered. The subject matter described herein provides such enhanced security measures, including classifying some NFDeregister requests as suspicious, using NF heartbeat messaging to reverse NF deregistration operations, and storing copies of deregistered NF profiles for subsequent restoration of NF registration.

[0073] Figure 4B is a message flow diagram illustrating exemplary messages exchanged for a large-scale NFDeregister attack, where the messages pass through the SCP before reaching the NRF. Figure 4B Zhongzai Figure 4B In steps 2, 6 and 10, the NFDeregister request message is proxied by SCP 101 and forwarded outside NRF 100. Figure 4B The NFDeregister request message in steps 1, 5, and 9 is the same as Figure 4A The corresponding NFDeregister response is also proxied by SCP 101, such as Figure 4B As indicated in steps 3, 4, 7, 8, 11, and 12 of . Figure 4B The net result is Figure 4A The result is the same as in , that is, when all UDMs are unregistered, a network outage occurs, such as Figure 4B as indicated in step 13 of .

[0074] An enhanced security measure provided by the subject matter described herein is to mark or classify the NFDeregister service request as suspicious when specific criteria are met according to the policy configured by the operator, and queue the NFDeregister service request for later processing. If the NFDeregister service request is marked as suspicious, the NF subscribed to receive the change notification of the state of the NF that received the suspicious NFDeregister request may or may not get the cancellation notification, depending on the operator configuration. The discovery response may or may not include the NF profile of the NF that received the suspicious NFDeregister request, depending on the operator configuration. The NFDeregister response sent to the client NF may include a suspicious timer indicating to the client that the cancellation is valid. The suspicious timer indicates to the client NF that the NFDeregister request does not need to be retried.

[0075] In another security enhancement, the queued NFDeregister service request is only processed later if the NF heartbeat (NFUpdate) is not received before the NF heartbeat timer expires. The failure to receive the NF heartbeat confirms that the deregistration is performed by the NF that owns the NF profile being deregistered. If an NF heartbeat is received for an NF with a queued suspicious deregistration request, the NF that sent the NFDeregister request can be marked as blacklisted and the network operator can be notified of a possible attack. If an NF heartbeat is received for a deregistered profile that is deregistered based on a NFDeregister request that is classified as normal or non-suspicious, the NF profile can be restored. If large-scale NF deregistration attack mitigation functionality is being implemented at the NRF, the restoration of the NF profile can be performed by retaining a copy of the NF profile when processing a normal (non-suspicious) NFDeregister request. The copy can be stored by the NRF 100 for at least the duration of the NF heartbeat timer. If an NF heartbeat message is received for a deregistered NF, the NRF 100 can use the stored copy to restore the NF profile of the NF. If the large-scale NF deregistration attack mitigation function is implemented at the SCP, then when a NF heartbeat request for a deregistered NF is received, the NRF 100 can send a 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. If a NFRegister request is received for an NF with a queued suspicious NFDeregister request, the NF can be deregistered and then registered with a new profile. Figure 5 is a message flow diagram illustrating exemplary messages exchanged when the NRF 100 utilizes the methods described herein to detect and defend against successful large-scale NF deregistration attacks. Figure 5 In step 1, UDM1 104A sends a NFRegister request to NRF 100. NRF 100 registers UDM1 104A by storing its NF profile in a NF profile database maintained by NRF 100, and responds with a NFRegister response message in step 2. After registering with the NRF, UDM1 104A can be discovered by other NFs.

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

[0077] In step 5 of the message flow diagram, UDM3 104C sends a NFRegister request to NRF 100. NRF 100 registers UDM3 104C by storing its NF profile in the NF profile database and responds with a NF Registration Response message in step 6. Therefore, after step 6, UDMs 104A-104C are all discoverable and able to provide services in the network.

[0078] In step 7, the hacker 400 sends a NFDeregister request identifying UDM3 104C to the NRF 100. In step 8, the NRF 100 accepts the NFDeregister request and deletes the NF profile for UDM3 104C. The NRF 100 may accept the NFDeregister request by classifying the NFDeregister request as normal based on the application of suspicious NFDeregister request classification rules. For example, one rule may be that UDM services in a network must be provided by at least two UDMs. Because the NFDeregister request in step 7 only deregisters 1 of the 3 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 in order to subsequently restore the registration of the NF in the event that a large-scale NF deregistration attack is detected.

[0079] 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 not discoverable in the network. However, because UDM1 104A and UDM2 104B are still registered, the UDM services are still available in the network.

[0080] In step 10, the hacker 400 sends a 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 or otherwise delay processing of the NFDeregister request for a predetermined time interval, which may be at least equal to the NF heartbeat time interval of the NF instance whose NF profile is identified in the NFDeregister request.

[0081] In step 12, the NRF 100 sends a NFDeregister response to the hacker 400. The NRF 100 may include a suspect timer in the NFDeregister response. The suspect timer may be a timer or amount of time to wait before closing and / or resending the NFDeregister response. Fig. 6A and 6B The processing of the NFDeregister response is illustrated in the figure without and with a suspect timer. Fig. 6A In the example of FIG. 1 , in step 1 , NF 200 sends a NFDeregister request to NRF 100. In step 2 , NRF 100 sends a NFDeregister response without a suspicious timer. Upon receiving the NFDeregister response without a suspicious timer, NF 200 shuts down, as indicated in step 3.

[0082] In addition to the NFDeregister response including the suspect timer in step 2, Figure 6B The diagram shows Fig. 6A Same message flow. Figure 6B In step 3 of , NF 200 delays processing of the NFDeregister response until the suspicious timer expires. While waiting for the suspicious timer to expire, NF 200 can respond to service requests from other NFs. NF 200 can also avoid resending NFDeregister requests. When the suspicious timer expires, NF 200 shuts down. Therefore, the suspicious timer allows a smooth shutdown of a NF that legally deregisters itself.

[0083] Return to Figure 5 , in step 13, the hacker 400 sends a NFDeregister request to the NRF 100 for deregistering UDM1 104A. In step 14, the NRF 100 applies the suspicious NF deregistration request classification rule to the NFDeregister request and classifies the request as suspicious. In response to classifying the NFDeregister request as suspicious, the NRF 100 may queue the request and formulate and send a NFDeregister response including a suspicious timer. In step 15, the NRF 100 sends a NFDeregister response with a suspicious timer to the hacker 400.

[0084] In steps 16-18 of the message flow diagram, UDMs 104A and 104B send NF Heartbeat Request messages to NRF 100. Because a NF that has requested deregistration should not send NF Heartbeat Requests, in step 19, NRF 100 blacklists the senders of the deregistrations of UDM1 104A and UDM2 104B whose NFDeregister Requests are queued, classifies the NFDeregister Requests as components of a large-scale NFDeregister attack, and notifies the network operator of the large-scale NFDeregister attack. In step 20, NRF 100 restores the NF profile of UDM3 104C using the copy of the NF profile stored in step 8. The sender of the NFDeregister Requests in steps 7, 10, and 13 may be blacklisted so that further SBI Service Request messages from the sender are not processed. Therefore, using Figure 5 to prevent successful large-scale NF logout attacks.

[0085] Fig. 7A is a message flow diagram illustrating exemplary messages exchanged using SCP for defending against large-scale NFDeregister attacks, wherein SCP classifies NFDeregister requests matching operator-specified criteria as suspicious requests and queues the suspicious requests. SCP tracks NFDeregister requests and NF heartbeat messages proxied through SCP. SCP uses NF heartbeat timer to decide whether NFDeregister requests identified as suspicious (or non-suspicious) are valid or invalid. Figure 5 As in the NRF implementation shown in , when certain criteria are met according to the policies or rules configured by the network operator, the SCP classifies the NFDeregister service request as suspicious and queues the NFDeregister service request for later processing. For NFDeregister requests identified as suspicious, the SCP sends NFDeregister responses to the client NF, each response including a suspicious timer, which gives the impression that the deregistration has been successful, so the client NF does not need to retry the request. The SCP forwards the NFDeregister requests classified as normal to the NRF, and queues (i.e., stores and does not forward to the NRF) the NFDeregister requests classified as suspicious, so other NFs believe that the NF has not been deleted. That is, the NF contacting the NRF will be able to discover the service profile of the NF with the suspicious NFDeregister request queued by the SCP.

[0086] refer to Fig. 7A, in step 1, the hacker 400 sends a NFDeregister request identifying UDM3 104C to SCP 101. In step 2, SCP 101 applies the operator-specified suspicious NFDeregister request classification rules, classifies the request as non-suspicious, and in step 3, forwards the NFDeregister request to NRF 100, which deletes the NF profile for UDM3 104C. In step 4, NRF 100 sends a NFDeregister response to SCP 101. In step 5, SCP 101 forwards the NFDeregister response to the hacker 400.

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

[0088] In step 8, SCP 101 sends a NFDeregister response to hacker 400 on behalf of NRF 100. SCP 101 may include a suspicious timer in the NFDeregister response. In the case where a legitimate NF deregisters itself, the suspicious timer instructs the NF to wait until the suspicious timer expires before shutting down. Fig. 8A and 8B Messages exchanged between SCP 101 and a legitimate NF deregistering itself are illustrated in FIG. Fig. 8A and 8B The messages exchanged in Fig. 6A and 6B , except that the NFDeregister request is terminated and queued by the SCP instead of the NRF and the SCP sends the NFDeregister response on behalf of the NRF.

[0089] Figure 7B yes Fig. 7AA continuation of the message flow in , wherein the SCP avoids sending a queued suspicious NFDeregister request to the NRF when an NF Heartbeat message for a NF is received during the NF Heartbeat time interval for the NF. The queued NFDeregister service request is sent to the NRF only when no NF heartbeat (NFUpdate) is received when the NF heartbeat timer expires in the future. The failure to receive the NF heartbeat confirms that the deregistration was performed by the NF owning the profile. If an NF heartbeat is received for an NF with a queued suspicious deregistration request, the sender of the deregistration request can be blacklisted and the network operator can 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. The deregistered NF can re-register with the NRF in response to receiving an NF heartbeat response indicating an error.

[0090] refer to Figure 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. Because 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.

[0091] In step 17, UDM2 104B transmits a NF Heartbeat Request to SCP 101. It is assumed that the NF Heartbeat Request is within the NF Heartbeat interval for UDM2 104B. Because SCP 101 should not receive a NF Heartbeat Request for a NF for which a NFDeregister message has been received, SCP 101 blocks or avoids sending the NFDeregister Request for UDM2 104B to NRF 100, blacklists the sender of the NFDeregister Request for UDM2 104B, and notifies the network operator of the possible large-scale 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 sends a NF Heartbeat Response to SCP 101 in step 19. In step 20, SCP 101 sends a NF Heartbeat Response to UDM2 104B.

[0092] In step 21, UDM1 104A sends a NF Heartbeat Request to SCP 101. It is assumed that the NF Heartbeat Request is within the NF Heartbeat interval for UDM1 104A. Because SCP 101 should not receive a NF Heartbeat Request for a NF for which a NFDeregister message has been received, SCP 101 blocks or avoids sending the NFDeregister Request for UDM1 104A to NRF 100, blacklists the sender of the NFDeregister Request for UDM1 104A, and notifies the network operator of a possible large-scale 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 sends a NF Heartbeat Response to SCP 101 in step 23. In step 24, SCP 101 sends a NF Heartbeat Response to UDM1 104A.

[0093] Figure 7C is a message flow diagram illustrating exemplary messages exchanged using SCP for defending against large-scale NFDeregister attacks, wherein SCP classifies NFDeregister requests matching operator-specified criteria as suspicious and queues the suspicious requests. Figure 7C The NFDeregister requests in steps 1, 6 and 9 of derive from UDMs 104C, 104B and 104A rather than from outside hacker 400, Figure 7C The message flow in Fig. 7A Using the suspicious NFDeregister request classification rule, the NFDeregister request Figure 7C However, if Fig.7D (It continues Figure 7C As shown in the message flow in FIG, when no NF heartbeat request is received within the NF heartbeat time interval for the NF, SCP 101 sends a queued NFDeregister request to the NRF. Fig.7D , in step 12, SCP 101 determines that the NF heartbeat timer for UDM1 104A has expired. In step 13, SCP 101 sends a queued NFDeregister request for UDM1 104A to NRF 100. In step 14, NRF 100 sends a NFDeregister response to SCP 101. It should be noted that SCP 101 does not forward the NFDeregister response to UDM1 104A because SCP 101 has already Figure 7CIn step 9 of , a NFDeregister response is sent to UDM1 104A. If a NFRegister, NFUpdate or NF Heartbeat request is received from a blacklisted NF, 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 removed from the list of blacklisted NFs.

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

[0095] As indicated above, the NFDeregister request may be classified as suspicious based on operator defined suspicious NFDeregister request identification rules or policies. The following is an example of a policy that the NRF 100 or SCP 101 may apply when classifying a NFDeregister request as suspicious.

[0096] Minimum Registrations: A deregistration that causes the number of registered NFs of a given type to fall below a configured minimum threshold will be classified as suspicious. For example, an operator may choose 2 as the minimum number of UDMs that should be registered in the network. If processing a NFDeregister request will cause the number of registered UDMs to fall below 2, then the NFDeregister request is classified as suspicious and queued for at least the NF Heartbeat interval to determine whether to process the NFDeregister request.

[0097] Maximum rate: The operator can define the maximum allowed rate of NFDeregister requests. This causes NFDeregister requests that exceed the maximum rate to be classified as suspicious. For example, if the operator sets the maximum rate to 100 requests in a minute, then NFDeregister requests that cause the rate to exceed 100 requests in a minute will be classified as suspicious.

[0098] Always: Operators can select "Always" to classify all NFDeregister requests as suspicious by default. In this 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 interval for each NF requested to be deregistered.

[0099] Automatic: This means that the NRF learns past traffic patterns and classifies NFDeregister requests if they are part of a traffic pattern that is statistically different from the learned passed traffic pattern.

[0100] The NRF 100 or SCP 101 may 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 exceeds the average by more than one standard deviation, then NFDeregister requests that exceed the average number of deregistrations plus one standard deviation will be classified as suspicious.

[0101] • Policies can be combined logically, e.g., logical AND or OR. An example of an AND policy is to classify a NFDeregister request as suspicious when the deregistration will cause the deregistration rate to exceed a maximum rate threshold and the minimum number of available NFs is below a minimum threshold.

[0102] Fig. 9 is a state transition diagram illustrating exemplary state transitions of the NRF in implementing the 3GPP defined NFUpdate, NFDeregister and NF Heartbeat service operations and the large-scale NFDeregister attack mitigation described herein. Fig. 9In the present invention, 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 large-scale NF deregistration attack mitigation process described in this article. The NF DELETED state is the state that occurs when the NF profile is deleted. The arrows between the states represent state transitions, and the boxes on each arrow represent the conditions that cause the transition from one state to another. For example, when the NRF registers the NF profile, the NRF is in the REGISTERED state for the newly registered NF profile. Starting from the REGISTERED state, when the NRF receives a NFDeregister request and classifies the NFDeregister request as suspicious based on the application of the NFDeregister request suspicious classification rules, the NRF transitions to the SUSPECTED state. While in SUSPECTED state, if an NF Heartbeat message is received regarding the NF Profile within the configured time period, then the sender of the NFDeregister request is marked as blacklisted and the NRF transitions to REGISTERED state for the NF Profile identified in the NF Heartbeat message. While in SUSPECTED state, if no NF Heartbeat message is received regarding the NF within the configured time period, then the NRF deregisters the NF by deleting the NF Profile from the NF Profile database and transitions to NF DELETED state.

[0103] Returning to REGISTERED state, upon receiving a NFDeregister request that does not match the suspicious NF deregistration policy, the NRF transitions to the UNREGISTERED state for the NF profile. In the UNREGISTERED state, if no NF heartbeat message is received for the NF profile within the configured time interval, then 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 the configured time interval, then the NRF transitions to the REGISTERED state for the NF profile. Fig. 9 The remaining state transitions in implement the standard NFUpdate and NF Heartbeat service operations defined in 3GPP TS 29.510.

[0104] When in the SUSPECTED state, the NRF may implement operator-defined procedures to handle update and discovery requests for subscribed NFs. Table 2 shown below illustrates examples of operator-configurable policies for NF deregistration notifications and discovery responses for subscribed NFs that may be implemented by the NRF when in the SUSPECTED state for a particular NF profile.

[0105] NF Guidelines Send a logout notification Include in discovery response NF Type = UDM yes yes Location = LOC1 yes no default no yes

[0106] Table 2: Configurable NRF operations for NRF when in SUSPECTED state for NF profile

[0107] According to Table 2, the first policy indicates that if the NF type is UDM and the NRF is in the SUSPECTED state for the UDM NF profile, the NRF sends a deregistration notification to the subscribed NF and includes the NF profile of the UDM in the discovery response (i.e., the response to the NFDiscover request). The second policy indicates that for the NF profile of the NF in LOC1, the NRF sends a deregistration notification but does not include the NF profile in the discovery response. The third policy is the default policy, which indicates that if a specific NF profile does not match any other policy conditions, the default NRF behavior is to not send the NF deregistration notification and include the NF profile in the discovery response. It should be noted that the policy examples in Table 2 are illustrative, and different policies for NF deregistration notification and discovery response can be configured without departing from the scope of the subject matter described herein.

[0108] Fig.10 is a block diagram illustrating an exemplary architecture of an NRF or SCP 100 or 101 for implementing the large-scale NF deregistration attack mitigation process described herein. 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 storing the NF profiles of the registered NFs and an NF profile manager 1006 managing 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 separated from the SCP. The NRF or SCP 100 or 101 includes a large-scale NF deregistration attack mitigation module 1008, which implements the subject matter described herein for reducing the likelihood of a successful large-scale NF deregistration attack. The large-scale NF deregistration attack mitigation module 1008 may be implemented using computer executable instructions stored in the memory 1002 and executed by the processor 1004.

[0109] Fig.11is a flow chart illustrating an exemplary process performed by an NRF or SCP for classifying NFDeregister requests and suspicious requests and defending against large-scale NF deregistration attacks using NF heartbeat messages. Fig.11 The steps in Fig.10 The large-scale NF logout attack mitigation module 1008 shown in FIG. Fig.11 In step 1100, the process includes receiving a NFDeregister request for deregistering a NF. For example, the NRF or SCP 100 or 101 may receive a NFDeregister request for deregistering a NF.

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

[0111] In step 1104, the processing includes queuing the NFDeregister request in response to classifying the NFDeregister request as suspicious. For example, in an SCP implementation, the SCP 101 may queue the NFDeregister request and refrain from forwarding the NFDeregister request to the NRF 100. In an NRF implementation, the NRF 100 may store the NFDeregister request in its memory and block processing of the NFDeregister request.

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

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

[0114] In step 1110, the processing includes blocking processing of NFDeregister requests and blacklisting the sender of the NF deregister request in response to determining that an NF heartbeat message is received within the NF heartbeat time interval for the NF. For example, in an NRF implementation, the NRF may block processing of queued NFDeregister requests by dropping, ignoring, or rewriting the request. The NRF may blacklist the sender of the request by refusing to process further communications from the sender. In an SCP implementation, the SCP may block processing of queued NFDeregister requests by dropping, ignoring, rewriting, or otherwise avoiding forwarding the NFDeregister request to the NRF. The SCP may blacklist the sender of the request by refusing to process or forward further communications from the sender.

[0115] Fig.12 is a flow chart illustrating an exemplary process performed by an NRF for restoring a deregistered NF profile after detecting a large-scale NF deregistration attack. Fig.12 In step 1200, the process includes receiving a NFDeregister request to deregister the NF. For example, the NRF 101 may receive the NFDeregister request from a hacker or from a real NF seeking to deregister its NF profile.

[0116] In step 1202, a copy of the NF profile is stored. Step 1202 may be implemented if the NFDeregister request is classified as non-suspicious by applying the suspicious NFDeregister request classification rule.

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

[0118] In step 1206, the process includes receiving an NF heartbeat message regarding 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 services.

[0119] In step 1208, the process includes determining that the NF heartbeat message is received within the NF heartbeat time interval for the NF. For example, the NRF 100 may determine that the NF heartbeat message is received within the NF heartbeat time interval or before the NF heartbeat timer for the NF expires.

[0120] In step 1210, the process includes restoring the registration of the NF using the stored copy of the NF profile of the NF. For example, the NRF 100 may restore the registration state of the NF by moving the stored copy of the NF profile of the NF to the NF profile database and changing the registration state of the NF to REGISTERED.

[0121] The subject matter described herein can achieve at least the following advantages:

[0122] Reduce the likelihood of a large-scale NF deregistration attack being successful.

[0123] Mass logouts can cause network services to become unavailable, which can lead to network outages.

[0124] The subject matter described herein reduces the likelihood of a successful attack that would cause such a disruption.

[0125] Easy to implement.

[0126] Since the NRF or SCP has received the NFDeregister message which can be used to carry out a large-scale NF deregistration attack, adding a security feature to filter such messages can be easily implemented.

[0127] Can be implemented on either NRF or SCP.

[0128] Both the NRF and SCP provide a centralized location for screening NFDeregister messages to reduce the likelihood of successful large-scale NF deregistration attacks.

[0129] The disclosure of each of the following references is incorporated herein by reference in its entirety.

[0130] References

[0131] 3.3 rd Generation Partnership Project; Technical Specification GroupServices and System Aspects; System architecture for the 5G System (5GS); Stage2 (version 17) 3GPP TS 23.501 V17.0.0 (2021-03).

[0132] 4.3 rdGeneration Partnership Project; Technical Specification GroupCore Network and Terminals; 5G System; Network Function Repository Services; Stage 3 (Version 17) 3GPP TS 29.510 V17.1.0 (2021-03).

[0133] 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. Furthermore, the foregoing description is for the purpose of illustration only and not for the purpose of limitation, as the subject matter described herein is defined by the claims set forth hereinafter.

Claims

1. A method for defending against large-scale network function NF deregistration attacks, the method comprising: At a NF repository function NRF or a service communication proxy SCP comprising at least one processor and a memory: Receive a NFDeregister request for deregistering the NF; Classifying the NFDeregister request as suspicious based on application of suspicious NFDeregister request classification rules; queuing the NFDeregister request in response to classifying the NFDeregister request as suspicious; Receive NF heartbeat messages about NFs; Determining that a NF heartbeat message is received within a NF heartbeat time interval for the NF; as well as In response to determining that an NF heartbeat message is received within an NF heartbeat time interval for the NF, processing of the NFDeregister request is blocked and a sender of the NFDeregister request is blacklisted.

2. The method of claim 1, wherein classifying the NFDeregister request as suspicious based on application of a suspicious NFDeregister request classification rule comprises: The NFDeregister request is classified 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 threshold defined by an operator.

3. The method of claim 1, wherein classifying the NFDeregister request as suspicious based on application of a suspicious NFDeregister request classification rule comprises: The NFDeregister requests are classified as suspicious in response to the rate of NFDeregister requests exceeding an operator defined threshold.

4. The method of claim 1, wherein classifying the NFDeregister request as suspicious based on application of a suspicious NFDeregister request classification rule comprises: The NFDeregister request is classified as suspicious based on detected differences between learned past traffic patterns and the current traffic pattern of which the NFDeregister request is a part.

5. The method of claim 1, wherein classifying the NFDeregister request as suspicious based on application of a suspicious NFDeregister request classification rule comprises: By default, NFDeregister requests are classified as suspicious.

6. A method as described in any of claims 1-5, wherein the receiving, classification, determination, blocking processing and blacklisting are performed at the NRF, and wherein the method also includes transitioning to a SUSPECTED state in response to classifying a NFDeregister request as suspicious, and applying an operator-defined policy in the SUSPECTED state that determines whether to send a NFDeregister response and respond to an NFDiscover request.

7. The method according to any one of claims 1 to 5, comprising: Respond to the NFDeregister request with a NFDeregister response; as well as The doubt timer is inserted in the NFDeregister response to instruct the NF to delay the shutdown until the doubt timer expires.

8. The method of any of claims 1-5, wherein receiving, classifying, determining, blocking processing and blacklisting are performed at the SCP, and wherein blocking processing of the NFDeregister request comprises refraining from forwarding the NFDeregister request to the NRF.

9. A method as claimed in claim 8, comprising, at the SCP, on behalf of the NRF, responding to the NFDeregister request with a NFDeregister response.

10. A system for defending against large-scale network function NF deregistration attacks, the system comprising: A NF repository function NRF or a service communication proxy SCP comprising at least one processor and a memory; A large-scale NFDeregister attack mitigation module implemented by the at least one processor, configured to receive a NFDeregister request for deregistering a NF, classify the NFDeregister request as suspicious based on application of a suspicious NFDeregister request classification rule, queue the NFDeregister request in response to classifying the NFDeregister as suspicious, receive an NF heartbeat message about the NF, determine that the NF heartbeat message is received within an NF heartbeat time interval for the NF, and block processing of the NFDeregister request and blacklist a sender of the NFDeregister request in response to determining that the NF heartbeat message is received within the NF heartbeat time interval for the NF.

11. The system of claim 10, wherein the large-scale NF deregistration attack mitigation module is configured to classify 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 threshold defined by an operator.

12. The system of claim 10, wherein the large-scale NF deregistration attack mitigation module is configured to classify the NFDeregister request as suspicious in response to a rate of the NFDeregister requests exceeding an operator-defined threshold.

13. The system of claim 10, wherein the large-scale NF deregistration attack mitigation module is configured to classify the NFDeregister request as suspicious based on a detected difference between a learned past traffic pattern and a current traffic pattern of which the NFDeregister request is a part.

14. The system of claim 10, wherein the large-scale NF deregistration attack mitigation module is configured to classify the NFDeregister request as suspicious by default.

15. The system of any one of claims 10 to 14, wherein the NRF or SCP comprises the NRF, and wherein the large-scale NF deregistration attack mitigation module is configured to: transition to a SUSPECTED state in response to classifying a NFDeregister request as suspicious, and apply an operator-defined policy in the SUSPECTED state that determines whether to send a NFDeregister response and respond to a NFDiscover request.

16. The system of any one of claims 10 to 14, wherein the large-scale NF deregistration attack mitigation module is configured to: responding to the NFDeregister request with a NFDeregister response; and The doubt timer is inserted in the NFDeregister response to instruct the NF to delay the shutdown until the doubt timer expires.

17. The system of any one of claims 10 to 14, wherein the NRF or the SCP comprises an SCP, and wherein the large-scale NF deregistration attack mitigation module is configured to prevent processing of the NFDeregister request by avoiding forwarding the NFDeregister request to the NRF.

18. The system of claim 17, wherein the large-scale NF deregistration attack mitigation module is configured to: respond to the NFDeregister request with a NFDeregister response on behalf of the NRF.

19. A non-transitory computer readable medium having executable instructions stored thereon, wherein when the executable instructions are executed by a processor of a computer, the computer is controlled to perform the following steps: At the network function NF repository function NRF or the service communication proxy SCP: Receive a NFDeregister request for deregistering the NF; Classifying the NFDeregister request as suspicious based on application of suspicious NFDeregister request classification rules; queuing the NFDeregister request in response to classifying the NFDeregister request as suspicious; Receive NF heartbeat messages about NFs; Determining that a NF heartbeat message is received within a NF heartbeat time interval for the NF; as well as In response to determining that an NF heartbeat message is received within an NF heartbeat time interval for the NF, processing of the NFDeregister request is blocked and a sender of the NFDeregister request is blacklisted.

Images