Network-level traffic analysis

The previous Track 5 modules covered detection at single observation points: DPI on a flow, active probing of an endpoint, fingerprinting at the handshake. This module steps up to the network level — observers with visibility into many flows across many links, who can correlate observations to learn things no single-vantage observer could see. NetFlow analysis, multi-vantage flow correlation, and BGP-aware attacks like RAPTOR all live at this layer.

The core thesis: where you observe traffic matters as much as what you observe. A single-link observer sees one flow's metadata; a multi-link observer can correlate different flows seen at different points in the network. The capabilities scale dramatically with observation breadth. ISPs see lots of their own customers' traffic; transit providers see lots of their own customers' traffic; intelligence services with global telemetry can see significant fractions of all internet traffic.

This module concludes Track 5. We'll cover what NetFlow/IPFIX records preserve and what analyses they enable, the canonical end-to-end flow-correlation attack against Tor, RAPTOR's BGP-routing-based attack and what it implies about the assumption "the network can't see both ends," and the practical operator-mindset shift from "detect this packet" to "correlate these flows." Track 6 will cover the countermeasures — the active-evasion techniques designed against these threats.

Prerequisites

• tor-onion-routing-and-circuit-anonymity — the canonical low-latency anonymity overlay these attacks target.
• traffic-analysis-fundamentals — the per-flow attack-side primitive that network-level extends.
• active-probing-methodology — passive multi-vantage observation often pairs with active confirmation.

Learning objectives

1. Explain NetFlow/IPFIX as the standard summary format for network-level observation, and describe what they preserve from raw traffic.
2. Describe multi-vantage flow correlation — including DeepCorr-style attacks on Tor — and the assumptions that make it work.
3. Explain the RAPTOR family of attacks and what BGP-aware adversary capabilities mean for anonymity assumptions.
4. Distinguish single-vantage detection from multi-vantage correlation in terms of what they can and cannot infer.

NetFlow and what it preserves

Most large networks don't capture full packet traces — the storage and processing requirements are prohibitive. They capture flow-level summaries instead. The standard format is NetFlow (Cisco's original specification, now superseded by IPFIX/IETF standardization).

A NetFlow record represents a unidirectional flow between a source-and-destination pair, summarizing:

• 5-tuple: source IP, destination IP, source port, destination port, protocol.
• Timing: flow start time, last-packet time, duration.
• Volume: total bytes, total packets.
• TCP flags (if TCP): OR'd flags seen across the flow's packets.
• TOS / DSCP: quality-of-service markers.
• Routing context: ingress interface, egress interface, next-hop AS.

A flow record might be a few dozen bytes for a flow that was megabytes of traffic. The compression ratio is dramatic, which is what makes flow collection scalable to large networks.

What NetFlow preserves enough information for:

• Application-class identification. Most application classes are distinguishable from byte volume, packet count, duration, and port usage.
• Per-source profiling. The set of flows from one source over a time window characterizes that source's activity.
• Anomaly detection. Unusual flow patterns (sudden spike in flows to one destination, scanning patterns) are visible from flow records.
• Geographic and AS-level correlation. Flows traversing one network can be linked to flows traversing another by matching 5-tuple or by inferring relationships through timing and volume.

What NetFlow loses:

• Per-packet information. Specific packet sizes, exact timing, payload content.
• Order of packets. Reordering, retransmissions, fragmentation.
• Application content. Anything that requires deep packet inspection.

For traffic-analysis purposes, NetFlow is enough to do flow correlation — the central capability of network-level analysis.

Multi-vantage flow correlation

The core network-level attack: an adversary with visibility at multiple points correlates flows seen at different points to determine they're related.

Concrete example against Tor:

Setup. Adversary observes:

• Vantage A: traffic from a user to their guard relay (so sees user-to-Tor entry).
• Vantage B: traffic from a Tor exit to a destination (so sees Tor-exit-to-destination).

Both flows are encrypted, but their flow shapes are correlated because the same data is flowing through them, just with different encryption layers.

Attack. For each pair (flow at A, flow at B) within a reasonable time window, compute a similarity score based on:

• Per-second byte counts (do they spike at the same times?)
• Total volume (similar?)
• Duration (similar?)
• Packet count (similar?)
• Inter-arrival timing patterns (correlated?)

Pairs with high similarity scores are probably the same end-to-end flow. The adversary now knows which user is talking to which destination.

This is the fundamental anonymity-overlay vulnerability that Tor's design paper acknowledges. Mitigations require either:

• High latency (mixnets — covered earlier).
• Cover traffic dense enough to make timing correlation statistically hard.
• Path diversity so any single observer isn't in both positions.

Real-world correlation accuracy depends on:

• Observation coverage (more vantages → more correlation opportunities).
• Flow volume (more flows → harder to single-out).
• Background noise (unrelated flows act as cover).
• Adversary's algorithm (DeepCorr-style deep models perform much better than naive correlation).

