QUIC-Based UDP Forwarding for Zero-Trust Network Access
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Current Zero-Trust Network Access (ZTNA) devices only support Transmission Control Protocol (TCP)-based services, limiting the kinds of services that can be accessed.
Innovation Solution
Implementing User Datagram Protocol (UDP) message forwarding through ZTNA devices using QUIC as the underlying protocol, allowing transparent tunneling of UDP traffic without explicit user interaction.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Adaptability or versatility
If ZTNA devices only support TCP-based services, then the device complexity is reduced and ease of operation is improved, but the adaptability or versatility of services that can be accessed is limited
Solution Approach 1:
The patent introduces a protocol translation intermediary that converts UDP packets into TCP-compatible formats. The ZTNA device includes a UDP handler that intercepts UDP packets, wraps them in TCP-style frames with appropriate headers, and forwards them through the existing TCP processing pipeline. This intermediary layer enables UDP service access without requiring the core ZTNA device to natively understand UDP protocols, thus maintaining device simplicity while expanding service adaptability.
Solution Approach 2:
The patent changes the protocol parameter representation by encoding UDP-specific information (source/destination ports, IP addresses) into TCP-compatible header fields. The UDP handler transforms UDP packet parameters into equivalent TCP frame parameters, allowing the existing TCP-based ZTNA infrastructure to process UDP traffic by interpreting it through TCP parameter structures. This parameter transformation enables versatile protocol support while maintaining the original device architecture.
2Adaptability or versatility
If UDP message forwarding is implemented through ZTNA devices, then the adaptability or versatility of services is improved, but the device complexity increases
Solution Approach 1:
The patent segments the UDP forwarding functionality into a separate, modular UDP handler component that operates independently from the core ZTNA device. The handler is divided into distinct functional modules: packet interception, frame wrapping, header insertion, and forwarding. This segmentation allows the complex UDP handling logic to be isolated in a manageable module that can be added or removed without affecting the core device architecture, thus enabling protocol versatility while controlling overall device complexity.
Solution Approach 2:
The UDP handler is designed as a universal interface that can handle multiple UDP-based services through a single unified mechanism. Rather than implementing separate handling logic for each UDP service type, the handler provides a general-purpose UDP-to-TCP translation framework that works across different applications and protocols. This multi-functional approach enables broad service adaptability while minimizing the complexity increase by using a single versatile component rather than multiple specialized ones.
3Productivity
If TCP forwarding is used for all services, then device complexity is minimized, but the overhead and inefficiency for UDP-based services increases
Solution Approach 1:
The patent implements a dynamic protocol selection mechanism where the ZTNA device automatically detects whether incoming traffic is UDP or TCP and applies the appropriate handling path. The UDP handler is activated dynamically when UDP traffic is detected, allowing the system to adapt its complexity level based on the actual traffic type. For UDP services, the specialized handler provides efficient native processing; for TCP services, the standard TCP path is used. This dynamic adaptation optimizes forwarding efficiency while avoiding the permanent overhead of maintaining both protocols simultaneously.
Data Source
AI summary
Zero-trust network access (ZTNA) with user datagram protocol (UDP) message forwarding is disclosed. A forwarding rule is determined based on a destination address associated with a received data traffic packet formatted according to a first protocol (e.g., UDP). A bi-directional tunnel is created to forward the traffic based on the determined forwarding rule. A request is generated over a stream having a corresponding stream identifier within the bi-directional tunnel to establish a connection with a proxy device. The traffic packet payload formatted according to the first protocol is wrapped with at least the stream identifier. The wrapped data traffic packet is forwarded to a client device based on the determined forwarding rule to a destination device corresponding to the stream identifier.