Internet key exchange and internet protocol security synchronization and reachability detection

Abstract

A first network device (102-1) in a network (100, 200) implements one or more techniques to determine the reachability of an Internet Protocol security (IPsec) framework (601, 605). For example, upon establishment of an IPsec tunnel (605) with a second network device (102-2), the first network device sends at least a first probe message (606-1) to the second network device through the IPsec tunnel. In response to a first reply probe message (608-1) from the second network device, the first network device sends a second probe message (606-2) through the IPsec tunnel when one or more indications of an issue are detected with the framework. In response to a second reply probe message (608-2) having not been received from the second network device in response to the second probe message, the first network device determines that an issue exists with IPsec framework, and performs one or more IPsec recovery actions.

Description

INTERNET KEY EXCHANGE AND INTERNET PROTOCOL SECURITY SYNCHRONIZATION AND REACHABILITY DETECTIONBACKGROUND

[0001] The development of cellular networks has rapidly progressed, particularly with the introduction of fifth-generation (5G) technology, leading to significant enhancements in speed, data capacity, and overall connectivity. Similarly, non- cellular networks, such as Wi-Fi and other wireless internet technologies, have seen comparable advancements. Such advancements have rendered cellular and non- cellular networks increasingly essential for a wide range of uses, from personal communication to professional interactions, underscoring the critical need for secure transmission of information. In parallel, there has been a noticeable increase in the usage and dependence on non-cellular networks, encompassing both wired and wireless internet connections, necessitating stringent security measures to safeguard data.

[0002] In this evolving digital environment, Internet Protocol Security (IPsec) and Internet Key Exchange (IKE) have established themselves as key components in network security. IPsec, in particular, is instrumental in ensuring that data transmitted over the IP layer is both authenticated and encrypted, thereby protecting communications across networks that may be vulnerable to security breaches, such as the Internet. IKE, an integral part of the IPsec protocol suite, is important for establishing a security association (SA), which is a process fundamental to the process of negotiating encryption keys and authentication methods. Together, IPsec and IKE form a robust framework for securing digital communications, reflecting their pivotal role in addressing the security challenges prevalent in the modern era of widespread digital connectivity.SUMMARY OF EMBODIMENTS

[0001] In one aspect a method, at a first network device, for determining reachability of an Internet Protocol security (IPsec) framework includes establishingan IPsec tunnel with a second network device, and sending at least a first probe message to the second network device through the IPsec tunnel.

[0002] In at least some embodiments, the at least first probe message is one of an Internet Control Message Protocol (ICMP) ping or a Dead Peer Detection (DPD) message.

[0003] In at least some embodiments, sending the at least first probe message to the second network device through the IPsec tunnel includes sending the at least first probe message without an active delay by the first network device upon detecting establishment of the IPsec tunnel.

[0004] In at least some embodiments, the method further includes sending, in response to receiving a first reply probe message from the second network device through the IPsec tunnel, at least a second probe message through the IPsec tunnel to the second network device when one or more indications of an issue are detected with the IPsec framework.

[0005] In at least some embodiments, the method further includes detecting an issue with the IPsec framework based on at least one of a determination that a data packet has not been received through the IPsec tunnel within a threshold period of time, or detecting a dynamic address update has been performed.

[0006] In at least some embodiments, the method further includes determining that the IPsec framework is operating correctly in response to receiving a second reply probe message from the second network device in response to sending the at least second probe message.

[0007] In at least some embodiments, the method further includes continuing to transmit data through the IPsec tunnel in response to determining that the IPsec framework is operating correctly.

[0008] In at least some embodiments, the method further includes determining that an issue exists with IPsec framework in response to a second reply probe message having not been received from the second network device in response to sending the at least second probe message.

[0009] In at least some embodiments, the method further includes performing one or more IPsec recovery actions in response to determining that an issue exists with I Psec framework.

[0010] In at least some embodiments, the one or more IPsec recovery actions include re-establishing the IPsec framework with the second network device.

[0011] In at least some embodiments, sending at least a first probe message is in response to establishing the IPsec tunnel with the second network device.

[0012] In at least some embodiments, the method further includes determining a reachability of the second network device outside of the IPsec tunnel in response to a determination that the second network device is not configured to respond to probe messages.

[0013] In accordance with another aspect, network device configured to determine reachability of an Internet Protocol security (IPsec) framework includes a processor, and a network security protocol stack implemented at the processor to perform the method of any of claims 1 to 13 the methods described above and herein.

[0014] In accordance with another aspect, a user equipment device configured to determine reachability of an Internet Protocol security (IPsec) framework includes one or more radio frequency (RF) modems configured to wirelessly communicate with at least one network, one or more processors coupled to the one or more RF modems, and at least one memory storing executable instructions, the executable instructions configured to manipulate at least one of the one or more processors or the one or more RF modems to perform the methods described above and herein.BRIEF DESCRIPTION OF THE DRAWINGS

[0003] The present disclosure may be better understood, and its numerous features and advantages made apparent to those skilled in the art by referencing the accompanying drawings. The use of the same reference symbols in different drawings indicates similar or identical items.

[0004] FIG. 1 is a block diagram of a network environment implementing network devices configured to perform reachability procedures for IPsec SAs in accordance with some embodiments.

[0005] FIG. 2 is a block diagram of another network environment implementing network devices configured to perform reachability procedures for IPsec SAs in accordance with some embodiments.

[0006] FIG. 3 is a block diagram illustrating example modes of an IPsec reachability mechanism employed by one or more of the network devices of FIG. 1 and FIG. 2 in accordance with some embodiments.

[0007] FIG. 4 is a diagram illustrating an example hardware configuration of a network device configured to implement reachability procedures for IPsec SAs in accordance with some embodiments.

[0008] FIG. 5 is a diagram illustrating another example hardware configuration of a network device configured to implement reachability procedures for IPsec SAs in accordance with some embodiments.

[0009] FIG. 6 is a transactional diagram illustrating a sequence of operations performed by the network devices of FIG. 1 or FIG. 2 for implementing reachability procedures for IPsec SAs.

[0010] FIG. 7 is a flow diagram illustrating an example method of determining IPsec SA reachability in accordance with some embodiments.DETAILED DESCRIPTION

[0011] IKE and IPsec are foundational technologies in the realm of network tunneling, playing a pivotal role in the functionality of, for example, Virtual Private Networks (VPNs) and offloading processes within Third Generation Partnership Project (3GPP) systems, particularly for non-3GPP networks. Non-3GPP offloading refers to the transfer of data services from a cellular network to a non-cellular network, such as a wireless fidelity (Wi-Fi) network, which is often utilized to improve coverage or connection speeds. IPsec provides IP-level security and supports bothmobility and tunneling, while IKE acts as the control protocol, managing Child Security Associations (SAs). Child SAs are typically constructed using two unidirectional IPsec tunnels and are established for encrypting user data traffic. The endpoints of an IPsec connection, referred to as IKE and Child SA peers, establish and maintain these SAs, setting the rules for data encryption and transfer. This process is crucial, especially in mobile environments where IP addresses can change, necessitating dynamic address updates.

