Device for the dynamic detection and redirection of security gateways in mobile communication networks

Abstract

A device (300) for the dynamic discovery and redirection of security gateways in mobile communication networks, the device comprising: a processing circuit arrangement (310) which is configured as follows: based on a first domain name, to initiate communication between a first security gateway in a first mobile communication network and a second security gateway in a second mobile communication network (210); to receive a redirect response from the second security gateway (220), wherein the redirect response indicates a second domain name to be used for DNS-based discovery of another security gateway in the second mobile communications network; based on the second domain name, to redirect communication from the first security gateway in the first mobile communication network to a third security gateway in the second mobile communication network (230).

Description

Area

[0001] The present disclosure relates to the field of mobile communication networks, in particular to methods and apparatus for dynamic discovery and rerouting of security gateways to manage communication between networks and ensure secure and efficient traffic routing. background

[0002] The evolution of mobile networks is culminating in the deployment of 5G standalone (SA) networks, which represent a significant leap forward from previous technologies. Unlike 5G non-standalone (NSA) networks, which rely on existing 4G LTE infrastructure, 5G SA networks operate with a dedicated 5G core (5GC) and fully exploit the capabilities of 5G technology. This brings improvements such as ultra-low latency, high throughput, and support for massive Internet of Things (IoT) applications. In this context, the Security Edge Protection Proxy (SEPP) plays a crucial role in ensuring secure communication between different mobile network operators, especially in roaming scenarios where multiple public land mobile networks (PLMNs) interact.

[0003] A Security Edge Protection Proxy (SEPP) is a security gateway that can ensure the confidentiality, integrity, and authenticity of signaling messages exchanged between networks in 5G environments. Since 5G networks facilitate communication between different public mobile networks (PLMNs), SEPPs can be deployed at the edge of each network to secure exchanges between the networks. This exchange can occur via the inter-PLMN interface N32, which allows two SEPPs from different PLMNs to interact securely, protecting sensitive data and maintaining network integrity. The SEPP ensures that communication between networks is encrypted to prevent unauthorized access, tampering, or data loss.

[0004] However, the current standards for SEPP operation in 5G, as defined by the 3rd Generation Partnership Project (3GPP), reach their limits when it comes to dynamically routing traffic between multiple SEPPs within the same PLMN. In certain situations, an operator may deploy multiple SEPPs for various reasons, such as load balancing, failover mechanisms, or routing based on specific network capabilities or roaming partner requirements. However, the existing standards do not provide a clear mechanism for dynamically discovering and routing traffic to different SEPPs based on these requirements. The process of selecting a SEPP is currently constrained by Domain Name System (DNS) queries, which always return the same SEPP for a given PLMN, thus limiting the flexibility required for dynamic traffic management.

[0005] This limitation can be particularly problematic in 5G SA networks, where flexibility in routing roaming traffic can be critical for optimizing network performance and ensuring seamless communication between partners. In roaming scenarios where multiple SEPPs may be deployed within a single PLMN, the inability to dynamically select and redirect traffic to different SEPPs can impair the network's ability to adapt to different conditions and traffic demands. This can not only impair load balancing and failover capabilities but also reduce the network's efficiency in handling complex roaming use cases that require targeted routing.

[0006] One challenge that needs to be addressed is the lack of a mechanism that enables dynamic rerouting of SEPP traffic within and between PLMNs. While existing specifications provide some rerouting capabilities via Hypertext Transfer Protocol (HTTP) responses, these are insufficient for scenarios that require dynamic discovery and selection of multiple SEPPs based on specific operational requirements. The current reliance on static DNS responses and limited rerouting options prevents operators from achieving the full flexibility that 5G SA networks are designed to provide and necessitates a more adaptive approach to SEPP discovery and rerouting. Summary

[0007] This need is addressed by methods and devices according to the appended independent claims. Potentially advantageous embodiments are addressed by the dependent claims.

[0008] According to a first aspect of the present disclosure, a method for dynamic discovery and redirection of security gateways in mobile communication networks is proposed. The method comprises, based on a first domain name, initiating communication between a first security gateway in a first mobile communication network and a second security gateway in a second mobile communication network. The method further comprises receiving a redirection response from the second security gateway. The redirection response indicates a second domain name to be used for DNS-based discovery of another security gateway in the second mobile communication network.The method further comprises, based on the second domain name, redirecting communication from the first security gateway in the first mobile communication network to a third security gateway in the second mobile communication network. The proposed method can dynamically discover security gateways in different mobile networks. By initiating communication between the gateways and using redirection responses, the system can enable flexible routing of data traffic. This can ensure optimized communication paths and load balancing, which benefits roaming scenarios in mobile networks.

[0009] According to some embodiments, the redirection response is received via an interface between mobile communication networks. This can enable seamless communication between networks, which is particularly useful in roaming scenarios involving different PLMNs. According to some embodiments, the interface between mobile communication networks is an inter-PLMN interface. A well-known inter-PLMN interface is the N32 interface, which is specifically used in 5G networks for secure communication between SEPPs. The N32 interface ensures that signaling messages exchanged between different mobile operators are protected during roaming scenarios.Another well-known inter-PLMN interface is the S8 interface, which is part of the 4G LTE architecture and enables user-plane data transmission between the Serving Gateway (SGW) in the visited PLMN and the Packet Data Network Gateway (PGW) in the home PLMN while roaming. These interfaces can enable secure and efficient communication between networks operated by different mobile operators. The use of an inter-PLMN interface can enable communication between security gateways of different mobile operators, can improve roaming capabilities, and can ensure that data traffic can be dynamically rerouted between networks. This can support more flexible and resilient network architectures.

[0010] According to some embodiments, initiating communication between the first and second security gateways includes constructing the first domain name for a target security gateway in the second mobile communications network based on a network ID of the second mobile communications network. Constructing the domain name based on the network ID can provide a clear and organized method for identifying and addressing security gateways in the second mobile communications network. This can assist in accurately routing traffic to the correct gateway, improving communication efficiency. For another example, domain names can be generated based on predefined naming conventions that incorporate additional factors such as a gateway location, the type of service being accessed, or specific security requirements.Another approach could involve dynamically constructing domain names based on load balancing or performance metrics of the available security gateways, ensuring optimal traffic routing. Furthermore, domain names could be generated by leveraging hierarchical naming schemes, where different components of the domain reflect different levels of the network architecture, such as the operator name, the geographic region, or service-specific identifiers.

