Method, system, and computer-readable medium for receiving message rate limiting

Abstract

Disclosed are methods, systems, and computer-readable media for receive message rate limiting. One method, executed at a first network node of a first network, includes obtaining an identifier identifying the second network node or the second network from a Transport Layer Security (TLS) message from a second network node of a second network, receiving a request message from the second network node or the second network, determining using the identifier that an allowed receive message rate associated with the second network node or the second network has been reached or exceeded, and performing a rate limiting operation in response to determining that an allowed receive message rate associated with the second network node or the second network has been reached or exceeded.

Description

[Technical Field]

[0001] Priority claims This application claims the benefit of priority to U.S. Patent Application No. 17 / 134,635, filed December 28, 2020, U.S. Patent Application No. 17 / 129,487, filed December 21, 2020, Indian Provisional Application No. 202041049614, filed November 13, 2020, and Indian Provisional Application No. 202041048552, filed November 6, 2020, the disclosures of all of which are incorporated herein by reference.

[0002] Technical Field The subject matter described herein relates to improving security in 5G communication networks. In particular, the subject matter described herein relates to a method, system, and computer-readable medium for receiving message rate limiting. [Background technology]

[0003] background In a 5G telecommunications network, a network node that provides a service is called a producer NF (Network Function). A network node that consumes a service is called a consumer NF. A Network Function can be either a producer NF or a consumer NF depending on whether it is consuming or providing a service.

[0004] A given producer NF may have many service endpoints, where a service endpoint is a connection point for one or more NF instances hosted by the producer NF. A service endpoint is identified by a combination of an Internet Protocol (IP) address and port number, or a fully qualified domain name that resolves to an IP address and port number on the network node hosting the producer NF. An NF instance is an instance of a producer NF that provides a service. A given producer NF may contain two or more NF instances. Note that multiple NF instances can share the same service endpoint.

[0005] Producer NFs register with the Network Function Repository Function (NRF). The NRF maintains service profiles of available NF instances that identify the services each NF instance supports. Consumer NFs can subscribe to receive information about producer NF instances that are registered with the NRF. 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). An SCP subscribes via the NRF to obtain reachability and service profile information about producer NF service instances. Consumer NFs can: SCP Connect to SCP load balances the traffic among the producer NF service instances that provide the requested service, or routes the traffic directly to the destination producer NF instance.

[0006] In addition to SCPs, other examples of intermediate proxy nodes or 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. SEPPs are network nodes used to protect control plane traffic exchanged between different 5G public land mobile networks (PLMNs). As such, SEPPs perform message filtering, policing, and topology hiding for all API (Application Programming Interface) messages.

[0007] However, improvements to security measures in one or more NFs are needed. Summary of the Invention

[0008] overview

[0009] Methods, systems, and computer-readable media for receive message rate limiting are disclosed. One exemplary method for receive message rate limiting is executed at a first network node of a first network and includes obtaining an identifier identifying the second network node or the second network from a Transport Layer Security (TLS) message from a second network node of a second network, receiving a request message from the second network node or the second network, utilizing the identifier to determine that an allowed receive message rate associated with the second network node or the second network has been reached or exceeded, and performing a rate limiting operation in response to determining that an allowed receive message rate associated with the second network node or the second network has been reached or exceeded.

[0009] One exemplary system for receive message rate limiting includes a first network node of a first network, the first network node having at least one processor and a memory, configured to obtain an identifier identifying the second network node or the second network from a Transport Layer Security (TLS) message from a second network node of the second network, receive a request message from the second network node or the second network, determine using the identifier that an allowable receive message rate associated with the second network node or the second network has been reached or exceeded, and perform a rate limiting operation in response to determining that an allowable receive message rate associated with the second network node or the second network has been reached or exceeded.

[0010] One exemplary non-transitory computer-readable medium includes computer-executable instructions that, when executed by at least one processor of at least one computer, cause the at least one computer to perform steps including: obtaining, at a first network node of a first network, an identifier identifying the second network node or the second network from a Transport Layer Security (TLS) message from a second network node of a second network; receiving a request message from the second network node or the second network; using the identifier to determine that an allowed receive message rate associated with the second network node or the second network has been reached or exceeded; and performing a rate limiting action in response to determining that an allowed receive message rate associated with the second network node or the second network has been reached or exceeded.

[0011] According to aspects of the subject matter described herein, obtaining the identifier from the TLS message may include obtaining the identifier from a certificate (e.g., an X.509v3 certificate) included in the TLS message. For example, the X.509v3 certificate in the TLS message may include a Subject field or a Subject Alternative Name field that includes an FQDN associated with the sender's identity. In this example, the FQDN may include or represent a network node identifier or network identifier, e.g., the network identifier may be "5gc.mnc <mnc>.mcc <mcc>It may be stored in a format such as ".3gpp(R)network.org". <mnc>" and " <mcc>The " fields correspond to the MNC and MCC of the operator's PLMN.

