Method, system and computer-readable medium for performing indirect general packet radio service (GPRS) tunneling protocol (GTP) firewall filtering using diameter agents and signal transfer points (STPs) - Patents.com

Abstract

A method for performing indirect GTP firewall filtering includes dynamically populating an indirect GTP-C firewall filtering database with an IMSI and a VPLMN ID extracted from a mobility management signaling message for updating the location of an outbound roaming subscriber using a signaling message routing node. The method further includes receiving a CCR-I message generated in response to the GTP-C message. The method further includes extracting the IMSI and the VPLMN ID from the CCR-I message. The method further includes accessing the indirect GTP-C firewall filtering database using the IMSI extracted from the CCR-I message. The method further includes determining that a record corresponding to the IMSI exists in the indirect GTP-C firewall filtering database. The method further includes determining that the VPLMN ID in the record does not match the VPLMN ID extracted from the CCR-I message. The method further includes rejecting the CCR-I message in response to determining that the VPLMN ID in the record does not match the VPLMN ID extracted from the CCR-I message.

Description

[Technical field]

[0001] Priority claim This application claims the benefit of priority to U.S. Patent Application No. 16 / 732,098, filed December 31, 2019, the disclosure of which is incorporated herein by reference in its entirety.

[0002] Technical Field The subject matter described herein relates to performing firewall functions for GTP Core (GTP-C) signaling traffic. More particularly, the subject matter described herein relates to methods, systems, and computer-readable media for performing indirect GTP firewall filtering to prevent fraud-based attacks using one or more Diameter agents and STP without blocking GTP-C roaming signaling. [Background technology]

[0003] background GTP is a family of IP-based communications protocols used to carry GPRS traffic in Global System for Mobile Communications (GSM), Universal System for Mobile Telecommunications (UMTS), Long Term Evolution (LTE) and 5G networks. GTP-C is used for signaling between Serving Gateways (SGWs) and Packet Gateways (PGWs) in Evolved Packet Core (EPC) networks. GTP-C control plane messages are exchanged between SGWs and PGWs to convey Serving Gateway capability information to the PGW, to create, update and delete GTP tunnels, and for path management. Summary of the Invention [Problem to be solved by the invention]

[0004] Since the PGW is used for Internet traffic, it may be subject to fraud-based attacks from nodes impersonating SGWs serving outbound roaming subscribers. An outbound roaming subscriber is a subscriber of a service provider's network who is roaming within another service provider's network. An outbound roaming subscriber can be distinguished from an inbound roaming subscriber, a subscriber of another network who is roaming within the service provider's home network. Signaling related to outbound mobile subscribers is particularly susceptible to fraud-based attacks because an attacker impersonating a serving gateway or mobility management entity (MME) serving a particular subscriber can impersonate the subscriber using the subscriber's International Mobile Subscriber Identity (IMSI), which is not difficult to obtain. An attacker may use the real subscriber's IMSI to establish a GTP session with a packet gateway and, at a minimum, deny service to the real subscriber. An attacker may also obtain subscriber information from the subscriber's home network. One possible way to prevent such attacks is to implement a GTP-C firewall function in the PGW of the home network. However, implementing a GTP-C firewall function in the PGW can be burdensome for network operators in terms of the number of PGWs that may be deployed in a network, and can also be burdensome for the processing resources of the PGW. For example, if the PGW is equipped to screen GTP-C messages, it would have to contact a Home Subscriber Server (HSS) to determine whether a subscriber is roaming out and then decide whether to allow a GTP-C session from a particular MME or Serving Gateway (SGW) of the roaming network. Such processing would be burdensome for both the PGW and the HSS. The PGW would have to intercept the GTP-C signaling, query the HSS, receive a response from the HSS, and decide whether to allow a GTP session based on the response.This would be non-standard PGW behavior since there is no existing standard-defined interface between the PGW and the HSS: the HSS would have to handle queries and responses for every GTP-C session from every PGW in the network.

[0005] Therefore, there is a need to perform the GTP firewall function in a manner that reduces the processing burden on core network nodes, without interfering with GTP-C roaming signaling. [Means for solving the problem]

[0006] overview A method for performing indirect GTP firewall filtering includes dynamically populating an indirect GTP-C firewall filtering database with an IMSI and a VPLMN ID extracted from a mobility management signaling message for updating a location of an outbound roaming subscriber using a signaling message routing node. The method further includes receiving a CCR-I message generated in response to a GTP-C message. The method further includes extracting an IMSI and a VPLMN ID from the CCR-I message. The method further includes accessing the indirect GTP-C firewall filtering database using the IMSI extracted from the CCR-I message. The method further includes determining that a record corresponding to the IMSI exists in the indirect GTP-C firewall filtering database. The method further includes determining that the VPLMN ID in the record does not match the VPLMN ID extracted from the CCR-I message. The method further includes rejecting the CCR-I message in response to determining that the VPLMN ID in the record does not match the VPLMN ID extracted from the CCR-I message.