[0011] According to some embodiments, initiating communication between the first and second security gateways includes performing a DNS query using the first domain name to obtain a list of security gateways in the second mobile communication network. Using DNS queries may enable dynamic discovery of available security gateways in the second network. This may enable more efficient and real-time identification of potential gateways for communication, increasing flexibility and resilience in network management. For another example, a centralized registry or database with which security gateways are pre-registered could be used, and the initiating gateway may query this registry directly to obtain relevant information.Alternatively, communication between security gateways could use dynamic service discovery protocols, such as Service Location Protocol (SLP) or Universal Plug and Play (UPnP), to discover available gateways. Additionally, peer-to-peer communication between gateways could enable direct gateway advertisement, where each security gateway periodically broadcasts its availability to others without requiring a DNS lookup.

[0012] According to some embodiments, the method further comprises selecting a security gateway from the list and initiating communication between the first security gateway and the selected second security gateway in the second mobile communication network. The selection of a security gateway from the list may be based on several criteria. A common criterion may be load balancing, where the gateway with the least traffic or optimal capacity is selected to prevent overloading any single gateway. Another criterion could be geographic proximity, which selects the gateway physically closest to the user or the source of the traffic to minimize latency. Security policies could also influence the selection and prioritize gateways that meet certain encryption or privacy standards.Additionally, the selection could be based on network performance metrics such as response times, bandwidth availability, or packet loss rates to ensure the best quality of service. Gateway availability and redundancy could also play a role, with the system favoring gateways that have high uptime or offer failover support in the event of network disruptions. Such criteria can ensure that the most appropriate security gateway is selected to maintain optimal performance and security. Selecting a specific gateway from the list can ensure that traffic can be optimally routed through the most appropriate gateway, potentially based on factors such as load or geographic location. This can contribute to improved network performance and resource management.

[0013] According to some embodiments, initiating communication between the first and third security gateways includes performing a second DNS query using the second domain name to dynamically discover a new target security gateway. By performing a second DNS query, the method can further enhance dynamic discovery by enabling real-time adaptation of the communication path as new gateways are discovered. This flexibility can ensure optimized network routing. For another example, a centralized registry or database with which security gateways are pre-registered could be used, and the initiating gateway can query this registry directly to obtain relevant information. Alternatively, communication between security gateways could utilize dynamic service discovery protocols, such as SLP or UPnP, to discover available gateways.

[0014] According to some embodiments, the method further comprises redirecting the communication to the new destination security gateway based on the results of the second DNS query. The second DNS query may return a second list of destination security gateways in the second mobile communication network, similar to how the first DNS query provided the initial list. This second list would include available security gateways suitable for handling the redirected communication. The list may include multiple gateways that meet specific criteria, such as location, capacity, or service type. Based on this second list, the system may then dynamically select the most suitable destination security gateway for the redirected communication, ensuring that the communication is efficiently routed through the best available gateway in the network.Redirecting communication based on the second DNS query can allow the method to dynamically adjust the communication flow, ensuring that traffic is routed through the most efficient or available security gateway. This can improve both reliability and scalability in the network.

[0015] According to some embodiments, the DNS queries include respective DNS Naming Authority Pointer (NAPTR) queries. Using NAPTR queries as part of the DNS process can enable more complex and flexible service discovery, allowing the network to resolve not only the gateway's address but also the services provided. This can improve the system's ability to adapt to varying network needs. For another example, SRV (service) queries could be used to locate specific services within a network by identifying the hostname and port number of the server providing the desired service. Additionally, A (address) queries or AAAA (IPv6 address) queries could be employed to resolve domain names directly to their corresponding IPv4 or IPv6 addresses, bypassing service discovery.CNAME (Canonical Name) queries could also be used to map an alias name to a canonical domain name, allowing for flexible redirection.

[0016] According to some embodiments, the security gateways comprise respective SEPPs. The use of SEPPs as the security gateways can ensure that communication between different mobile networks is secure, particularly in roaming scenarios. SEPPs can protect the integrity of signaling messages between networks, thereby providing a critical security layer. There are several other types of security gateways used in mobile and communication networks. One example is the security gateway (SEG), which is used in IP-based networks, particularly for securing IPsec tunnels between different network segments or between a user and a network. Another example is the border gateway function (BGF), which can be used in telecommunications networks to manage and secure data traffic at the boundary of a service provider's network.Additionally, in 4G LTE networks, the Diameter Edge Agent (DEA) serves as a security gateway to control and secure Diameter signaling traffic between networks. These gateways, such as SEPPs, are responsible for securing inter-network communications, ensuring privacy, and managing access between different network domains or operators.

[0017] According to some embodiments, the first and second mobile communication networks comprise respective 5G standalone (SA) networks. Applying the proposed method to 5G SA networks can improve the performance and flexibility of next-generation mobile networks, enabling better handling of security and communication in advanced mobile architectures. This can lead to improved network slicing and security. Those skilled in the art, having the benefit of the present disclosure, will appreciate that embodiments of the present disclosure may be applicable not only to 5G SA networks, but also to other communication networks employing security gateways.By leveraging domain names and redirection responses, embodiments of the present disclosure can be adapted to manage secure communication across a variety of network architectures, enabling dynamic discovery and redirection of gateways in networks that require secure and efficient routing of traffic between different operators or regions. This flexibility ensures that embodiments of the present disclosure can optimize communication paths and load balancing in both next-generation and legacy next-generation cellular networks, improving overall network performance and security.

[0018] According to some embodiments, the domain names comprise respective fully qualified domain names (FQDNs). Using FQDNs to address security gateways can ensure clarity and precision in the communication process, allowing networks to easily resolve and communicate with the correct endpoints. This can improve reliability and reduce routing errors. For another example, partially qualified domain names (PQDNs) could be used, where only part of the domain is specified and the missing parts can be derived based on a local network context. Additionally, relative domain names could be used, which can be interpreted relative to a predefined domain, typically within the same network or organization.In specific closed network environments, customer-specific domain naming schemes could also be applied, with domain names structured differently to meet specific security or operational requirements.

[0019] According to some embodiments, the redirection response includes a Hypertext Transfer Protocol (HTTP) redirection response. An HTTP redirection response may enable the method to utilize a widely used protocol for routing communications, ensuring compatibility and ease of integration into existing network infrastructures. This may simplify the process and improve scalability. For another example, SIP (Session Initiation Protocol) redirection responses could be used in networks involving voice, video, or messaging services, allowing the redirection of communication sessions to alternative endpoints. In IP-based networks, DNS-based redirection responses could also be used, with DNS responses redirecting traffic by providing alternative IP addresses or domain names.In addition, application-layer redirection protocols, such as Diameter or GTP (GPRS Tunneling Protocol), could be used in telecommunications networks to handle the redirection of signaling or data traffic between nodes.