[0012] According to aspects of the subject matter described herein, determining that an allowed received message rate associated with the second network node or second network has been reached or exceeded may include obtaining an allowed received message rate associated with the second network node or second network, obtaining a current received message rate associated with the second network node or second network, and comparing the current received message rate to the allowed received message rate to determine that the current received message rate meets or exceeds the allowed received message rate.

[0013] According to aspects of the subject matter described herein, obtaining a current received message rate associated with the second network node or the second network may include tracking or deriving message rates of multiple SEPPs in the second network to determine a current received message rate associated with the second network. For example, assuming rate limits are based on a source network identifier, the SEPP 126 may track the received message rate across multiple N32-f interface connections, may combine the received message rates of multiple SEPPs associated with the same network identifier, and may compare the combined received message rate associated with the network identifier to a predetermined allowed received message rate associated with the network identifier.

[0014] According to aspects of the subject matter described herein, the rate limiting action may include discarding the request message, generating or modifying a throttle rate to discard some of the messages, or notifying a network operator or management system.

[0015] The subject matter described herein may be implemented in hardware, software, firmware, or any combination thereof. As such, the terms "function," "node," or "module," as used herein, refer to hardware (which may also include software and / or firmware components) for implementing the described features. In one exemplary embodiment, the subject matter described herein may be implemented using a computer-readable medium having computer-executable instructions stored thereon. The instructions, when executed by a computer processor, control the computer to perform any one or more steps of the present invention. Exemplary computer-readable media suitable for implementing the subject matter described herein include non-transitory computer-readable media, such as disk storage, chip storage, programmable logic circuits, and application-specific integrated circuits. Additionally, a computer-readable medium implementing the subject matter described herein may be located on a single device or computing platform, or distributed among multiple devices or computing platforms. Additionally, a computer-readable medium implementing the subject matter described herein may be located on a single device or computing platform, or distributed among multiple devices or computing platforms.

[0016] The subject matter described herein will now be described with reference to the accompanying drawings. [Brief explanation of the drawings]

[0017] [Figure 1] FIG. 1 is a network diagram illustrating an exemplary 5G network architecture. [Figure 2] FIG. 1 illustrates an N32-f interface connection using TLS (Transport Layer Security). [Figure 3] FIG. 1 illustrates an exemplary node for receiving message rate limiting. [Figure 4] FIG. 10 is a message flow diagram illustrating a TLS handshake involving the N32-f interface. [Figure 5] FIG. 10 illustrates exemplary message rate related data. [Figure 6] FIG. 10 is a message flow diagram illustrating an example of received message rate limiting. [Figure 7] 1 is a flowchart illustrating an exemplary process for receiving message rate limiting. DETAILED DESCRIPTION OF THE INVENTION

[0018] Detailed Description Various embodiments of the subject matter described herein will now be described in detail, examples of which are illustrated in the accompanying drawings. Wherever possible, the same reference numbers will be used to refer to the same elements. Wherever possible, the same reference numbers will be used throughout the drawings to refer to the same or like parts.

[0019] 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 HPLMN (Home Public Land Mobile Network). As described above, the NRF 100 maintains profiles of available producer NF service instances and the services they support, allowing consumer NFs or SCPs to subscribe to or be notified of new / updated producer NF service instance registrations. The SCP 101 may also support service discovery and producer NF instance selection. The SCP 101 may perform load balancing of connections between consumer NFs and producer NFs. Additionally, using techniques described herein, the SCP 101 may perform preferred selection and routing based on the location of the NFs.

[0020] The NRF 100 is a repository of service profiles of NFs or producer NF instances. To communicate with a producer NF instance, a consumer NF or SCP must obtain the NF or service profile, or the producer NF instance, from the NRF 100. The NF or service profile is a JavaScript Object Notation (JSON) data structure specified in 3GPP (Third Generation Partnership Project) Technical Specification (TS) 29.510. The NF or service profile specification 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. In FIG. 1 , all nodes (except the NRF 100) can be either consumer NFs or producer NFs, depending on whether they are requesting or providing services. In the illustrated example, these nodes include a Policy Control Function (PCF) 102 that performs policy-related operations in the network, and a User Datagram Protocol (UDM) 103 that manages user data. Unified 1 includes an Access and Mobility Management Function (AMF) 110 and a Session Management Function (SMF) 108 that manages sessions between the PCF 102 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 UEs (User Equipment), such as UE 114, that wish to access the network.

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

[0022] The Radio Access Network (RAN) 120 connects the User Equipment (UE) 114 to the network via a wireless link. The Radio Access Network 120 may be accessed using a g-NodeB (gNB) (not shown in FIG. 1) or other wireless access point. The User Plane Function (UPF) 122 may support various proxy functions for user plane services. One example of such a proxy function is a Multipath Transmission Control Protocol (MPTCP) proxy function. The UPF 122 may also support performance measurement functions, which may be used by the UE 114 to obtain measurements of network performance. Also shown in FIG. 1 is a Data Network (DN) 124 through which the UE accesses data network services, such as Internet services.

