Method and apparatus for security management in a communication system

Abstract

This application relates to methods and apparatus for security management in a communication system. In a communication system, a first network is operatively coupled to a second network, the first network including a first security edge protection proxy element that is operatively coupled to a second security edge protection proxy element of the second network. One of the first security edge protection proxy element and the second security edge protection proxy element is a sending security edge protection proxy element and the other of the two is a receiving security edge protection proxy element, the receiving security edge protection proxy element receiving a message from the sending security edge protection proxy element. The receiving security edge protection proxy element detects one or more error conditions associated with the received message. The receiving security edge protection proxy element determines one or more error handling actions to be taken in response to the one or more detected error conditions.

Description

[0001] This application is a divisional application of the invention patent application with international application number PCT / FI2019 / 050354, international application date May 7, 2019, which entered the Chinese national phase on November 13, 2020, with application number 2019800323564 and invention title: "Error Handling Framework for Security Management in Communication Systems". Technical Field

[0002] This field generally relates to communication systems, and more specifically, but not exclusively, to security management within such systems. Background Technology

[0003] This section may help to facilitate a better understanding of various aspects of the invention. Therefore, the statements in this section should be read in this light and should not be construed as an admission of anything present in the prior art or not present in the prior art.

[0004] Fourth-generation (4G) wireless mobile telecommunications technology (also known as Long Term Evolution (LTE) technology) is designed to provide high-capacity mobile multimedia at high data rates, particularly for human interaction. Next-generation or fifth-generation (5G) technology is designed not only for human interaction but also for machine-type communication in so-called Internet of Things (IoT) networks.

[0005] While 5G networks are designed to support large-scale IoT services (e.g., numerous devices with limited capacity) and mission-critical IoT services (e.g., requiring high reliability), they also support improvements to traditional mobile communication services in the form of enhanced mobile broadband (eMBB) services that provide improved wireless internet access to mobile devices.

[0006] In the example communication system, a user equipment such as a mobile terminal (subscriber) (a 5G UE in a 5G network, or more broadly, a UE) communicates with a base station or access point (referred to as a gNB in ​​a 5G network) via an air interface. An access point (e.g., a gNB) is illustratively part of the access network of the communication system. For example, in a 5G network, the access network is referred to as the 5G system and is described in V15.0.0 of the 5G technical specification (TS) 23.501 entitled “Technical Specification Group Services and System Aspects; System Architecture for the 5G System,” the entire contents of which are incorporated herein by reference. Typically, the access point (e.g., the gNB) provides the UE with access to the core network (CN), which in turn provides the UE with access to other UEs and / or data networks (such as packet data networks, e.g., the Internet).

[0007] TS 23.501 goes on to define a service-based architecture (SBA) for 5G that models services as network functions (NFs) that communicate with each other using a representative state transition application programming interface (RESTful API).

[0008] In addition, V0.7.0 of the 5G technical specification (TS) 33.501, entitled “Technical Specification Group Services and System Aspects; Security Architecture and Procedures for the 5G System” (the entire contents of which are incorporated herein by reference in their entirety), describes the security management details associated with 5G networks.

[0009] Security management is a critical consideration in any communication system. However, security management issues can present significant challenges as efforts continue to improve the architecture and protocols associated with 5G networks to enhance network efficiency and / or subscriber convenience. Summary of the Invention

[0010] The illustrative embodiments provide improved techniques for security management in communication systems.

[0011] For example, in one illustrative embodiment, a method includes the following steps. In a communication system including a first network operatively coupled to a second network, wherein the first network includes a first security edge protection agent element operatively coupled to a second security edge protection agent element of the second network, and wherein one of the first and second security edge protection agent elements is a transmitting security edge protection agent element and the other is a receiving security edge protection agent element, the receiving security edge protection agent element receiving a message from the transmitting security edge protection agent element. The receiving security edge protection agent element detects one or more error conditions associated with the received message. The receiving security edge protection agent element determines one or more error handling actions to be taken in response to the detected one or more error conditions.