[0020] According to another aspect of the present disclosure, an apparatus for dynamically discovering and rerouting security gateways in mobile communication networks is proposed.The apparatus comprises processing circuitry configured to: initiate communication between a first security gateway in a first mobile communication network and a second security gateway in a second mobile communication network based on a first domain name; receive a redirection response from the second security gateway, the redirection response indicating a second domain name to be used for DNS-based discovery of another security gateway in the second mobile communication network; and redirect communication from the first security gateway in the first mobile communication network to a third security gateway in the second mobile communication network based on the second domain name.The proposed device can enable dynamic discovery and rerouting of communication paths between security gateways, enabling seamless communication across cellular networks. This can lead to a flexible and efficient system for managing data traffic between networks, improving both security and performance.

[0021] According to another aspect of the present disclosure, a method for dynamic discovery and rerouting of security gateways in mobile communication networks is proposed. The method comprises, based on a first domain name, initiating communication between a first security gateway in a first mobile communication network and a second security gateway in a second mobile communication network, and sending a rerouting response from the second security gateway to the first security gateway, wherein the rerouting response indicates a second domain name to be used for DNS-based discovery of another security gateway in the second mobile communication network. This method is performed from the perspective of the second security gateway, which actively transmits the rerouting response, enabling the first gateway to rerouting traffic accordingly.This approach can allow the second gateway to influence traffic routing, providing more control over network paths and improving traffic distribution.

[0022] According to another aspect of the present disclosure, an apparatus for dynamically discovering and rerouting security gateways in mobile communication networks is proposed. The apparatus comprises processing circuitry configured to initiate communication between a first security gateway in a first mobile communication network and a second security gateway in a second mobile communication network based on a first domain name, and to send a rerouting response from the second security gateway to the first security gateway, wherein the rerouting response indicates a second domain name. This apparatus may enable the second security gateway to take an active role in the rerouting process, optimizing network resource utilization by directing the first security gateway to the best available communication paths.This can improve load balancing and network management.

[0023] Embodiments of the present disclosure propose methods and apparatus for dynamic discovery and rerouting of security gateways in mobile communication networks, focusing on optimizing inter-network traffic. The proposed concept includes initiating communication between security gateways based on domain names and using DNS queries to dynamically discover available security gateways. The proposed concept supports seamless rerouting to more suitable gateways, enabling flexible routing and load balancing, which are particularly advantageous in roaming scenarios. The use of Security Edge Protection Proxies (SEPPs), DNS NAPTR queries, and FQDNs for addressing can ensure security and efficiency.Redirection responses, HTTP protocols, and inter-PLMN interfaces can enable the proposed concept to dynamically adapt communication paths, improving performance and resilience in 5G standalone networks. Short description of the characters

[0024] Some examples of devices and / or methods are described below solely by way of example and with reference to the accompanying figures, in which: Fig. 1 illustrates a network architecture for mobile communication networks according to aspects of the present disclosure; Fig. 2 shows a flowchart for a method for dynamic discovery and redirection of security gateways according to one embodiment; Fig. 3 shows a block diagram of an apparatus for dynamic discovery and redirection of security gateways according to an embodiment; and Fig. 4 shows a sequence diagram of a dynamic discovery and redirection process for security gateways according to example embodiments. Detailed description

[0025] Some examples will now be described in more detail with reference to the accompanying figures. However, other possible examples are not limited to the features of these detailed embodiments. Other examples may include modifications of the features, as well as equivalents and alternatives to the features. Furthermore, the terminology used herein to describe specific examples is not intended to be limiting of other possible examples.

[0026] Throughout the description of the figures, identical or similar reference numerals refer to identical or similar elements and / or features, which may be implemented identically or in a modified form while providing the same or a similar function. Furthermore, in the figures, the thicknesses of lines, layers, and / or regions may be exaggerated for clarity.

[0027] When two elements A and B are combined using "or," this is to be understood as disclosing all possible combinations, i.e., only A, only B, and A and B, unless explicitly defined otherwise in the individual case. Alternative wording for the same combinations may be "at least one of A and B" or "A and / or B." This applies accordingly to combinations of more than two elements.

[0028] If a singular form is used, such as "a," "an," and "the," and the use of only a single element is neither explicitly nor implicitly defined as mandatory, further examples may also use multiple elements to implement the same function. If a function is subsequently described as being implemented using multiple elements, further examples may implement the same function using a single element or a single processing entity.It is further understood that the terms "comprises", "comprising", "has" and / or "having" when used describe the presence of the specified features, integers, steps, operations, processes, elements, components and / or a group thereof, but do not preclude the presence or addition of one or more other features, integers, steps, operations, processes, elements, components and / or a group thereof.

[0029] A PLMN operator is an organization that deploys and operates mobile networks. The technology for these networks may be defined in 3GPP (3rd Generation Partnership Project) specifications, and operational aspects may be defined by the GSMA (GSM Association). This applies to 5G networks and previous generations.

[0030] The 5G specifications define that for inter-PLMN communication, i.e., roaming, a non-transparent proxy, the Security Edge Protection Proxy (SEPP), is used. The SEPP can establish communication between two PLMNs and protect the network edge of the PLMN. Inter-PLMN communication refers to communication between two different PLMNs, which typically occurs in roaming scenarios when a mobile user connects to a network outside of their home operator's network. A SEPP can be used to secure and manage this communication. A SEPP can serve as a security gateway in 5G networks, specifically designed to secure communication between different PLMNs during inter-network interactions, such as roaming.Acting as a secure intermediary, the SEPP can ensure that all signaling traffic exchanged between two networks remains protected and confidential. It can prevent the disclosure of sensitive network details by enforcing encryption and integrity protection, effectively securing the network perimeter from potential threats. As a gateway, the SEPP can enable secure and efficient message exchange while preventing unauthorized access or tampering with network resources. Its role is necessary to maintain the security and integrity of 5G communications, especially in scenarios where multiple mobile operators need to collaborate without compromising their internal network structures.

[0031] The inter-PLMN interface between two SEPPs is called N32. The N32 interface can enable SEPPs to securely exchange signaling messages between networks, ensuring that communications are protected during roaming or other inter-network activities. It can enable SEPPs to establish and maintain secure connections, applying encryption and other security mechanisms to ensure the integrity and confidentiality of data transmitted between the two PLMNs. Using N32, SEPPs can securely manage and route data traffic across different mobile networks without exposing sensitive information to external parties.

[0032] For roaming, each PLMN can be identified by a globally unique PLMN identifier (ID). A global registry for these IDs can exist. The PLMN ID can be used to identify and distinguish networks, especially when users connect to foreign networks while roaming. This unique identification can help ensure that devices can correctly authenticate and establish connections to the appropriate network. Additionally, there can be a global registry that maintains and manages these PLMN IDs, ensuring their uniqueness and avoiding conflicts between network operators across different countries and regions. This registry can enable the smooth operation of international mobile communications.