[0012] A critical issue arises from the necessity that both the IKE SA and the Child SA should ideally operate using the same network address. This alignment is essential for ensuring a seamless and secure communication flow. However, real- world applications often reveal inconsistencies in this ideal setup. A common issue observed is that while the IKE SA (the initial security association for establishing VPN connectivity) may function without any issues, the Child SA, which is responsible for the actual encrypted data transmission via IPsec tunnels, may encounter operational difficulties. These challenges become particularly acute when both SAs manage the same data traffic but do not align in their operational parameters.

[0013] One cause of such discrepancies is when one IKE peer in a secure connection involving IPsec modifies the IPsec tunnel's rules or configurations without adequately communicating these changes to the other IKE peer. This lack of coordination can lead to a mismatch in the operation of the IKE SA and Child SA. Such a mismatch can lead to potential disruptions or vulnerabilities in the secure data transmission over the secure communication link (e.g., a VPN connection).

[0014] Additionally, many IKE peers prioritize service continuity and mobility, often updating their addresses dynamically to keep connections stable. However, these updates can introduce uncertainties, especially if there is ambiguity about whether the corresponding peer will recognize and adapt to these changes. Consequently, an IKE message may be sent using an updated IP address without the IPsec tunnel being informed or aligned with this new address. This lack of coordination can cause operational inefficiencies or security vulnerabilities, as the IPsec tunnel may operate based on outdated settings, unaware of the updated network context.

[0015] The IKE protocol implements mechanisms for an IKE peer to detect issues caused by mismatched operational parameters, IP addresses, or the like. However, these mechanisms are implemented at the IKE layer and, therefore, cannot typically be used by an IKE peer to determine the operational status and reachability of the IPsec SA. For example, an IKE peer sends Internet Control Message Protocol (ICMP) pings, Dead Peer Detection (DPD) messages, or a combination thereof to another IKE (remote) peer. ICMP pings are used by the IKE peer to ensure that the underlying IKE path is functioning and that the other IKE peer is reachable. DPD messages are used by the IKE peer to detect failures in the other IKE peer. Conventionally, the IKE peer sends these ICMP pings or DPD messages to another IKE peer via the IKE SA (i.e., outside of the IPsec SA and IPsec tunnel). In other words, the IKE peer can only determine the status and reachability of the other IKE peer and not that of the IPsec framework. Therefore, conventional mechanisms do not provide for an IKE peer to efficiently and effectively determine the status and reachability of the IPsec SA or IPsec tunnel.

[0016] As such, the following describes embodiments of systems and methods for a network device, such as an IKE peer, to efficiently and effectively determine the status and reachability of an IPsec SA or IPsec tunnel. As described in greater detail below, a first network device establishes a secure connection with a second network device over a network, such as a cellular (3GPP) network or a non-cellular (non- 3GPP) network. The secure connection, in at least some embodiments, is established using IKE and IPsec protocols. In these embodiments, the first network device and the second network device are referred to as IKE endpoints or IKE peers. To establish the secure connection, the first network device and the second network negotiate an IKE SA. The IKE SA establishes a secure and authenticated channel that facilitates the negotiation of security parameters and the exchange of cryptographic keys, ensuring the integrity and confidentiality of this negotiation process. After the IKE SA has been negotiated, the first network device and the second network negotiate the IPsec SAs, such as Child SAs, one for inbound traffic and one for outbound traffic. The IPsec SAs are security agreements between the first network device and the second network device defining cryptographic parameters and protocols to secure data packets within an IPsec tunnel.

[0017] After successful negotiation of the IPsec SAs, an I Psec tunnel is established using the parameters defined in the I Psec SAs. The first network device and the second network device use the I Psec tunnel to securely transmit data between each other. In at least some embodiments, the establishment of the IPsec tunnel acts as a trigger condition for the first network device to perform a first or initial reachability procedure. For example, the first network device sends probe messages, such as ICMP pings or DPD messages, to the second network device directly within the IPsec tunnel. In at least some embodiments, the first network device sends the probe messages through the IPsec tunnel immediately (e.g., without an active or intentional delay on the part of the first network device) after the IPsec tunnel has been established.

[0018] The probe messages are sent from the first network device to the second network device using an IPsec packet, which encapsulates and encrypts the probe messages. The second network device receives and decrypts the IPsec packet. If the second network device is configured to process probe messages, the second network device sends a reply probe message to the first network device through the IPsec tunnel. In response to receiving a reply probe message, the first network device determines that the second network device is configured to respond to probe messages through the IPsec tunnel. However, in some instances, the second network device is configured to not process probe messages for reasons such as, security, resource conservation, network stability, compliance, or the like. In these configurations, the second network device does not send a reply probe message to the first network device. In response to not receiving a reply probe message, the first network device determines that the second network device is not configured to respond to probe messages through the IPsec tunnel. The first network device can have high confidence in this determination because the probe messages were sent through the IPsec tunnel within a minimal amount of time after the IPsec tunnel was established, which reduces the likelihood that a change in operational parameters or addresses was the cause for not receiving the reply probe messages.

[0019] By performing the first reachability procedure, the first network device is able to determine the adaptability and configuration of the second network device basedon whether the second network device appropriately responds to the probe messages through the IPSec tunnel. Stated differently, the first reachability procedure enables the first network device to determine if the second network device can respond to probe messages through the IPsec tunnel. Based on the first reachability procedure, if the first network device determines that the second network device is not configured to respond to probe messages through the IPsec tunnel, the first network device implements one or more conventional mechanisms for determining the reachability outside the IPsec tunnel, either through the IKE SA or independently of it.

[0020] However, if the first network device determines that the second network device is configured to respond to probe messages through the IPsec tunnel, the first network device proceeds to perform a second reachability procedure when it becomes suspicious that the IPsec tunnel may not be reachable. In other words, the first network device performs a second reachability procedure when it determines or suspects that the I Psec tunnel is not functioning correctly. For example, similar to the first reachability procedure, the first network device sends one or more probe messages to the second network device directly through the IPsec tunnel using one or more IPsec packets. Given that the first network device previously confirmed that the second network device is able to send probe messages through the IPsec tunnel, if the second network device does not respond with a reply probe message, the first network device determines that an issue exists with the IPsec tunnel instead of, for example, the second device being configured to block probe messages. The first network device then takes one or more IPsec recovery actions, such as performing a new IKE negotiation process to re-establish the security parameters and create new Child SAs for the IPsec tunnel.

[0021] For ease of illustration, the following techniques are described in one or more example contexts in which network devices are part of a non-cellular network such as a Wireless Local Area Network (WLAN), a cellular network such as a Fifth Generation (5G) New Radio (NR) standard network, a combination thereof, or the like. However, it should be understood that the present disclosure is not limited to the example networks described herein, but rather, the techniques described hereincan be applied to any network configurations, architectures, or environments capable of implementing secure connections between two or more network devices using, for example, the IKE and IPsec protocols or their equivalents.