[0007] In accordance with another aspect of the subject matter described herein, dynamically populating the indirect GTP-C firewall filtering database using a signaling message routing node includes receiving a Diameter Location Update Request (ULR) message at the signaling message routing node; extracting an IMSI and a VPLMN ID from the Diameter ULR message; temporarily storing the IMSI and the VPLMN ID extracted from the Diameter ULR message; determining that the update of the location of the subscriber is successful; and in response to determining that the update of the subscriber's location is successful, associating the VPLMN ID extracted from the Diameter ULR message with the IMSI extracted from the Diameter ULR message in the indirect GTP-C firewall filtering database.

[0008] In accordance with yet another aspect of the subject matter described herein, the signaling message routing node includes a Diameter Edge Agent (DEA).

[0009] In accordance with yet another aspect of the subject matter described herein, the signaling message routing node includes a Diameter Relay Agent (DRA).

[0010] In accordance with yet another aspect of the subject matter described herein, dynamically populating the indirect GTP-C firewall filtering database includes receiving, at the signaling message routing node, a Mobile Application Part (MAP) location update request message; extracting an IMSI and a VPLMN ID from the MAP location update request message; temporarily storing the IMSI and the VPLMN ID extracted from the MAP location update request message; determining that the update of the subscriber's location is successful; and in response to determining that the update of the subscriber's location is successful, associating the VPLMN ID with the IMSI extracted from the MAP location update request message in the indirect GTP-C firewall filtering database.

[0011] In accordance with yet another aspect of the subject matter described herein, the signaling message routing node includes a signal transfer point (STP).

[0012] In accordance with yet another aspect of the subject matter described herein, the indirect GTP-C firewall filtering database is implemented on a computing platform separate from the signaling message routing node.

[0013] In accordance with yet another aspect of the subject matter described herein, the indirect GTP-C firewall filtering database is co-located with the signaling message routing node.

[0014] In accordance with yet another aspect of the subject matter described in this specification, the indirect GTP-C firewall filtering database is located on a computing platform separate from the signaling message routing node and a Home Location Register (HLR) or a Home Subscriber Server (HSS).

[0015] In accordance with yet another aspect of the subject matter described herein, a method for indirect GTP-C firewall filtering includes dynamically populating the GTP-C firewall filtering database with an International Mobile Equipment Identifier (IMEI) extracted from a mobility management signaling message, extracting an IMEI value from the CCR-I message, and screening the CCR-I message using the IMEI in the GTP-C firewall filtering database.

[0016] In accordance with yet another aspect of the subject matter described herein, a system for performing indirect General Packet Radio Service (GPRS) Tunneling Protocol (GTP) firewall filtering, the system includes an indirect GTP Core (GTP-C) firewall filtering database. The system further includes at least one signaling message routing node, which dynamically populates the indirect GTP-C firewall filtering database with an International Mobile Subscriber Identifier (IMSI) and a Visited Public Land Mobile Network Identifier (VPLMN ID) extracted from a mobility management signaling message for updating a location of an outbound roaming subscriber, receives a Credit-Control-Request-Initial (CCR-I) message generated in response to a GTP-C message, extracts an IMSI and a VPLMN ID from the CCR-I message, accesses the indirect GTP-C firewall filtering database using the IMSI extracted from the CCR-I message, determines that a record corresponding to the IMSI exists in the indirect GTP-C firewall filtering database, determines that the VPLMN ID in the record does not match the VPLMN ID extracted from the CCR-I message, and determines that the VPLMN ID in the record matches the VPLMN ID extracted from the CCR-I message. In response to determining that the ID does not match, the CCR-I message is rejected.

[0017] According to yet another aspect of the subject matter described herein, the at least one signaling message routing node is configured to receive a Diameter Location Update Request (ULR) message, extract an IMSI and a VPLMN ID from the Diameter ULR message, temporarily store the IMSI and the VPLMN ID extracted from the Diameter ULR message, determine that the update of the subscriber's location is successful, and in response to determining that the update of the subscriber's location is successful, dynamically populate the indirect GTP-C firewall filtering database by associating the VPLMN ID extracted from the Diameter ULR message with the IMSI extracted from the Diameter ULR message in the indirect GTP-C firewall filtering database.

[0018] In accordance with yet another aspect of the subject matter described herein, the at least one signaling message routing node includes a Diameter Edge Agent (DEA).

[0019] In accordance with yet another aspect of the subject matter described herein, the at least one signaling message routing node includes a Diameter Relay Agent (DRA).

[0020] According to yet another aspect of the subject matter described herein, the at least one signaling message routing node is configured to receive a Mobile Application Part (MAP) location update request message, extract an IMSI and a VPLMN ID from the MAP location update request message, temporarily store the IMSI and the VPLMN ID extracted from the MAP location update request message, determine that the update of the subscriber's location is successful, and in response to determining that the update of the subscriber's location is successful, dynamically populate the indirect GTP-C firewall filtering database by associating the VPLMN ID with the IMSI extracted from the MAP location update request message in the indirect GTP-C firewall filtering database.