[0033] For a SEPP to establish communication with another SEPP, it can construct a well-known fully qualified domain name (FQDN). The well-known FQDN includes the PLMN ID and the domain "3gppnetwork.org." Once the PLMN ID is known, the well-known FQDN can be constructed. This describes how a SEPP can communicate with another SEPP across different cellular networks. To initiate this communication, the SEPP constructs the well-known FQDN, which is essentially a structured web address used to identify the target SEPP. This FQDN is generated by combining the unique identifier of the target network, known as the PLMN ID, with the standard domain name "3gppnetwork.org," universally used for 5G networks. This approach can ensure that SEPPs can correctly identify and locate each other across different PLMNs.

[0034] To discover a SEPP, the known FQDN can be used in a DNS NAPTR (Naming Authority Pointer) query to obtain a list of purposes. A NAPTR query is a type of DNS query that can resolve domain names into services or specific functions. By using this query, the SEPP can retrieve a list of purposes or available services offered by the target SEPP. This can enable the initiating SEPP to understand the capabilities of the other SEPP and select the correct one for communication, ensuring proper handling of signaling and security between networks.

[0035] From the list, the initiating SEPP can select the intended purpose and perform an SRV (service) request on the selected entry. This means that after receiving a list of purposes or services from the DNS NAPTR query, the initiating SEPP can select the appropriate one based on its intended purpose for communication. Once the correct service or function is identified, the SEPP performs an SRV request on this selected entry. An SRV request is a type of DNS query used to locate the specific server or service that can handle the communication. This can allow the initiating SEPP to find the exact SEPP instance that can meet its communication needs, ensuring a precise and efficient connection between the networks.

[0036] The DNS server can respond with a prioritized and weighted list of SEPPs' FQDNs. The initiating SEPP can select one of them, send a DNS query to obtain the IP address (A or AAAA), and finally communicate with the IP address corresponding to the selected target SEPP. This means that after the initiating SEPP performs an SRV request, the DNS server can respond with a list of FQDNs representing available SEPPs, along with priority and weight values. These values ​​can help the initiating SEPP determine the most suitable SEPP to communicate with based on factors such as load balancing or proximity. Once a SEPP is selected from this list, the initiating SEPP can send a DNS query to resolve the FQDN to an IP address, which can be either an IPv4 (A) or IPv6 (AAAA) address.The initiating SEPP can then use this IP address to establish direct communication with the selected SEPP in the target network.

[0037] This approach can enable a SEPP to discover the IP address of the roaming partner's peer SEPP, knowing only the PLMN ID. No prior knowledge or configuration is required.

[0038] The 3GPP specifications define an HTTP redirect for a SEPP to inform an initiating entity that a different SEPP should be used. This redirect response includes the FQDN of the intended new destination SEPP. This FQDN can be resolved to an IP address via a DNS A or AAAA query. This means that if an initiating SEPP attempts to communicate with a destination SEPP that is not best suited for the task, the destination SEPP can send an HTTP redirect response to inform the initiating SEPP to use a different SEPP instead. This redirect response can include the FQDN of the new destination SEPP. The initiating SEPP can then resolve this FQDN to an IP address through a DNS query, using either an A record for IPv4 or an AAAA record for IPv6.This process can enable the initiating SEPP to redirect its communication to the appropriate SEPP, ensuring optimized routing and network efficiency.

[0039] One limitation is that DNS always responds with the same answers. If a PLMN wants to route specific roaming partners to dedicated SEPPs, current standards do not allow this. When a DNS query is performed, it can always provide the same set of answers for a given request, without considering specific conditions or preferences. This means that if a mobile network operator (PLMN) wants to route traffic from specific roaming partners to specific, dedicated SEPPs, existing standards do not support this level of customization. The operator cannot control which SEPP a roaming partner connects to, as DNS responses lack the flexibility to route different partners to different SEPPs based on their identity or other factors. This limits the ability to optimize routing and load balancing in roaming scenarios.

[0040] Currently, a SEPP can redirect an HTTP request over a non-N32 interface to another SEPP by sending a 307 Temporary Redirect or 308 Permanent Redirect response to the HTTP client, which includes a RedirectResponse data structure. The Location header is ignored and contents of RedirectResponse (targetSepp Information Element (IE)) are used. In such cases, the SEPP can send an HTTP redirect response, specifically a 307 Temporary Redirect or a 308 Permanent Redirect, to the HTTP client. Instead of using the standard HTTP Location header for redirection, which is typically used in other types of web redirections, the SEPP includes a specialized data structure called a RedirectResponse. This structure contains a specific information element known as the targetSepp Information Element (IE), which directs the client to the new SEPP.The Location header is ignored in this process and only the information within the RedirectResponse is used to handle the redirection, ensuring that traffic is correctly routed to the intended SEPP.

[0041] This approach can be used when an element, a so-called Network Function (NF) within the PLMN, wants to communicate with another PLMN. The NF sends its messages to the SEPP of its own PLMN for delivery. This SEPP can instruct the NF to use a different SEPP for sending instead. This is intra-PLMN communication and therefore irrelevant for roaming.

[0042] In contrast, an N32 HTTP request can be redirected to another SEPP service instance located within the same PLMN. An example scenario is shown in Fig. 1 illustrates.

[0043] With reference to Fig. 1 illustrates a network architecture 100 for mobile communications networks. The illustrated architecture 100 includes multiple PLMNs 110A, 110B, 110C, specifically PLMN A, PLMN B, and PLMN C. Each PLMN may be a 5G standalone (SA) network, and each may include at least one SEPP 112. The SEPPs 112, which may be implemented as processing circuitry, serve as security gateways for inter-PLMN communications.

[0044] In the illustrated example, PLMN A comprises two SEPPs, SEPP 112A1 and SEPP 112A2. SEPP 112A1 is connected to PLMN B via an interface between mobile communication networks 120, 130, such as an inter-PLMN interface represented by an N32 connection. Similarly, SEPP 112A2 is connected to PLMN C via another inter-PLMN (N32) interface 120, 130. PLMN B and PLMN C each have their own SEPPs, SEPP 112B and SEPP 112C, for connecting to PLMN A.