[0022] FIG. 1 illustrates a network environment 100 implementing network devices configured to perform reachability procedures for IPsec SAs in accordance with at least some embodiments. As shown in FIG. 1 , the network environment 100 includes multiple network devices 102 (illustrated as network device 102-1 and network device 102-2) that are communicatively coupled by one or more networks 104. It should be understood that the number of network devices 102 shown in FIG.1 is for illustration purposes only. Examples of network devices 102 include a laptop computer, a desktop computer, a tablet computing device, a smartwatch, a server, a VPN endpoint (client or server) a router, a firewall device, a user equipment (UE) device (e.g., a mobile phone, a laptop computer, a desktop computer, a tablet computing device, a smartwatch, a vehicle, or the like), a base station (BS), a core network, an IP Multimedia System (IMS), or the like. Examples of a network 104 include a mobile cellular (3GPP) network such as a 5G NR standard network (e.g., 3GPP Release 15, 3GPP Release 16, 3GPP Release 17, etc.), a non-cellular (non- 3GPP) network such as a WLAN network (e.g., a Wi-Fi network), or the like. In at least some embodiments, at least one of the network devices 102 is a client device, and at least one other network device 102 is a server device.

[0023] FIG. 2 illustrates one example of a mobile cellular network 200. In this example, at least one of the network devices 102-1 is a user equipment (UE) device 202, and the other network device 102-2 is another UE device, a component within the mobile cellular network 200, or a network device 230 connected to the cellular network 200 via an external network 222, such as the Internet, or the like. A UE device 202 within the mobile cellular network 200 is configured to communicate with one or more base stations (BSs) 204 (illustrated as BS 204-1 and BS 204-2) through one or more wireless communication links 206 (illustrated as wireless links 206-1 and 206-2). The UE device 202, in at least some embodiments, includes any of a variety of wireless communication devices, such as a cellular phone, a cellular-enabled tablet computer or cellular-enabled notebook computer, a cellular-enabled wearabledevice, an automobile, or other vehicle employing cellular services (e.g., for navigation, provision of entertainment services, in-vehicle mobile hotspots, etc.), and so on.

[0024] In at least some embodiments, the UE device 202 employs a single RAT 208. In other embodiments, the UE device 202 is a multi-mode UE device that employs multiple RATs 208 (illustrated as RAT 208-1 and RAT 208-2). Examples of multiple RATs include cellular-based RATs, such as a 3GPP Long-Term Evolution (3GPP LTE) RAT, a 3GPP Fifth Generation New Radio (5G NR) RAT, a Wi-Fi RAT, and the like. It should be understood that although FIG. 2 only shows the UE device 202 implementing two different RATs 208, the UE device 202, in at least some embodiments, implements three or more different RATs 208. In at least some embodiments, one or more RAT modules 210 (illustrated as RAT module 210-1 and RAT module 210-2) manage the RATs 208 and enable communication between the UE device 202 and the radio access technology of the network 200. The one or more RAT modules 210, in at least some embodiments, include one or more of a modem chipset(s) of the UE device 202, a protocol stack(s), driver software, or the like.

[0025] In at least some embodiments, the BSs 204 are implemented in a macrocell, microcell, small cell, picocell, and the like, or any combination thereof. Examples of base stations 204 include an Evolved Universal Terrestrial Radio Access Network Node B (E-UTRAN Node B), Evolved Node B (eNodeB or eNB), Next Generation (NG or NGEN) Node B (gNode B or gNB), and so on. The BSs 204 communicate with the UE device 202 via the wireless links 206, which are implemented using any suitable type of wireless link. The wireless links 206, in at least some embodiments, include a downlink of data and control information communicated from the base stations 204 to the UE device 202, an uplink of data and control information communicated from the UE device 202 to the BSs 204, or both. In at least some embodiments, the wireless links 206 (or bearers), such as data radio bearers (DRBs) and signal radio bearers (SRBs), are implemented using any suitable communication protocol or standard, or combination of communication protocols or standards, such as 3GPP 4G LTE, 5G NR, and so on.

[0026] The BSs 204 collectively form a Radio Access Network (RAN) 212, such as an E-UTRAN or 5G NR RAN. The BSs 204 are connected to a core network (CN) 214 (illustrated as CN 214-1 and CN 214-2) via control-plane and user-plane interfaces through one or more links 216 (illustrated as link 216-1 and link 216-2). Depending on the configuration of the mobile cellular network 200, the core network 214 is either an Evolved Packet Core (EPC) network 214-1 or a 5G Core Network (5GC) 214-2. For example, in an E-UTRAN configuration or a 5G non-standalone (NSA) EN-DC configuration, the core network 214 is an EPC network 214-1 that includes, for example, a Mobility Management Entity (MME) 218, a Serving Gateway (SGW) 220, and a Packet Data Network Gateway (PGW) 222. In a 5G standalone (SA) configuration or an NSA NE-DC or NGEN-DC configuration, the core network 214 is a 5GC network 214-2. The 5GC 214-2 includes, for example, an Access and Mobility Management function (AMF) 224, a User Plane Function (UPF) 226, and a Session Management Function (SMF) 228.

[0027] Referring again to FIG. 1 , the network devices 102 establish a secure connection 106 between each other using, for example, IKE and IPsec protocols. The IKE protocol is responsible for establishing and managing security associations (SAs) between IKE peers, such as the first network device 102-1 and the second network device 102-2. The IKE protocol handles the exchange of IKE messages, negotiates security parameters, and creates Child SAs for the IPsec tunnel. The IPSec protocol provides secure communication over IP networks. The IPsec protocol encapsulates data packets within IPsec packets, encrypts and decrypts data using algorithms negotiated during IKE, and verifies the integrity and authenticity of data packets. In at least some embodiments, the network 104 implements an IKE server (not shown) and an IPsec server (not shown), which, in some embodiments, are part of the same network device 102 or different network devices 102. In these embodiments, a network device 102 acting as an IKE client securely connects to another network device 102 through the IKE server and IPsec server. In other embodiments, two or more network devices 102 establish a direct secure connection between each other without the IKE server and the IPsec server.

[0028] Each network device 102, in at least some embodiments, includes a network security protocol stack 108, such as an IPSec stack, an IKE stack, a combination thereof, or the like. In at least some embodiments, each network security protocol stack 108 (illustrated as network security protocol stack 108-1 and network security protocol stack 108-2) includes an IKE client 110 (illustrated as IKE client 110-1 and IKE client 110-2), an IKE manager 112 (illustrated as IKE manager 112-1 and IKE manager 112-2), an SA manager 114 (illustrated as SA manager 114-1 and SA manager 114-2), an IPsec packet processor 116 (illustrated as IPsec packet processor 116-1 and I Psec packet processor 116-2), and an I Psec tunnel manager 118 (illustrated as IPsec tunnel manager 118-1 and IPsec tunnel manager 118-2). It is noted that the number of components of the network devices 102 may vary. It is also noted that, in at least some embodiments, the network devices 102 includes other components not shown in FIG. 1 , and the network devices 102, in at least some embodiments, are structured differently than shown in FIG. 1.