[0023] The Security Edge Protection Proxy (SEPP) 126 filters incoming traffic from other PLMNs and performs topology hiding for traffic egressing from the home PLMN. The SEPP 126 may communicate with an SEPP in the foreign PLMN that manages security for the foreign PLMN. Thus, traffic between NFs in different PLMNs may traverse two SEPP functions: one for the home PLMN and one for the foreign PLMN.

[0024] The SEPP 126 may utilize an N32-c interface and an N32-f interface. The N32-c interface is a control plane interface between two SEPPs that can be used to perform an initial handshake (e.g., a TLS handshake) and to negotiate various parameters related to the N32-f interface connection and associated message transfer. The N32-f interface is a transport interface between two SEPPs that can be used to transfer various information (e.g., 5GC requests) between consumer and producer NFs after applying application-level security protections.

[0025] Typically, N32-f interface connections between SEPPs use TLS protected mode, but may use PRINS-based protected mode if there are one or more IP exchanges between SEPPs. When setting up an N32-f interface connection using PRINS-based protected mode, an N32-f context identifier is created as part of the handshake procedure, but when setting up an N32-f interface connection using TLS protected mode, an N32-f context identifier is not created. Furthermore, transport messages sent over an N32-f interface connection using TLS protected mode are HTTP / 2 messages and may not include the identity of the originating SEPP.

[0026] A potential problem with the existing 5G architecture is that a SEPP in a foreign PLMN may create a signaling storm by sending a significant number of inter-PLMN messages to another SEPP in the home PLMN. While the receiving SEPP or home PLMN can initiate a global message rate limiting procedure to contain or mitigate the impact of the signaling storm, the global message rate limiting can discard messages from the network or SEPPS that are not the cause of or related to the signaling storm.

[0027] FIG. 2 illustrates an N32-f interface connection using TLS. In FIG. 2, a SEPP 126 may be connected to various SEPPs in networks managed by different MNOs (Mobile Network Operators). As shown in FIG. 2, the SEPP 126 is connected to a SEPP 200 in an "MNO-1" network via an N32-f interface connection using TLS protection mode. The SEPP 126 is connected to a SEPP 202 in an "MNO-2" network via an N32-f interface connection using TLS protection mode. The SEPP 126 is connected to a SEPP 204 in an "MNO-3" network via an N32-f interface connection using TLS protection mode.

[0028] In some embodiments, the SEPP 126 may include functionality defined in 3GPP TS 33.501, such as message protection, mutual authentication, key management, topology hiding, access control, discarding unauthorized N32 signaling messages, rate limiting, and anti-spoofing mechanisms. For example, if the SEPP 200 and / or other SEPPs in the "MNO-1" network are sending a significant amount of traffic (e.g., a signaling storm) and the SEPP 126 or nodes in its home network are experiencing network congestion and / or other problems, the SEPP 126 may perform a global message rate limiting procedure. The global message rate limiting procedure may discard or throttle incoming messages in an attempt to throttle the global incoming message rate. However, such a procedure is generally indiscriminate about which networks' messages are throttled or discarded.

[0029] While global message rate limiting can mitigate the negative impact of signaling storms, such rate limiting may also unduly discard or throttle traffic associated with networks that are not the cause of or involved in the signaling storm (e.g., the "MNO-2" and "MNO-3" networks).

[0030] Effective identifiers for selective incoming message rate limiting may not be readily available due to a variety of factors. For example, while an N32-f context ID is available for an N32-f interface connection utilizing PRINS-based protection, such an ID is not available for an N32-f interface connection utilizing TLS protection. Furthermore, while a sender identifier may be parsed or derived from individual inter-PLMN messages, HTTP / 2 messages that typically traverse an N32-f interface connection utilizing TLS protection may not contain the identity of the sending SEPP, and utilizing the source IP address would be cumbersome due to network address translation and multiple SEPP instances and / or connections. Furthermore, rate limiting solutions requiring such parsing may be resource intensive, unscalable, and / or undesirable.

[0031] The subject matter described herein addresses such problems by providing methods and techniques for efficient and selective receive message rate limiting per PLMN or node therein, e.g., by discarding only excessive inter-PLMN messages from the network that are causing the problem. Moreover, such methods and techniques can provide receive message rate limiting for inter-PLMN messages with little additional overhead and can avoid parsing inter-PLMN messages to obtain the PLMN's identifier. For example, a receive message rate limiting method or technique described herein may obtain a source or sender identifier (e.g., an FQDN or network domain identifier) ​​from a received TLS message or X.509 certificate during a handshake procedure and then rate limit the receive messages based on the identifier.