[0021] In accordance with yet another aspect of the subject matter described herein, the at least one signaling message routing node comprises a signal transfer point (STP) for dynamically populating the GTP-C firewall filtering database; and a diameter agent for receiving the CCR-I message generated in response to the GTP-C message, extracting the IMSI and the VPLMN ID from the CCR-I message, accessing the indirect GTP-C firewall filtering database using the IMSI extracted from the CCR-I message, determining that a record corresponding to the IMSI exists in the indirect GTP-C firewall filtering database, determining that the VPLMN ID in the record does not match the VPLMN ID extracted from the CCR-I message, and rejecting the CCR-I message in response to determining that the VPLMN ID in the record does not match the VPLMN ID extracted from the CCR-I message.

[0022] In accordance with yet another aspect of the subject matter described herein, the indirect GTP-C firewall filtering database is co-located with the signaling message routing node.

[0023] In accordance with yet another aspect of the subject matter described in this specification, the indirect GTP-C firewall filtering database is located on a computing platform separate from the signaling message routing node and a Home Location Register (HLR) or a Home Subscriber Server (HSS).

[0024] In accordance with yet another aspect of the subject matter described herein, the at least one signaling message routing node is configured to dynamically populate the GTP-C firewall filtering database with an International Mobile Equipment Identifier (IMEI) extracted from a mobility management signaling message, extract an IMEI value from the CCR-I message, and screen the CCR-I message using the IMEI in the GTP-C firewall filtering database.

[0025] According to yet another aspect of the subject matter described herein, a non-transitory computer-readable medium having executable instructions stored thereon, the instructions, when executed by a processor of a computer, control the computer to perform steps including dynamically populating, using a signaling message routing node, an international mobile subscriber identifier (IMSI) and a visited public land mobile network identifier (VPLMN ID) extracted from a mobility management signaling message for updating a location of an outbound roaming subscriber into an indirect General Packet Radio Service (GPRS) Tunneling Protocol Core (GTP-C) firewall filtering database. The steps further include receiving a Credit-Control-Request-Initial (CCR-I) message generated in response to a GTP-C message. The steps further include extracting the IMSI and the VPLMN ID from the CCR-I message. The steps further include accessing the indirect GTP-C firewall filtering database using the IMSI extracted from the CCR-I message. The steps further include determining that a record corresponding to the IMSI exists in the indirect GTP-C firewall filtering database, determining that a VPLMN ID in the record does not match the VPLMN ID extracted from the CCR-I message, and rejecting the CCR-I message in response to determining that the VPLMN ID in the record does not match the VPLMN ID extracted from the CCR-I message.

[0026] The subject matter described herein may be implemented in hardware, software, firmware, or any combination thereof. Thus, the terms "function," "node," or "module" as used herein refer to hardware that may also include software and / or firmware components to implement the described features. In one exemplary implementation, the subject matter described herein may be implemented using a computer-readable medium having computer-executable instructions stored thereon that, when executed by a processor of a computer, control a computer to perform 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. Additionally, the computer-readable medium implementing the subject matter described herein may be located on a single device or computing platform, or may be distributed across multiple devices or computing platforms. [Brief description of the drawings]

[0027] [Figure 1] FIG. 1 is a network diagram illustrating example messaging for an outbound roaming subscriber in a 4G network to perform a location update procedure with a home network. [Diagram 2] A network diagram showing example messaging for validating a GTP-C session creation request for an outbound roaming subscriber in a 4G network. [Diagram 3] 1 is a network diagram illustrating example messaging associated with an outbound roaming subscriber in a second generation / third generation (2G / 3G) network performing a location update procedure with a home network. [Figure 4]A network diagram illustrating example messaging associated with validating a create GTP PDP context request for an outbound roaming subscriber in a 2G / 3G network. [Diagram 5] FIG. 1 is a block diagram illustrating an example architecture of a DEA / DRA / STP node for creating a GTP-C screening database and using this database to perform GTP-C firewall functions without intercepting GTP-C signaling. [Figure 6] 1 is a flow chart illustrating an exemplary process for dynamically populating entries into a GTP-C screening database. [Figure 7] 1 is a flowchart illustrating an example process for performing GTP-C firewall functionality without interrupting GTP-C roaming signaling. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0028] Detailed Description The subject matter described herein performs GTP-C firewall functionality using an indirect GTP-C firewall filtering database populated by the DEA, DRA and / or STP, and uses the database to screen GTP-C traffic without blocking GTP-C roaming signaling. Such a database provides GTP-C signaling-based fraud detection in cases where an attacker attempts to masquerade as a node serving a legitimate outbound roaming subscriber. This solution does not require blocking of GTP-C roaming signaling traffic, thus simplifying PGW implementation. The solution described herein provides the ability to indirectly detect fraudulent GTP-C roaming signaling traffic at the DEA and DRA based on Diameter messages sent to the DEA and DRA in response to the GTP-C roaming signaling traffic. The DEA and DRA may receive a Create Connection Request message generated in response to a GTP-C Session Creation Request sent by an attacker. The DEA and DRA may utilize subscriber PLMN information obtained from Diameter location update signaling transactions maintained in the indirect GTP-C firewall filtering database, or subscriber roaming information obtained from SS7 signal messaging traffic stored in the indirect GTP-C firewall filtering database by the STP.

[0029] As mentioned above, GTP-C traffic is used for session management, information management and location management, and allows UEs to access the Internet. By providing an efficient screening mechanism for such traffic, core network security is enhanced in a more efficient manner than performing such screening at the PGW based on GTP-C traffic.