[0045] In PLMN A, various network functions (NF) 116A, such as the NRF (Network Repository Function) 114A and NEF (Network Exposure Function) 118A, are shown as part of the 5G service-based architecture (SBA). These network functions can interact with SEPPs 112A1, 112A2 via an SBI (Service-Based Interface) connection 111A, which can handle internal communication within PLMN A. The SEPPs 112A1, 112A2, in turn, can establish secure external communication with SEPPs in PLMN B and PLMN C through N32 connections 120, 130. The N32 interface is divided into two parts: the N32-c connection 120 and the N32-f connection 130.The N32-c connection 120 can be used for control plane signaling between SEPPs, including security negotiations and parameter exchange, while the N32-f connection 130 can handle the forwarding of protected application layer messages between the networks. The cloud at the center represents a broader internet or IP exchange network through which the SEPPs can communicate across different PLMNs, ensuring that signaling and data between networks are secure, especially in roaming scenarios. It also includes a central domain represented by the domain "mnc001.mcc001.3gppnetwork.org." This domain can be used for DNS-based SEPP discovery, enabling inter-PLMN communication.

[0046] In some aspects, the multiple SEPPs within PLMN A, particularly SEPP 112A1 and SEPP 112A2, may serve different purposes. For example, a PLMN operator may choose to connect through one SEPP to certain roaming partners while using a different SEPP for others. This approach allows the operator to direct specific roaming partners to specific SEPPs based on their preferences. For example, SEPP 112A1 may be used to connect to PLMN B, while SEPP 112A2 may be used to connect to PLMN C.

[0047] In some cases, deploying multiple SEPPs within a single PLMN, such as PLMN A, can enable load balancing. Load balancing can be achieved by distributing network traffic across multiple SEPPs to ensure that no single SEPP is overwhelmed with traffic. This can improve network efficiency and reliability by preventing any single point of failure and ensuring that network resources are used optimally.

[0048] In some aspects, the multiple SEPPs 112A1, 112A2 within PLMN A may also enable failover mechanisms. A failover mechanism is a backup mode of operation in which the functions of a system component, such as a SEPP, are assumed by secondary system components if the primary component becomes unavailable. In the context of the present disclosure, if one SEPP within PLMN A becomes unavailable or fails, the other SEPP may assume its functions, ensuring uninterrupted service.

[0049] Furthermore, the multiple SEPPs 112A1, 112A2 within PLMN A can be used to implement traffic prioritization and routing based on specific network functions (NFs). In some cases, certain types of traffic or specific NFs can be prioritized and routed through a specific SEPP. For example, traffic related to emergency services or critical infrastructure can be prioritized and routed through a specific SEPP to ensure reliable and timely communication.

[0050] For example, SEPP 112A1 in PLMN A may receive an N32 HTTP request from another SEPP, such as SEPP 112B located in PLMN B, and redirect the request to another SEPP 112A2 in PLMN A. SEPP 112A1 may send a 307 Temporary Redirect response to SEPP 112B, which may include a RedirectResponse data structure. The Location header is used, and the contents of RedirectResponse(targetSepp IE) are ignored.

[0051] The HTTP Location header is defined in the HTTP RFC. The RFC states that the Location header consists of a URI containing an FQDN. This FQDN can be interpreted as the host FQDN. The RFC leaves no room for any other interpretation.

[0052] Informing the initiating SEPP 112B about a new target SEPP 112A2 using this approach only allows PLMN A to respond with a dedicated SEPP FQDN. This reduces flexibility because it is not possible for the new target SEPP 112A2 to re-perform DNS-based SEPP discovery.

[0053] The present disclosure provides a method, apparatus, and system for dynamically discovering and rerouting security gateways in mobile communication networks. This may be particularly relevant in the context of 5G networks, where SEPPs play a role in securing the edges of mobile networks and enabling secure communication between networks. The disclosed methods and apparatus address the need for more flexible and dynamic routing of traffic to specific SEPPs based on various criteria or preferences, a capability currently lacking in existing standards. This is particularly advantageous in scenarios where a PLMN operator may want to direct certain roaming partners to dedicated SEPPs while using others for others.The disclosed methods and devices can also overcome the limitations of the static nature of DNS responses in the current setup, enabling a new round of DNS-based SEPP discovery upon redirection, thereby enabling advanced load balancing or failover strategies. Furthermore, the disclosed methods and devices can eliminate the need for prior configuration or awareness by the initiating network, thereby reducing complexity in network management and improving agility in responding to changing network conditions or security requirements.

[0054] With reference to Fig. 2 illustrates a flowchart for a method 200 for dynamic discovery and rerouting of security gateways in mobile communication networks.

[0055] The method 200 includes initiating 210 a communication between a first security gateway in a first mobile communication network and a second security gateway in a second mobile communication network based on a first domain name.

[0056] In some aspects, the first security gateway may be a SEPP in a PLMN, such as PLMN B ( Fig. 1). The second security gateway may be another SEPP in a different PLMN, e.g., PLMN A. The first domain name may be constructed based on a network ID of the second mobile communications network (e.g., PLMN A). The network ID may be a globally unique PLMN ID, and the first domain name may be an FQDN comprising the PLMN ID and a domain, such as "3gppnet-work.org."

[0057] In some cases, step 210 of initiating communication between the first and second security gateways may include performing a DNS query using the first domain name to obtain a list of security gateways in the second mobile communication network (e.g., PLMN A). The DNS query may be a DNS NAPTR query. The first security gateway (e.g., in PLMN B) may select a security gateway from the list and initiate communication with the selected second security gateway in the second mobile communication network (e.g., PLMN A), as described above.

[0058] The next step 220 in the method 200 includes receiving a redirection response from the second security gateway (e.g., in PLMN A) indicating a second domain name to be used for DNS-based discovery of another security gateway in the second mobile communication network. The redirection response may be received via an interface between mobile communication networks, such as an interface between PLMN (N32) 120, 130. The redirection response may be an HTTP redirection response. In some aspects, the redirection response may inform the first security gateway (e.g., in PLMN B) that another security gateway (e.g., in PLMN A) should be used for communication. The redirection response may include a new information element (IE) containing a data structure representing an FQDN. This FQDN may be interpreted to be used for DNS NAPTR queries.

[0059] Finally, based on the second domain name from the redirection response, the method 200 redirects 230 a communication from the first security gateway (e.g., in PLMN B) to a third security gateway in the second mobile communication network (e.g., in PLMN A). Redirecting 230 the communication may include performing a second DNS query using the second domain name to dynamically discover a new destination security gateway in the second mobile communication network (e.g., in PLMN A). The second DNS query may also be a DNS NAPTR query. The first security gateway (e.g., in PLMN B) may then redirect the communication to the new destination security gateway (e.g., in PLMN A) based on the results of the second DNS query.

[0060] In some cases, the third security gateway (e.g., in PLMN A) can be a different SEPP (e.g., SEPP 112A2) in the same PLMN as the second security gateway (e.g., SEPP 112A1). For example, if the second security gateway is located in PLMN A, the third security gateway can also be located in PLMN A. This allows a PLMN to direct specific roaming partners to dedicated SEPPs, improving flexibility in network management and traffic routing.