[0032] 3 illustrates an exemplary node 300 for receiving message rate limiting. Node 300 may represent any suitable entity or entities for performing aspects of receiving message rate limiting. In some embodiments, node 300 may represent or include one or more 5GC NFs, such as a SEPP, NRF, PCF, NSSF, NEF, UDM, AUSF, UDR, Binding Support Function (BSF), or Unstructured Data Storage Function (UDSF). In some embodiments, node 300 may represent or include a network gateway, network proxy, edge security device, or related functionality.

[0033] In some embodiments, node 300 or associated modules may be configured (e.g., via programming logic) to rate limit incoming messages for inter-PLMN messages based on their source PLMN, thereby limiting or mitigating the impact of control plane signaling storms on nodes in the home network or other downstream NFs. For example, node 300 or associated modules may be configured to identify the identity of the PLMN from a digital certificate received during a TLS handshake, and may then rate limit incoming messages related to the PLMN identity.

[0034] 3, node 300 may include one or more communication interface(s) 302 for communicating messages via a communication environment, e.g., a home 5GC network. In some embodiments, communication interface(s) 302 may include a first communication interface for communicating with one or more SEPPs in a first network, a second communication interface for communicating with one or more SEPPs in a second network, and a third communication interface for communicating with one or more SEPPs in a home network, e.g., a home 5GC network.

[0035] The node 300 may include a Rate Limiting Manager (RLM) 304. The RLM 304 may be any suitable entity (e.g., software running on at least one processor) for performing one or more aspects of receiving message rate limiting. In some embodiments, the RLM 304 may include functionality for obtaining an identifier that identifies a network node or associated network from a TLS message from the network node and utilizing the identifier for receiving message rate limiting. For example, obtaining the identifier from the TLS message may include obtaining the identifier from a certificate (e.g., an X.509v3 certificate) included in the TLS message. In this example, the X.509v3 certificate in the TLS message may include a Subject field or Subject Alternative Name field that includes an FQDN associated with the sender's identity. In this example, the FQDN may include or represent a network node identifier or network identifier, e.g., the network identifier may be "5gc.mnc <mnc>.mcc <mcc>It may be the ID of a PLMN or a network domain stored in a format such as ".3gppnetwork.org" where " <mnc>" and " <mcc>The " fields correspond to the MNC and MCC of the operator's PLMN.

[0036] In some embodiments, for example, after identifying an identifier associated with a particular N32-f interface connection, the RLM 304 may be configured to monitor the N32-f interface connection for inter-PLMN messages (e.g., HTTP / 2 messages). In this example, for each received inter-PLMN message, the RLM 304 may utilize the identifier to determine whether the allowed received message rate associated with the identifier has been reached or exceeded, and in response to determining that the allowed received message rate associated with the identifier has been reached or exceeded, the RLM 304 may perform a rate limiting action. Rate limiting actions may include discarding the request message, generating or modifying a throttle rate to discard some of the received messages, and / or notifying a network operator or management system about the received message rate or related events.

[0037] In some embodiments, the RLM 304 may be configured to determine whether to perform receive message rate limiting by obtaining an allowed receive message rate associated with the network node or a network that includes the network node, obtaining a current receive message rate associated with the network node or network, and comparing the current receive message rate to the allowed receive message rate. If the current receive message rate meets or exceeds the allowed receive message rate, a rate limiting action may be performed. If the current receive message rate meets or exceeds the allowed receive message rate, the RLM 304 may, for example, handle or process messages without receive message rate limiting.

[0038] In some embodiments, the RLM 304 may be configured to track or derive message rates for multiple nodes or associated connections. For example, assuming rate limits are based on the source network identifier, the RLM 304 may track the received message rate across multiple N32-f interface connections, may combine the received message rates of multiple SEPPs associated with the same network identifier, and may compare the combined received message rate associated with the network identifier to a predetermined allowed received message rate associated with the network identifier.

[0039] Node 300 may access (e.g., read and / or write information from) data storage 306. Data storage 306 may be any suitable entity (e.g., computer-readable medium or memory) for storing various data. In some embodiments, data storage 306 may include logic for obtaining identifiers of TLS messages and / or digital certificates, logic for checking whether to perform received message rate limiting, logic for implementing or triggering rate limiting actions, logic for tracking current received message rates associated with various connections (e.g., N32-f interface connections) and / or source entities (e.g., PLMN IDs or FQDNs), and predetermined allowed message rates for one or more external networks and / or nodes therein.

[0040] In some embodiments, data storage 306 may include message rate limit data. For example, data storage 306 may include information for identifying current message rates, allowed message rates, and / or message throttle rates for various PLMNs or network nodes therein. In this example, the associated message rates and throttle rates may be indexed or otherwise identified using identifiers obtained from TLS messages or X.509 certificates therein.