[0030] FIG. 1 is a network diagram illustrating exemplary network nodes and messaging associated with an outbound roaming subscriber performing a location update procedure. With reference to FIG. 1, when a subscriber roams to a visited network, a mobility management entity (MME) or serving GPRS support node (SGSN) 100 initiates a diameter location update transaction with the core network. In the illustrated example, the MME / SGSN 100 sends a location update request to the subscriber's home network. The location update request is intended to update the subscriber's location in a home subscriber server (HSS) 102 in the home network. In particular, according to Third Generation Partnership Project (3GPP) TS 29.272, the location update procedure is used between the MME and HSS and between the SGSN and HSS to update location information in the HSS. Table 1 shown below illustrates exemplary parameters that may be included in the location update request message.

[0031] [Table 1-1]

[0032] [Table 1-2]

[0033] [Table 1-3]

[0034] In Table 1, it can be seen that the Location Update Request message contains the subscriber's IMSI and the visited PLMN identifier as mandatory parameters. These parameters can be used to perform indirect GTP-C firewall filtering, as will be explained in more detail below. Another parameter, which can be yet another information element that can be used to perform indirect GTP-C firewall filtering, is the IMEI.

[0035] The DEA 104 may temporarily store the IMSI, Visited PLMN (VPLMN) ID, and IMEI until it receives a Location Update Request message from the MME / SGSN 100 and the information is verified by the HSS. One reason that the DEA 104 does not initially store these parameters in its indirect GTP-C firewall filtering database is that the Location Update Request message may be initiated by an attacker. Only after successful verification by the HSS does the DEA 104 store the parameters identifying the location of the outbound roaming subscriber in its GTP-C screening database.

[0036] In step 2 of the call flow diagram, the DEA 104 forwards the ULR message to a core Diameter Relay Agent (DRA) 106. In step 3, the core DRA 106 forwards the S6A ULA message to the HSS 102.

[0037] The HSS 102 may validate the ULR message and, upon successful validation, update the subscriber's location in a database maintained by the HSS 102. In step 4, the HSS 102 sends a Location Update Answer (ULA) message to the core DRA 106 indicating successful updating of the subscriber's location. In step 5, the core DRA 106 forwards the S6A ULA message to the DEA 104. In step 6, the DEA 104 updates the indirect GTP-C firewall filtering database 108 with the IMSI, VPLMN ID, and optionally the IMEI previously extracted from the ULR message. As described in more detail below, the records in the indirect GTP-C firewall filtering database 108 are used to screen GTP-C traffic without requiring blocking of the GTP-C traffic. In step 7, the DEA 104 forwards the ULA message to the MME / SGSN 100.

[0038] 1 also includes an STP 110, which may also dynamically populate the indirect GTP-C firewall filtering database 108 with subscriber location information obtained from SS7 signaling messages.

[0039] Table 2, shown below, illustrates an example of entries that may be populated into the indirect GTP-C firewall filtering database 108 following the call flow shown in FIG.

[0040] [Table 2]

[0041] In Table 2, the record contains the IMSI, visited network identity (ie, VPLMN ID), and IMEI for the outbound roaming subscriber.

[0042] Once the database is populated with subscriber information, the database can be used to screen GTP-C messages. FIG. 2 is a network and message flow diagram illustrating the use of the indirect GTP-C firewall filtering database 108 to indirectly screen GTP-C messages. With reference to FIG. 2, in step 1, an attacker masquerades as a serving gateway serving a bogus outbound mobile subscriber. The objective of such an attack may be to create a session between the attacker and a core network node, such as a packet gateway 202, to send attack traffic to the core network. The attacker initiates the attack by sending a GTP-C session creation request message with the IMSI and VPLMN ID of the serving network. In one example, the IMSI may be the IMSI of a subscriber actually provisioned in the network, and the VPLMN ID may be a bogus network corresponding to the attacker, rather than the network currently serving the outbound roaming subscriber. The GTP-C session creation request is sent to the home network packet gateway 202 as part of a packet data network session establishment procedure. The GTP-C session creation request may include a user location information element that stores the VPLMN ID. If the GTP-C connection creation request is a legitimate connection creation request from a real outbound roaming subscriber, the VPLMN ID may be the ID of the VPLMN in which the subscriber is roaming. However, if the GTP-C connection creation request originates from an attacker, the VPLMN ID may be the VPLMN that identifies the network in which the attacker is located. Yet another information element that may be included in the GTP-C connection creation request is the IMSI, which contains the 15-digit identifier of the UE. In this example, it is assumed that the attacker has obtained the IMSI of the real outbound roaming subscriber and inserts a fake VPLMN ID into the GTP-C session creation request.

[0043] In step 2 of the message flow diagram, the PGW 202 receives the GTP-C session creation request and in response constructs and sends a Credit Control Request-Initial (CCR-I) message addressed to the Policy and Charging Rules Function (PCRF) 204. The CCR-I message is sent from the PGW to the PCRF to request policy and charging control rules for bearers and to provision IP flow mobility routing rules. The CCR-I message includes a Subscription-ID Attribute Value Pair (ADP) that stores the IMSI of the subscriber. The CCR-I message also includes a 3GPP Location Information AVP that stores an indication of the subscriber's current location, such as the VPLMN ID of the network serving the subscriber. In this example, the VPLMN ID may be the one inserted by the SGW 200, rather than the subscriber's actual VPLMN ID.

