| Internet-Draft | Path Validation Problems Statement | October 2023 |
| Liu, et al. | Expires 25 April 2024 | [Page] |
This document provides a problem statement, history revisiting, gap analysis and use cases for path validation techniques.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 25 April 2024.¶
Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
Path validation has been interpreted differently in different contexts due to its ambiguous name and long history. This document aims to deliver a clearer understanding of the path validation problem and help navigate exploration towards potential solutions.¶
The term "path validation" was first used in the BGP context, referring to validating the correctness of AS-level path propagation. The term "path validation" mostly refers to verifying that a BGP route advertisement (an AS-path) is authentic, indeed authorized by all ASes on the path, and correctly representing the inter-AS propagation path, which later becomes BGPSec [RFC8205][BGPSEC]. While some RFCs also discussed data plane consistency with control plane [RFC5123], mentioning validating also the actual path that a packet has traversed, it remains a minority of understanding to this term.¶
Later, as the inconsistency gap between control plane and data plane becomes bigger, the term "path validation" later be interpreted by a lot of research papers [PATHVALIDATIONPAPER1][PATHVALIDATIONPAPER2][PATHVALIDATIONPAPER3][PATHVALIDATIONPAPER4] as "Validating what path a packet has actually traversed". The unambiguous equivalence to this interpretation in the IETF community is the concept of Proof-of-Transit [I-D.ietf-sfc-proof-of-transit-08].¶
Despite the different focus, control plane or the data plane, we think they are two sides of a same coin. The former is to make sure the router receives the correct routing reference (routing table, interface configurations, segment list etc) before the forwarding happens, while the latter is to directly verify the correctness of forwarding outcome, after the forwarding is done. As a result, the scope of path validation should be:¶
Validating the planned path is a trusted, authorized path.¶
Validating what path a packet has actually traversed.¶
With the former protecting routing integrity and the latter protecting forwarding security.¶
There are three major gaps in path validation.¶
The gap between path validation and proof of transit¶
The gap between BGP scenarios and more scenarios¶
The gap between routing integrity and forwarding integrity¶
The first gap is explained in the history section. Now we believe proof of transit is part of path validation. The second gap requires use case analysis which we will discuss later. The third gap exists in both explict routing and conventional routing scenarios, and it is the main gap for path validation to fill.¶
Also known as the inconsistency between control plane and data plane. To achieve secure routing, three basic steps are needed:¶
Secure path propagation relies on secure control plane techniques such as BGPSec and RPKI, leading to the correctness of routing reference information such as routing table, segment list, etc. Secure router execution relies on remote attestations on the trustworthiness of the router hardware, firmware, software and configurations. Achieving these two leads to routing integrity, and implies forwarding integrity. However, misconfigurations and/or various of new attacks could circumvent the security measures, leading to the deviation of actual forwarding path from the correct routing path [SECUREROUTINGFAIL], which can only be directly discoverable by data plane validation mechanisms like proof of transit. A secure proof of transit mechanism would significantly help fill the gap between routing integrity and forwarding integrity as it verifies the final results directly.¶
Note that a probing mechanism such as IFIT/IOAM or other new path tracing mechanisms [I-D.filsfils-spring-path-tracing-05] also has the same purpose. But they still rely on a secure proof of transit mechanism.¶
As discussed earlier, the gap between routing integrity and forwarding integrity can be filled by a secure proof of transit mechanism that directly verifies the final forwarding results. Proof of Transit (POT) is thus the critical part of the path validation problem and we model path validation security around the security of a POT mechanism. We say a Proof-of-Transit mechanism is secure if the transit proof is correct, unforgeable identity-binding and position-binding.¶
Correctness: A 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: A 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)¶
Identity-binding: A transit proof computed by a false node n_z at position i cannot pass a verification check.¶
Position-binding A transit proof computed by a correct node n_i in the wrong position j, where i != j, cannot pass a verification check.¶
Hiding * A transit proof may or may not directly reveal the creator's identity and/or his position.¶
Service Function Chaining enables the traffic to traverse virtual network functions in a user-defined order. Compliance or legal requirements may demand the service provider to prove that all packets have followed a specific path, preferably cryptographically verifiable. In today's deployments, this proof is typically delivered in an indirect way. A path validation mechanism can produce a cryptographically verifiable transit proof, proving that the corresponding packet has indeed been processed by a sequence of service functions.¶
Enterprises have been migrating their production-level IT systems to the cloud. This means that some of the enterprises' key production workflow security now heavily relies on the ordered calling of different microservices or APIs. Similar to the SFC case, workload identity [I-D.gilman-wimse-use-cases-00] also requires some kind of ordered proof-of-processing, proving to the enterprise management that the production systems are working correctly, or proving to the customers that they indeed received a sequence of services with a designated order.¶
For legal or business compliance reasons, customers' personal data cannot travel outside of certain geolocations, i.e., customer campus or native country (GeoFencing). Path validation can detect and avoid such exception. Similarly, path validation can make sure certain undesired geolocations will not be travelled too.¶
End-to-end Security: Some customers have high-security service path requirement for their sensitive traffic, i.e., VOIP calls or video conferences for VIP clients, or a bank's financial data. They need to make sure their data does not leak outside of their chosen secure path, especially to some insecure devices or domain.¶
To provide high-security VPN services for VIP customers, the operator needs to prove that the VPN connection indeed passes through a high security level service path.¶
uRPF is a security feature that helps prevent source IP address spoofing and denial-of-service (DoS) attacks [RFC8704][RFC5635][RFC3704]. It works by validating the source IP address of a received packet by performing a reverse path lookup in FIB table, all the way to the source. If the path does not exist, the packet is dropped. Now path validation can do one more step of validation, by sending a request for proof-of-transit all the way back to the source. By sending the request to the source and collecting transit proof of every hop on the path, the router can validate if the currently stored path does not only exist but is also unexpired, potentially reducing the false negative rate.¶
In certain scenarios, user wishes to have explicit control over the path that network traffic takes, in order to meet certain performance, security or regulatory compliance requirements. Segment routing enables source-based packet steering through networks using segment lists. However current segment routing security is also implied by assuming the router will truthfully forward the packet according to the segment list. Path validation is a critical verification technique that checks whether the planned path was strictly followed, and could support segment routing as potential security extensions.¶
Illegal data copy: This refers to an attack where the router illegally copies and sends out the data he is currently forwarding. We believe this is out-of-scope because data is intangible by nature. Once fully obtained in the plaintext, there is no mechanism to trace it unless using a data watermark technique, which is out-of-scope.¶
Stealth nodes: Stealth nodes are the inferior nodes that not perceivable in the current layer. They could be old or computationally weak nodes, or nodes within transparent tunnels. We believe this is out-of-scope because layered design of the Internet purposely makes tunnels and inferior nodes not perceivable. It does not make sense to violate layered design principle just trying to perceive stealth nodes. To the very least, it is a problem that the control plane (BGPSec) also suffers from [BGPSECATTACK], and the goal of this work is to fill the gap between the control and data planes thus leaving the problem out-of-scope.¶
This document has no further security considerations.¶
This document has no IANA actions.¶