[0012] In another embodiment, a method includes the following steps. In a communication system including a first network operatively coupled to a second network, wherein the first network includes a first security edge protection proxy element, the first security edge protection proxy element being operatively coupled to a second security edge protection proxy element of the second network, and wherein one of the first and second security edge protection proxy elements is a transmitting security edge protection proxy element and the other of the first and second security edge protection proxy elements is a receiving security edge protection proxy element, and in response to detecting one or more error conditions associated with a message transmitted by the transmitting security edge protection proxy element to the receiving security edge protection proxy element, the transmitting security edge protection proxy element receives an error handling message from the receiving security edge protection proxy element. In response to the error handling message, the transmitting security edge protection proxy element performs at least one of the following: initiating one or more error handling actions and executing the one or more error handling actions.

[0013] Other illustrative embodiments are provided in the form of a non-transitory computer-readable storage medium in which executable program code is implemented, which, when executed by a processor, causes the processor to perform the steps described above. Further illustrative embodiments include an apparatus having a processor and memory configured to perform the steps described above.

[0014] These and other features and advantages of the embodiments described herein will become clearer from the accompanying drawings and the following detailed description. Attached Figure Description

[0015] Figure 1 A communication system that can implement one or more illustrative embodiments is shown.

[0016] Figure 2 The diagram illustrates network elements / functions for providing security management that can be used to implement one or more exemplary embodiments.

[0017] Figure 3 A communication system architecture with a secure edge protection agent between the visited network and the home network is shown, which can be used to implement one or more exemplary embodiments.

[0018] Figure 4 An example of a message passed from a network function in a visited network to a network function in a home network via a security edge protection agent is shown, which can be used to implement one or more exemplary embodiments.

[0019] Figure 5A method for error handling for interconnect security in a communication system architecture with a secure edge protection agent between a visited network and a home network, according to an illustrative embodiment, is shown. Detailed Implementation

[0020] This document will illustrate embodiments in conjunction with example communication systems and associated techniques for providing security management within communication systems. However, it should be understood that the scope of the claims is not limited to the specific types of communication systems and / or processes disclosed. Embodiments can be implemented in a variety of other types of communication systems using alternative processes and operations. For example, although described in the context of a wireless cellular system utilizing 3GPP system elements such as 3GPP Next Generation Systems (5G), the disclosed embodiments are directly applicable to a variety of other types of communication systems.

[0021] According to the illustrative embodiments implemented in a 5G communication system environment, one or more 3GPP Technical Specifications (TS) and Technical Reports (TRs) can provide further descriptions of network elements / functions and / or operations that can interact with various parts of the present invention solution, such as the aforementioned 3GPP TS 23.501 and 3GPP TS 33.501. Other 3GPP TS / TR documents can provide additional general details that will be recognized by those skilled in the art. However, while well suited to 5G-related 3GPP standards, the embodiments are not necessarily intended to be limited to any particular standard.

[0022] The illustrative embodiments relate to security management associated with a service-based architecture (SBA) for 5G networks. Before describing such illustrative embodiments, the following will... Figure 1 and 2 A general description of the main components of a 5G network within the context of [the context].

[0023] Figure 1 A communication system 100 implementing illustrative embodiments is shown. It should be understood that the elements shown in the communication system 100 are intended to represent key functions provided within the system, such as UE access functions, mobility management functions, authentication functions, serving gateway functions, etc. Therefore, Figure 1 The boxes shown refer to specific elements in a 5G network that provide these key functions. However, other network elements can be used to implement some or all of the key functions represented. Additionally, it should be understood that... Figure 1 The diagram depicts all the functions of a 5G network. Instead, it illustrates functions that facilitate the explanation of illustrative embodiments. Subsequent figures may depict additional elements / functions.

[0024] Therefore, as shown, the communication system 100 includes a user equipment (UE) 102 communicating with an access point (gNB) 104 via an air interface 103. The UE 102 may be a mobile station, and such a mobile station may include, for example, a mobile phone, a computer, or any other type of communication device. Therefore, the term "user equipment" as used herein is intended to be interpreted broadly to encompass various types of mobile stations, subscriber stations, or (more generally) communication devices, including examples such as combinations of data cards inserted into a laptop or other device (such as a smartphone). Such communication devices are also intended to encompass devices commonly referred to as access terminals.

[0025] In one embodiment, UE 102 includes a Universal Integrated Circuit Card (UICC) portion and a Mobile Equipment (ME) portion. The UICC is the user-related portion of the UE and contains at least one Universal Subscriber Identity Module (USIM) and appropriate application software. The USIM securely stores a persistent subscription identifier and its associated key, which are used to identify and authenticate subscribers seeking network access. The ME is the user-independent portion of the UE and includes Terminal Equipment (TE) functionality and various Mobile Terminal (MT) functions.