[0041] It will be appreciated that FIG. 3 and the associated description are for illustrative purposes, and that node 300 may include additional and / or different modules, components, or functionality.

[0042] 4 is a message flow diagram illustrating a TLS handshake associated with setting up an N32-f interface connection between a SEPP 200 and a SEPP 126. In some embodiments, the SEPP 126 or the RLM 304 therein may be configured to obtain or determine an identifier associated with the initiating SEPP 200 when setting up or configuring the N32-f interface connection. For example, the initiating SEPP 200 and the responding SEPP 126 exchange TLS handshake messages over the N32-c interface to establish a TLS connection. The TLS handshake may include an exchange of ClientHello and ServerHello messages, followed by an exchange of Certificate messages. Each Certificate message may include the sender's X.509 certificate. The sender's identity may be contained in the X.509 certificate and is difficult to spoof because the X.509 certificate is signed by a certificate authority.

[0043] The TLS handshake protocol is specified in IETF (Internet Engineering Task Force) RFC (Request for Comments) 5246 and includes the exchange of certificate messages by both ends of a TLS connection. The TLS handshake message structure (including the certificate message) specified in IETF RFC 5246 is shown below.

[0044]

number

[0045] As indicated by the structure of the TLS handshake message described above, one of the defined handshake message types is a Certificate message. The Certificate message contains either a client certificate or a server certificate, depending on whether the sender is acting as a client or a server. When establishing secure TLS communication over the N32-c interface, common TLS or m-TLS is used, in which both ends of the TLS connection receive and verify the other end's X.509 certificate. IETF RFC 5246 indicates that the certificate type must be X.509v3 unless explicitly negotiated. While the embodiments described herein use X.509v3 certificates as examples, the subject matter described herein is not limited to verifying a sender's N32-c identity using a sender's identity extracted from X.509v3. The format of an X.509v3 certificate is specified in IETF RFC 3280. According to IETF RFC 3280, an extension or parameter that an X.509v3 certificate can include is the Subject Alternative Name extension. The Subject Alternative Name extension is defined as follows:

[0046] The Subject Alternative Name extension allows additional identities to be bound to the subject of a certificate. Defined options include Internet email addresses, DNS names, IP addresses, and Uniform Resource Identifiers (URIs). Other options exist, including entirely local definitions. Multiple name forms, and multiple instances of each name form, may be included. Whenever such identities are bound to a certificate, the Subject Alternative Name (Issuer Alternative Name) extension MUST be used. However, DNS names may also be represented in the subject field using the domainComponent attribute, as described in Section 4.1.2.4.

[0047] Since the Subject Alternative Name is considered to be ultimately bound to the public key, all parts of the Subject Alternative Name must be verified by the CA.

[0048] In some embodiments, as described above, the subject alternative name extension of an X.509v3 certificate may contain a DNS name, IP address, or URI, verified by the certificate authority, that identifies the subject of the certificate. Because the subject alternative name is verified by the certificate authority, it is difficult to spoof the subject alternative name.

[0049] Referring to FIG. 4, in step 401, a ClientHello message may be sent from SEPP 200 to SEPP 126 to initiate a TLS handshake.

[0050] In step 402, various handshake-related messages (eg, a ServerHello message, a Certificate message, a ServerKeyExchange message, a CertificateRequest message, and a ServerHelloDone message) may be sent from SEPP 126 to SEPP 200, for example, in response to a ClientHello message.

[0051] In step 403, various handshake-related messages (eg, Certificate message, ClientKeyExchange message, CertificateVerify message, ChangeCipherSpec message, and Finished message) may be sent from SEPP 200 to SEPP 126, for example, in response to the ServerHelloDone message.

[0052] In step 404, a client-related identifier may be extracted from the Certificate message and stored, for example, in data storage 306. For example, the SEPP 126 or the RLM 304 therein may extract or derive the relevant identifier from the FQDN stored in the X.509v3 certificate of the Certificate message. In this example, the FQDN may include or represent a network node identifier or network identifier, for example, the network identifier may be "5gc.mnc <mnc>.mcc <mcc>.3gppnetwork.org" where " <mnc>" and " <mcc>The " fields correspond to the MNC and MCC of the operator's PLMN.

[0053] In step 405, various handshake-related messages (eg, a ChangeCipherSpec message, and a Finished message) may be sent from SEPP 126 to SEPP 200, for example, in response to the Finished message.

[0054] In step 406, after identifying a client-related identifier (e.g., a PLMN ID) associated with the N32-f interface connection, the SEPP 126 or the RLM 304 therein may monitor inter-PLMN messages (e.g., HTTP / 2 messages) received over the N32-f interface connection for purposes of receiving message rate limiting. For example, when an HTTP / 2 request message associated with a particular PLMN ID is received over the N32-f interface connection, the SEPP 126 or the RLM 304 therein may determine whether the current message rate associated with the client-related identifier meets or exceeds the allowed message rate associated with the client-related identifier before processing, forwarding, and / or responding to the inter-PLMN message.