[0061] With reference to Fig. 3 schematically illustrates an apparatus 300 for implementing the method 200 for dynamic discovery and rerouting of security gateways in mobile communication networks. The apparatus 300 includes processing circuitry 310 configured to perform various operations.

[0062] In some aspects, processing circuitry 310 is configured to initiate communication between a first security gateway in a first mobile communication network (e.g., PLMN B) and a second security gateway in a second mobile communication network (e.g., PLMN A) based on a first domain name. The first security gateway and the second security gateway may be SEPPs in respective PLMNs. The first domain name may be an FQDN constructed based on a network ID of the second mobile communication network (e.g., PLMN A). The network ID may be a globally unique PLMN ID, and the first domain name may include the PLMN ID and a domain, such as "3gppnetwork.org."

[0063] In one implementation from the perspective of the initiating (first) security gateway, the processing circuitry 310 is further configured to receive a redirect response from the second security gateway (e.g., in PLMN A). In another implementation from the perspective of the rejecting (second) security gateway, the processing circuitry 310 is configured to send the redirect response to the first security gateway (e.g., in PLMN B). The redirect response may indicate a second domain name to be used for DNS-based discovery of another security gateway in the second mobile communication network. The redirect response may be received via an interface between mobile communication networks, such as an interface between PLMNs 120, 130. The redirect response may be an HTTP redirect response that the first security gateway (e.g.,in PLMN B) that a different security gateway (e.g., in PLMN A) should be used for communication. The redirect response may include a new IE containing a data structure representing an FQDN. This FQDN can be interpreted to be used for DNS NAPTR queries.

[0064] In some aspects, processing circuitry 310 is configured to redirect communication from the first security gateway in the first mobile communication network (e.g., PLMN B) to a third security gateway in the second mobile communication network (e.g., PLMN A) based on the second domain name. Redirecting communication may include performing a second DNS query using the second domain name to dynamically discover a new destination security gateway. The second DNS query may also be a DNS NAPTR query. The first security gateway (e.g., in PLMN B) may then redirect communication to the new destination security gateway (e.g., in PLMN A) based on the results of the second DNS query.

[0065] In some cases, the third security gateway (e.g., in PLMN B) can be a different SEPP in the same PLMN as the second security gateway. For example, if the second security gateway is located in PLMN A, the third security gateway can also be located in PLMN A. This allows a PLMN to direct specific roaming partners to dedicated SEPPs, improving flexibility in network management and traffic routing.

[0066] Those skilled in the art, having the benefit of the present disclosure, will recognize that apparatus 300 may be implemented within a SEPP to support the dynamic discovery and redirection of security gateways in mobile communication networks. Apparatus 300 includes processing circuitry 310 that initiates communication between security gateways based on domain names constructed from network identifiers, such as PLMN IDs. Processing circuitry 310 is also capable of handling redirection responses from SEPPs, interpreting these responses to dynamically redirect communication to more appropriate security gateways. In terms of hardware and software, processing circuitry 310 may be used to perform DNS NAPTR queries and handle HTTP redirection responses.This circuitry may be a combination of a processor and software modules that manage DNS queries, FQDN resolution, and communication routing. Device 300 can ensure that if a SEPP is not the optimal destination for communication, it can dynamically redirect traffic to another SEPP in the same network, thereby improving network flexibility and efficiency. This redirection mechanism can be implemented using standard network hardware combined with software that adheres to 3GPP protocols, such as those defined for the N32 interface.

[0067] With reference to Fig.Figure 4 illustrates a more detailed sequence diagram 400 of a dynamic discovery and redirection process for security gateways 112 in mobile communication networks. The illustrated process includes four main entities: a first security gateway 112B, a DNS server 410, a second security gateway 112A1, and a third security gateway 112A2.

[0068] The sequence begins with the first security gateway 112B (e.g., in PLMN B) constructing the first domain name for a target security gateway in the second mobile communication network (e.g., PLMN A) based on the network ID of the second mobile communication network (step 211). This construction of the first domain name may be based on a globally unique PLMN ID, and the first domain name may be a well-known FQDN comprising the PLMN ID and a domain, such as "3gppnetwork.org." The well-known FQDN is the initial domain name constructed based on the information of the target mobile network (e.g., PLMN A). It is called "well-known" because it follows a standardized naming convention that allows any network to locate security gateways (SEPPs) in another network. This FQDN is generated using the PLMN ID of the second mobile communication network (e.g., PLMN A).The PLMN ID may include the Mobile Country Code (MCC) and the Mobile Network Code (MNC), which uniquely identifies the network.

[0069] Next, the first security gateway 112B performs a DNS query using the first domain name (known FQDN) to obtain a list of security gateways in the second mobile communication network (step 212). The DNS query may be a NAPTR query, which is a specific type of DNS query used for service discovery. The known FQDN may be used in the first DNS query to discover SEPPs in the target network (e.g., PLMN A). This domain name serves as a unique identifier for the target network and allows the security gateway to perform a DNS lookup. The NAPTR query resolves the known FQDN into a list of potential SEPPs within the target network. These SEPPs are security gateways responsible for managing secure communication between different PLMNs.The response to this query can provide a prioritized list of SEPPs, including their capabilities and services, that the initiating SEPP (112B) can use to establish secure communication with the most appropriate SEPP in PLMN A. By using a NAPTR query, the first security gateway is able to dynamically discover the available SEPPs in the target network, enabling real-time decisions about routing traffic through the most optimal gateway.

[0070] The DNS server 410 responds with a list of destination security gateways (step 213). When the DNS server 410 receives the DNS query from the first security gateway 112B, it may process the request by looking up records associated with the known FQDN provided in the query. The DNS server 410 may be responsible for maintaining a database of domain names and their corresponding network services, including the security gateways or SEPPs available in the destination network. After resolving the query, the DNS server 410 responds by returning a list of destination security gateways, e.g., in the form of FQDNs. Each FQDN may represent a SEPP within the second mobile communications network (e.g., PLMN A). This response may also include additional details, such as:Priority and weight values ​​for each SEPP, allowing the initiating security gateway to select the most appropriate SEPP for the communication. If the query is a NAPTR query, the DNS server 410 may return service records that not only provide the FQDNs of the available SEPPs, but also indicate the specific functions or services each SEPP is configured to handle. This may allow the initiating security gateway 112B to resolve the appropriate SEPP for the type of communication or traffic being handled.