[0026] Note that in one example, the permanent subscription identifier is the UE's International Mobile Subscriber Identity (IMSI). In one embodiment, the IMSI is a fixed 15-bit length and includes a 3-digit Mobile Country Code (MCC), a 3-digit Mobile Network Code (MNC), and a 9-digit Mobile Station Identifier Number (MSIN). In 5G communication systems, the IMSI is referred to as the Subscription Permanent Identifier (SUPI). When the IMSI is used as the SUPI, the MSIN provides the subscriber identity. Therefore, typically only the MSIN portion of the IMSI needs to be encrypted. The MNC and MCC portions of the IMSI provide routing information that the serving network can use to route to the correct home network. When the MSIN of the SUPI is encrypted, it is called the Subscription Hidden Identifier (SUCI).

[0027] Access point 104 is illustratively part of the access network of communication system 100. Such an access network may include, for example, a 5G system having multiple base stations and one or more associated radio network control functions. The base stations and radio network control functions may be logically separate entities, but in a given embodiment, they may be implemented in the same physical network element, such as, for example, a base station router or a femtocellular access point.

[0028] In this illustrative embodiment, access point 104 is operatively coupled to mobility management function 106. In a 5G network, mobility management functions are implemented by an Access and Mobility Management Function (AMF). A Security Anchoring Function (SEAF) can also be implemented by connecting the UE to a mobility management function via the AMF. As used herein, a mobility management function is an element or function (i.e., entity) in the core network (CN) portion of a communication system that manages or otherwise participates in access and mobility (including authentication / authorization) operations with the UE (via access point 104) and other network operations. The AMF may also be more generally referred to herein as an Access and Mobility Management Entity.

[0029] In this illustrative embodiment, AMF 106 is operatively coupled to Home Subscriber Function 108, i.e., one or more functions residing in the subscriber's home network. As shown, some of these functions include Unified Data Management (UDM) functions and Authentication Server Function (AUSF). AUSF and UDM (respectively or jointly) may also be more generally referred to herein as authentication entities. Furthermore, Home Subscriber Functions may include, but are not limited to, Network Slice Selection Function (NSSF), Network Exposure Function (NEF), Network Repository Function (NRF), Policy Control Function (PCF), and Application Function (AF).

[0030] Access point 104 is also operatively coupled to a Serving Gateway function, namely Session Management Function (SMF) 110, which is operatively coupled to a User Plane Function (UPF) 112. UPF 112 is operatively coupled to a packet data network, such as the Internet 114. Other typical operations and functions of such network elements are not described here, as they are not the focus of this illustrative embodiment and can be found in appropriate 3GPP 5G documentation.

[0031] It should be understood that this particular arrangement of system elements is merely an example, and in other embodiments, other types and arrangements of additional or alternative elements may be used to implement the communication system. For example, in other embodiments, system 100 may include other elements / functions not explicitly shown herein.

[0032] therefore, Figure 1 The arrangement shown is just one example configuration for a wireless cellular system, and many alternative configurations of system components can be used. For example, although in Figure 1 The embodiments shown depict only a single element / function, but this is merely for the sake of simplicity. The given alternative embodiments may, of course, include many more such system elements, as well as additional or alternative elements of the type typically associated with conventional system implementations.

[0033] It should also be noted that, although Figure 1While system components are illustrated as single functional blocks, the various subnets that make up a 5G network are divided into so-called network slices. A network slice (network partition) comprises a set of network functions (NFs) (i.e., function chains) for each corresponding service type using Network Function Virtualization (NFV) on a common physical infrastructure. Network slices can be instantiated as needed for a given service (e.g., eMBB service, large-scale IoT service, and mission-critical IoT service). Thus, a network slice or function is instantiated when an instance of it is created. In some embodiments, this involves installing or otherwise running the network slice or function on one or more host devices in the underlying physical infrastructure. UE 102 is configured to access one or more of these services via gNB 104.

[0034] Figure 2 This is a block diagram of network elements / functions used to provide security management in an illustrative embodiment. System 200 is shown as including a first network element / function 202 and a second network element / function 204. It should be understood that network elements / functions 202 and 204 represent any network element / function configured to provide security management and other technologies described herein, such as, but not limited to, AMF, SEAF, UDM, AUSF, NSSF, NEF, NRF, PCF, and AF. Furthermore, one or both of the first network element / function 202 and the second network element / function 204 may also represent a Security Edge Protection Agent (SEPP), which will be described in further detail below.

