Beyond Encryption: Understanding the Full Scope of Communication Path Threats

TLCTC Cluster #5 addresses Man in the Middle attacks, but the generic vulnerability it identifies is broader than most realize: "Insufficient end-to-end confidentiality/integrity protection AND implicit trust in local networks and intermediate path infrastructure."

That conjunction matters. There are two distinct problems here, and they require different controls.

The Two Halves of #5: Path Control vs. Content Protection

Notice the structure: the attacker first needs a position, then they abuse that position. These map to fundamentally different defensive concerns:

Most organizations focus almost exclusively on content protection while implicitly trusting the path. This is the gap that sophisticated attackers—and nation-state actors—exploit.

SCION: The Path Control Solution

SCION (Scalability, Control, and Isolation on Next-Generation Networks) represents the most mature attempt to address the path control problem. Developed at ETH Zurich and now deployed in production networks including the Swiss financial sector, SCION fundamentally reimagines internet routing.

What SCION Actually Does

Unlike traditional BGP-based routing, where your traffic follows paths determined by opaque autonomous system negotiations you cannot observe or control, SCION provides:

• Path Visibility: Every hop between origin and destination is cryptographically verified
• Path Selection: Senders choose which paths their data takes
• Isolation Domains (ISDs): Logical groupings of networks with shared trust policies
• BGP Hijack Prevention: Protection against route leaks, hijacks, and IP spoofing
• Geofencing: Provable assurance that traffic stays within specified jurisdictions

"With the SCION protocol you are in control of routing. You decide and design policies depending on the service. You control who has routable access to your service." — SCION Implementer

What SCION Does NOT Do

Here's the critical insight: SCION does not encrypt your traffic.

SCION ensures you know where your packets travel and that no one can redirect them without your knowledge. But the packets themselves remain standard IP packets. Without encryption, any intermediary on the (now-verified) path can still observe or modify the content.

"Encryption is not isolating your service from bad actors. It's only making sure you are in control of the content."

This is not a criticism of SCION—it's the proper separation of concerns. SCION solves path trust. Encryption solves content trust. Complete #5 defense requires both.

The Encryption Landscape: Post-Quantum TLS

If SCION addresses the "where does my traffic go" question, encryption addresses "can anyone read or modify it." And the encryption landscape has evolved dramatically.

The Quantum Threat

Traditional encryption relies on mathematical problems that classical computers cannot efficiently solve. Quantum computers, using Shor's algorithm, could break RSA and elliptic curve cryptography. This creates the "harvest now, decrypt later" threat: adversaries capture encrypted traffic today, expecting to decrypt it once quantum computers mature.

Post-Quantum TLS Is Here Now

The good news: post-quantum cryptography is no longer theoretical. NIST standardized ML-KEM (formerly Kyber) in 2024, and hybrid post-quantum key exchange is already widely deployed:

• As of late 2025, over 38% of HTTPS traffic on major CDNs uses hybrid post-quantum key exchange
• Firefox and Chrome support X25519MLKEM768 by default
• Major cloud providers (AWS, Cloudflare, Akamai, Fastly) offer PQ-TLS on their endpoints

The hybrid approach—combining classical X25519 with post-quantum ML-KEM—provides a safety net: if either algorithm proves vulnerable, the other maintains protection.

Practical Implication

For most web-facing applications, deploying post-quantum TLS addresses the "harvest now, decrypt later" threat today, without requiring new network infrastructure like SCION. This is the pragmatic starting point for most organizations.

The Forgotten Middle: East-West and Backplane Traffic

Here's where the #5 threat landscape gets complicated. Most security discussions focus on "north-south" traffic—data entering or leaving your environment through the internet. But modern data centers and cloud environments have a different reality.

The East-West Problem

East-west traffic—communication between servers, VMs, containers, and services within the same data center or cloud environment—now represents the majority of data center traffic. Studies suggest 70% or more of data center traffic is lateral.

• Firewalls guard the perimeter (north-south)
• VPNs protect traffic to/from remote locations
• But server-to-server communication inside the data center? Often completely unencrypted.

This creates a massive #5 attack surface. Once an attacker achieves initial access, lateral movement through unprotected east-west traffic is trivial. The 2013 Target breach demonstrated this pattern: attackers pivoted from an HVAC vendor's access to payment systems through unprotected internal networks.

The Two-Layer Encryption Model

Complete #5 defense in modern environments requires thinking about encryption at two layers:

• Layer 1 – Infrastructure/Backplane: Hypervisor-to-hypervisor communication, Container orchestration traffic, Storage area network (SAN) communication, Management plane traffic, Service mesh communication.
  Controls: IPsec, WireGuard, microsegmentation with encryption, mTLS between infrastructure components