[0055] It will be appreciated that Figure 4 is for illustrative purposes and that different and / or additional messages and / or actions may be used. It will also be appreciated that the various messages and / or actions described herein may be performed in a different order or sequence.

[0056] 5 is a diagram illustrating example message rate related data 500. Data 500 may include information for identifying current message rates, allowed message rates, and / or message throttle rates for various PLMNs or network nodes therein. For example, each rate in data 500 may represent a number of messages, requests, or transactions per TPS (transactions per second) over a period of time.

[0057] 5, the table illustrating data 500 includes columns and / or fields for network and / or node ID, current message rate, allowed message rate, and message throttle rate. The NET ID field may store information for representing a PLMN. The network ID may include a PLMN identifier, a Mobile Country Code (MCC), a Mobile Network Code (MNC), a Location Area Code (LAC), a network identifier, a Cell Global Identifier (CGI), a Base Station Identifier (BSID), an access node identifier, a Cell Identity (CI), a Service Area Code (SAC), a Routing Area Identity (RAI), a Routing Area Code (RAC), a Tracking Area Identity (TAI), a Tracking Area Code (TAC), an eUTRAN CGI (EGCI), location coordinates (e.g., Global Positioning System (GPS) information), and / or relative location information. The node ID may include a FQDN, a URI, a Domain Name System (DNS) name, an IP address, or the like.

[0058] The current message rate field may store information to represent a measured or tracked message rate associated with one or more messages, message types, or transactions. For example, the current message rate (e.g., 50 TPS) may indicate a measured rate of inter-PLMN request messages or transactions received from a particular PLMN.

[0059] The allowed message rate field may store information to indicate a predetermined allowed message rate associated with one or more messages, message types, or transactions. For example, an allowed message rate (e.g., 40 TPS) may indicate the rate of inter-PLMN request messages or transactions from a particular PLMN that the SEPP 126 is configured to allow, e.g., without performing rate-limiting operations.

[0060] The message throttle rate field may store information to indicate a message throttle rate associated with one or more messages, message types, or transactions. For example, the message throttle rate may indicate the rate at which inter-PLMN request messages or transactions from a particular PLMN are throttled or dropped by the SEPP 126. In this example, the throttle rate may be based on the difference between the current message rate and the allowed message rate, e.g., 50 TPS - 40 TPS = 10 TPS.

[0061] It will also be appreciated that data 500 is for illustrative purposes and that different and / or additional data may be used to indicate default values ​​or other information for particular data portions other than the data shown in Figure 5. Moreover, data 500 may be stored and managed (e.g., in data storage 306) using various data structures and / or computer-readable media.

[0062] 6 is a message flow diagram illustrating an example of received message rate limiting. In some embodiments, the SEPP 126 or the RLM 304 therein may be configured to perform received message rate limiting using an identifier associated with the initiating SEPP obtained or derived from TLS-based certificates exchanged when setting up or configuring the N32-f interface connection. After identifying a sender identifier (e.g., a PLMN ID) associated with the N32-f interface connection, the SEPP 126 or the RLM 304 therein may monitor received inter-PLMN messages (e.g., HTTP / 2 messages) associated with the sender identifier and determine whether the current message rate associated with the sender identifier meets or exceeds the allowed message rate associated with the sender identifier before processing, forwarding, and / or responding to the inter-PLMN message. If the SEPP 126 or the RLM 304 determines that the current message rate meets or exceeds the allowed message rate, the SEPP 126 or the RLM 304 therein may discard one or more of the inter-PLMN messages or perform another rate limiting action. If the SEPP 126 or the RLM 304 therein determines that the current message rate does not meet or exceed the allowed message rate, the SEPP 126 or the RLM 304 therein may allow inter-PLMN messages.

[0063] 6, in step 601, a TLS handshake may occur between SEPP 202 and SEPP 126 over the N32-c interface. For example, SEPP 202 may initiate a TLS handshake with SEPP 126, and during the TLS handshake, SEPP 202 and SEPP 126 may exchange digital certificates (e.g., X.509v3 certificates) that include identifiers.

[0064] In some embodiments, during the TLS handshake, the SEPP 126 or the RLM 304 therein may receive a digital certificate containing an identity associated with the SEPP 202. In such embodiments, the SEPP 126 or the RLM 304 therein may extract, derive, or otherwise determine an identifier from the digital certificate and use the identifier for receive message rate limiting functionality.

[0065] In step 602, after a TLS handshake, a 5GC request (e.g., an HTTP / 2 message) may be sent from SEPP 202 to SEPP 126 over the N32-f interface utilizing TLS protected mode. For example, a producer NF in an external network may generate a 5GC request that is forwarded via SEPP 202 and SEPP 126 to a consumer NF in another network.

