Network Working Group C. Liu, Ed. Internet-Draft Q. Wu Intended status: Standards Track L. Xia Expires: 10 January 2024 Huawei Technologies 9 July 2023 On Network Path Validation draft-liu-on-network-path-validation-00 Abstract Network path validation refers to a technology that ensures data packets to strictly travel along a chosen network path. It aims to enforce data to travel only on the assigned network path and provide evidence that the data has indeed followed this path. While existing efforts primarily focus on the control plane, path validation protects and monitors routing security in the data plane. This document provides a technical definition of the Network Path Validation problem, briefly overviews past efforts, models its ideal solution and design goals, and lists out different use case across various layers of the Internet. 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 10 January 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. Liu, et al. Expires 10 January 2024 [Page 1] Internet-Draft On Network Path Validation July 2023 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Use Case 1: Proof of Service Level Assurance . . . . . . 3 2.2. Use Case 2: Proof of Security Service Processing . . . . 4 2.3. Use Case 3: Security-sensitive Communication . . . . . . 4 3. Design Goals . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Modelling the Ideal Solution . . . . . . . . . . . . . . . . 5 4.1. Roles: . . . . . . . . . . . . . . . . . . . . . . . . . 5 4.2. Required Functionality: . . . . . . . . . . . . . . . . . 5 5. Security . . . . . . . . . . . . . . . . . . . . . . . . . . 6 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 7.1. Normative References . . . . . . . . . . . . . . . . . . 7 7.2. Informative References . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 1. Introduction In the current Internet architecture, the network layer provides best-effort service to the endpoints using it [RFC9217]. 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 [RFC9217][PAIA]. 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 [RFC7908], causing unintended ASes to receive traffic. Liu, et al. Expires 10 January 2024 [Page 2] Internet-Draft On Network Path Validation July 2023 * 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) [RFC6810] 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 [RFC8205] 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 [I-D.ietf-sfc-proof-of-transit-08]. 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. 2. 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. 2.1. 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 Liu, et al. Expires 10 January 2024 [Page 3] Internet-Draft On Network Path Validation July 2023 premium routing nodes. Additionally, it is important to provide Alice with verifiable proof that such premium services are indeed being delivered. 2.2. 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. 2.3. 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 [BADCRYPTOIMPL1][BADCRYPTOIMPL2]. 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. 3. Design Goals As the name suggests, the Network Path Validation mechanism aims to achieve two main goals: 1. Enforcement: Committing to a given network path and enforcing traffic to traverse the designated nodes in the specified order. 2. 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. Liu, et al. Expires 10 January 2024 [Page 4] Internet-Draft On Network Path Validation July 2023 1. 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. 2. Transit Proof: A transit proof is a cryptographic proof that securely logs the exact nodes transited by this data packet. 4. Modelling the Ideal Solution 4.1. 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. 4.2. Required Functionality: The path validation mechanism consists of the following algorithms: 1. Configure: Setup control plane parameters based on a security parameter. * Input: Security parameter * Output: Control plane parameter distributed 2. 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 Liu, et al. Expires 10 January 2024 [Page 5] Internet-Draft On Network Path Validation July 2023 3. 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 4. 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. 5. 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) Liu, et al. Expires 10 January 2024 [Page 6] Internet-Draft On Network Path Validation July 2023 * *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. 6. IANA Considerations This document has no IANA actions. 7. References 7.1. Normative References [RFC8205] Lepinski, M., Ed. and K. Sriram, Ed., "BGPsec Protocol Specification", RFC 8205, DOI 10.17487/RFC8205, September 2017, . [RFC6810] Bush, R. and R. Austein, "The Resource Public Key Infrastructure (RPKI) to Router Protocol", RFC 6810, DOI 10.17487/RFC6810, January 2013, . 7.2. Informative References [RFC9217] Trammell, B., "Current Open Questions in Path-Aware Networking", RFC 9217, DOI 10.17487/RFC9217, March 2022, . [RFC7908] Sriram, K., Montgomery, D., McPherson, D., Osterweil, E., and B. Dickson, "Problem Definition and Classification of BGP Route Leaks", RFC 7908, DOI 10.17487/RFC7908, June 2016, . [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, . Liu, et al. Expires 10 January 2024 [Page 7] Internet-Draft On Network Path Validation July 2023 [PAIA] "Adding Path Awareness to the Internet Architecture", April 2018, . [BADCRYPTOIMPL1] "Secure coding practices in Java":" challenges and vulnerabilities", May 2018, . [BADCRYPTOIMPL2] "Mining Your Ps and Qs":" Detection of Widespread Weak Keys in Network Devices", August 2012, . Authors' Addresses Chunchi Liu (editor) Huawei Technologies 101 Ruanjian Ave Nanjing 210012 China Email: liuchunchi@huawei.com Qin Wu Huawei Technologies China Email: bill.wu@huawei.com Liang Xia Huawei Technologies China Email: frank.xialiang@huawei.com Liu, et al. Expires 10 January 2024 [Page 8]