On Network Path Validation

Introduction In the current Internet architecture, the network layer provides best-effort service to the endpoints using it . This means that the endpoints are unaware, unable to visualize, and unable to control the network path between them, and thus the traffic inside the path too. This deficiency not only undermines Internet routing security but also hampers the development of new concepts like path-aware networking . Exploiting this vulnerability, various routing attacks have emerged, including:

Routing Hijack / Prefix Hijack: AS (Autonomous System) incorrectly announces prefix ownership, diverting normal traffic to the wrong AS.
Route Injection / Traffic Detour: Attacker injects additional hops into a path, redirecting traffic to locations where it can be monitored, analyzed, or even manipulated before being sent back to the original destination.
Route leak: Propagation of routing announcements beyond their intended scope , causing unintended ASes to receive traffic.
Denial of Service (DOS): Adversary overwhelms important routers with interfering traffic, preventing them from receiving and processing valid traffic.

These attacks exploit the trusting and flexible nature of the Internet, resulting in unreliability in both path establishment and actual data forwarding. To address this issue, several works are proposed focusing on securing network path in the control plane. Resource Public Key Infrastructure (RPKI) consider IP prefixes as resources, and their ownership must be proven by signed statements called Route Origin Authorizations (ROAs), issued by the root CA or authorized CAs of the Internet Routing Registry -- similar to how certificates work in regular PKI. Through a chain of ROAs, BGPSec can secure an AS path. While these measures provide necessary authentication services and enhance routing security in the control plane, they have limitations. Securing a path in the control plane does not necessarily mean we can control and track the actual forwarding of traffic within these paths. To put it simply, even though we have secured highways to connect correct locations so that cars can reach their intended destinations, controlling how cars actually travel on the highways and reliably logging their movements is a separate challenge. In order to achieve this goal, an effective path validation mechanism should enable data packets to carry both mandatory routing directives and cryptographically secure transit proofs in their headers. This mechanism should serve as an orthogonal complement to existing techniques that primarily focus on the control plane. Cisco made an exploratory attempt by designing a Proof of Transit scheme using modified Shamir Secret Sharing . Although they did not provide a rigorous security proof and the work regretfully discontinued but the question they asked is too significant to be left undiscussed.

Use Cases We have compiled a list of use cases that highlight the importance of path validation. We invite discussions to add more cases, aiming to cover as many scenarios as possible.

Use Case 1: Proof of Service Level Assurance Internet Service Providers (ISPs) often have different levels of routing nodes with varying service qualities. When customers like Alice subscribe to premium plans with higher prices, it is reasonable for them to expect superior connection quality, including higher bandwidth and lower latency. Therefore, it would be beneficial to have a mechanism that ensures Alice's traffic exclusively traverses premium routing nodes. Additionally, it is important to provide Alice with verifiable proof that such premium services are indeed being delivered.

Use Case 2: Proof of Security Service Processing Service Function Chaining enables the abstraction of services such as firewall filtering and intrusion prevention systems. Enterprises need to demonstrate to others or verify internally that their outbound and inbound traffic has passed through trusted security service functions. In this context, the service function acts as the node that must be transited. After the processing and endorsing of these security service functions, traffic becomes verifiably more reliable and more traceable, making it possible to reduce spamming and mitigate Distributed Denial-of-Service (DDoS) attacks.

Use Case 3: Security-sensitive Communication Routing security is a critical concern not only on the Internet but also within private networks. End-to-end encryption alone may not be sufficient since bad cryptographic implementations could lead to statistical information leak, and bad cryptographic implementation or API misuse is not uncommon . If a flow of traffic is maliciously detoured to the opposing AS and secretly stored for cryptanalysis, useful information (such as pattern of plaintexts) could be extracted by the adversary. Thus, when given a specific path or connection, it is crucial to ensure that data packets have solely traveled along that designated route without exceeding any limits. Ultimately, it would be advantageous to provide customers with verifiable evidence of this fact.

Design Goals As the name suggests, the Network Path Validation mechanism aims to achieve two main goals:

Enforcement: Committing to a given network path and enforcing traffic to traverse the designated nodes in the specified order.
Validation: Verify the traffic indeed transited the designated nodes in exact order specified for this path.

The enforcement and validation to the traffic forwarding are two sides of a coin. In order to achieve these goals, two additional pieces of information must be added to the data header.

Routing Directive: A routing directive commands the exact forwarding of the data packet hop-by-hop, disobeying which will cause failure and/or undeniable misconduct records.
Transit Proof: A transit proof is a cryptographic proof that securely logs the exact nodes transited by this data packet.

Modelling the Ideal Solution

Roles: The path validation mechanism should include three roles:

The network operator chooses or be given a routing path P and commit to it. P = (n_1, n_2, ..., n_i, ..., n_N) is an ordered vector consists of N nodes. The network operator also does the setup and pre-distribution of the public parameters.
The forwarding "node" is a physical network device or a virtual service that processes and forwards the data traffic. Within that path, this node is the minimal atomic transit unit meaning there are no other perceptible inferior nodes between these regular nodes.
The observer is an abstract role that represents public knowledge. Any publicized information is known to the observer. Any person or device who is interested in examining the trustworthiness of this routing path could be an instance of observer. An observer can verify publicized information such as node identity or transit proof with an unbiased property.

Required Functionality: The path validation mechanism consists of the following algorithms:

Configure: Setup control plane parameters based on a security parameter.
- Input: Security parameter
- Output: Control plane parameter distributed
Commit: Generates a commitment proof for the chosen path using public parameters and the path itself.
- Input: public parameters, path P
- Output: Commitment Proof C of the path P
CreateTransitProof (in-situ / altogether): Generates transit proofs for individual nodes or sets of nodes, either during data processing or when transmission finishes.
- Input: public parameters, index i of node n_i or indices I of a set of node n_I, identity information of node n_i or set of nodes n_I.
- Output: Transit proof p_i or batch transit proof p_I
VerifyTransitProof (in-situ / altogether): Verifies transit proofs for individual nodes or sets of nodes, either in-step or all at once.
- Input: public parameters, transit proof p_i/p_I, index i of node n_i or indices I of a set of node n_I, identity information of node n_i or set of nodes n_I.
- Output: success = 1, fail = 0

The Network Operator performs the Configure and Commit steps. The CreateTransitProof step could be done by either each node n_i during he is processing the data, or the end node n_N when the transmission finishes altogether. That being said, the VerifyTransitProof step can also be executed in an in-situ (for step-by-step control and visibility) or one-time fashion. Usually the VerifyTransitProof step is executed by the observer, but it can also be executed by the next-hop node for origin verification.

Security As we can see, the creation and verification of the transit proof is the critical part of the mechanism. Therefore, we define the security of the Network Path Validation mechanism around the security of the transit proof: We say a Network Path Validation mechanism is secure if the transit proof is correct, unforgeable and binding.

Correctness: Transit proof created by the right node n_i at the position i must pass the verification. (probability of a correct proof not passing verification is smaller than a negligible function)
Unforgeability: Transit proof at position i must only be created by the node n_i. (probability of a forged proof passing verification is smaller than a negligible function)
Binding: An identity value at position i different than what is committed created by polynomial adversary cannot pass a verification check.

Other security discussions like replay attack resistance are discussed separately. Since transit proof is added to the header, the compactness of proof, short proof creation and verification time is also critical. Ideally:

Efficiency: The creation time, verification time and size of the transit proof is sublinear to the number of total nodes on a path.

IANA Considerations This document has no IANA actions.