Client-Hello Routing for Multipath VPN and ZTNA Without DNS Complexity
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing VPN and ZTNA technologies face challenges in managing dynamic routing and load balancing in multipath and multi-tunnel secure access systems due to the difficulty in maintaining unique DNS entries and managing IP addresses when using Anycast, leading to imbalanced loads and inefficient data plane session management.
Innovation Solution
The use of client-hello techniques to generate a communication session identifier that includes bits indicating a target routing device, allowing for intelligent routing and load balancing by configuring the routing device to assign a Session-ID or equivalent, enabling rapid setup of encrypted data plane sessions using a Resumed Handshake.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Adaptability or versatility
If traditional DNS-based routing is used for multipath VPN/ZTNA, then routing can be implemented, but the system becomes difficult to manage and maintain due to the need for unique DNS entries
Solution Approach 1:
The patent extracts the routing decision logic from DNS-based name resolution and relocates it to the TLS handshake process. By using the Client Hello message as the routing decision point, the system eliminates the need for complex DNS entry management while maintaining routing flexibility. The routing decision is made at the protocol level rather than at the DNS level, simplifying the overall system architecture.
Solution Approach 2:
The patent introduces the TLS Client Hello message as an intermediary carrier for routing information. Instead of relying on DNS entries to encode routing decisions, the system uses the Client Hello message to convey session identification information that enables intelligent routing. This intermediary approach allows routing flexibility without requiring unique DNS entries for each path.
2Productivity
If multiple data plane sessions are directed to different datacenters for multipathing, then load balancing is improved, but the system complexity increases due to Anycast IP address space sharing
Solution Approach 1:
The patent applies preliminary action by establishing the routing decision before the data plane sessions are fully established. The Client Hello message is used to determine the target datacenter and routing path in advance, allowing the system to prepare and configure multiple data plane sessions efficiently. This preliminary routing decision enables load balancing across different datacenters without increasing operational complexity.
Solution Approach 2:
The patent makes the TLS Client Hello message multi-functional by using it for both cryptographic handshaking and routing decisions. Instead of requiring separate mechanisms for authentication and routing, the system combines these functions into a single protocol message, simplifying the Anycast ecosystem while maintaining efficient load balancing capabilities.
3Adaptability or versatility
If dynamic routing is implemented for multipath sessions, then routing flexibility is improved, but the difficulty of detecting and measuring increases due to managing unique DNS entries
Solution Approach 1:
The patent implements feedback mechanisms through the TLS handshake process, where the Client Hello message contains information about the desired routing path, and the server responds with appropriate routing decisions. This feedback loop enables dynamic routing while providing measurable and detectable routing information through the standardized TLS protocol, eliminating the need for complex DNS-based measurement systems.
Data Source
AI summary
Techniques for utilizing a portion of a communication session identifier (e.g., a Session-ID, an SPI, a CID, a DCID, and/or the like) to indicate a target routing device (e.g., a VPN and/or ZTNA termination device) for establishing control plane session(s) and/or data plane session(s) at wire-speed in a networked computing environment. The routing device(s) of a networked computing environment may generate a communication session identifier and send the communication session identifier to the client device, such that subsequent packets send from the client device may be forwarded to the proper routing device indicated by the communication session identifier for establishment of one or more data plane sessions. Additionally, data plane sessions may be established using a Resumed Handshake rather than a full handshake that is typically required, as Session Resumption utilizes the assigned communication session identifier for mapping.