[0066] In step 603, for example, after determining not to perform rate limiting, a 5GC response (e.g., an HTTP / 2 message) may be sent from SEPP 126 to SEPP 202 via the N32-f interface. For example, a consumer NF in a home network may generate a 5GC response that is forwarded via SEPP 126 and SEPP 202 to a producer NF in an external network.

[0067] In step 604, a TLS handshake may occur over the N32-c interface between SEPP 200 and SEPP 126. For example, SEPP 200 may initiate a TLS handshake with SEPP 126, during which SEPP 200 and SEPP 126 may exchange digital certificates (e.g., X.509v3 certificates) that include identifiers.

[0068] In some embodiments, during the TLS handshake, the SEPP 126 or the RLM 304 therein may receive a digital certificate containing an identity associated with the SEPP 200. In such embodiments, the SEPP 126 or the RLM 304 therein may extract, derive, or otherwise determine an identifier from the digital certificate and use the identifier for purposes of receiving message rate limiting.

[0069] In step 605, after the TLS handshake, a 5GC request (e.g., an HTTP / 2 message) may be sent from the SEPP 200 to the SEPP 126 via the N32-f interface utilizing the TLS protected mode. For example, a producer NF in an external network may generate a 5GC request that is forwarded via the SEPP 200 and the SEPP 126 to a consumer NF in another network.

[0070] In step 606, for example, after determining not to rate limit, the 5GC request may be discarded. For example, the SEPP 126 or the RLM 304 therein may prevent the consumer NF from receiving the 5GC request forwarded by the SEPP 200.

[0071] It will be appreciated that Figure 6 is for illustrative purposes and that different and / or additional messages and / or actions may be used. It will also be appreciated that the various messages and / or actions described herein may be performed in a different order or sequence.

[0072] 7 illustrates an example process 700 for receiving message rate limiting. In some embodiments, the example process 700 described herein, or portions thereof, may be performed in or by node 300, RLM 304, and / or another module or node.

[0073] Referring to the exemplary process 700, aspects (e.g., processing steps or operations) may be performed in a network node of a first network (e.g., a node 300 including a SEPP 126 or an RLM 304 in a home 5GC network).

[0074] In step 702, an identifier identifying the second network node or the second network may be obtained from a TLS message from a second network node in the second network. For example, SEPP 200 in the "MNO-1" network may initiate a TLS handshake with SEPP 126 in the home network and, during the TLS handshake, may provide a TLS message including a certificate having an identifier associated with SEPP 200.

[0075] In some embodiments, obtaining the identifier from the TLS message may include obtaining the identifier from a certificate (e.g., an X.509v3 certificate) included in the TLS message. For example, the X.509v3 certificate in the TLS message may include a Subject field or Subject Alternative Name field that includes an FQDN associated with the sender's identity. In this example, the FQDN may include or represent a network node identifier or network identifier, e.g., the network identifier may be "5gc.mnc <mnc>.mcc <mcc>It may be stored in a format such as ".3gppnetwork.org" where " <mnc>" and " <mcc>The " fields correspond to the MNC and MCC of the operator's PLMN.

[0076] In step 704, a request message may be received from a second network node or second network. For example, after a TLS handshake, the SEPP 200 in the "MNO-1" network may forward one or more 5GC requests (e.g., from the producer NF) to the SEPP 126 in the home network over the N32-f interface utilizing TLS protected mode.

[0077] In step 706, the identifier may be used to determine that an allowed received message rate associated with the second network node or the second network has been reached or exceeded. For example, the SEPP 126 may use the identifier associated with the initiating SEPP to determine whether the SEPP has reached or exceeded the received message rate. In this example, the SEPP 126 may query a data store or database that includes the current received message rate and the allowed message rate indexed or associated with the relevant identifier (e.g., PLMN identifier and / or SEPP identifier).

[0078] In some embodiments, determining that an allowed received message rate associated with the second network node or second network has been reached or exceeded may include obtaining an allowed received message rate associated with the second network node or second network, obtaining a current received message rate associated with the second network node or second network, and comparing the current received message rate to the allowed received message rate to determine that the current received message rate meets or exceeds the allowed received message rate.

[0079] In some embodiments, obtaining the current received message rate associated with the second network node or second network may include tracking or deriving message rates of multiple SEPPs in the second network to determine the current received message rate associated with the second network. For example, assuming rate limiting is based on a source network identifier, the SEPP 126 may track the received message rate across multiple N32-f interface connections, may combine the received message rates of multiple SEPPs associated with the same network identifier, and may compare the combined received message rate associated with the network identifier to a predetermined allowed received message rate associated with the network identifier.

[0080] Step 708 may involve performing a rate limiting action in response to determining that an allowed receive message rate associated with the second network node or the second network has been reached or exceeded.

[0081] In some embodiments, the rate limiting action may include discarding the request message, generating or modifying a throttle rate to discard some of the messages, or notifying a network operator or management system.