[0044] In step 3 of the message flow diagram, the DRA 106 performs a lookup in the indirect GTP-C firewall filtering database 108 using the IMSI received in the CCR-I message. In this example, it is assumed that a record exists in the indirect GTP-C firewall filtering database 108 and that the VPLMN ID exists in the record. Thus, the DRA 106 searches the indirect GTP-C firewall filtering database 108 for the VPLMN ID corresponding to the IMSI. In step 4 of the message flow diagram, the DRA 106 compares the VPLMN ID extracted from the database record with the VPLMN ID received in the CCR-I message. In this example, it is assumed that the VPLMN ID stored in the database 108 for the IMSI is different from the VPLMN ID received in the CCR-I message. Thus, in step 5, the DRA 106 sends a message to the PGW 202 indicating a mismatch with the VPLMN ID, or alternatively, a message indicating that no record was found if no record corresponding to the IMSI exists in the database 108. The message from the Core DRA 106 to the PGW 202 may be a Credit-Control-Answer-Initial (CCA-I) message with a result code indicating that the Create GTP-C Session request should be rejected. In step 6 of the message flow diagram, the PGW 202 creates and sends a Create GTP-C Session response to the SGW 200 with an error code indicating APN Access Rejected - No Subscription.

[0045] Thus, using the steps in FIG. 2, subscriber roaming data obtained from Diameter location update transactions is used to indirectly screen fraudulent GTP-C traffic. Such an approach is more advantageous than performing screening directly at the PGW 202, where the PGW 202 would need to query the HLR or HSS to obtain the subscriber's location, or where the subscriber's location would need to be stored locally at the PGW. In such an example, the DEA and / or DRA can perform GTP-based fraud detection without intercepting GTP messages. The solution shown in FIG. 1 and FIG. 2 does not require a dedicated GTP firewall from the mobile network operator. Instead, the DEA 104 and / or DRA 106 indirectly realizes a GTP firewall by blocking connection creation request traffic generated in response to GTP-C session creation request traffic.

[0046] 1 and 2, the DEA dynamically populates the subscriber's current location into the indirect GTP-C firewall filtering database 108 and the DRA 106 performs GTP-C firewall functions using records in the database 108, although the subject matter described herein is not limited to such implementations. In alternative implementations, the DEA 104 can dynamically populate the indirect GTP-C firewall filtering database 108 with subscriber location information obtained from location update transactions, and the DEA 104 can screen connection creation traffic using records stored in the database 108.

[0047] In yet another alternative implementation, the database 108 can be populated using subscriber location information obtained by a signal transfer point such as the STP 110. FIG. 3 is a network diagram illustrating exemplary messaging associated with populating the indirect GTP-C firewall filtering database 108 using subscriber location information obtained by the STP 110. Referring to FIG. 3, in line 1 of the message flow diagram, when a subscriber roams into a visited 2G or 3G network, a Visitor Location Register (VLR) 300 serving the roaming subscriber in the visited network sends a Mobile Application Part (MAP) location update request to a Home Location Register (HLR) 302 in the subscriber's home network. The map location update request message includes the subscriber's IMSI and a VPLMN ID that identifies the visited network x in which the subscriber is currently roaming. The STP 110 receives the map location update request and temporarily stores the IMSI and VPLMN ID for the transaction. In line 2 of the message flow diagram, the STP 110 forwards the MAP location update request to the HLR 302. The HLR 302 validates the location update request and, if validated, updates the subscriber's location in its local location database.

[0048] At line 3 of the message flow diagram, the HLR 302 sends a MAP location update response to the VLR 300 indicating that the subscriber location was successfully updated. The HLR 302 forwards the location update response to the STP 110.

[0049] In step 4 of the message flow diagram, in response to receiving the map location update request, the STP 110 updates the indirect GTP-C firewall filtering database 108 with the IMSI and VPLMN ID previously stored by the STP 110. Updating the indirect GTP-C firewall filtering database 108 may include determining whether a record corresponding to the IMSI exists. If a record corresponding to the IMSI exists, the STP 110 may update the VPLMN ID in the record with the VPLMN ID received in the map location update request message. If the database 108 does not contain a record corresponding to the IMSI, the STP 110 may create a new record in the database that maps the IMSI to the VPLMN ID received in the map location update request message. The STP 110 may also store the IMEI in the record. After the record is updated or newly created, it may appear as described above in Table 1.

[0050] 1, the STP 110 populates the database 108 with the mapping between VPLMN IDs and IMSIs only upon receiving confirmation from the HLR that the location update transaction was successful. The reason for waiting until confirmation that the location update transaction was successful is to reduce the possibility of an attacker impersonating the VLR 300 and populating the database 108 with false location information for subscribers.

[0051] Also, in the example shown in Figure 3, database 108 is populated by an STP. It is understood that database 108 may be populated by a physical STP or a virtual STP without departing from the scope of the subject matter described herein. Such an STP may be a physical on-premise node in a service provider's network or a virtual STP in a network cloud hosted by the service provider or a cloud service provider.