[0029] The IKE client 110 is responsible for initiating and managing IKE negotiations with other IKE peers and handles the exchange of IKE messages, negotiates security parameters, and creates Child SAs. The IKE manager 112 manages IKE peer relationships and coordinates the activities of the IKE Client 110 and other IKE-related components. In at least some embodiments, the IKE manager 112 maintains a list of available IKE peers, handles peer authentication, and triggers rekeying when necessary. The SA manager 114 manages the IPsec SAs, which are the security agreements between IKE peers that define the encryption algorithms, authentication protocols, and key management schemes for data packets within the IPsec tunnel. The IPsec packet processor 116 intercepts and processes data packets that are to be sent or received over the IPsec tunnel. The IPsec packet processor 116 applies encryption and authentication algorithms specified by the IPsec SAs and also handles packet fragmentation and reassembly. The IPsec tunnel manager 118 monitors the status of IPsec tunnels and manages their lifecycle. The IPsec tunnel manager initiates tunnel establishment, handles tunnel rekeying, and detects and responds to tunnel failures. The network security protocol stack 108, in at least some embodiments, includes other components or different components than those illustrated in FIG. 1 . For example, the network securityprotocol stack 108 includes an IKE daemon (not shown), which is a background process that continuously monitors for IKE messages and triggers the appropriate actions when necessary. The IKE daemon listens for incoming IKE messages, handles retransmissions, and manages the overall IKE state.

[0030] As described above, an IKE peer, such as the first network device 102-1 or the second network device 102-2, may change operational parameters of the secure connection 106, such as IPSec tunnel rules or IP addresses, without informing the other IKE peer or the IPsec SA. Therefore, an IKE message may be transmitted using the updated operational parameters while the IPsec SA is operating according to different operational parameters, which results in communication errors, security vulnerabilities, or the like. Therefore, one or more of the network devices 102 acting as an IKE peer employs an IPsec reachability mechanism 120 (illustrated in FIG. 1 and FIG. 2 as IPsec reachability mechanism 120-1 and IPsec reachability mechanism 120-2) for enabling I KE / IPsec synchronization and IPsec framework (e.g., IPsec SAs and IPsec tunnel) reachability detection. In the examples shown in FIG. 1 and FIG. 2, the IPsec reachability mechanism 120 is implemented within the IPsec tunnel manager 118. However, in other embodiments, the IPsec reachability mechanism 120 is separate from the I Psec tunnel manager 118.

[0031] In at least some embodiments, when the IPsec reachability mechanism 120 of the first network device 102-1 detects inception of an IPsec SA or the establishment of an IPsec tunnel with the second network device 102-2, the IPsec reachability mechanism 120-1 of the first network device 102-1 performs a first IPsec reachability procedure to determine if the second network device 102-2 is able to respond to probe messages, such as ICMP pings or DPD messages, directly through the IPsec tunnel. If so, when the first network device 102-1 suspects an issue with the IPsec SA or IPsec tunnel, the first network device 102-1 performs a second IPsec reachability procedure by sending one or more probe messages to the second network device 102-2 directly through the IPsec tunnel to verify the operational status of the I Psec SA or I Psec tunnel. If the second network device 102-2 does not respond to the probe messages, the first network device 102-1 is able to determine there is an issue with the IPsec tunnel or one of its IPsec SAs, given that the firstnetwork device 102-1 previously confirmed that the second network device 102-2 is able to process and respond to probe messages received through the IPsec tunnel.

[0032] FIG. 3 illustrates various example modes employed singularly or in various combinations by a network device 102 as part of the IPsec reachability mechanism 120 in accordance with at least some embodiments. In at least some embodiments, these modes include a first reachability procedure mode 302 that is triggered by inception of an IPsec SA or establishment of an IPsec tunnel, an IPsec tunnel monitoring mode 304, and a second reachability procedure mode 306 triggered by the behavior, or monitoring, of the IPsec tunnel. During the first reachability procedure mode 302, the IPsec reachability mechanism 120 monitors for the inception of an IPsec SA (including Child SAs) or IPsec tunnel. The inception of an IPsec SA or IPsec tunnel triggers the IPsec reachability mechanism 120 to perform a first reachability procedure. During the first reachability procedure, the IPsec reachability mechanism 120 sends probe messages, such as ICMP pings or DPD messages, to the second network device 102-2 directly through the IPsec tunnel using one or more IPsec packets.

[0033] The second network device 102-2 receives and decrypts the IPsec packets. If the second network device 102-2 is configured to process probe messages, the second network device 102-2 sends a reply probe message to the first network device 102-1 through the IPsec tunnel. In response to receiving a reply probe message, the IPsec reachability mechanism 120 determines that the second network device 102-2 is configured to respond to probe messages through the IPsec tunnel. However, in some instances, the second network device 102-2 is configured to not process probe messages for reasons such as, security, resource conservation, network stability, compliance, or the like. In these configurations, the second network device 102-2 does not send a reply probe message to the first network device 102-1 . In response to not receiving a reply probe message, the IPsec reachability mechanism 120 determines that the second network device 102-2 is not configured to respond to probe messages through the IPsec tunnel, and the IPsec reachability mechanism 120 does not implement the IPsec tunnel monitoring mode 304 or the second reachability procedure mode 306.

[0034] However, if the IPsec reachability mechanism 120 determines that the second network device 102-2 is configured to respond to probe messages through the IPsec tunnel, the IPsec reachability mechanism 120 implements the IPsec tunnel monitoring mode 304. During this mode, the IPsec reachability mechanism 120 monitors for any indications, such as unusual or unexpected activity, of a problem with the IPsec SA or IPsec tunnel. An example of this unexpected / unusual activity includes not receiving data packets (e.g., IPsec packets) within a threshold amount of time. If the IPsec reachability mechanism 120 detects or suspects indications of a problem or issue with the IPsec SA or IPsec tunnel, the IPsec reachability mechanism 120 implements the second reachability procedure mode 306. It should be understood that the terms “problem”, “issue”, and their variations as used herein refer to a problem or issue that has occurred, is currently occurring, or may potentially occur with the IPsec SA or IPsec or related component

[0035] During the second reachability procedure mode 306, the IPsec reachability mechanism 120 sends one or more probe messages to the second network device 102-2 directly through the IPsec tunnel to verify the operational status of the IPsec tunnel. Given that the IPsec reachability mechanism 120 previously confirmed that the second network device 102-2 is able to send probe messages through the IPsec tunnel, if the second network device 102-2 does not respond with a reply probe message, the IPsec reachability mechanism 120 determines that an issue exists with the IPsec SA or IPsec tunnel instead of, for example, the second device being configured to block probe messages. The network security protocol stack 108-1 of the first network device 102-1 is then able to perform one or more recovery actions, such as performing a new IKE negotiation process to re-establish the security parameters and create new Child SAs for the IPsec tunnel.

