Traceroute Server for Encrypted Tunnel Hop Detection

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Conventional traceroute tools are limited in accurately determining network performance metrics, especially when encountering encrypted tunnels and cloud-based systems, as they fail to detect network hops, packet loss, and latency, and are opaque to proxies or firewalls, leading to incomplete and inaccurate results.

Innovation Solution

The use of traceroute techniques combined with API detection for egress routers and adaptive probing with ICMP, UDP, and TCP protocols to segment network paths, cache traceroute results, and employ reverse tracing to overcome tunnel opacity, enabling comprehensive network hop detection and latency measurement.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Measurement precision

If conventional traceroute tools are used to monitor network paths, then basic network visibility is provided, but accurate detection of network hops, packet loss, and latency through encrypted tunnels is lost

Engineering Contradiction:
Improvenetwork performance metrics detectionVSAvoidnetwork hop details through tunnels
Core Design Contradiction:
Measurement precisionVSLoss of information

Solution Approach 1:

The patent introduces intermediary components including a traceroute server positioned within the tunnel infrastructure and modified traceroute clients that coordinate with this server. The intermediary server receives probe packets, tracks them through tunnel hops, and returns detailed latency and hop information that conventional tools cannot obtain through opaque encrypted tunnels.

Inventive Principle:
Principle #24Intermediary (Mediator)

Solution Approach 2:

The patent segments the tunnel traversal into discrete measurable hops by having the traceroute server identify and report each intermediate hop point within the tunnel. This segmentation allows measurement of latency and packet loss at each individual hop rather than treating the tunnel as a single opaque black box.

Inventive Principle:
Principle #1Segmentation

2Object-affected harmful factors

If encrypted tunnels are used to secure network traffic, then network security is improved, but traceroute tools become opaque and cannot detect network state details

Engineering Contradiction:
Improvenetwork security against sniffingVSAvoidnetwork state through tunnels
Core Design Contradiction:
Object-affected harmful factorsVSDifficulty of detecting and measuring

Solution Approach 1:

The traceroute server acts as a trusted intermediary embedded within the tunnel infrastructure that can observe and measure traffic without breaking encryption. It receives specially formatted probe packets, tracks their journey through the tunnel hops, and returns measurement data without exposing the actual encrypted content.

Inventive Principle:
Principle #24Intermediary (Mediator)

Solution Approach 2:

The patent modifies the traceroute protocol parameters by using TCP protocols with specific port numbers and packet formats that are recognized by the traceroute server. This allows the probes to be distinguished from normal traffic while maintaining encryption, enabling measurement without compromising security.

Inventive Principle:
Principle #35Parameter changes

3Reliability

If conventional traceroute is used to determine destination reachability, then basic connectivity is checked, but accurate latency measurement between hops is not provided

Engineering Contradiction:
Improvedestination reachability determinationVSAvoidlatency between hops
Core Design Contradiction:
ReliabilityVSMeasurement precision

Solution Approach 1:

The traceroute server serves as an intermediary that receives probe packets from the client, forwards them through the network path, and captures return packets. By measuring the time stamps at each stage, it can calculate precise latency between individual hops and provide this detailed timing information back to the client.

Inventive Principle:
Principle #24Intermediary (Mediator)

Solution Approach 2:

The traceroute server performs preliminary actions by pre-positioning itself at various hop points within the tunnel infrastructure. This allows it to immediately capture and time-stamp probe packets as they pass through, enabling accurate latency measurement without adding significant processing delay.

Inventive Principle:
Principle #10Preliminary action

4Adaptability or versatility

If TCP traceroute is used to trace network paths, then tunnel detection capability is improved, but the ability to read destination responses and determine complete path is lost

Engineering Contradiction:
Improvetunnel detection capabilityVSAvoiddestination response information
Core Design Contradiction:
Adaptability or versatilityVSLoss of information

Solution Approach 1:

The traceroute server acts as an intermediary that can read and interpret TCP responses from destinations even when sent through encrypted tunnels. It receives the destination's TCP responses, extracts the necessary information about reachability and path completion, and communicates this back to the client without requiring the client to directly interpret encrypted or obfuscated responses.

Inventive Principle:
Principle #24Intermediary (Mediator)

Data Source

PatentUS11671438B2Detection of latency, packet drops, and network hops through a tunnel by tracing hops therein
Publication Date: 2023.06.06 ZSCALER INC
  • US11671438B2 patent drawing
  • US11671438B2 patent drawing
  • US11671438B2 patent drawing

AI summary

Techniques for using traceroute with tunnels and cloud-based systems for determining measures of network performance are presented. Systems and methods include receiving a request, from a client, for a trace of the tunnel; causing the trace inside the tunnel; obtaining results of the trace inside the tunnel; and sending the results of the trace inside the tunnel to the client so that the client aggregates these details with details from one or more additional legs to provide an overall view of a service path between the client and a destination.