[0052] Figure 4 is a network and message flow diagram illustrating an example messaging used to screen GTP-C traffic for an outbound roaming subscriber in a 2G / 3G network. With reference to Figure 4, an attacker masquerades as an SGSN 400 serving an outbound mobile subscriber in a 2G or 3G visited network. The attacker initiates the attack in step 1 by sending a GTP-C Create PDP Context Request message to a GGSN 402 located in the subscriber's home network. The GTP-C Create PDP Context Request includes the IMSI and a VPLMN ID that identifies the attacker's network, in this example, instead of the VPLMN ID of the current subscriber that corresponds to the IMSI.

[0053] The GGSN 402 receives the GTP-C Create PDP Context Request message and constructs and sends a CCR-I message to the PCRF 204. The CCR-I message includes the IMSI, VPLMN ID, and IMEI from the GTP-C message. The GGSN 402 forwards the CCR-I message to the DRA 106.

[0054] In step 4 of the message flow diagram, the DRA 106 compares the VPLMN ID stored in the indirect GTP-C firewall filtering database 108, which corresponds to the IMSI, with the VPLMN ID extracted from the CCR-I message. In this example, it is assumed that there is a mismatch between the IMSI and the VPLMN ID. Thus, in line 5, the DRA 106 rejects the CCR-I message by sending a CCA-I message with a 5XXX response code to the GGSN 402. In response to receiving the CCA-I message with the reject response code, the GGSN 402 sends a create PDP context response to the attacker 400 indicating APN access rejected - no subscription. Thus, using the steps shown in FIG. 4, the database populated by the STP can be used to screen for attackers impersonating SGSNs in visited 2G or 3G networks.

[0055] FIG. 5 is a block diagram illustrating an exemplary internal architecture for a DEA / DRA / STP 104, 106, or 110 for implementing the subject matter described above with respect to FIGS. 1-4. In the example illustrated in FIG. 5, the DEA / DRA / STP 104, 106, or 110 includes a Diameter routing function and an SS7 routing function. It is understood that these functions may be performed in the same real or virtual network node, or may be performed in separate network nodes. With reference to the architecture illustrated in FIG. 5, the DEA / DRA / STP 104, 106, or 110 includes multiple message processors (MPs) 500, 502, 504, and 506. Each message processor 500, 502, 504, and 506 includes at least one processor 508 and a memory 510. Each message processor 500, 502, 504, and 506 may be implemented using a printed circuit board and corresponding traces for interconnecting components mounted on the circuit board. Message processors 500, 502, 504 and 506 may communicate with each other using an internal communication medium 512, which in one example is an Ethernet communication medium.

[0056] The message processor 500 performs DEA and / or DRA functions. Accordingly, the message processor 500 includes a diameter protocol stack 514 that performs diameter connection and routing functions. Thus, the diameter stack 514 can initiate or respond to diameter connections with diameter peers and route messages based on diameter layer information in the messages.

[0057] The message processor 502 performs SS7 routing functions. Thus, the message processor 502 includes an SS7 protocol stack 516 for routing SS7 messages based on Message Transfer Part (MTP) Level 3 information in the messages. The SS7 stack 516 may also implement the SIGTRAN protocol for transporting SS7 messages over IP networks.

[0058] Each of message processors 504 and 506 performs GTP-C firewall functions using indirect GTP-C firewall filtering database 108. In the example shown, message processors 504 and 506 may be provisioned with an identical copy of GTP firewall database 108, and message processors 500 and 502 may load balance messages requiring GTP-C firewall screening between message processors 500 and 506. Each message processor 504 and 506 also includes an indirect GTP-C firewall filtering database controller / screener 518 for screening connection creation request messages using subscriber location information populated in database 108, and for dynamically populating database 108 using information received from Diameter or SS7 location update messages for roaming subscribers.

[0059] 6 is a flow chart illustrating an exemplary process for dynamically populating an indirect GTP-C firewall filtering database. Referring to FIG. 6, in step 600, a mobility management message for updating an outbound roaming subscriber's location is received. For example, if the network uses Diameter to update the subscriber's location, the mobility management message may be a location update request message from the MME or SGSN serving the roaming mobile subscriber to update the subscriber's location stored in the HSS. If the network uses SS7 messaging to update the subscriber's location, the mobility management message may be a MAP location update request from the VLR to update the subscriber's location in the HLR.

[0060] In step 602, the process includes extracting and temporarily storing the VPLMN ID and IMSI from the message. For example, the DEA 104, DRA 106, or STP 110 may temporarily store the subscriber's IMSI and VPLMN ID extracted from the Diameter or SS7 location update request in a memory local to the DEA 104, DRA 106, or STP 110. In step 604, it is determined whether the location update was successful. For example, the DEA 104, DRA 106, or STP 110 may receive a location update answer or response message from the HLR or HSS indicating that the subscriber's location update at the HLR or HSS was successful or unsuccessful. If the location update answer or request message indicates that the subscriber's location update was unsuccessful, control proceeds to step 606 where the IMSI and VPLMN ID stored in step 602 are discarded.

