Network Working Group C. Liu Internet-Draft Q. Wu Updates: draft-liu-on-network-path-validation-00 L. Xia (if approved) Huawei Intended status: Standards Track 23 October 2023 Expires: 25 April 2024 Path Validation Problem Statement, History, Gap Analysis and Use Cases draft-liu-path-validation-problem-statement-00 Abstract This document provides a problem statement, history revisiting, gap analysis and use cases for path validation techniques. Status of This Memo 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 Notice 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. Liu, et al. Expires 25 April 2024 [Page 1] Internet-Draft Path Validation Problems Statement October 2023 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Problem Statement of Path Validation . . . . . . . . . . . . 2 2.1. History . . . . . . . . . . . . . . . . . . . . . . . . . 2 2.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.3. Goal . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Gap Analysis . . . . . . . . . . . . . . . . . . . . . . . . 3 3.1. Routing Integrity vs Forwarding Integrity . . . . . . . . 4 3.2. Proof-of-Transit Security . . . . . . . . . . . . . . . . 4 4. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4.1. Service Function Chaining . . . . . . . . . . . . . . . . 5 4.2. Workload Identity . . . . . . . . . . . . . . . . . . . . 5 4.3. Traffic Path Compliance . . . . . . . . . . . . . . . . . 5 4.4. High Security traffic path . . . . . . . . . . . . . . . 6 4.5. Validating uRPF path . . . . . . . . . . . . . . . . . . 6 4.6. Segment Routing Security . . . . . . . . . . . . . . . . 6 5. Out-of-scopes . . . . . . . . . . . . . . . . . . . . . . . . 6 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 8.1. Normative References . . . . . . . . . . . . . . . . . . 7 8.2. Informative References . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 1. Introduction 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. 2. Problem Statement of Path Validation 2.1. History 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. Liu, et al. Expires 25 April 2024 [Page 2] Internet-Draft Path Validation Problems Statement October 2023 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][P ATHVALIDATIONPAPER3][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]. 2.2. Scope 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: 1. Validating the planned path is a trusted, authorized path. 2. Validating what path a packet has actually traversed. With the former protecting routing integrity and the latter protecting forwarding security. 2.3. Goal Given the above scope, the goal of path validation is to achieve: * Verifiable assurance of hop-by-hop forwarding integrity. 3. Gap Analysis There are three major gaps in path validation. 1. The gap between path validation and proof of transit 2. The gap between BGP scenarios and more scenarios 3. 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. Liu, et al. Expires 25 April 2024 [Page 3] Internet-Draft Path Validation Problems Statement October 2023 3.1. Routing Integrity vs Forwarding Integrity Also known as the inconsistency between control plane and data plane. To achieve secure routing, three basic steps are needed: 1. Secure path propagation 2. Secure router execution 3. Secure proof of transit 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. 3.2. Proof-of-Transit Security 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) Liu, et al. Expires 25 April 2024 [Page 4] Internet-Draft Path Validation Problems Statement October 2023 * *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. 4. Use Cases 4.1. Service Function Chaining 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. 4.2. Workload Identity 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. 4.3. Traffic Path Compliance 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. Liu, et al. Expires 25 April 2024 [Page 5] Internet-Draft Path Validation Problems Statement October 2023 4.4. High Security traffic path 1. 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. 2. 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. 4.5. Validating uRPF 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. 4.6. Segment Routing Security 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. 5. Out-of-scopes * 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. Liu, et al. Expires 25 April 2024 [Page 6] Internet-Draft Path Validation Problems Statement October 2023 * 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. 6. Security Considerations This document has no further security considerations. 7. IANA Considerations This document has no IANA actions. 8. References 8.1. Normative References [RFC8205] Lepinski, M., Ed. and K. Sriram, Ed., "BGPsec Protocol Specification", RFC 8205, DOI 10.17487/RFC8205, September 2017, . [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, DOI 10.17487/RFC3704, March 2004, . [RFC8704] Sriram, K., Montgomery, D., and J. Haas, "Enhanced Feasible-Path Unicast Reverse Path Forwarding", BCP 84, RFC 8704, DOI 10.17487/RFC8704, February 2020, . 8.2. Informative References [RFC5123] White, R. and B. Akyol, "Considerations in Validating the Path in BGP", RFC 5123, DOI 10.17487/RFC5123, February 2008, . [RFC5635] Kumari, W. and D. McPherson, "Remote Triggered Black Hole Filtering with Unicast Reverse Path Forwarding (uRPF)", RFC 5635, DOI 10.17487/RFC5635, August 2009, . Liu, et al. Expires 25 April 2024 [Page 7] Internet-Draft Path Validation Problems Statement October 2023 [I-D.ietf-sfc-proof-of-transit-08] Brockners, F., Bhandari, S., Mizrahi, T., Dara, S., and S. Youell, "Proof of Transit", Work in Progress, Internet- Draft, draft-ietf-sfc-proof-of-transit-08, 1 November 2020, . [I-D.filsfils-spring-path-tracing-05] Filsfils, C., Abdelsalam, A., Camarillo, P., Yufit, M., Graf, T., Su, Y., Matsushima, S., Valentine, M., and Dhamija, "Path Tracing in SRv6 networks", Work in Progress, Internet-Draft, draft-filsfils-spring-path- tracing-05, 23 October 2023, . [I-D.gilman-wimse-use-cases-00] Gilman, E., Richer, J., Kasselman, P., and J. A. Salowey, "Workload Identity Use Cases", Work in Progress, Internet- Draft, draft-gilman-wimse-use-cases-00, 28 August 2023, . [BGPSEC] "Securing BGP with BGPsec", July 2011, . [BGPSECATTACK] "BGP with BGPsec":" Attacks and Countermeasures", August 2019, . [SECUREROUTINGFAIL] "Opinion":" Is secured routing a market failure?", December 2022, . [PATHVALIDATIONPAPER1] "Atomos":" Constant-Size Path Validation Proof", January 2020, . [PATHVALIDATIONPAPER2] "Unveiling the Mystery of Internet Packet Forwarding":" A Survey of Network Path Validation", September 2020, . [PATHVALIDATIONPAPER3] "Lightweight source authentication and path validation", August 2014, . Liu, et al. Expires 25 April 2024 [Page 8] Internet-Draft Path Validation Problems Statement October 2023 [PATHVALIDATIONPAPER4] "EPIC":" Every Packet Is Checked in the Data Plane of a Path-Aware Internet", January 2020, . Authors' Addresses Chunchi Liu Huawei 101 Ruanjian Ave Nanjing 210012 China Email: liuchunchi@huawei.com Qin Wu Huawei China Email: bill.wu@huawei.com Liang Xia Huawei China Email: frank.xialiang@huawei.com Liu, et al. Expires 25 April 2024 [Page 9]