[0071] Once the list is received, the first security gateway 112B selects a security gateway from the list (step 214) and initiates communication with the selected second security gateway 112A1 in the second mobile communication network (step 215). Once the first security gateway 112B receives the list of SEPPs from the DNS server 410, it may proceed to select one of the SEPPs based on several potential criteria, such as priority, load, geographic location, or service type. The list returned by the DNS server 410 may include additional metadata, such as priority and weight, to help the gateway determine the most suitable SEPP for communication.

[0072] After selecting the appropriate SEPP 112A1 in the second network, the first security gateway 112B initiates communication. To do so, the FQDN of the selected SEPP from the list may need to be further resolved to an IP address using a different DNS query, such as an A or AAAA query for IPv4 or IPv6 addresses, respectively. Once the IP address is obtained, the first security gateway 112B may establish a secure communication link to the selected SEPP 112A1 in the second mobile communication network. This communication initiation 215 may include exchanging signaling messages, possibly over an encrypted channel, such as TLS, since SEPPs are designed to secure the edges of networks.Data traffic between the two SEPPs can now be secured, ensuring that sensitive data remains protected while traveling between the two mobile networks, typically in scenarios such as roaming or inter-network communication. The SEPP 112A1 in the second mobile network can then handle the routing and security of the data traffic within its own network.

[0073] However, the second security gateway 112A1 responds with a redirect response comprising a second domain name to be used for DNS-based discovery of another security gateway in the second mobile communication network (step 220). This redirect response may be an HTTP redirect response informing the first security gateway 112B that another security gateway should be used for communication. The redirect response may include an IE containing a data structure representing an FQDN. This FQDN may be interpreted to be used for DNS NAPTR queries. When the first security gateway 112B initiates communication with the selected second security gateway 112A1 in the destination network (PLMN A), the second gateway 112A1 may determine that it is not the most suitable SEPP to handle the traffic.In response, the second security gateway 112A1 issues an HTTP redirection response to inform the initiating SEPP 112B that communication should be directed to another security gateway within the same network. The first security gateway 112B can interpret the second FQDN from the HTTP redirection response and use it to initiate a new DNS discovery process.

[0074] SEPP-A1 in PLMN-A receives an HTTP request (N32 interface) from SEPP-B in PLMN-B. However, SEPP-A1 decides that SEPP-B should communicate with another SEPP within PLMN-A, so it redirects the request. To redirect SEPP-B to the correct SEPP within PLMN-A, SEPP-A1 sends an HTTP 307 Temporary Redirect response. This response may include a data structure called an Ext-RedirectResponse, which may contain attributes. A first attribute (the "Cause" attribute) may specify a reason or trigger for the redirection. It may provide the receiving entity (in this case, SEPP-B) with information about why the redirection is occurring. In this context, it may signal that the redirection involves a discovery process that instructs SEPP-B to look for another service or entity within the network.A second attribute (the "seppFqdnForDiscovery" attribute) can contain an FQDN that serves as a reference for the receiving entity (SEPP-B) to initiate a new discovery process. It can indicate a target or service that the receiving entity should locate, typically by performing a DNS query. The FQDN can act as a dynamic address that the system can use to find the most suitable resource without preconfiguring specific targets. • Cause attribute: set to a value such as SEPP_REDIRECTION_WITH_DISCOVERY, indicating that the redirection should include a discovery procedure. • Attribute “seppFqdnForDiscovery”: contains the Fully Qualified Domain Name (FQDN) that SEPP-B will use to discover the new SEPP via DNS-based discovery.

[0075] SEPP-B can ignore the standard HTTP Location header in the response. Instead, it can use the FQDN provided in the "seppFqdnForDiscovery" attribute. Using this FQDN, SEPP-B can perform a DNS NAPTR query to automatically discover the appropriate SEPP within PLMN-A.

[0076] Thus, upon receiving the redirection response from the second gateway 112A1, the first security gateway 112B performs a second DNS query using the second domain name (second FQDN) to dynamically discover a new target security gateway (step 232). The second DNS query may be a second NAPTR query. The second FQDN may be used in the second DNS query to discover new SEPPs in the target network (e.g., PLMN A).

[0077] The DNS server 410 responds with a list of new target security gateways (step 233). The first security gateway 112B then selects a new security gateway from this updated list (step 234) based on several potential criteria, such as priority, load, geographic location, or service type. In this case, the new security gateway is the third security gateway 112A2.

[0078] After selecting the new target SEPP 112A2 in the second network, the first security gateway 112B initiates redirection communication with the newly selected third security gateway 112A2 (step 235). To do so, the FQDN of the selected new target SEPP from the list may need to be further resolved to an IP address using a different DNS query, such as an A or AAAA query for IPv4 or IPv6 addresses, respectively. Once the IP address is obtained, the first security gateway 112B may establish a secure communication link to the selected new target SEPP 112A2 in the second mobile communication network. This communication initiation 235 may include exchanging signaling messages, possibly over an encrypted channel, such as TLS, since SEPPs are designed to secure the edges of networks.The data traffic between the two SEPPs 112B, 112A2 is now secured, ensuring that sensitive data remains protected while traveling between the two mobile networks, typically in scenarios such as roaming or inter-network communication. The SEPP 112A2 in the second mobile network can then handle the routing and security of the data traffic within its own network.

[0079] Embodiments of the present disclosure can treat each SEPP-to-SEPP communication initiation equally, regardless of whether there is a redirection or not. When one starts resolving the known FQDN, one obtains the list of SEPP's FQDNs. One speaks to a SEPP, and it sends a redirection. The new target FQDN from the redirection can then go through the same discovery procedure again, i.e., perform a NAPTR resolution on the FQDN received in the redirection. This way, the initiating SEPP can learn the list of possible new target SEPPs. In the case of redirection within the same PLMN, i.e., a redirection is performed to another SEPP whose FQDN is already in the list received via DNS discovery, a new NAPTR request would be of little value.However, there is a use case where the FQDN received in the redirection would be a different generic FQDN, and the list of SEPPs received from a NAPTR request based on this new generic FQDN would be different. It may be possible for a PLMN to have more than one SEPP for the same PLMN ID(s). It may not be necessary to pre-inform a roaming partner about the intended destination SEPP—only dynamic discovery may be intended.

[0080] Embodiments of the present disclosure define a new SEPP HTTP redirection response mechanism by introducing a new API attribute to ensure that the RedirectionResponse data type results in an FQDN that can be used for a new SEPP discovery procedure and a new NAPTR query, which will help obtain the list of possible new target SEPPs. This new mechanism can ensure dynamic discovery of the target SEPP and avoid informing roaming partners about the intended responding SEPPs in advance. One proposed solution is to use an HTTP redirection and define a new IE for the redirection response message that contains a data structure representing an FQDN. This FQDN can be interpreted to be used for DNS NAPTR queries (as opposed to the HTTP Location header, which is defined as the host FQDN).