[0061] If in step 604 it is determined that the location update transaction was successful, control proceeds to step 608 to access the indirect GTP-C firewall filtering database using the IMSI. For example, the DEA 104, DRA 106, or STP 110 may access the indirect GTP-C firewall filtering database 108 using the IMSI extracted from the location update message.

[0062] In step 610, it is determined whether the record exists in the database. If the record exists in the database, control passes to step 612 where the record is updated with the VPLMN ID from the message. If the record does not exist, control passes to step 614 where a new record is added that maps the IMSI to the VPLMN ID from the message.

[0063] 7 illustrates an exemplary process for performing GTP-C fraud detection and screening using a dynamically populated indirect GTP-C firewall filtering database. With reference to FIG. 7, in step 700, a CCR-I message generated in response to a GTP-C create context request message is received. For example, the DEA 104 or DRA 106 may receive a CCR-I message associated with a GTP-C create context request from a legitimate subscriber or an attacker.

[0064] In step 702, the process includes extracting the IMSI, VPLMN ID and IMEI from the message. In step 704, the IMSI is used to access an indirect GTP-C firewall filtering database.

[0065] In step 706, if a record exists, control proceeds to step 708, where it is determined whether the VPLMN ID from the message matches the VPLMN ID in the database record. If the VPLMN ID does not match the VPLMN ID in the database record, control proceeds to step 710, where the CCR-I message is rejected. If the VPLMN ID in the message matches the VPLMN ID stored for the IMSI in the database, control proceeds to step 712, where the CCR-I message is forwarded to the PCRF. For example, the DEA 104 or DRA 106 may forward the CCR-I message to the PCRF 204. The PCRF 204 may determine an appropriate policy for the session and respond with a Credit-Control-Request-Answer (CCR-A) message indicating successful establishment of the session. The DEA 104 or DRA 106 may forward the CCR-A message to the Gateway GPRS Support Node (GGSN) that sent the CCR-I message. The GGSN may respond with a GTP-C message indicating successful creation of the PDP context.

[0066] Thus, using the process described herein, the dynamically populated indirect GTP-C firewall filtering database can be accessed by the DRA, DEA and / or STP to indirectly implement a GTP-C firewall. Such an implementation does not require blocking of GTP-C signaling traffic or for the PGW to perform GTP-C screening functions. Also, because the indirect GTP-C firewall filtering database is dynamically provisioned based on answer messages received from the subscriber's home HLR or HSS, less effort is required to populate the database than with manual population methods.

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

[0068] [Table 3]

[0069] It will be understood that various details of the presently disclosed subject matter may be changed without departing from the scope of the presently disclosed subject matter. Further, the above description is for purposes of illustration only and not for purposes of limitation.

Claims

1. 1. A method for performing indirect General Packet Radio Service (GPRS) Tunneling Protocol (GTP) firewall filtering, comprising: using a signaling message routing node to dynamically populate an indirect GTP core (GTP-C) firewall filtering database with an International Mobile Subscriber Identifier (IMSI) and a Visited Public Land Mobile Network Identifier (VPLMN ID) extracted from a mobility management signaling message for updating the location of an outbound roaming subscriber; receiving a Credit-Control-Request-Initial (CCR-I) message generated in response to the GTP-C message; extracting the IMSI and VPLMN ID from the CCR-I message; accessing the indirect GTP-C firewall filtering database using the IMSI extracted from the CCR-I message; determining that a record corresponding to the IMSI exists in the indirect GTP-C firewall filtering database; determining that the VPLMN ID in the record does not match the VPLMN ID extracted from the CCR-I message; and in response to determining that the VPLMN ID in the record does not match the VPLMN ID extracted from the CCR-I message, rejecting the CCR-I message.

2. The step of dynamically populating the indirect GTP-C firewall filtering database using a signaling message routing node includes, at the signaling message routing node: receiving a Diameter Location Update Request (ULR) message for updating the location of an outbound roaming subscriber at a home network of the subscriber; extracting an IMSI and a VPLMN ID from the Diameter ULR message; temporarily storing the IMSI and the VPLMN ID extracted from the Diameter ULR message; determining that the updating of the location of the subscriber at the home network of the subscriber was successful; and in response to determining that the update of the subscriber's location was successful, associating in the indirect GTP-C firewall filtering database the VPLMN ID extracted from the Diameter ULR message with the IMSI extracted from the Diameter ULR message.

3. The method of claim 1 or 2, wherein the signaling message routing node comprises a Diameter edge agent.

4. The method according to any one of claims 1 to 3, wherein the signaling message routing node comprises a Diameter Relay Agent (DRA).

5. The step of dynamically populating the indirect GTP-C firewall filtering database comprises, at the signaling message routing node: receiving a Mobile Application Part (MAP) location update request message for updating a location of an outbound roaming subscriber at a home network of the subscriber; extracting an IMSI and a VPLMN ID from the MAP Location Update Request message; temporarily storing the IMSI and the VPLMN ID extracted from the MAP Location Update Request message; determining that the updating of the location of the subscriber at the home network of the subscriber was successful; and in response to determining that the update of the subscriber's location at the subscriber's home network was successful, associating the VPLMN ID with the IMSI extracted from the MAP Location Update Request message in the indirect GTP-C firewall filtering database.

