Method, system, and computer-readable medium for mitigating 5G roaming attacks on Internet of Things (IoT) devices based on expected user equipment (UE) behavior patterns

Abstract

A method for mitigating 5G roaming attacks on an Internet of Things (IoT) device based on expected user equipment (UE) behavior patterns includes, at a network function (NF) including at least one processor, receiving a service request message requesting a service from a home public land mobile network (PLMN) of a UE identified in the service request message, the UE including an IoT device, and the method further includes obtaining, for the UE identified in the service request message, at least one parameter provisioned in the home PLMN to indicate an expected UE behavior pattern. The method further includes comparing the at least one parameter provisioned in the home PLMN to indicate an expected UE behavior pattern with at least one parameter from the service request message, and determining that the at least one parameter from the service request message is not indicative of an expected UE behavior pattern for the UE. The method further includes filtering out or rejecting the service request message.

Description

[Technical field]

[0001] The subject matter described herein relates to network security. More particularly, the subject matter described herein relates to methods, systems, and computer-readable media for mitigating 5G roaming attacks on Internet of things (IoT) devices based on expected user equipment (UE) behavior patterns. [Background technology]

[0002] background In a 5G telecommunications network, a network function that provides a service is called a producer network function (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 consumes, produces, or consumes and produces a service. The terms "producer NF" and "NF service producer" are used interchangeably herein. Similarly, the terms "consumer NF" and "NF service consumer" are used interchangeably herein.

[0003] A given producer NF may have many service endpoints. A service endpoint is a contact point for one or more NF instances hosted by the producer NF. A service endpoint is a combination of an Internet protocol (IP) address and a port number or a fully qualified domain name (that resolves into an IP address and a 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 may contain two or more NF instances. Note that multiple NF instances can share the same service endpoint.

[0004] Producer NFs register with a network function repository function (NRF). The NRF maintains service profiles of available NF instances that identify the services supported by each NF instance. Consumer NFs can subscribe to receive information about producer NF instances that have registered with the NRF.

[0005] In addition to consumer NFs, another type of network node that can subscribe to receive information about NF service instances is the service communications 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 service communications proxy, which load balances traffic between producer NF service instances offering the requested service or routes traffic directly to the destination producer NF instance.

[0006] In addition to SCPs, other examples of intermediate proxy nodes or groups of network nodes that route traffic between producer and consumer NFs include security edge protection proxies (SEPPs), service gateways, and nodes in a 5G service mesh. A SEPP is a network node used to protect control plane traffic exchanged between different 5G public land mobile networks (PLMNs). As such, a SEPP performs message filtering, policing, and topology hiding for all application programming interface (API) messages sent between PLMNs. Summary of the Invention [Problem to be solved by the invention]

[0007] One issue in 5G communication networks is the possibility of fraudulent attacks on IoT devices via inter-PLMN roaming signaling. Examples of such attacks include location tracking attacks, denial of service (DoS) attacks, billing fraud, etc. Hackers may initiate authentic-looking roaming traffic towards the home core network to launch security attacks on cellular IoT devices. In one example, inter-PLMN roaming signaling may be initiated related to a fixed UE device such as a water meter. Such devices are stationary and always in the home network. Thus, no roaming traffic should be generated for such devices. These and other types of inter-PLMN signaling attacks may be used to obtain subscriber information from the home network and / or to launch denial of service attacks. SEPPs are ingress and egress points for roaming PLMN traffic and are deployed as signaling firewalls by mobile network operators to mitigate roaming security attacks. However, analysis of expected UE behavior is not specified by 3GPP and GSMA standards.

[0008] Therefore, there is a need for improved methods, systems, and computer-readable media for mitigating 5G roaming security attacks. [Means for solving the problem]

[0009] overview A method for mitigating 5G roaming attacks on an Internet of Things (IoT) device based on expected user equipment (UE) behavior patterns includes receiving, at a network function (NF) including at least one processor, a service request message requesting a service from a home public land mobile network (PLMN) of a UE identified in the service request message, the UE including an IoT device. The method further includes the NF obtaining, for the UE identified in the service request message, at least one parameter provisioned in the home PLMN to indicate an expected UE behavior pattern. The method further includes the NF comparing the at least one parameter provisioned in the home PLMN to indicate an expected UE behavior pattern with at least one parameter from the service request message. The method further includes the NF determining, based on a result of the comparing, that the at least one parameter from the service request message is not indicative of an expected UE behavior pattern of the UE. The method further includes filtering out or rejecting the service request message in response to determining that the at least one parameter from the service request message is not indicative of an expected UE behavior pattern of the UE.

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

[0011] According to another aspect of the subject matter described in this specification, obtaining at least one parameter provisioned in the home PLMN to indicate an expected UE behavior pattern includes interrogating a user data management (UDM) function located in the home PLMN.

[0012] According to another aspect of the subject matter described in this specification, obtaining at least one parameter provisioned in the home PLMN to indicate the expected UE behavior pattern includes querying a database within the SEPP that includes at least one parameter provisioned in the home PLMN to indicate the expected UE behavior pattern.

[0013] According to another aspect of the subject matter described in this specification, obtaining at least one parameter provisioned in the home PLMN to indicate an expected UE behavior pattern includes obtaining the parameters provisioned in the home PLMN using a Nnef_ParameterProvision service.

[0014] According to another aspect of the subject matter described herein, the network function includes a Diameter signaling router (DSR) with an integrated firewall.

[0015] According to another aspect of the subject matter described in this specification, obtaining at least one parameter provisioned in a home PLMN to indicate an expected UE behavior pattern includes obtaining the at least one parameter by querying a home subscriber server (HSS).

[0016] According to another aspect of the subject matter described in this specification, obtaining at least one parameter provisioned in the home PLMN to indicate an expected UE behavior pattern includes obtaining the at least one parameter from a database internal to the DSR.

[0017] According to another aspect of the subject matter described in this specification, comparing at least one parameter provisioned in the home PLMN to indicate an expected UE behavior pattern with at least one parameter in the service request message includes comparing at least one of the mobility indicative parameter, the communication time indicative parameter, and the communication type indicative parameter with at least one of the mobility indicative parameter, the communication time indicative parameter, and the communication type indicative parameter from the service request message.

[0018] According to another aspect of the subject matter described in this specification, determining that the at least one parameter from the service request message is not indicative of an expected UE behavior pattern for the UE based on results of the comparing step includes determining that at least one of a mobility, air time, or communication type indicated by the at least one parameter in the service request message does not match at least one of a mobility, air time, or communication type indicated by the at least one parameter provisioned in the home PLMN to indicate an expected UE behavior pattern for the UE.

[0019] According to another aspect of the subject matter described herein, a system for mitigating 5G roaming attacks on an Internet of Things (IoT) device based on an expected user equipment (UE) behavior pattern is provided. The system includes a network function (NF) including at least one processor configured to receive a service request message requesting a service from a home public land mobile network (PLMN) of a UE identified in the service request message, the UE including an IoT device. The system further includes an expected UE behavior determination unit configured to obtain, for the UE identified in the service request message, at least one parameter provisioned in a home PLMN to indicate an expected UE behavior pattern of the UE, compare the at least one parameter provisioned in the home PLMN to indicate an expected UE behavior pattern of the UE with at least one parameter from the service request message, determine based on a result of the comparison that the at least one parameter from the service request message is not indicative of an expected UE behavior pattern of the UE, and filter out or reject the service request message in response to determining that the at least one parameter from the service request message is not indicative of an expected UE behavior pattern of the UE.

[0020] According to another aspect of the subject matter described in this specification, the expected UE behavior determination unit is configured to obtain at least one parameter provisioned in the home PLMN to indicate an expected UE behavior pattern by querying a User Data Management (UDM) function located in the home PLMN.

[0021] According to another aspect of the subject matter described in this specification, the expected UE behavior determination unit is configured to obtain at least one parameter provisioned in the home PLMN to indicate an expected UE behavior pattern by querying an expected UE behavior parameter database within the SEPP, the database including at least one parameter provisioned in the home PLMN to indicate an expected UE behavior pattern.

[0022] According to another aspect of the subject matter described in this specification, the at least one parameter provisioned in the home PLMN to indicate the expected UE behavior pattern includes at least one parameter provisioned in the home PLMN using a Nnef_ParameterProvision service.

[0023] According to another aspect of the subject matter described in this specification, the NF includes a DSR, and the expected UE behavior determination unit is configured to obtain at least one parameter provisioned in a home PLMN to indicate an expected UE behavior pattern by querying a home subscriber server (HSS).

[0024] According to another aspect of the subject matter described in this specification, the NF includes a DSR, and the expected UE behavior determination unit is configured to obtain at least one parameter provisioned in a home PLMN to indicate an expected UE behavior pattern by querying an expected UE behavior parameter database within the DSR.

[0025] According to another aspect of the subject matter described in this specification, the expected UE behavior determination unit is configured to compare at least one parameter provisioned in the home PLMN to indicate an expected UE behavior pattern with at least one parameter in the service request message by comparing at least one of a parameter indicative of mobility, a parameter indicative of communication time, and a parameter indicative of communication type with at least one of a parameter indicative of mobility, a parameter indicative of communication time, and a parameter indicative of communication type from the service request message.

[0026] According to another aspect of the subject matter described herein, a non-transitory computer-readable medium is provided having executable instructions stored thereon that, when executed by a processor of the computer, control the computer to perform a plurality of steps. The plurality of steps includes receiving, at a network function (NF) including at least one processor, a service request message requesting a service from a home public land mobile network (PLMN) of a UE identified in the service request message, the UE including an Internet of Things (IoT) device. The plurality of steps further includes the NF obtaining, for the UE identified in the service request message, at least one parameter provisioned in the home PLMN to indicate an expected UE behavior pattern. The plurality of steps further includes the NF comparing the at least one parameter provisioned in the home PLMN to indicate an expected UE behavior pattern with at least one parameter from the service request message. The plurality of steps further includes the NF determining, based on a result of the comparing step, that the at least one parameter from the service request message is not indicative of an expected UE behavior pattern of the UE. The plurality of steps further includes filtering out or rejecting the service request message in response to determining that at least one parameter from the service request message is not indicative of an expected UE behavior pattern for the UE.

[0027] The subject matter described herein may be implemented in software combined with hardware and / or firmware. For example, the subject matter described herein may be implemented in software executed by a processor. In one exemplary implementation, the subject matter described herein may be implemented using a non-transitory computer-readable medium having computer-executable instructions stored thereon 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, and application specific integrated circuits. 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 among multiple devices or computing platforms. [Brief description of the drawings]

[0028] [Figure 1] FIG. 1 is a network diagram illustrating an example 5G network architecture. [Diagram 2] FIG. 13 is a message flow diagram illustrating example messages exchanged to mitigate security attacks based on expected UE behavior when the node performing security attack mitigation is a home network SEPP. [Diagram 3] FIG. 2 is a block diagram illustrating a SEPP configured to mitigate roaming security attacks based on expected UE behavior. [Figure 4] 1 is a flowchart illustrating an example process for mitigating roaming security attacks based on expected UE behavior. [Diagram 5]FIG. 13 is a message flow diagram illustrating example messages exchanged to mitigate security attacks based on expected UE behavior when the node performing security attack mitigation is a Diameter signaling router with an integrated firewall. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0029] 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 may maintain a profile of available producer NF service instances and their supported services, and enable consumer NFs or SCPs to subscribe to new / updated producer NF service instances and be notified of their registration. The SCP 101 may also support service discovery and selection of producer NF instances. The SCP 101 may perform load balancing of connections between consumer NFs and producer NFs.

[0030] The NRF 100 is a repository for NF profiles or service profiles of producer NF instances. To communicate with a producer NF instance, a consumer NF or SCP must obtain the NF profile or service profile of the producer NF instance from the NRF 100. The NF profile or service profile is a JavaScript object notation (JSON) data structure defined in Third Generation Partnership Project (3GPP) Technical Specification (TS) 29.510. The NF profile 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.

[0031] In FIG. 1, any of the network functions (other than the NRF 100) may be consumer NFs, producer NFs, or both, depending on whether they are requesting, providing, or both services. In the illustrated example, the NFs include a policy control function (PCF) 102 that performs policy-related operations in the network, a user data management (UDM) function 104 that manages user data, and an application function (AF) 106 that provides application services. As described in more detail below, the UDM 104 may store parameters provisioned for a home network UE that indicate expected UE behavior patterns. These parameters may be used to identify and mitigate roaming security attacks.

[0032] 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.

[0033] The network slice selection function (NSSF) 116 provides network slicing services for devices that want to access specific network capabilities and characteristics associated with a network slice. The network exposure function (NEF) 118 provides application programming interfaces (APIs) for application functions that want to obtain information about Internet of Things (IoT) devices and other UEs connected to the network. The NEF 118 performs a function similar to the service capability exposure function (SCEF) in 4G networks.

[0034] 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 a proxy functionality is a multipath transmission control protocol (MPTCP) proxy functionality. The UPF 122 may also support performance measurement functionality, which 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.

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

[0036] As mentioned above, one problem with the 3GPP network architecture is that although the SEPP is used as a firewall for the home network, the procedures for identifying and blocking roaming security attacks are not specified by the 3GPP and GSMA standards.

[0037] The ability to block 5G roaming security attacks is especially important in that Massive IoT is one of the most important use cases of 5G network deployment. Roaming security for IoT devices is of paramount importance. The subject matter described herein includes methods for mitigating roaming fraud security attacks using expected UE device behavior. Examples of such behavior include stationary device indication, authorized geographic areas for IoT device movement, authorized / scheduled airtime for IoT devices, etc. In one example, the 5G SEPP obtains expected UE behavior pattern information from the UDM and blocks inter-PLMN communications that do not follow the expected UE behavior.

[0038] One example of expected UE behavior that may be monitored by the SEPP described herein is whether the UE is stationary or not. A fixed device, such as a water meter, should not roam outside the home network. Thus, if the SEPP receives a 5G service request indicating that a fixed device, such as a water meter, is roaming, the SEPP may block inter-PLMN messaging related to the roaming of the fixed device. As shown in more detail below, whether the device is stationary or not may be obtained by the SEPP sending a query message to the UDM.

[0039] Another example of expected UE behavior that may be used by the SEPP to identify unauthorized roaming security attacks is the scheduled communication time of the UE. For example, a low power wide area (LWPA) IoT device may communicate at scheduled times of day. One such LWPA device may be a smart power meter scheduled to transmit power consumption measurements at 12:00 AM every day or transmit health status messages every hour. If the SEPP receives a message from the power meter outside of one of these scheduled times (examples of such messages include user equipment context management (UECM) registration, PDU session updates, non-IP data, mobile originated (MO) data communications, etc.), the SEPP may identify such communication as unauthorized and block or reject such messages.

[0040] In another example, the SEPP may use geofencing information to identify inter-PLMN communications as unauthorized. For example, some vehicles may be geofenced to communicate or travel within predefined tracking area / coverage areas (TA / CA) or PLMNs. Roaming signaling that identifies such a vehicle outside one of these geographic areas may be from an attacker rather than the vehicle and may be classified as unauthorized and blocked by the SEPP.

[0041] The SEPP is ideally positioned to intercept unauthorized signaling before it has a chance to enter the home PLMN of a UE, such as an IoT device. However, as noted above, the 3GPP or GSMA standards do not define the procedures to be used by the SEPP to identify attack traffic. The subject matter described herein includes methodologies for obtaining expected UE behavior information provisioned in the HPLMN and using that information to identify unauthorized inter-PLMN communications.

[0042] In a 5G communication network, the UDM network function hosts UE subscription data, which includes expected UE behavior data, such as stationary indication indicating whether the UE is fixed or mobility-enabled, expected geographic movement of the UE, whether UE communication is periodic or on-demand, and scheduled communication times identifying the times and days of the week when the UE is available for communication. These expected UE behavior parameters are used to derive core network-assisted RAN parameter adjustments that help the RAN minimize state transitions and achieve optimal network behavior. The SEPP described herein uses these parameters to identify expected UE behavior and determine whether the parameters in the 5G service request message are indicative of expected UE behavior. If the SEPP determines that the parameters are not indicative of expected UE behavior, the SEPP may block or reject the service request message.

[0043] The expected UE behavior parameters are either provisioned directly in the UDM or provisioned by a third party application (application function, or AF) via the NEF using the Nnef_ParameterProvision service exposed by the NEF to provision these expected UE behavior parameters. Examples of expected UE behavior parameters and provisioning are described in 3GPP TS 23.502 and 3GPP TS 29.122.

[0044] The SEPP described herein screens inter-PLMN service requests associated with outbound roaming subscribers coming over the N32 interface from remote PLMNs. The SEPP validates the messages against expected UE behavior parameters obtained from the UDM for a given outbound roaming subscriber. Messages that do not meet the expected UE behavior are to be marked as vulnerable and the SEPP may discard and / or reject the messages.

[0045] 2 is a message flow diagram illustrating validation of expected UE behavior at a home network SEPP to mitigate inter-PLMN roaming attacks. With reference to FIG. 2, at line 1, a consumer NF 200 sends a service request to its local PLMN SEPP 126B. The SEPP 126B receives the service request and forwards the service request at line 2 to the home network SEPP 126A.

[0046] At line 3, in response to the service request, the home network SEPP 126A sends a Nudm_SDM_Get message to the UDM 104. The Nudm_SDM_Get message requests expected UE behavior parameters from the UDM 104 using the UE identification information obtained from the service request message.

[0047] In response to the Nudm_SDM_Get message, the UDM 104 performs a lookup in its subscription database to find a record corresponding to the UE identified in the Nudm_SDM_Get message. At line 4, the UDM 104 responds to the Home SEPP 126A with a Nudm_SDM_Get response message that includes at least one parameter indicative of expected UE behavior. At step 5, the Home PLMN SEPP 126A compares the UE behavior parameters extracted from the service request with the expected UE behavior parameters obtained from the UDM. If the comparison indicates that these behaviors match, the Home PLMN SEPP B forwards the service request message to the producer NF 202, which will provide the service requested by the service request message. In this example, it is assumed that the parameters in the service request message do not indicate the expected UE behavior. Thus, at step 6, the Home PLMN SEPP 126A filters out or rejects the service request because the verification failed.

[0048] FIG. 3 is a block diagram illustrating an example SEPP 126A suitable for mitigating 5G roaming security attacks based on expected UE behavior. With reference to FIG. 3, the SEPP 126A includes at least one processor 300 and a memory 302. The SEPP 126A further includes an expected UE behavior determination unit 304, which may be stored in the memory 302 and executed by the processor 300. The expected UE behavior determination unit 304 receives inter-PLMN service requests from the attacker and the genuine remote SEPP. The expected UE behavior determination unit 304 also signals with the UDM to obtain expected UE behavior parameters. The expected UE behavior determination unit 304 compares the expected UE behavior parameters from the service request message with the parameters obtained from the UDM to determine whether the UE behavior indicated by the service request message is expected. If the behavior is expected, the expected UE behavior determination unit 304 may forward valid signaling to the home PLMN. If the expected UE behavior determiner 304 determines that the UE behavior indicated by the service request is not as expected, the UE behavior determiner 304 may block or reject such signaling.

[0049] FIG. 4 is a flow chart illustrating an example process for mitigating 5G roaming security attacks based on expected UE behavior. With reference to FIG. 4, in step 400, an NF, such as a home network SEPP, receives a service request message requesting a service from a home PLMN of a UE identified in the service request message. For example, the SEPP 126A may receive the service request message requesting a service from a producer NF. The service request message may be a Nudm_UECM_Registration request message directed to a UDM. In another example, the service request message may be a UE authentication message, a PDU session establishment message for IP or non-IP data delivery, a non-IP data delivery mobile originated (MO) or mobile terminated (MT) message, etc. The home network SEPP may receive the service request via the N32 interface through transport layer security (TLS) or protocol for N32 interconnect security (PRINS) protection mode. However, even with these security mechanisms, the service request may be fraudulent.

[0050] In step 402, the NF obtains at least one parameter provisioned in the home PLMN for the UE identified in the service request message to indicate an expected UE behavior pattern. For example, an application function (AF) may provision the expected UE behavior pattern in the UDM using the Nnef_ParameterProvision service defined in 3GPP TS 23.502. Examples of expected UE behavior parameters that may be provisioned in the home PLMN are defined in section 4.15.6.3 of 3GPP TS 23.502. Table 1 shown below is an example of expected UE behavior parameters that may be used by an NF, such as a SEPP, to screen incoming service request messages requesting services from the home PLMN for the UE.

[0051] [Table 1]

[0052] Table 1 is a copy of Table 4.15.6.3-1 from 3GPP TS 23.502. The expected UE behavior parameters identified in Table 1 may be provisioned by the AF or other nodes to indicate expected UE behavior. As indicated above, these parameters are typically used by the home PLMN to communicate with the UE over the air interface. In accordance with the subject matter described herein, the SEPP, SCP, or other nodes may use these parameters to screen incoming service request messages. One parameter from Table 1 that may be used to screen service request messages is the stationary indication parameter, which identifies the UE as being stationary or mobile. Any of the other parameters, such as scheduled communication time, periodic time, communication duration, traffic profile, scheduled communication type, etc., may also be used.

[0053] 2, the SEPP 126A obtains the expected UE behavior parameters from the UDM. In an alternative implementation, the expected UE behavior parameters, such as those shown in Table 1, may be provisioned in the SEPP such that the SEPP is not required to query the UDM in response to receiving a service request message. Instead, in such an implementation, the SEPP would query its internal database using the subscriber or UE identifier in the service request message to obtain the expected UE behavior parameters.

[0054] In step 406, the NF, such as a SEPP, compares the parameter(s) from the UDM or an internal database with the parameters in the service request message. For example, the SEPP 126A may compare the mobility-indicating parameter from the service request message with the stationary indication parameter in the data obtained from the home PLMN to determine whether the behavior indicated by the service request matches the expected UE behavior indicated by the value of the stationary indication parameter. Using the expected UE behavior parameters in Table 1 as an example, if the value of the stationary indication parameter provisioned in the home PLMN indicates that the UE is a stationary device and the service request message is a Nudm_UECM_Registration request message with a registration type parameter set to "mobility registration update", the NF may determine that the UE behavior indicated by the service request message is abnormal or unexpected. Section 4.2.2.2.1 of 3GPP TS 23.502 defines the mobility registration update registration type as follows: Mobility Registration Update: In both CM Connected and CM Idle states, when there is a change to a new Tracking Area (TA) outside the UE's registration area, or when the UE needs to update its capabilities or protocol parameters negotiated in the registration procedure, with or without a change to a new TA, a change in the UE's preferred network behavior that would create an incompatibility with the supported network behavior offered by the serving AMF, or when the UE intends to retrieve LADN information.

[0055] In the above example, the Mobility Registration Update registration type may be used to update the tracking area or capabilities of a portable device. Thus, receipt of a Nudm_UECM_Registration request to update the tracking area of ​​a device with the stationary indication parameter value set to "stationary" may be viewed as unexpected behavior, whereas receipt of a Nudm_UECM_Registration request to update the capabilities of a device with the stationary indication parameter set to "stationary" may not be viewed as unexpected behavior.

[0056] In another example, if a UE has a provisioned stationary display parameter set to "portable" and a Nudm_UECM_Registration request to update the tracking area of ​​the device is received, the value of the "expected UE movement trajectory" parameter may be checked to determine whether the tracking area specified in the Nudm_UECM_Registration request is within the trajectory specified by the value of the expected UE movement trajectory parameter. If the tracking area specified in the Nudm_UECM_Registration request is not within the trajectory specified by the value of the expected UE movement trajectory parameter, the UE behavior indicated by the Nudm_UECM_Registration request message may be determined to be unexpected and the Nudm_UECM_Registration request message may be discarded and / or blocked from entering the home PLMN.

[0057] In other examples, the NF may compare communication times, frequencies, durations, or other behaviors indicated by parameters in the service request message with expected UE behavior parameters provisioned in the home PLMN to determine whether the UE behavior indicated by the service request message matches the UE behavior indicated by the expected UE behavior parameters provisioned in the home PLMN for the UE. If the service request message indicates that the UE is communicating at a different time, on a different frequency, and / or for a different duration than indicated by the expected UE behavior parameters provisioned in the home PLMN for the UE, the NF may determine that the UE behavior indicated by the service request message is not the expected UE behavior.

[0058] In step 406, the NF determines, based on the results of the comparing step, that the parameters from the service request do not indicate an expected UE behavior pattern. Using any of the examples above, the NF may determine that the UE behavior indicated by the service request message is not an expected UE behavior.

[0059] In step 408, the NF filters out or rejects the service request message. In the above example, the UE's communication pattern is verified against the information obtained from the UDM. In an alternative example, the UE behavior pattern can be provisioned directly in the SEPP.

[0060] In the above example, the service request is validated by the home network SEPP. In another example, the NF that analyzes the service request to determine whether it indicates expected or unexpected UE behavior may be a 4G NF, such as a Diameter Signaling Router (DSR) with an integrated firewall. The DSR may perform similar steps as described above for the 5G case to validate 4G service request messages and block or reject such messages if they do not match the expected UE behavior pattern.

[0061] Figure 5 is a message flow diagram illustrating the use of a DSR to perform such functions. With reference to Figure 5, a DSR 500 with an integrated firewall may be located at the edge of the home network such that inter-PLMN signaling related to roaming subscribers arrives at the DSR 500 first. The DSR 500 may implement Diameter relay agent functionality as described in IETF RFC 6733. Briefly, such functionality includes routing Diameter messages based on Diameter layer information in the messages. In addition to the basic Diameter relay agent functionality, the DSR 500 may perform validation of expected UE behavior using steps similar to those described above with respect to SEPP 126A.

[0062] 5, in line 1, the attacker sends a service request to the home PLMN. The service request may be a location update request or other message that includes a UE identity and at least one parameter indicating the UE behavior. For example, the message type of the location update request message may indicate that the UE is mobile.

[0063] In response to the service request message, at line 2, the DSR 500 queries a home subscriber server (HSS) 504 using a Diameter configuration information request (CIR) message to obtain expected UE behavior parameters from the HSS 504. In response to the CIR message, the HSS 504 performs a lookup in its UE subscription database to extract expected UE behavior parameters such as portable or stationary indication, expected UE location, expected UE communication pattern statistics, etc. At line 3 of the message flow diagram, the HSS 504 returns the expected UE behavior parameters to the DSR 500 in a configuration information answer (CIA) message.

[0064] In step 4, the DSR 500 validates the service request message against expected UE behavior parameters provisioned in the home PLMN for the UE. If the expected behavior parameters indicate that the service request message represents expected UE behavior, the DSR 500 may forward the service request message to the subscriber's home PLMN. If the expected UE behavior parameters obtained from the HSS indicate that the UE behavior is not as expected, the DSR 500 may filter out or reject the service request, as indicated by step 5. Instead of obtaining the expected UE behavior parameters from the HSS, as in the SEPP example above, in an alternative implementation, the expected UE behavior parameters may be provisioned in a database internal to the DSR, and the DSR may query the database to obtain the expected UE behavior parameters used to validate the inter-PLMN service request.

[0065] Advantages of the subject matter described herein include mitigation of roaming security attacks using expected IoT device behavior parameters such as stationary indication, communication frequency, communication type, communication duration, permitted geographic areas for communication, etc. Another advantage of using the methods and systems described herein to perform roaming security attack mitigation is that expected UE behavior parameters are already provisioned in the network for purposes other than roaming security. Reusing these parameters from roaming security eliminates the need for complex or computationally expensive algorithms to derive expected UE behavior patterns. As a result, the ability to screen service requests more quickly may be achieved.

[0066] The disclosure of each of the following references is incorporated herein by reference in its entirety: References 1.3GPP TS 23.502 V16.6.0 (2020-09), Technical Specification, 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Procedures for 5G System (5GS); Stage 2 (Release 16) 2.3GPP TS 29.122 V15.6.0 (2019-12), Technical Specification, 3rd Generation Partnership Project; Technical Specification Group Core Network and Terminal; T8 Reference Point for Northbound API (Release 15) 3. IETF RFC 6733; Diameter Base Protocol (October 2012).

[0067] It will be understood that various details of the subject matter described herein can be changed without departing from the scope of the subject matter described herein. Moreover, the above description is intended to be illustrative and not limiting, since the subject matter described herein is defined by the claims as set forth below.

Claims

1. 1. A method for mitigating 5G roaming attacks on Internet of Things (IoT) devices based on expected User Equipment (UE) behavior patterns, the method comprising: The method includes receiving, at a network function (NF) including at least one processor, a service request message requesting a service from a home public land mobile network (PLMN) of a UE identified in the service request message, the UE including an IoT device, the method further comprising: The method further comprises: the NF obtaining, for the UE identified in the service request message, at least one parameter provisioned in the home PLMN to indicate an expected UE behavior pattern of the UE, the at least one parameter including one or more of a parameter indicating that the UE is a stationary device, a parameter indicating a time when the UE is allowed to communicate, and a parameter indicating a mobility range of the UE; the NF comparing the at least one parameter provisioned in the home PLMN to indicate the expected UE behavior pattern with at least one parameter from the service request message; the NF determining, based on a result of the comparing step, that the at least one parameter from the service request message is not indicative of the expected UE behavior pattern of the UE; and in response to determining that the at least one parameter from the service request message is not indicative of the expected UE behavior pattern for the UE, filtering out or rejecting the service request message.

2. The method of claim 1 , wherein the NF comprises a security edge protection proxy (SEPP).

3. 3. The method of claim 1 or 2, wherein obtaining the at least one parameter provisioned in the home PLMN to indicate an expected UE behavior pattern comprises interrogating a User Data Management (UDM) function located in the home PLMN.

4. 3. The method of claim 2, wherein obtaining the at least one parameter provisioned in the Home PLMN to indicate an expected UE behavior pattern comprises querying a database internal to the SEPP and including the at least one parameter provisioned in the Home PLMN to indicate the expected UE behavior pattern.

5. The step of obtaining at least one parameter provisioned in the home PLMN to indicate the expected UE behavior pattern includes obtaining parameters provisioned in the home PLMN using a Nnef_ParameterProvision service. The method according to any one of claims 1 to 4, comprising the step of:

6. The method of any one of claims 1 to 5, wherein the network function includes a Diameter Signaling Router (DSR) with an integrated firewall.

7. 7. The method of claim 6, wherein obtaining the at least one parameter provisioned in the home PLMN to indicate an expected UE behavior pattern comprises obtaining the at least one parameter by querying a Home Subscriber Server (HSS).

8. 7. The method of claim 6, wherein obtaining the at least one parameter provisioned in the home PLMN to indicate an expected UE behavior pattern comprises obtaining the at least one parameter from a database internal to the DSR.

9. The step of comparing the at least one parameter provisioned in the home PLMN to indicate the expected UE behavior pattern with at least one parameter in the service request message comprises: determining whether the service request message is received indicating that the stationary device is roaming; determining whether the service request message is received outside a time period during which the UE is allowed to communicate; and The method according to any one of claims 1 to 8, further comprising one or more steps of: determining whether the service request message is received from outside a mobility coverage area of ​​the UE.

10. A program for causing a processor to execute the method according to any one of claims 1 to 9.

11. A memory storing the program according to claim 10; A processor for executing the program.

Images