[0035] Network element / function 202 includes a processor 212 coupled to memory 216 and interface circuitry 210. The processor 212 of network element / function 202 includes a security management processing module 214, which may be implemented at least partially as software executed by the processor. Processing module 214 performs security management as described in conjunction with the following figures and other methods herein. The memory 216 of network element / function 202 includes a security management storage module 218, which stores data generated or otherwise used during security management operations.

[0036] Network element / function 204 includes a processor 222 coupled to memory 226 and interface circuitry 220. The processor 222 of network element / function 204 includes a security management processing module 224, which may be implemented at least partially in the form of software executed by the processor 222. Processing module 224 performs security management in conjunction with the following figures and other methods described herein. The memory 226 of network element / function 204 includes a security management storage module 228, which stores data generated or otherwise used during security management operations.

[0037] The processors 212 and 222 of the corresponding network elements / functions 202 and 204 may include, for example, microprocessors, application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), digital signal processors (DSPs), or other types of processing devices or integrated circuits, as well as portions or combinations of such elements. Such integrated circuit devices and portions or combinations thereof are examples of the term "circuit system" as used herein. Various other arrangements of hardware and associated software or firmware may be used to implement the illustrative embodiments.

[0038] The memories 216 and 226 of the corresponding network elements / functions 202 and 204 can be used to store one or more software programs executed by the corresponding processors 212 and 222 to implement at least a portion of the functionality described herein. For example, security management operations and other functionality, as described in conjunction with the following figures and otherwise herein, can be implemented directly using software code executed by processors 212 and 222.

[0039] Therefore, a given memory in memory 216 or 226 can be considered as an example of a processor-readable storage medium having executable program code implemented therein, more generally referred to herein as a computer program product. Other examples of processor-readable storage media may include, in any combination, magnetic disks or other types of magnetic or optical media. Illustrative embodiments may include articles of manufacture comprising such computer program products or other processor-readable storage media.

[0040] Memory 216 or 226 may more specifically include, for example, electronic random access memory (RAM), such as static RAM (SRAM), dynamic RAM (DRAM), or other types of volatile or non-volatile electronic memory. The latter may include, for example, non-volatile memory, such as flash memory, magnetic RAM (MRAM), phase-change RAM (PC-RAM), or ferroelectric RAM (FRAM). The term “memory” as used herein is intended to be interpreted broadly and may additionally or alternatively include, for example, read-only memory (ROM), disk-based memory, or other types of storage devices, and portions or combinations thereof.

[0041] The interface circuitry systems 210 and 220 of the corresponding network elements / functions 202 and 204 illustratively include transceivers or other communication hardware or firmware that allow associated system elements to communicate with each other in the manner described herein.

[0042] from Figure 2 Clearly, network element / function 202 is configured to communicate with network element / function 204 via its respective interface circuitry 210 and 220, and vice versa. This communication involves network element / function 202 sending data to network element / function 204, and network element / function 204 sending data to network element / function 202. However, in alternative embodiments, other network elements may be operatively coupled between network elements / functions 202 and 204. The term "data" as used herein is intended to be interpreted broadly to encompass any type of information that can be sent between network elements / functions (and between user equipment and the core network), including but not limited to messages, identifiers, keys, indicators, user data, control data, etc.

[0043] It should be understood that Figure 2 The specific arrangement of the components shown is merely an example, and many alternative configurations can be used in other embodiments. For example, any given network element / function can be configured to include other or alternative components and support other communication protocols.

[0044] Other system components (such as UE 102 and gNB 104) can also be configured individually as components including, for example, processors, memory, and network interfaces. These components do not necessarily need to be implemented on separate, independent processing platforms, but can instead represent, for example, different functional parts of a single common processing platform.

[0045] Given the general concepts above, illustrative embodiments for addressing certain security management problems will now be described. More specifically, the illustrative embodiments provide security management techniques for 5G systems. The architecture of 5G systems is currently being standardized in 3GPP. As mentioned above, 3GPP TS 23.501 defines the 5G system architecture as service-based, such as Service-Based Architecture (SBA).