[0081] The proposed solution can use an HTTP redirect for the N32 interface, as specified in TS 29500 for the non-N32 interface, where the HTTP Location header can be ignored. A new IE can be defined (different from the one already defined) that can be used instead of the Location header. The new IE can contain a data structure representing an FQDN. This FQDN can be used by the SEPP receiving the redirect response to issue a DNS NAPTR query for SEPP discovery.

[0082] The present disclosure provides a method, apparatus, and system for dynamically discovering and rerouting security gateways in mobile communication networks. This may be particularly relevant in the context of 5G networks, where Security Edge Protection Proxies (SEPPs) play a crucial role in securing the edges of mobile networks and enabling secure communication between networks. The disclosed methods and apparatus address the need for more flexible and dynamic routing of traffic to specific SEPPs based on various criteria or preferences, a capability currently lacking in existing standards. This may be particularly advantageous in scenarios where a Public Land Mobile Network (PLMN) operator may want to direct certain roaming partners to dedicated SEPPs while using others for others.The disclosed methods and devices can also overcome the limitations of the static nature of DNS responses in the current setup, enabling a new round of DNS-based SEPP discovery upon redirection, thereby enabling advanced load balancing or failover strategies. Furthermore, the disclosed methods and devices eliminate the need for prior configuration or knowledge by the initiating network, thereby reducing complexity in network management and improving agility in responding to changing network conditions or security requirements.

[0083] The aspects and features described in connection with a particular one of the previous examples may also be combined with one or more of the further examples to replace an identical or similar feature of that further example or to additionally introduce the features into the further example.

[0084] Examples may further be or relate to a (computer) program comprising program code for carrying out one or more of the foregoing methods, when the program is executed on a computer, a processor, or other programmable hardware component. Steps, operations, or processes of various of the methods described above may therefore also be carried out by programmed computers, processors, or other programmable hardware components. Examples may also cover program storage devices, e.g., digital data storage media, that are machine-, processor-, or computer-readable and / or encode and / or include machine-executable, processor-executable, or computer-executable programs and instructions. The program storage devices may, for example,digital storage devices, magnetic storage media, such as magnetic disks and magnetic tapes, hard disk drives, or optically readable digital data storage media. Further examples may also cover computers, processors, control units, (field-)programmable logic arrays ((F)PLAs; (field) programmable logic arrays)), (field) programmable gate arrays ((F)PGAs; (field) programmable gate arrays)), graphics processor units (GPUs), application-specific integrated circuits (ASICs), integrated circuits (ICs), or system-on-a-chip (SoCs) systems programmed to carry out the steps of the methods described above.

[0085] It is further understood that the disclosure of multiple steps, processes, operations, or functions disclosed in the description or claims should not be construed as necessarily being in the described order, unless explicitly stated in the individual case or required for technical reasons. Therefore, the foregoing description does not limit the performance of multiple steps or functions to any particular order. Furthermore, in further examples, a single step, function, process, or operation may include and / or be broken down into multiple sub-steps, functions, processes, or operations.

[0086] If some aspects have been described in the context of a device or system, these aspects are also to be understood as a description of the corresponding method. For example, a block, device, or functional aspect of the device or system may correspond to a feature, such as a method step, of the corresponding method. Accordingly, aspects described in the context of a method are also to be understood as a description of a corresponding block, element, property, or functional feature of a corresponding device or system.

[0087] The following claims are hereby incorporated into the detailed description, whereby each claim may stand on its own as a separate example. It should also be noted that although a dependent claim in the claims refers to a particular combination with one or more other claims, other examples may also include a combination of the dependent claim with the subject matter of any other dependent or independent claim. Such combinations are hereby explicitly proposed unless it is stated in the individual case that a particular combination is not intended. Furthermore, features of a claim for any other independent claim are also intended to be encompassed, even if that claim is not directly defined as dependent on that other independent claim.

Claims

[1] An apparatus (300) for dynamically discovering and rerouting security gateways in mobile communication networks, the apparatus comprising: a processing circuit arrangement (310) which is designed: based on a first domain name, to initiate (210) a communication between a first security gateway in a first mobile communication network and a second security gateway in a second mobile communication network; receive (220) a redirection response from the second security gateway, the redirection response indicating a second domain name to be used for DNS-based discovery of another security gateway in the second mobile communication network; based on the second domain name, redirect the communication from the first security gateway in the first mobile communication network to a third security gateway in the second mobile communication network (230). [2] The device (300) according to claim 1, wherein the interface (120; 130) between mobile communication networks is an inter-PLMN interface. [3] The device (300) according to any one of the preceding claims, wherein the processing circuitry (310) is configured to initiate (210) communication between the first and second security gateways (112B; 112A1) based on constructing (211) the first domain name for a target security gateway in the second mobile communication network based on a network ID of the second mobile communication network. [4] The device (300) according to any one of the preceding claims, wherein the processing circuitry (310) is configured to initiate (210) communication between the first and second security gateways based on performing (212) a DNS query using the first domain name to obtain a list of security gateways in the second mobile communication network. [5] The device (300) according to claim 4, wherein the processing circuitry (310) is further configured: to select a security gateway from the list (214) and to initiate communication between the first security gateway and the selected second security gateway in the second mobile communication network. [6] The apparatus (300) according to any one of the preceding claims, wherein the processing circuitry (310) is configured to initiate (230) communication between the first and third security gateways based on performing (232) a second DNS query using the second domain name to dynamically discover a new target security gateway. [7] The device (300) according to claim 6, wherein the processing circuitry (310) is further configured: redirect communication to the new target security gateway based on the results of the second DNS query (235). [8] The apparatus (300) according to any one of claims 4 to 7, wherein the DNS queries comprise respective DNS Naming Authority Pointer, NAPTR, queries. [9] The device (300) according to any one of the preceding claims, wherein the security gateways comprise respective Security Edge Protection Proxies, SEPPs. [10] The apparatus (300) according to any preceding claim, wherein the first and second mobile communication networks comprise respective 5G standalone, SA, networks. [11] The apparatus (300) according to any preceding claim, wherein the domain names comprise respective fully qualified domain names, FQDNs. [12] The apparatus (300) according to any preceding claim, wherein the redirection response comprises a Hypertext Transfer Protocol, HTTP, redirection response. [13] An apparatus for dynamically discovering and rerouting security gateways in mobile communication networks, the apparatus comprising: a processing circuit arrangement which is designed: based on a first domain name, to initiate communication between a first security gateway in a first mobile communication network and a second security gateway in a second mobile communication network; send a redirection response from the second security gateway to the first security gateway, the redirection response indicating a second domain name to be used for DNS-based discovery of another security gateway in the second mobile communication network.

Images