[0036] FIG. 4 illustrates an example device diagram of a network device 400 (also referred to herein as “processing device 400”), such as the network devices 102 of FIG. 1 and FIG. 2, configured to implement the IPSec reachability detection techniques described herein in accordance with some embodiments. Note that the depicted hardware configuration represents the processing components most directly related to establishing a secure connection with another network device using IKEand IPsec protocols and omits certain components well-understood to be frequently implemented in such processing devices, such as displays, peripherals, power supplies, and the like. Further, although the hardware configuration is depicted as being located at a single component, the functionality, and thus the hardware components, of the network device 400 instead can be distributed across multiple infrastructure components or nodes and can be distributed in a manner to perform the functions of one or more embodiments. Also, the network device 400 includes one or more additional or fewer components than illustrated in FIG. 4.

[0037] In at least some embodiments, the network device 400 is a desktop computer, a server, a portable computing device, a cloud-based computing device, or any other processing device capable of implementing one or more of the techniques described herein. The network device 400, in at least some embodiments, includes one or more processors 402, one or more network interface(s) 404, memory / storage 406, and the like. The processor(s) 402 includes, for example, one or more central processing units (CPUs), graphics processing units (GPUs), machine-learning (ML) accelerator, tensor processing units (TPUs) or other application-specific integrated circuits (ASIC), or the like. The network interface(s) 404 enables the network device 400 to communicate over one or more networks, such as network 104. The memory / storage 408, in at least some embodiments, includes one or more computer-readable media that include any of a variety of media used by electronic devices to store data and / or executable instructions, such as random-access memory (RAM), read-only memory (ROM), caches, Flash memory, solid-state drive (SSD) or other mass-storage devices, and the like. For ease of illustration and brevity, the memory / storage 406 is referred to herein as “memory 406” in view of the frequent use of system memory or other memory to store data and instructions for execution by the processor 402, but it will be understood that reference to “memory 406” shall apply equally to other types of storage media unless otherwise noted. The one or more memories 406 of the network device 400 store one or more sets of executable software instructions and associated data that manipulate the processor(s) 402 and other components of the network device 400 to perform the various functions attributed to the network device 400. The sets of executable software instructions include, for example, an operating system (OS) andvarious drivers (not shown), and various software applications. The sets of executable software instructions further include the network security protocol stack 108 and its components such as the IKE client 110, the IKE manager 112, the SA manager 114, the IPsec packet processor 116, and the IPsec tunnel manager 118 described above with respect to FIG. 1 . In the example shown in FIG. 4, the IPsec tunnel manager 118 implements the IPsec reachability mechanism 120 described above with respect to FIG. 3. Although the network security protocol stack 108 is illustrated as residing in the memory 406, in other embodiments, one or more of the components of the network security protocol stack 108 are implemented as circuitry or hardware.

[0038] FIG. 5 illustrates another example device diagram of a network device, such as the UE device 202 of FIG. 2. In at least some embodiments, the device diagram describes a UE device 202 that implements the IPSec reachability detection techniques described herein. The UE device 202 may include additional functions and interfaces that are omitted from FIG. 5 for the sake of clarity. The UE device 202, in at least some embodiments, includes antennas 502, a radio frequency (RF) front end 504, and one or more RF transceivers 506 (e.g., a 3GPP 4G LTE transceiver 506-1 and a 5G NR transceiver 506-2) for communicating with one or more base stations 204 in a RAN 212, such as a 5G RAN, an E-UTRAN, a combination thereof, and so on. The RF front-end 504, in at least some embodiments, includes a transmitting (Tx) front end 504-1 and a receiving (Rx) front end 504-2. The Tx front end 504-1 includes components such as one or more power amplifiers (PA), drivers, mixers, filters, and so on. The Rx front end 504-2 includes components such as low-noise amplifiers (LNAs), mixers, filters, and so on. The RF front end 504, in at least some embodiments, couples or connects the one or more transceivers 506, such as the LTE transceiver 506-1 and the 5G NR transceiver 506- 2, to the antennas 502 to facilitate various types of wireless communication.

[0039] In at least some embodiments, the antennas 502 of the UE device 202 include an array of multiple antennas configured similarly to or different from each other. The antennas 502 and the RF front end 504, in at least some embodiments, are tuned to or are tunable to one or more frequency bands, such as those definedby the 3GPP LTE, 3GPP 5G NR, IEEE wireless local area network (WLAN), IEEE wireless metropolitan area network (WMAN), or other communication standards. In at least some embodiments, the antennas 502, the RF front end 504, the LTE transceiver 506-1 , and the 5G NR transceiver 506-2 are configured to support beamforming (e.g., analog, digital, or hybrid) or in-phase and quadrature (l / Q) operations (e.g., I / Q modulation or demodulation operations) for the transmission and reception of communications with one or more base stations 204. By way of example, the antennas 502 and the RF front end 504 operate in sub-gigahertz bands, sub-6 GHz bands, above 6 GHz bands, or a combination of these bands defined by the 3GPP LTE, 3GPP 5G NR, or other communication standards.

[0040] In at least some embodiments, the antennas 502 include one or more receiving antennas positioned in a one-dimensional shape (e.g., a line) or a two- dimensional shape (e.g., a triangle, a rectangle, or an L-shape) for implementations that include three or more receiving antenna elements. While the one-dimensional shape enables the measurement of one angular dimension (e.g., an azimuth or an elevation), the two-dimensional shape enables two angular dimensions to be measured (e.g., both azimuth and elevation). Using at least a portion of the antennas 502, the UE device 202 can form beams that are steered or un-steered, wide or narrow, or shaped (e.g., as a hemisphere, cube, fan, cone, or cylinder). The one or more transmitting antennas may have an un-steered omnidirectional radiation pattern or may produce a wide steerable beam. Either of these techniques enables the UE device 202 to transmit a radio signal to illuminate a large volume of space. In some embodiments, the receiving antennas generate thousands of narrow steered beams (e.g., 2000 beams, 4000 beams, or 6000 beams) with digital beamforming to achieve desired levels of angular accuracy and angular resolution.

[0041] The UE device 202, in at least some embodiments, includes one or more sensors 508 implemented to detect various properties such as one or more of temperature, supplied power, power usage, battery state, or the like. Examples of sensors include a thermal sensor, a battery sensor, a power usage sensor, and so

[0042] The UE device 202 also includes at least one processor 510. The processor 510, in at least some embodiments, is a single-core processor or a multiple-core processor composed of a variety of materials, such as silicon, polysilicon, high-K dielectric, copper, and so on. In at least some embodiments, the processor 510 is implemented at least partially in hardware, including, for example, components of an integrated circuit or a system-on-a-chip (SoC), a digital-signal-processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), a complex programmable logic device (CPLD), other implementations in silicon or other hardware, or a combination thereof.