6. The method of claim 1 or 5, wherein the signaling message routing node comprises a signal transfer point (STP).

7. The method of any one of claims 1 to 6, wherein the indirect GTP-C firewall filtering database is on a computing platform separate from the signaling message routing node.

8. The method of any one of claims 1 to 6, wherein the indirect GTP-C firewall filtering database is co-located with the signaling message routing node.

9. The method according to any one of claims 1 to 7, wherein the indirect GTP-C firewall filtering database is located on a computing platform separate from the signalling message routing node and a Home Location Register (HLR) or a Home Subscriber Server (HSS).

10. dynamically populating said GTP-C firewall filtering database with an International Mobile Equipment Identifier (IMEI) extracted from a mobility management signaling message; extracting an IMEI value from the CCR-I message; The method of any one of claims 1 to 9, further comprising the step of: screening the CCR-I message using the IMEI in the GTP-C firewall filtering database.

11. 1. A system for performing indirect General Packet Radio Service (GPRS) Tunneling Protocol (GTP) firewall filtering, comprising: an indirect GTP core (GTP-C) firewall filtering database; and at least one signaling message routing node, which dynamically populates the indirect GTP-C firewall filtering database with an International Mobile Subscriber Identifier (IMSI) and a Visited Public Land Mobile Network Identifier (VPLMN ID) extracted from a mobility management signaling message for updating a location of an outbound roaming subscriber, receives a Credit-Control-Request-Initial (CCR-I) message generated in response to a GTP-C message, extracts an IMSI and a VPLMN ID from the CCR-I message, accesses the indirect GTP-C firewall filtering database using the IMSI extracted from the CCR-I message, determines that a record corresponding to the IMSI exists in the indirect GTP-C firewall filtering database, determines that a VPLMN ID in the record does not match the VPLMN ID extracted from the CCR-I message, and accesses the indirect GTP-C firewall filtering database using the IMSI extracted from the CCR-I message, and determines that the VPLMN ID in the record does not match the VPLMN ID extracted from the CCR-I message. The system is configured to reject the CCR-I message in response to determining that the VPLMN ID does not match the VPLMN ID extracted from the CCR-I message.

12. The at least one signaling message routing node receiving a Diameter Location Update Request (ULR) message; Extracting the IMSI and VPLMN ID from the Diameter ULR message; Temporarily storing the IMSI and the VPLMN ID extracted from the Diameter ULR message; determining that the update of the subscriber's location was successful; in response to determining that the update of the subscriber's location was successful, associating in the indirect GTP-C firewall filtering database the VPLMN ID extracted from the Diameter ULR message with the IMSI extracted from the Diameter ULR message.

12. The system of claim 11, configured to dynamically populate the indirect GTP-C firewall filtering database by:

13. The system of claim 12 , wherein the at least one signaling message routing node comprises a Diameter edge agent.

14. The system according to any one of claims 11 to 13, wherein the at least one signaling message routing node comprises a Diameter Relay Agent (DRA).

15. The at least one signaling message routing node Receive a mobile application unit (MAP) location update request message; Extracting the IMSI and VPLMN ID from the MAP Location Update Request message; Temporarily storing the IMSI and the VPLMN ID extracted from the MAP Location Update Request message; determining that the update of the subscriber's location was successful; in response to determining that the update of the subscriber's location was successful, associating, in the indirect GTP-C firewall filtering database, the VPLMN ID with the IMSI extracted from the MAP Location Update Request message; 12. The system of claim 11, configured to dynamically populate the indirect GTP-C firewall filtering database by:

16. The at least one signaling message routing node a signal transfer point (STP) for dynamically populating the GTP-C firewall filtering database; and a Diameter agent for receiving the CCR-I message generated in response to the GTP-C message, extracting the IMSI and the VPLMN ID from the CCR-I message, accessing the indirect GTP-C firewall filtering database using the IMSI extracted from the CCR-I message, determining that a record corresponding to the IMSI is present in the indirect GTP-C firewall filtering database, determining that the VPLMN ID in the record does not match the VPLMN ID extracted from the CCR-I message, and rejecting the CCR-I message in response to determining that the VPLMN ID in the record does not match the VPLMN ID extracted from the CCR-I message.

17. The system of any one of claims 11 to 16, wherein the indirect GTP-C firewall filtering database is co-located with the at least one signaling message routing node.

18. The system of any one of claims 11 to 16, wherein the indirect GTP-C firewall filtering database is located on a computing platform separate from the at least one signaling message routing node and a Home Location Register (HLR) or a Home Subscriber Server (HSS).

19. The at least one signaling message routing node dynamically populating said indirect GTP-C firewall filtering database with an International Mobile Equipment Identifier (IMEI) extracted from a mobility management signaling message; Extracting an IMEI value from the CCR-I message; A system according to any one of claims 11 to 18, configured to screen the CCR-I messages using the IMEI in the GTP-C firewall filtering database.

20. A computer program having executable instructions stored thereon, the instructions causing, when executed by a processor of a computer, to carry out a method according to any of claims 1 to 10.

Images