[0046] Figure 3 A 5G architecture in a configuration is depicted, comprising a Visited Public Land Mobile Network (VPLMN) 310, which is operatively coupled to a Home Public Land Mobile Network (HPLMN) 330 via an Intermediate Interconnect Network Packet Switched (IPX) network 320. Note that more than one IPX network is operatively coupled between the VPLMN 310 and the HPLMN 330. More specifically, Figure 3 The presence of a Security Edge Protection Proxy (SEPP) at the edge of each PLMN (i.e., vSEPP 312 in VPLMN 310 and hSEPP 332 in HPLMN 330) is illustrated. It should be understood that the various network functions illustrated in VPLMN 310 and HPLMN 330 are known and described in detail in various 5G specifications, such as, but not limited to, TS23.501 and TS 33.501 mentioned above.

[0047] As mentioned above, in 5G, SBA is introduced to model services as network functions (NFs) that communicate with each other using a RESTful application programming interface (representative state transition API). In scenarios where two communicating NFs are located in two different PLMNs (e.g., VPLMN 310 and HPLMN 330), communication occurs through the roaming network interface (N32) between the two participating PLMNs.

[0048] To protect NF-specific content in messages sent through roaming network interfaces, 5G introduces SEPP as an entity located on the periphery of the PLMN network to protect the PLMN from external services and implement Transport Layer Security (TLS) and Application Layer Security (ALS) for all data and signaling exchanged between network functions at the service layer. For example, before a message is sent externally via the roaming N32 interface, the SEPP performs security management functions on the Information Elements (IEs) in Hypertext Transfer Protocol (HTTP) messages. The protected HTTP message is called an N32 message. Protections such as ALS involve protecting the information sent in various parts of the HTTP message, including but not limited to HTTP request / response lines, HTTP headers, and HTTP payloads. However, some parts of the message may require intermediaries between two SEPPs (e.g., Figure 3The IPX 330 network provider shown is modified.

[0049] Therefore, in 5G SBA, PLMN operators deploy SEPPs at their network edge for interoperability and to obtain services from network functions in their roaming partner networks. SEPPs interface with one or more other SEPPs in one or more other networks via the N32 interface. As an edge proxy, the SEPP implements ALS as described above to protect HTTP messages exchanged between network functions in its network and another network function in the roaming partner network.

[0050] For example, Figure 4 An example of a message passed from a network function in the visited network to a network function in the home network via a security edge protection agent is shown. More specifically, Figure 4 Example 400 depicts a VPLMN 410 operatively coupled to an HPLMN 430 via an IPX network 420. Assume that an AMF NF 412 in the VPLMN 410 invokes an API request on an AUSFNF 432 in the HPLMN 430. The message flow is as follows: a) AMF NF 412 first sends an HTTP request message to its local SEPP (i.e., vSEPP 414). b) vSEPP 414 applies ALS and sends security messages to AUSF NF432 in HPLMN 430 via IPX network 420 on the N32 interface. c) hSEPP 434 is at the edge of HPLMN 430 and receives all incoming HTTP messages from its roaming partner network (vSEPP 414 in VPLMN410 in this case). d) hSEPP 434 removes the security mechanisms applied at the application layer and forwards the resulting HTTP request messages to the corresponding AUSF NF 432.

[0051] More generally, N32 messages are exchanged between two SEPPs located at the periphery of two networks. The N32 message is generated by the sending SEPP (sSEPP) by reformatting and securing a received HTTP message sent by an internal network function (e.g., AMF NF 412) in its network to another network function (e.g., AUSF NF 432) via a receiving SEPP (rSEPP) in the roaming partner network. Note that in one scenario, vSEPP 414 is an sSEPP and hSEPP 434 is an rSEPP, while in another scenario, hSEPP 434 is an sSEPP and vSEPP 414 is an rSEPP.

[0052] In one or more embodiments, ALS relates to protecting information transmitted in various parts of an HTTP message, including but not limited to HTTP request / response lines, HTTP headers, and HTTP payloads. Protection of the N32 message is achieved by using optional encryption of selected fields in the HTTP message to provide integrity protection for the entire HTTP message. Additionally, the selected fields in the HTTP message are suitable for modification by an authorized IPX provider (e.g., IPX 420) present in the interconnecting networks connecting two operators. In one embodiment, at rSEPP, the received N32 message is verified in a phased manner and then forwarded to the target NF in the roaming network.