[0043] Examples of the processor(s) 510 include a communication processor, an application processor, microprocessors, DSPs, controllers, and so on. A communication processor, in at least some embodiments, is implemented as a modem baseband processor, software-defined radio module, configurable modem (e.g., multi-mode, multi-band modem), wireless data interface, wireless modem, or so on. In at least some embodiments, a communication processor supports one or more of data access, messaging, or data-based services of a wireless network, as well as various audio-based communication (e.g., voice calls). An application processor, in at least some embodiments, provides computing resources to applications executing on the UE device 202. For example, an application provides a self-contained operating environment that delivers system capabilities (e.g., graphics processing, memory management, and multimedia processing) to support applications executing on the UE device 202.

[0044] The UE device 202 further includes a non-transitory computer-readable storage media 512 (CRM 512). The computer-readable storage media described herein excludes propagating signals. The CRM 512, in at least some embodiments, includes any suitable memory or storage device such as random-access memory (RAM), static RAM (SRAM), dynamic RAM (DRAM), non-volatile RAM (NVRAM), read-only memory (ROM), or Flash memory useable to store device data 514 of the UE device 202. In at least some embodiments, the device data 514 includes user data, multimedia data, beamforming codebooks, applications 516, a user interface(s) 518, an operating system of the UE device 202, and so on, which are executable bythe processor(s) 510 to enable user-plane communication, control-plane signaling, and user interaction with the UE device 202. The user interface 518, in at least one embodiment, is configured to receive inputs from a user of the UE device 202. In at least some embodiments, the user interface 518 includes a graphical user interface (GUI) that receives the input information via a touch input. In other instances, the user interface 518 includes an intelligent assistant that receives the input information via an audible input or speech. Alternatively, or additionally, the operating system of the UE device 202 is maintained as firmware or an application on the CRM 512 and executed by the processor(s) 510.

[0045] The CRM 512, in at least some embodiments, further includes either or both of a communication manager 520 and the network security protocol stack 108. Alternatively, or additionally, either or both of the communication manager 422, the network security protocol stack 108 or one or more of the network security protocol stack components, in at least some embodiments, are implemented in whole or part as hardware logic or circuitry integrated with or separate from other components of the UE device 202. In at least some embodiments, the communication manager 520 configures the RF front end 504, the LTE transceiver (modem) 506-1 , the 5G NR transceiver (modem) 506-2, or a combination thereof to perform one or more wireless communication operations.

[0046] The network security protocol stack 108 includes the IKE client 110, the IKE manager 112, the SA manager 114, the IPsec packet processor 116, and the IPsec tunnel manager 118 described above with respect to FIG. 1 . In the example shown in FIG. 5, the IPsec tunnel manager 118 implements the IPsec reachability mechanism 120 described above with respect to FIG. 3.

[0047] FIG. 6 is a transactional diagram illustrating a sequence of operations performed by the network devices 102 for implementing the IPSec reachability detection techniques described herein. In the example shown in FIG. 6, the first network device 102-1 and the second network device 102-2 perform a procedure 602 involving IKE initiation, discovery and establishing an IKE SA 601 (IKE Phase 1 procedure). For example, the first network device 102-1 , acting as the initiator, sends an IKE SA request message to the second network device 102-2, acting asthe responder. The SA request message includes, for example, the first network device’s 102-1 identity (e.g., IP address, hostname, or domain name), supported algorithms, and proposed security parameters. The second network device 102-2 receives the IKE SA request message and analyzes the proposed security parameters. If a compatible set of algorithms is found, the second network device 102-2 sends an IKE SA initiation message to the first network device 102-1. The IKE SA initiation message includes the second network device’s 102-2 identity (e.g., IP address, hostname, or domain name), selected algorithms, and proposed security parameters.

[0048] After the first network device 102-1 receives the IKE SA initiation message from the second network device 102-2, both network devices 102 exchange nonces, which are random numbers used to generate encryption keys and prevent replay attacks. The network devices 102 authenticate each other using a chosen authentication method, such as pre-shared keys, digital certificates, or public key cryptography. The network devices 102 also negotiate an encryption algorithm and a hashing algorithm to be used for IKE messages and exchange Diffie-Hellman keys that will be used to derive a shared secret key. The first network device 102-1 and the second network device 102-2 each derive a shared key from the Diffie-Hellman keys. This shared key will be used to encrypt and decrypt IKE messages. Then, the network devices 102 send an IKE SA authentication message, including the shared secret key and authentication data, to each other confirming successful authentication and key derivation. At this point, the IKE SA 601 is established.

[0049] After the IKE SA has been established, the first network device 102-1 and the second network device 102-2 perform a procedure 604 to establish IPsec SAs, including Child SAs, and an IPSec tunnel. For example, using the secure channel provided by the IKE SA 601 , the first network device 102-1 sends an IKE SA initiation message to the second network device 102-2 to initiate the IKE Phase 2 negotiation. The first network device 102-1 also sends an IKE SA request message to the second network device 102-2 requesting creation of a Child SA. The IKE SA request message specifies, for example, the traffic type, encryption algorithm, authentication protocol, and key lifetime for the Child SA. The second network device 102-2 sendsa response message back to the first network device 102-1 acknowledging the Child SA creation request. The second network device 102-2 reviews the IKE SA request message to determine if the specified parameters are acceptable. If not, the network devices 102 continue to negotiate until they agree on the parameters. If the second network device 102-2 agrees with the Child SA parameters proposed by the first network device 102-1 , the second network device 102-2 sends an IKE SA authentication message to the first network device 102-1 and an IPsec SA is created including two Child IPsec SAs 603 (illustrated as Child SA 603-1 and Child SA 603- 2), one for inbound traffic and one for outbound traffic. The network devices 102 also exchange the necessary information to establish the IPsec tunnel, including IP addresses, traffic selectors, and Security Association Identifier (SAID). At this point, the IPsec tunnel 605 is established and the Child SAs 603 define security parameters for the traffic that is protected by the IPsec tunnel 605. The IPsec tunnel 605 allows the network devices 102 to securely send data. The data packets transmitted by the network devise 102 are now encapsulated within IPsec packets, using the agreed-upon encryption algorithms and authentication protocols.

[0050] The IPsec tunnel manager 118 (or another component) of the first network device 102-1 implementing the IPsec reachability mechanism 120 monitors the IKE process and detects the inception of the Child SAs 603 or the establishment of the IPsec tunnel 605. When the IPsec tunnel manager 118 detects one of these trigger events, the IPsec tunnel manager 118 performs a first IPsec reachability procedure. For example, the I Psec tunnel manager 118 sends one or more probe messages 606 (illustrated as probe messages 606-1 ), such as ICMP pings or DPD messages, to the second network device 102-2 directly within the IPsec tunnel 605 via the Child SA 603-1 . In at least some embodiments, the IPsec tunnel manager 118 sends the probe messages 606-1 through the IPsec tunnel 605 immediately after the Child SAs 603 have been created, or the IPsec tunnel 605 has been established. Here, the term “immediately” means without active or intentional delay, after a nominal time has passed since the Child SAs 603 have been created or the IPsec tunnel 605 has been established, or within a threshold period of time. In one example, when the IPsec tunnel manager 118 sends the probe messages 606-1 without an active delay, the probe message 606-1 is sent in 20 seconds or less after the Child SAs 603 havebeen created or the IPsec tunnel 605 has been established, although other time frames are applicable.