The DeepCorr paper (Nasr et al., 2018) demonstrated that deep convolutional networks could perform end-to-end correlation against Tor with substantial accuracy. The model takes the flow time-series at both vantages and learns to predict whether they're the same flow. Reported accuracy on labeled test data is high; production deployment against an actual user population is lower (background traffic, dataset shifts) but still operationally meaningful.

RAPTOR and routing-aware attacks

The RAPTOR paper (Sun et al., USENIX Security 2015) introduced a family of attacks that combine traffic correlation with BGP-routing dynamics. The insight: an adversary doesn't need to be in a fixed position; they can manipulate BGP to position themselves favorably for correlation.

The attack family:

Asymmetric routing analysis. Observe the forward path of one direction of a TCP flow and the reverse path of the other direction (forward from client to server is one BGP-routed path; reverse from server to client may be a different path). Different ASes see each direction; correlating across them reveals connection structure.

BGP-induced churn. BGP path changes are routine. When a path change happens, traffic shifts to a different network. An adversary observing many networks can take advantage of churn to gain temporary visibility into flows that were previously invisible.

BGP hijacking. A capable AS-level adversary can announce more-specific routes for prefixes they don't own, hijacking traffic destined for those prefixes. If the hijacked prefix includes Tor relays, the adversary temporarily becomes the next-hop for a user trying to reach the relay.

Long-term observation accumulation. Over months of observation, BGP path changes accumulate; the adversary's effective coverage of network paths grows. Even an adversary that's not a global observer at any single moment can see large fractions of paths over time.

The RAPTOR contributions:

• Demonstrated practical end-to-end correlation against Tor by AS-level adversaries.
• Showed BGP attacks could substantially shift the threat picture.
• Quantified how often BGP churn alone provides deanonymization opportunities.

Mitigations:

• Path-aware relay selection. Tor's path selection considers AS-level diversity (avoid picking guard and exit in the same AS or same operator family).
• Cross-AS correlation defenses. Padding, cover traffic, and timing defenses help against AS-level observers similarly to other network observers.
• BGP security improvements. RPKI deployment, ROV adoption — these reduce the BGP-hijacking attack vector but don't eliminate it.

The post-RAPTOR research (Vanhoef and Pierson 2017, Sun et al. follow-ups, several other papers) has continued to evaluate AS-level adversaries against Tor and other anonymity systems. The general finding: a sufficiently positioned AS-level adversary can correlate against substantial fractions of Tor users; complete protection requires high-latency systems or global cover-traffic schemes that are operationally expensive.

Why a cross-vantage observer is stronger

A local observer (corporate IT, single-ISP) sees one network's traffic in isolation. They can do single-flow analysis but can't correlate across networks. Their threat picture is bounded by their network.

A cross-vantage observer (large transit provider, intelligence agency, AS-level coalition) sees multiple networks' traffic. They can:

• Correlate flows seen at multiple vantages to identify end-to-end flow structure.
• Combine observations from many sources to see things any single source can't see (e.g., the same user contacted from different ISPs to the same destination).
• Identify infrastructure (cloud regions, CDN POPs) that one source alone wouldn't see.
• Track users across network boundaries (changing ISPs, traveling, using VPNs across multiple countries).

The capability scales with vantage breadth. An ISP-level adversary is already powerful; a national-telecom-level adversary is substantially more powerful; a global-intelligence-level adversary is qualitatively different.

For anonymity-system designers, this means assumptions about adversary breadth shape every other design decision. Tor's design assumes "no single party is in both ends" — true against most adversaries, false against global ones. Mixnets accept higher latency to address the global threat. Different design choices for different threat models.

Practical detection-engineering perspective

For an operator running detection at network level, the practical work involves:

Flow collection infrastructure. NetFlow/IPFIX collection from routers, central storage, indexing. Modern setups use commercial flow analyzers or open-source like nfdump/SiLK.

Correlation queries. Given an interesting source flow (suspicious user, known target), search for related flows at other vantages. Time-windowed queries with similarity scoring.

Anomaly detection at scale. Batch analysis of flow data for unusual patterns — sudden spikes in flows to specific destinations, patterns of failed connections, unusual port usage.

Long-term storage. Flow data accumulates; storing months or years of flow records enables historical investigation.

Privacy and legal constraints. Flow data is often subject to retention regulations and privacy laws. Operators must navigate the legal landscape.

Alerting and triage. Most flows are normal; only a small fraction warrant investigation. Tooling to prioritize, summarize, and route alerts to analysts is critical.

The skills needed are systems engineering (running large-scale flow collection at line rate), data engineering (indexing and querying flow data efficiently), and analyst skills (interpreting flow patterns, knowing what to investigate). The work is rarely glamorous — much of it is filtering, deduplication, and false-positive reduction — but it's where most large-network detection actually happens.

Hands-on exercise

Toy NetFlow/IPFIX record table.

Tools: notes. Runtime: 10 minutes.

Sketch what a flow record might look like for a few different traffic types:

Flow 1: User browsing example.com
  src=10.1.1.1   dst=93.184.216.34   proto=TCP
  src_port=51234 dst_port=443        flags=SYN+ACK+FIN
  bytes=12345    packets=18          duration=0.45s

Flow 2: VPN tunnel
  src=10.1.1.1   dst=185.192.69.50   proto=UDP
  src_port=51820 dst_port=51820      flags=N/A (UDP)
  bytes=104857600 packets=80000      duration=3600.0s

Flow 3: Tor circuit
  src=10.1.1.1   dst=199.249.230.85  proto=TCP
  src_port=52001 dst_port=443        flags=SYN+ACK+PSH
  bytes=5242880  packets=4000        duration=1800.0s

Flow 4: Suspicious DNS spike
  src=10.1.1.1   dst=8.8.8.8         proto=UDP
  src_port=ephemeral dst_port=53     flags=N/A
  bytes=120000   packets=400         duration=60.0s
  (compared to baseline of 50 packets/min for this user)

For each flow, ask: what classifications would NetFlow alone allow? What features would you need additional data (full packet capture, application logs) to determine?

Flow-correlation scoring pseudocode.

def correlation_score(flow_a, flow_b, window_sec=10):
    """Score similarity between two flows for end-to-end correlation."""
    # Time alignment: do they overlap in time?
    if not time_overlap(flow_a, flow_b, window_sec):
        return 0.0

    score = 0.0
    score += 0.2 * volume_similarity(flow_a.bytes, flow_b.bytes)
    score += 0.2 * packet_count_similarity(flow_a.packets, flow_b.packets)
    score += 0.3 * duration_similarity(flow_a.duration, flow_b.duration)

    # Burst pattern correlation (requires sub-second resolution if available)
    if has_subflow_data(flow_a) and has_subflow_data(flow_b):
        score += 0.3 * burst_pattern_correlation(flow_a, flow_b)

    return score

def find_correlated_flows(target_flow, candidate_flows, threshold=0.7):
    """Return all candidate flows correlating above threshold."""
    return [f for f in candidate_flows if correlation_score(target_flow, f) > threshold]

The exercise: ask what false-positive rate this scoring produces. (High, in noisy networks.) What additional features would reduce false positives? (Per-second packet counts, exact timing distributions, behavioral context.)

Common misconceptions and traps

"NetFlow data is just metadata, not very useful." NetFlow is enough for most network-level traffic analysis tasks. Volume, timing, and 5-tuple data are sufficient for application-class identification, anomaly detection, and flow correlation.

"Tor protects against AS-level adversaries." Tor's design paper explicitly does not claim this. Path diversity helps against single-AS observers but not against AS-level coalitions or BGP-aware adversaries.

"BGP attacks are theoretical." They've been demonstrated in academic research (RAPTOR and successors) and observed in the wild (multiple BGP hijacks of cryptocurrency-related traffic, of cloud provider IPs). The risk is real.

"Network-level analysis requires nation-state resources." Large CDNs, large hosting providers, ISP federations — many entities have multi-vantage observation capability. The capability isn't unique to nation-states.

"Correlation requires perfect time synchronization." It helps but isn't required. Flow records have timestamps; correlation works with reasonable time alignment (seconds-to-tens-of-seconds). Imperfect timing reduces accuracy, doesn't eliminate the attack.

"My VPN protects against this." It changes one observation point but not multi-vantage correlation. An adversary with visibility into both your traffic to the VPN and the VPN's traffic to the destination can correlate them.

"This is just paper attacks." Operational deployment of network-level traffic analysis is widespread. Telecom-level monitoring exists; intelligence-agency-level monitoring is documented. The threat is real for users in some threat models.

Wrapping up

Network-level traffic analysis is where many vantages combine into capabilities single-vantage observers don't have. NetFlow/IPFIX preserves enough metadata for sophisticated analysis at scale. Multi-vantage flow correlation, especially of low-latency anonymity overlays like Tor, is well-documented. RAPTOR-family attacks add BGP awareness, demonstrating that the "no single observer in both ends" assumption can be undermined by routing manipulation or routing churn over time.

For low-latency anonymity systems, network-level adversaries are the defining threat. Defenses require either accepting the threat (Tor's position), shifting to high-latency systems (mixnets), or implementing extensive cover-traffic and padding (which has its own costs).

This concludes Track 5. Track 6 covers the active-evasion side — REALITY, naïveproxy, domain fronting, pluggable transports — that combine many of the ideas from Tracks 4 and 5 into deployed circumvention systems. Where Track 5 was the detector's perspective, Track 6 is the evader's perspective on the same arms race.

Further reading

• RAPTOR: Routing Attacks on Privacy in Tor — Sun et al., 2015 — the seminal AS-level-adversary paper.
• DeepCorr — Nasr et al., 2018 — deep-learning end-to-end correlation against Tor.
• HTTPS Event Flow Correlation — Hoang et al., 2020 — applying flow correlation specifically to HTTPS.
• SEI NetFlow Analysis Guide — practical NetFlow analysis methodology from CISA / SEI.