[0053] In rSEPP, received N32 messages are first verified through a series of steps before being accepted and reassembled into HTTP messages. This verification process can fail (i.e., lead to erroneous conditions) for many reasons. As examples, errors could occur due to a malicious middleman manipulating N32 messages, causing integrity checks to fail; packet loss due to congestion; a malicious man-in-the-middle (MITM) attacker intentionally removing portions of messages related to subscriptions and identity or service authorization, and so on.

[0054] In this context, the illustrative embodiment specifies that rSEPP takes corrective action, which may involve reporting the event to sSEPP for further action at its end and / or taking necessary actions locally, such as logging the event for offline analysis. More specifically, the illustrative embodiment provides a security management technique that includes an error handling framework. In one or more embodiments, the error handling framework includes four parts: (1) rSEPP detects an error and determines how to resolve it; (2) error handling actions initiated or otherwise performed by rSEPP; (3) signaling flows for updating (notifying) sSEPP; and (4) error handling actions initiated or otherwise performed by sSEPP.

[0055] Figure 5 An error handling framework is illustrated in the context of a method 500 for interconnect security in a communication system architecture with a security edge protection agent between a visited network and a home network, according to an illustrative embodiment. More specifically, as shown, network function 502 sends an HTTP request message to sending SEPP (sSEPP) 504 in step 1. As described above, in step 2, sSEPP 504 generates an N32 message (containing the HTTP request message) and sends it to receiving SEPP (rSEPP) 506. One or more IPX networks exist between sSEPP 504 and rSEPP 506, but are not explicitly shown for simplicity.

[0056] Assume one or more errors occur in response to an N32 message sent by sSEPP 504. These errors may be caused by one or more of the reasons described above (e.g., integrity check failure, packet loss, MITM attacker, etc.) or some other reason. According to an illustrative embodiment, the four-part error handling framework operates as follows:

[0057] (1) Error detection and decision-making in rSEPP

[0058] This section describes an illustrative embodiment of one part of a four-part error handling framework. Alternative or additional steps may be implemented as needed for specific error conditions.

[0059] In step 3, rSEPP 506 detects one or more errors and generates one or more appropriate error codes.

[0060] According to the illustrative embodiment, error detection in rSEPP 506 can occur in one of two ways:

[0061] a) Multi-level error detection. In one embodiment of error detection, rSEPP 506 performs all the steps required to fully validate all fields of the received message and uses a bitmap data structure to record the different failures in all fields of the received message. rSEPP 506 then analyzes the bitmap data structure to determine the next step, i.e., what one or more error handling actions to take.

[0062] b) One-step error detection. In an alternative embodiment of error detection, rSEPP 506 stops when the first error occurs and makes a decision about the action to be taken. In one example, the detection of a first critical error stops the detection step and triggers the decision step. The severity of the error can be predetermined by the network operator and the correspondingly configured rSEPP.

[0063] One or more error codes are generated. The generated error codes depend on the type of error detection used (e.g., multi-level or one-step). For example, when using multi-level error detection, the error codes capture all detected errors. As described below, rSEPP 506 analyzes the error codes(s) and determines the next action.

[0064] (2) Error handling in rSEPP

[0065] This section describes an illustrative embodiment of part two of the four-part error handling framework. Alternative or additional steps can be implemented as needed for specific error conditions.

[0066] In step 4, rSEPP 506 performs local actions. The types of actions taken by rSEPP 506 can be based on the configuration or analysis tools available in rSEPP 506.

[0067] As an example only, here are the types of actions that rSEPP 506 can take:

[0068] a) Report the operation, supervision and management (OAM) network 508 to the network operator (i.e., the operator of the network that its rSEPP 506 is used as a security edge protection agent) via logging, alerts, etc. (step 5).

[0069] b) Report back to sSEPP 504 (further explained in section (3) below). This may include sending a message to sSEPP 504 using one or more of the following instructions: (i) requesting sSEPP 504 to resend the message via a different IPX route; or triggering a renegotiation of the security mechanism with sSEPP 504 using different security parameters. In one or more illustrative embodiments, this may result in the use of end-to-end (e2e) TLS between the two SEPPs instead of ALS at the HTTP layer.

[0070] c) Depending on the error, renegotiation with rSEPP's trusted IPX provider (referred to as rIPX) may be required. This includes re-authentication and re-establishment of TLS between rSEPP and rIPX. This operation may also involve reissuing IPX credentials, such as certificates, shared secrets, etc.

