Consideration of Applying Zero Trust Philosophy in Network Infrastructure

Traditional network security architectures in operator and enterprise environments have long been built around a perimeter-centric protection model. In this model, security mechanisms are primarily deployed at network edges—such as access networks, inter-domain boundaries, or gateway nodes—under the core assumption that traffic originating inside the network can be inherently trusted once it passes the perimeter. This assumption of Implicit Trust reflected earlier network environments in which infrastructures were relatively static, tightly controlled, and operational roles were clearly separated. In such contexts, perimeter-based protection provided a reasonable balance between security and operational complexity. Modern networks, however, have evolved into highly distributed, virtualized, and software-driven systems. Automated orchestration, programmable control planes, open management interfaces, and closed-loop control systems significantly expand the internal attack surface and increase the potential impact of internal failures or compromise. As a result, threats originating from within the network can no longer be treated as exceptional or out of scope. The reliance on Implicit Trust within the network creates a structural mismatch between the threat environment and deployed protection mechanisms. This document examines the limitations of the perimeter-centric model and the necessity of applying Zero Trust principles to network protection itself. Zero Trust rejects trust based on network location and emphasizes continuous verification of entities and communications. Applying these principles within the network enables more robust containment of compromise and improved resilience of network operations.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in .

The following terms are used in this draft: ZTA: Zero Trust Architecture. An evolving set of cybersecurity paradigms that move defenses from static, network-based perimeters to focus on users, assets, and resources. Implicit Trust: The assumption that an entity (user, device, traffic flow) is trustworthy solely because of its network location (e.g., being inside the network perimeter). Lateral Movement: The technique used by attackers to progressively move deeper into a network from an initial point of compromise, often by exploiting Implicit Trust.

In today’s operational networks, the dominant security paradigm remains perimeter-centric. Most protection mechanisms are concentrated at the network boundary, reflecting the historical assumption of Implicit Trust for internal traffic. Common practices include: Traffic filtering, access control, and anomaly detection primarily enforced at ingress or egress points . Security inspection and policy enforcement focused on customer-facing interfaces and inter-domain links. Limited or coarse-grained security controls within the internal network, where routers, switches, virtualized network functions, and control systems are often treated as mutually trusted. This architectural approach originated in an era when networks were relatively static and infrastructure components were physically isolated. Under such conditions, deploying strong security controls only at the boundary was often sufficient and operationally efficient. However, the shift to virtualized, cloud-native, and software-driven networks has rendered this model increasingly fragile.

A security architecture that relies primarily on edge-based protection exhibits a critical weakness: once the perimeter is breached, the internal network is left largely unprotected. This creates a "hard shell, soft interior" structure, leading to systemic risks across the network planes. The core risk is the unrestricted lateral movement of an attacker who gains an initial foothold inside the network. Because internal traffic is subject to minimal verification, a compromised node can move across internal segments with limited resistance, accessing additional systems and services. Furthermore, the lack of internal validation mechanisms means that compromised nodes can easily impersonate other network elements or services, undermining trust relationships within the network. While edge-based mechanisms address external spoofing, they do not prevent a compromised internal entity from spoofing other internal entities.

Internal control protocols (e.g., routing, signaling) and management interfaces are often designed with the assumption of Implicit Trust. This exposure is critical because: Control protocols may accept unauthenticated or insufficiently verified traffic, enabling disruption or manipulation of network operations (e.g., malicious routing updates). In automated and intelligent networks, incorrect or malicious internal signals can trigger large-scale misconfigurations or service disruptions, as autonomous control loops amplify the original compromise.

Modern networks rely heavily on open APIs, software-defined networking (SDN) controllers, and automated orchestration systems. These systems manage the entire network state. If an attacker gains access to the management plane through a compromised internal entity, they can leverage the Implicit Trust to execute high-impact actions, such as reconfiguring security policies, redirecting traffic, or disabling critical network functions.

Zero Trust (ZT) principles address these challenges by eliminating Implicit Trust and requiring continuous, dynamic verification across the entire network. Trust is never implicit and must be continuously reassessed based on identity, context, and behavior. This approach is necessary for network protection for several reasons: Elimination of Trust-by-Location: Network nodes and traffic are no longer trusted solely because they originate from internal segments, forcing explicit authentication and authorization for all interactions. Containment of Compromise: Security enforcement at multiple internal points limits the "blast radius" of a compromised component and restricts lateral movement, transforming the network from a soft interior to a segmented, hardened structure. Improved Integrity of Control and Management Functions: Continuous verification helps ensure that routing, orchestration, and monitoring systems operate on trustworthy inputs, which is vital for the stability of automated network operations. Resilience and Compliance: ZT provides a framework for building networks that are inherently more resilient to internal threats and better aligned with modern security compliance mandates. Applying Zero Trust to network protection implies that internal communications, forwarding behaviors, and control interactions must be subject to security enforcement similar to that applied at the perimeter. This requires the development of network mechanisms that can enforce policy based on identity and context, rather than just network address and location.

The evolution of network architectures and threat models has rendered traditional edge-only security approaches insufficient. While perimeter defenses remain necessary, they are no longer adequate on their own. A breach at the boundary can expose the internal network to rapid and wide-ranging compromise. Adopting Zero Trust principles within the network is therefore not optional, but essential. By shifting from static, perimeter-based trust to dynamic, continuous verification across all network segments, operators can build more resilient, controllable, and trustworthy networks. Zero Trust-aligned network protection transforms security from a boundary function into an intrinsic property of the network itself, better suited to the demands of modern and future network environments.

This document is a Problem Statement and does not propose a solution. However, the deployment of Zero Trust principles within the network introduces its own set of security and operational considerations that must be addressed by any future solution. These include: Performance Overhead: Continuous verification and policy enforcement at multiple internal points may introduce latency and performance overhead to the data plane. Reliability and Availability: The Policy Decision Point (PDP) and Policy Enforcement Point (PEP) components of a ZT architecture represent critical infrastructure. Their failure could lead to network disruption or denial of service. Policy Complexity: Managing fine-grained, dynamic policies across a large, distributed network is complex and requires robust automation and orchestration to avoid misconfiguration and policy conflicts.

TBD