[0082] It will be appreciated that process 700 is for illustrative purposes and that different and / or additional operations may be used, and that the various operations described herein may be performed in a different order or sequence.

[0083] Although some aspects of the subject matter described herein have been described in the context of a 5G network, it will be appreciated that some aspects of the subject matter described herein may be utilized by a variety of other networks. For example, any network that utilizes certificates to identify senders or associated networks may utilize the features, mechanisms, and techniques described herein to, for example, perform more selective inbound message rate limiting based on the originating node or network.

[0084] It should be noted that the node 300, RLM 304, and / or functionality described herein may constitute a special-purpose computing device. Furthermore, the node 300, RLM 304, and / or functionality described herein may advance the art of network security and / or message rate limiting in a SEPP or other network node. For example, limiting the rate of incoming messages based on a network identifier and / or a node identifier may mitigate and / or prevent malicious behavior (e.g., signaling traffic storms) and their negative effects (e.g., network congestion, service disruptions, and / or poor user experience).

[0085] The entire disclosure of each of the following documents is incorporated herein by reference to the extent that it does not contradict this specification and to the extent that it supplements, explains, provides background for, or teaches the methods, techniques, and / or systems employed herein.

[0086] literature 1. IETF RFC 5246; The Transport Layer Security (TLS) Protocol, Version 1.2; August 2008. 2. IETF RFC 3280; Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile, April 2002. 3. 3GPP TS 23.003; 3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; Numbering, addressing and identification (Release 16), V16.4.0 (2020-09). 4. 3GPP TS 29.573; 3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; 5G System; Public Land Mobile Network (PLMN) Interconnection; Stage 3 (Release 16) V16.3.0 (2020-07). 5. 3GPP TS 33.501; 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Security Architecture and Procedures for the 5G System; (Release 16), V16.3.0 (2020-07). 6. 3GPP TS 29.510; 3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; 5G System; Network Function Repository Services; Stage 3 (Release 16), V16.4.0 (2020-07). 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. Moreover, the above description is illustrative only, and not limiting.< / mcc> < / mnc> < / mcc> < / mnc> < / mcc> < / mnc> < / mcc> < / mnc> < / mcc> < / mnc> < / mcc> < / mnc> < / mcc> < / mnc> < / mcc> < / mnc>

Claims

1. 1. A method comprising:

1. A method for receiving message rate limiting, comprising: in a first Security Edge Protection Proxy (SEPP) of a first network, obtaining an identifier identifying the second SEPP or the second network from a Transport Layer Security (TLS) message from a second SEPP of a second network, the TLS message being transmitted during a TLS handshake associated with establishing an N32-F interface connection between the first SEPP and the second SEPP, the method further comprising: receiving a request message from the second SEPP or the second network over the N32-F interface connection; utilizing the identifier to determine that an allowed receive message rate associated with the second SEPP or the second network has been reached or exceeded, wherein determining includes querying a data store containing an allowed receive message rate associated with the second SEPP or the second network and an identifier identifying and associated with the second SEPP or the second network, the method further comprising: responsive to determining that the allowed receive message rate associated with the second SEPP or the second network has been reached or exceeded, performing a rate limiting action.

2. The method of claim 1 , wherein obtaining the identifier from the TLS message comprises obtaining the identifier from a certificate included in the TLS message.

3. 3. The method of claim 2, wherein the certificate comprises an X.509 certificate.

4. 4. The method of claim 3, wherein obtaining the identifier includes extracting a fully qualified domain name (FQDN) of the second SEPP from a subject field or a subject alternative name field of the X.509 certificate.

5. The method of claim 4 , wherein obtaining the identifier includes obtaining a network identifier for identifying the second network from the FQDN.

6. Determining that the allowed receive message rate associated with the second SEPP or the second network has been reached or exceeded includes: obtaining the allowed receive message rate associated with the second SEPP or the second network; obtaining a current receive message rate associated with the second SEPP or the second network; and comparing the current receiving message rate with the allowed receiving message rate to determine that the current receiving message rate meets or exceeds the allowed receiving message rate.

7. 7. The method of claim 6, wherein obtaining the current receiving message rate associated with the second SEPP or the second network comprises tracking or deriving a composite message rate for a plurality of SEPPs in the second network to determine the current receiving rate associated with the second network.

8. The method of any one of claims 1 to 7, wherein the rate limiting action comprises discarding the request message, generating or modifying a throttle rate to discard some of the received messages, or notifying a network operator or a management system.

9. 1. A system for receiving message rate limiting, comprising: a first Security Edge Protection Proxy (SEPP) in a first network, the first SEPP having at least one processor and a memory storing a program; The system, wherein the program causes the at least one processor to execute the method according to any one of claims 1 to 8.

10. A program causing at least one processor to execute the method according to any one of claims 1 to 8.

Images