[0051] The probe messages 606-1 are sent from the first network device 102-1 to the second network device 102-2 using an IPsec packet, which encapsulates and encrypts the probe messages 606-1 . The second network device 102-2 receives and decrypts the IPsec packet, which returns the probe messages 606-1 to their unencrypted form. If the second network device 102-2 is configured to process probe messages 606-1 , the second network device 102-2 sends one or more reply probe messages 608 (illustrated as reply probe messages 608-1 ) to the first network device 102-1 through the IPsec tunnel 605 via the Child SA 603-2. In response to the first network device 102-1 receiving a reply probe message 608-1 , the IPsec tunnel manager 118 determines that the second network device 102-2 is configured to respond to probe messages 606-1 through the IPsec tunnel 605.

[0052] In some instances, the second network device 102-2 is configured to not process probe messages 606. In these configurations, the second network device 102-2 does not send a reply probe message 608-1 to the first network device 102-1 . In response to the first network device 102-1 not receiving a reply probe message 608-1 , the IPsec tunnel manager 118 determines that the second network device 102-2 is not configured to respond to probe messages 606 through the IPsec tunnel 605. The IPsec tunnel manager 118 can have high confidence in this determination because the probe messages 606-1 were sent through the IPsec tunnel 605 within a minimal amount of time after the IPsec tunnel 605 was established, which reduces the likelihood that a change in operational parameters or addresses was the cause for not receiving a reply probe message 608-1 .

[0053] By performing the first reachability procedure, the IPsec tunnel manager 118 is able to determine the adaptability and configuration of the second network device 102-2 based on whether the second network device 102-2 appropriately responds to the probe messages 606-1 through the IPSec tunnel 605. Based on the first reachability procedure, if the IPsec tunnel manager 118 determines that the second network device 102-2 is not configured to respond to probe messages 606 through the IPsec tunnel 605, the network security protocol stack 108 of the first networkdevice 102 implements one or more conventional mechanisms for determining the reachability outside the IPsec tunnel, either through the IKE SA or independently of it.

[0054] However, if the IPsec tunnel manager 118 determines that the second network device 102-2 is configured to respond to probe messages 606 through the IPsec tunnel 605, the IPsec tunnel manager 118 performs a monitoring process 610. During this monitoring process 610, the IPsec tunnel manager 118 monitors the IPsec tunnel 605 for indications, such as any unusual or unexpected activity, of a problem with the IPsec SA or IPsec tunnel 605. An example of this unusual / unexpected activity includes not receiving IPsec packets within a threshold amount of time, such as 6 seconds (although other time periods are applicable as well), as indicated by a timer set by the tunnel manager 118 (or another component). One example of a timer is the Tcall timer defined in the Global System for Mobile Communications Association (GSMA) IR.51 , “IMS Profile for Voice, Video and SMS Over Untrusted Wi-Fi Access”, Version 9.0 2021 specification. However, other timers are applicable as well. As described above, problems can occur with the IPsec tunnel 605 as a result of, for example, one of the network devices 102 changing IKE operational parameters or IPsec tunnel rules, performing dynamic address updates, or the like.

[0055] In response to detecting an indicative problem with the IPsec tunnel 605, the IPsec tunnel manager 118 performs a second reachability procedure. During this procedure, the IPsec tunnel manager 118 sends one or more probe messages 606 (illustrated as probe messages 606-2) to the second network device 102-2 through the IPsec tunnel via the Child SA 603-1 , similar to the first reachability procedure. In response to sending the one or more probe messages 606-2, the IPsec tunnel manager 118 determines an operational status 612 of the IPsec framework (also referred to herein as “IPsec framework). Stated differently, the IPsec tunnel manager 118 determines the operational status 612 of the IPsec SAs (e.g., the Child SAs 603), the IPsec tunnel 605, or a combination thereof. For example, if the first network device 102-1 receives one or more reply probe messages 608 (illustrated as reply probe messages 608-2), the IPsec tunnel manager 118 determines the IPsecframework is operational. In response, the first network device 102-1 trusts the IPsec framework and continues to use the IPsec tunnel 605 to transmit data to the second network device 102-2.

[0056] If the second network device 102-2 does not respond with a reply probe message 608-2, the IPsec tunnel manager 118 determines that an issue exists with the IPsec framework. For example, given that the IPsec tunnel manager 118 previously confirmed that the second network device 102-2 is able to send reply probe messages 608 through the I Psec tunnel 605, the I Psec tunnel manager 118 has high confidence that a reply probe message 608-2 was not received due to an issue with the IPsec security framework instead of, for example, the second network device 102-2 being configured to block probe messages. The first network device then takes one or more recovery actions 614, such as performing a new IKE negotiation process to re-establish the security parameters and create new Child SAs for the IPsec tunnel 605 or repeats the IKE processes described above to reestablish the I Psec framework (e.g., new IPSec SAs and a new IPsec tunnel).

[0057] FIG. 7 is a diagram illustrating an example method 700 of a network device 102 performing an IPsec reachability detection process in accordance with at least some embodiments. The processes described below with respect to method 700 have been described above in greater detail with reference to FIG. 1 to FIG. 6. It should be understood that method 700 is not limited to the sequence of operations shown in FIG. 7, as at least some of the operations can be performed in parallel or in a different sequence. Moreover, in at least some embodiments, method 700 can include one or more different operations than those shown in FIG. 7.

[0058] At block 702, the first network device 102-1 establishes an IKE SA 601 with the second network device 102-2 as described above with respect to FIG. 6. At block 704, the first network device 102-1 negotiates IPsec SAs, such as Child SAs 603, with the second network device 102-2, as described above with respect to FIG. 6. At block 706, an IPsec tunnel 605 is established based on the IPsec SA negotiation process.

[0059] At block 708, the IPsec tunnel manager 118 of the first network device 102-1 detects inception of the IPsec SAs or the establishment of the IPsec tunnel 605 and performs a first reachability procedure by sending one or more probe messages 606- 1 , such as ICMP pings or DPD messages, to the second network device 102-2 directly through the IPsec tunnel 605. At block 710, the IPsec tunnel manager 118 determines if a reply probe message(s) 608-1 was received from the second network device 102-2. If a reply probe message 608-1 was not received within a threshold period of time, the IPsec tunnel manager 118 determines that the second network device 102-2 is not configured to process probe messages or is not configured to send probe messages through the IPsec tunnel 605. In at least some embodiments, the first network device 102-1 determines reachability of the IPsec SA outside the IPsec tunnel, either through the IKE SA or independently of it. At block 712, the first network device 102-1 continues operating in a conventional manner.