[0071] (3) Signaling stream used to update sSEPP

[0072] This section describes an illustrative embodiment of part three of the four-part error handling framework. Alternative or additional steps may be implemented as needed for specific error conditions.

[0073] rSEPP 506 sends N32 signaling messages to sSEPP 504 using the existing N32-based interconnect interface. This is in Figure 5 This is represented as step 6.

[0074] In one or more illustrative embodiments, a new SEPP-to-SEPP N32 signaling message is created for this purpose. For example, in one embodiment, the new message includes, for instance, an additional set of elements or indicator flags that were generated in part one of the framework, and a specific set of elements that ultimately guide the recovery actions initiated and / or performed by sSEPP 504.

[0075] When set by rSEPP 506, the indicator flags are checked (step 7) and used in sSEPP 504 for a specific set of actions to be performed. Below are some non-limiting examples of the indicator flags used and the actions they represent:

[0076] a) Use different IPX routes, for example, to bypass any detected malicious nodes.

[0077] b) Request end-to-end TLS to communicate directly with rSEPP 506, thereby avoiding the use of IPX networks.

[0078] These messages are protected by SEPP's application-layer security mechanisms.

[0079] (4) Error handling in sSEPP

[0080] This section describes an illustrative embodiment of part four of the four-part error handling framework. Alternative or additional steps may be implemented as needed for specific error conditions.

[0081] sSEPP checks the acquired error codes (step 8) and takes appropriate action:

[0082] a) Perform local action (step 9). sSEPP 504 performs an action locally, which may involve sending a notification to the operator's OAM network (for networks associated with sSEPP 504 that are not yet logged, alerted, etc.) via logging, alarms, etc. Figure 5 (As clearly stated in the document) a report should be submitted.

[0083] b) Modify the interaction between sSEPP 504 and rSEPP 506. For example:

[0084] i) If guided by rSEPP 506, sSEPP 504 determines whether there are one or more alternative transmission routes available to rSEPP 506, and if available, retransmits the message via at least one of the one or more alternative routes.

[0085] ii) Re-examine or renegotiate the security profile (e.g., cipher suite, etc.) originally agreed upon during the previous handshake between sSEPP 504 and rSEPP 506.

[0086] iii) If instructed by rSEPP 506 or if sSEPP 504 deems it necessary, sSEPP 504 may establish an alternative security mechanism (e.g., e2e TLS) directly with rSEPP 506.

[0087] c) Update the source network functionality (step 10). After proper repackaging (appropriately mapping the N32 error code to the corresponding HTTP error code), send a "failure" HTTP response message to the source NF 502. In one illustrative embodiment, the NF 502 is unaware of the security error code and receives a generic HTTP failure message where the HTTP error code is closely mapped to the N32 error code. In another illustrative embodiment, the NF 502 is aware of the security error code and therefore does not need to map the N32 error code to the HTTP error code.

[0088] It should be understood that the above is in Figure 5 In the context of the error handling framework and in the alternative embodiments described exemplary, one or more portions of the error handling framework may overlap with one or more other portions of the error handling framework.

[0089] It should also be understood that, in one or more illustrative embodiments, two SEPPs may discover each other based on one or more processes, including but not limited to Name Authorization Pointer (U-NAPTR) resource records with Dynamic Host Configuration Protocol (DHCP) or Local Configuration and Uniform Resource Identifier (URI) enabled in the Domain Name System (DNS), FQDN configuration in a local database, etc.

[0090] Therefore, it should be emphasized again that the various embodiments described herein are presented by way of illustrative example only and should not be construed as limiting the scope of the claims. For example, alternative embodiments may utilize different communication system configurations, user equipment configurations, base station configurations, key pair provisioning and usage procedures, messaging protocols, and message formats than those described above in the context of the illustrative embodiments. These and many other alternative embodiments within the scope of the appended claims will be readily apparent to those skilled in the art.

Claims

1. A method comprising: In a 5G communication system, the 5G communication system includes a visited public land mobile network operatively coupled to a home public land mobile network, wherein the visited public land mobile network includes a first security edge protection proxy element, the first security edge protection proxy element being operatively coupled to a second security edge protection proxy element of the home public land mobile network, and wherein one of the first security edge protection proxy element and the second security edge protection proxy element is a transmitting security edge protection proxy element, and the other of the first security edge protection proxy element and the second security edge protection proxy element is a receiving security edge protection proxy element; At the receiving security edge protection agent element, a message is received from the sending security edge protection agent element; At the receiving security edge protection agent element, one or more error conditions associated with the received message are detected; as well as At the receiving security edge protection agent element, one or more error handling actions to be taken in response to the detected one or more error conditions are determined.

