DNS-Based VPN Liveness Check Without Dead Peer Detection
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
VPN tunnel state checking is inadequate in scenarios where Dead Peer Detection (DPD) is unavailable or disabled, leading to potential delays in communication due to inactive VPN tunnels.
Innovation Solution
Implementing a DNS-based VPN liveness check using a timer and DNS PTR requests to verify the VPN tunnel state, with increasing time intervals for retransmissions and a flag to determine the availability of DPD, allowing the VPN client manager to initiate tunnel take-down or re-establishment procedures when the tunnel is deemed inactive.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If Dead Peer Detection (DPD) is used for VPN tunnel liveness checking, then the number of IKE messages is minimized and liveness detection is efficient, but VPN clients or servers may not support DPD or may disable the DPD feature, making liveness checking impossible
Solution Approach 1:
The patent introduces DNS PTR requests as an intermediary mechanism to check VPN tunnel liveness. Instead of relying directly on DPD which may not be supported or enabled, the system uses DNS queries to a server behind the VPN terminator as a mediator to indirectly detect tunnel status. This resolves the contradiction by providing a universal liveness check method that works regardless of DPD support.
Solution Approach 2:
The patent replaces the mechanical IKE message-based DPD mechanism with a DNS-based liveness check. By substituting the protocol-specific DPD mechanism with a generic DNS query mechanism, the system achieves broader compatibility while maintaining the ability to detect tunnel liveness, thus resolving the contradiction between reliability and adaptability.
2Device complexity
If VPN tunnel state is not checked when DPD is unavailable, then system complexity is reduced, but service disruptions occur due to undetected inactive tunnels
Solution Approach 1:
The patent makes the DNS client component perform multiple functions: its original DNS resolution function plus an additional liveness check function by querying a specific server behind the VPN terminator. This multi-functionality allows the system to detect tunnel status without adding separate complex liveness check mechanisms, thus resolving the contradiction between simplicity and reliability.
Solution Approach 2:
The system uses its existing DNS client infrastructure to perform liveness checking, rather than introducing a separate dedicated liveness check mechanism. The DNS client serves itself by utilizing its own capabilities to monitor tunnel health, reducing overall system complexity while maintaining service continuity through reliable tunnel status detection.
3Loss of time
If frequent liveness checks are performed, then tunnel inactivity is detected quickly, but network traffic increases and battery consumption rises on mobile devices
Solution Approach 1:
The patent implements periodic liveness checks through timer mechanisms rather than continuous monitoring. The system schedules DNS queries at appropriate intervals, balancing the need for timely detection of tunnel inactivity with the need to conserve mobile device battery energy. This periodic action resolves the contradiction by providing structured, energy-efficient monitoring.
Solution Approach 2:
The system dynamically adjusts the timing and frequency of liveness checks based on tunnel activity states. When the tunnel is active, checks are performed less frequently; when idle or suspicious, check frequency increases. This parameter adjustment resolves the contradiction between detection speed and energy consumption by adapting the monitoring intensity to actual tunnel conditions.
Data Source
Figure 1
Figure 2
Figure 3
AI summary
A method and apparatus for virtual private network (`VPN') liveness checking, the method, upon expiration of a timer, sending, over a VPN tunnel, a request to a server located behind a terminator of the VPN; checking whether a response to the request is received within a time interval; if a response to the request is received, resetting the timer; and if a response to the request is not received within the time interval, resending the request if a request count is less than a set number of requests; or providing an inactive tunnel indication to a VPN client manager if the request count equals the set number of requests.