[0060] At block 714, if the first network device 102-1 receives a reply probe message 608, the IPsec tunnel manager 118 determines that the second network device 102-2 is configured to send probe messages through the IPsec tunnel 605 and monitors the IPsec framework for indications of one or more issues. At block 716, the IPsec tunnel manager 118 determines if an issue with the IPsec framework is suspected or has been detected. If not, the IPsec tunnel manager 118 continues to monitor the IPsec framework for indicative issues. At block 718, if an issue has been detected, the IPsec tunnel manager 118 performs a second reachability procedure by once again sending a probe message(s) 606-2 to the second network device 102-2. At block 720, the IPsec tunnel manager 118 determines if a reply probe message(s) 608-2 was received from the second network device 102-2. At block 722, if a reply probe message 608-2 was not received within a threshold period of time, the IPsec tunnel manager 118 determines that the IPsec framework is experiencing an issue and performs one or more recovery actions 614, as described above. At block 724, if a reply probe message 608-2 is received within a threshold period of time, the IPsec tunnel manager 118 determines that the IPsec framework is operating as expected or operating correctly, and the first network device 102-1 continues transmitting data through the IPsec tunnel 605. The method 700 then returns to, for example, block 714.

[0061] In some embodiments, certain aspects of the techniques described above may be implemented by one or more processors of a processing system executing software. The software comprises one or more sets of executable instructions stored or otherwise tangibly embodied on a non-transitory computer-readable storage medium. The software can include the instructions and certain data that, when executed by the one or more processors, manipulate the one or more processors to perform one or more aspects of the techniques described above. The non-transitory computer-readable storage medium can include, for example, a magnetic or optical disk storage device, solid-state storage devices such as Flash memory, a cache, random access memory (RAM), or other non-volatile memory device or devices, and the like. The executable instructions stored on the non-transitory computer readable storage medium may be in source code, assembly language code, object code, or other instruction format that is interpreted or otherwise executable by one or more processors.

[0062] A computer-readable storage medium may include any storage medium or combination of storage media accessible by a computer system during use to provide instructions and / or data to the computer system. Such storage media can include, but is not limited to, optical media (e.g., compact disc (CD), digital versatile disc (DVD), Blu-Ray disc), magnetic media (e.g., floppy disc, magnetic tape, or magnetic hard drive), volatile memory (e.g., random access memory (RAM) or cache), non-volatile memory (e.g., read-only memory (ROM) or Flash memory), or microelectromechanical systems (MEMS)-based storage media. The computer- readable storage medium may be embedded in the computing system (e.g., system RAM or ROM), fixedly attached to the computing system (e.g., a magnetic hard drive), removably attached to the computing system (e.g., an optical disc or Universal Serial Bus (USB)-based Flash memory), or coupled to the computer system via a wired or wireless network (e.g., network accessible storage (NAS)).

[0063] Note that not all of the activities or elements described above in the general description are required, that a portion of a specific activity or device may not be required, and that one or more further activities may be performed, or elements included, in addition to those described. Still further, the order in which activities arelisted are not necessarily the order in which they are performed. Also, the concepts have been described with reference to specific embodiments. However, one of ordinary skill in the art appreciates that various modifications and changes can be made without departing from the scope of the present disclosure as set forth in the claims below. Accordingly, the specification and figures are to be regarded in an illustrative rather than a restrictive sense, and all such modifications are intended to be included within the scope of the present disclosure.

[0064] Benefits, other advantages, and solutions to problems have been described above with regard to specific embodiments. However, the benefits, advantages, solutions to problems, and any feature(s) that may cause any benefit, advantage, or solution to occur or become more pronounced are not to be construed as a critical, required, or essential feature of any or all the claims. Moreover, the particular embodiments disclosed above are illustrative only, as the disclosed subject matter may be modified and practiced in different but equivalent manners apparent to those skilled in the art having the benefit of the teachings herein. No limitations are intended to the details of construction or design herein shown, other than as described in the claims below. It is therefore evident that the particular embodiments disclosed above may be altered or modified and all such variations are considered within the scope of the disclosed subject matter. Accordingly, the protection sought herein is as set forth in the claims below.

Claims

WHAT IS CLAIMED IS:

1. A method, at a first network device (102-1 ), for determining reachability of anInternet Protocol security (IPsec) framework (601 , 605), comprising: establishing an IPsec tunnel (605) with a second network device (102-2); and sending at least a first probe message (606-1) to the second network device through the IPsec tunnel.

2. The method of claim 1 , wherein the at least first probe message is one of anInternet Control Message Protocol (ICMP) ping or a Dead Peer Detection (DPD) message.

3. The method of claim 1 , wherein sending the at least first probe message to the second network device through the IPsec tunnel comprises: sending the at least first probe message without an active delay by the first network device upon detecting establishment of the IPsec tunnel.

4. The method of claim 1 , further comprising: responsive to receiving a first reply probe message (608-1) from the second network device through the IPsec tunnel, sending at least a second probe message (606-2) through the IPsec tunnel to the second network device when one or more indications of an issue are detected with the IPsec framework.

5. The method of claim 4, further comprising: detecting an issue with the IPsec framework based on at least one of: a determination that a data packet has not been received through the IPsec tunnel within a threshold period of time; or detecting a dynamic address update has been performed.

6. The method of claim 4, further comprising: responsive to receiving a second reply probe message (608-2) from the second network device in response to sending the at least secondprobe message, determining that the IPsec framework is operating correctly.

7. The method of claim 6, further comprising: responsive to determining that the IPsec framework is operating correctly, continuing to transmit data through the IPsec tunnel.

8. The method of claim 4, further comprising: responsive to a second reply probe message having not been received from the second network device in response to sending the at least second probe message, determining that an issue exists with IPsec framework.

9. The method of claim 8, further comprising: responsive to determining that an issue exists with IPsec framework, performing one or more IPsec recovery actions.

10. The method of claim 9, wherein the one or more IPsec recovery actions include re-establishing the IPsec framework with the second network device.11 . The method of claim 1 , wherein sending at least a first probe message is in response to establishing the IPsec tunnel with the second network device.

12. The method of claim 1 , further comprising: responsive to a determination that the second network device is not configured to respond to probe messages, determining a reachability of the second network device outside of the IPsec tunnel.

13. The method of claim 1 , wherein determining the reachability of the second network device comprises: determining the reachability outside of the IPsec tunnel through an Internet Key Exchange (IKE) security association (SA) (601) established for the IPsec tunnel or independent of the IKE SA.determining a reachability of the second network device outside of the IPsec tunnel.

14. A network device (400) configured to determine reachability of an InternetProtocol security (IPsec) framework (601 , 605), the network device comprising: a processor (402); and an network security protocol stack (108) implemented at the processor to perform the method of any of claims 1 to 1315. A user equipment device (202) configured to determine reachability of anInternet Protocol security (IPsec) framework, the user equipment device comprising: one or more radio frequency (RF) modems (506) configured to wirelessly communicate with at least one network (100); at least one processor coupled to the RF antenna interface; and at least one memory (512) storing executable instructions, the executable instructions configured to manipulate at least one of the one or more processors or the one or more RF modems to perform the method of any of claims 1 to 13.

Images