2. The method according to claim 1, further comprising: The receive security edge protection agent element generates one or more error codes corresponding to the detected one or more error conditions.

3. The method of claim 1, further comprising the receiving security edge protection agent element performing at least one of the following: initiating the one or more error handling actions, and executing the one or more error handling actions.

4. The method of claim 3, wherein the one or more error handling actions include: The receiving security edge protection agent element notifies the network element of the one or more error conditions.

5. The method of claim 4, wherein the network element includes an operation, monitoring, and management network.

6. The method of claim 3, wherein the one or more error handling actions include: The receiving security edge protection agent element re-establishes one or more security certificates with one or more network elements.

7. The method of claim 6, wherein at least one of the one or more network elements comprises: An intermediate network node operatively coupled between the visited public land mobile network and the home public land mobile network.

8. The method of claim 3, wherein the one or more error handling actions include: The receiving security edge protection agent element sends a signal to the sending security edge protection agent element.

9. The method of claim 8, wherein the signaling notification occurs via the N32 interface.

10. The method of claim 8, wherein the signaling notification comprises: The sending security edge protection agent element is signaled to resend the message to the receiving security edge protection agent element using a different route.

11. The method of claim 8, wherein the signaling notification comprises: The sending security edge protection agent element is signaled to communicate with the receiving security edge protection agent element using different security mechanisms.

12. The method of claim 11, wherein the different security mechanisms include: End-to-end encryption operations associated with transport layer security protocols.

13. The method of claim 8, wherein the signaling notification comprises: The receiving security edge protection agent element sends an error handling message to the sending security edge protection agent element.

14. The method of claim 13, wherein the error handling message includes one or more indicator flags configured to instruct the sending security edge protection agent element to take the one or more error handling actions.

15. The method of claim 13, wherein the error handling message includes one or more error codes corresponding to the detected one or more error conditions.

16. The method of claim 1, wherein the detection step and the determination step further comprise: The receiving security edge protection proxy element: Perform full validation of all fields of the received message; Use a bitmap data structure to record the different failures in all fields of the received message; as well as Analyze the bitmap data structure to determine the one or more error handling actions to be taken.

17. An article of manufacture comprising a non-transitory computer-readable storage medium in which executable program code is embodied, the executable program code causing the processor to perform the following steps when executed by a processor: In a 5G communication system, the 5G communication system includes a visited public land mobile network operatively coupled to a home public land mobile network, wherein the visited public land mobile network includes a first security edge protection proxy element, the first security edge protection proxy element being operatively coupled to a second security edge protection proxy element of the home public land mobile network, and wherein one of the first security edge protection proxy element and the second security edge protection proxy element is a transmitting security edge protection proxy element and the other of the first security edge protection proxy element and the second security edge protection proxy element is a receiving security edge protection proxy element; At the receiving security edge protection agent element, a message is received from the sending security edge protection agent element; At the receiving security edge protection agent element, one or more error conditions associated with the received message are detected; as well as At the receiving security edge protection agent element, one or more error handling actions to be taken in response to the detected one or more error conditions are determined.

18. An apparatus comprising: In a 5G communication system, the 5G communication system includes a visited public land mobile network operatively coupled to a home public land mobile network, wherein the visited public land mobile network includes a first security edge protection proxy element, the first security edge protection proxy element being operatively coupled to a second security edge protection proxy element of the home public land mobile network, and wherein one of the first security edge protection proxy element and the second security edge protection proxy element is a transmitting security edge protection proxy element, and the other of the first security edge protection proxy element and the second security edge protection proxy element is a receiving security edge protection proxy element; At least one processor, coupled to a memory associated with the receive security edge protection proxy element, the memory including computer program code, the memory and the computer program code being configured, together with the at least one processor, to cause the device to at least execute: At the receiving security edge protection agent element, a message is received from the sending security edge protection agent element; At the receiving security edge protection agent element, one or more error conditions associated with the received message are detected; as well as At the receiving security edge protection agent element, one or more error handling actions to be taken in response to the detected one or more error conditions are determined.

Images