• Layer 2 – Application: End-to-end TLS between application endpoints, Mutual TLS (mTLS) for service-to-service authentication, Application-layer encryption for sensitive fields.
  Controls: TLS 1.3 with post-quantum hybrid, certificate management, proper validation

Why Both Layers Matter

Consider a modern cloud deployment:

• Your application uses TLS to communicate with users (Layer 2 ✓)
• But inter-service communication within Kubernetes might be unencrypted
• Traffic between availability zones crosses backplane networks you don't control
• Storage replication happens over infrastructure networks with implicit trust

An attacker with access to the hypervisor or network fabric can observe or modify traffic that never touches your application-layer encryption. This is why zero-trust architectures mandate encryption at both layers.

Special Contexts: Telco Transit and Cloud Backplanes

Telco and Network Provider Transit

When your traffic leaves your infrastructure for the internet, it traverses autonomous systems operated by entities you have no relationship with. Standard BGP routing means:

• You cannot verify the actual path taken
• Traffic may transit unexpected countries
• Any intermediate AS can observe unencrypted traffic
• BGP hijacks can redirect traffic through hostile infrastructure

This is where SCION provides unique value. For organizations with regulatory requirements (GDPR, Swiss FADP, healthcare data residency), proving that data never left a jurisdiction is impossible with standard internet routing. SCION's cryptographically verified paths provide this assurance.

Cloud Provider Backplanes

Cloud environments introduce their own #5 considerations:

• Multi-tenancy: Your traffic shares physical infrastructure with unknown parties
• Virtualization layers: Traffic passes through software-defined networking you don't control
• Provider access: Cloud operators have potential visibility into your traffic
• Region connectivity: Traffic between regions may traverse public internet or provider-controlled dark fiber

The practical response:

• Encrypt at the application layer (assume the infrastructure is hostile)
• Use provider-offered encryption features (VPC encryption, encrypted storage)
• Consider dedicated tenancy for the most sensitive workloads
• Verify cloud provider's own controls and certifications

Mapping to TLCTC: The Complete #5 Picture

That last phrase is key: assume uncontrolled networks are hostile. This isn't paranoia—it's accurate threat modeling. The question isn't whether intermediaries will be malicious, but whether your architecture survives if they are.

Position Acquisition (Enabling Clusters)

Per the TLCTC boundary tests, gaining the privileged MitM position maps to other clusters. The framework provides examples:

• Via #1 (Abuse of Functions): ARP poisoning, DNS spoofing, BGP manipulation—abusing designed network functions to redirect traffic
• Via #8 (Physical Attack): Physical tap on cables, access to network equipment, rogue access points
• Via #9 (Social Engineering): Tricking administrators into installing malicious certificates or granting network access

This means #5 controls must consider not just encryption, but also the attack paths that establish the MitM position in the first place.

The Control Matrix Approach

Using the TLCTC × NIST CSF control matrix for #5:

Practical Guidance: A Layered Strategy

Given this analysis, here's a pragmatic control strategy for #5:

Tier 1: Universal (All Organizations)

• TLS 1.3 everywhere with strong cipher suites
• Certificate validation properly implemented (no skipping verification)
• HSTS for web applications
• Post-quantum hybrid key exchange where supported (increasingly automatic with modern browsers/libraries)

Tier 2: Enhanced (Security-Conscious Organizations)

• mTLS for service-to-service communication
• Certificate pinning for critical connections (with operational safeguards)
• East-west encryption via service mesh or network-layer IPsec
• DNS security (DNSSEC, DoH/DoT)

Tier 3: High-Assurance (Regulated, High-Value Targets)

• Network segmentation with encrypted microsegments
• Path visibility solutions (consider SCION where available)
• Hardware security modules for key management
• Traffic analysis resistance for the most sensitive communications

Tier 4: Specialized (Specific Requirements)

• SCION deployment for jurisdictional guarantees or BGP-resilient connectivity
• Dedicated connectivity (private fiber, dedicated cloud tenancy)
• Quantum key distribution for specific high-value links (emerging)

Conclusion: Complete #5 Defense

The TLCTC framework classifies threats by their generic vulnerability—the fundamental weakness being exploited. For #5, that vulnerability is dual: insufficient content protection AND implicit path trust.

Encryption alone—even post-quantum encryption—addresses only half the problem. You've protected what your data says, but not where it goes. Path control alone—even SCION's cryptographically verified routing—addresses the other half. You know where your traffic travels, but haven't protected its content.

Complete #5 defense requires both: encryption for content, path controls for routing, and the assumption that any network you don't fully control is hostile.

For most organizations today, the practical path forward is:

1. Deploy post-quantum TLS (increasingly automatic)
2. Extend encryption to east-west traffic (often neglected)
3. Assume hostile paths and architect accordingly
4. Monitor SCION ecosystem development for path-critical use cases

The attackers understand both halves of this vulnerability. Your defenses should too.