Internet Engineering Task Force X. Liu, Ed. Internet-Draft Y. Qiao, Ed. Intended status: Informational Y. Zhang, Ed. Expires: 1 September 2024 Pengcheng Laboratory 29 February 2024 Trust-enhanced Path Routing: Problem Statement and Use Cases draft-liu-trust-enhanced-path-routing-00 Abstract Digital trust refers to the measurable confidence of one entity posts on another about accomplishing some task in the digital world. This document introduces the concept of trust into the networking and routing area, and proposes the idea of trust-enhanced path routing, elaborates the key technical problems and design goals, and also lists some use cases. 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 1 September 2024. Copyright Notice Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. Liu, et al. Expires 1 September 2024 [Page 1] Internet-Draft Trust enhanced Path Routing February 2024 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 3. Design Goals . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4.1. Use case 1: end-to-end routing paths with different trust levels to meet diverse service requirements . . . . . . . 5 4.2. Use case 2: Wireless network with heterogeneous equipment in both radio access network and core network . . . . . . 5 4.3. Use case 3: Proof of Service Funtion Chaining with Different Trust Level Assurance . . . . . . . . . . . . . 6 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 7.1. Normative References . . . . . . . . . . . . . . . . . . 7 7.2. Informative References . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 1. Introduction In current Internet architecture, the network layer provides best- effort services to endpoints[RFC9217]. Data packets are forwarded by the routers along the data transmisison path. To provide better user experience, data packet may be forwarded based on the Quality of Service specified in the packet headers. In recent years, as more and more high-value services are brought online, criminals targeting on these services are also moved from offline to online. Security and trustworthiness of data transmission become a severe concern of Internet users. Existing security techonologies such as end-to-end encryption are not sufficient, there still exist several issues which undermines the security and trustworthiness of data transmission over Internet. * Routing attacks, including prefix hijack, route injectin, route leak[RFC7908],and etc. Liu, et al. Expires 1 September 2024 [Page 2] Internet-Draft Trust enhanced Path Routing February 2024 * Users are unaware of and have no control on how traffic is steered from the sender to the recepient, therefore lack of confidence that the transmission can be trusted. * End-to-end encryption is not sufficient to protect the confidentiality of highly sensitive traffic, since there may exist backdoors or malicious codes inside the network functions or network devices. Even though strong encrytion mechanisms have been implemented, the adversaries may break it down several years later once crypto-attacking techniques such as quantum computing are powerful enough. * The trustworthiness of network entities is not attested, so end users actually cannot be sure of to what extent they can trust the underlying Internent infrastructure. To overcome these issues, one way is to integrate the concept of trust into networking and data transmission, so the trustworthiness of the underlaying network infrastructures can be guaranteed to the services and users. Trusted path routing scheme has been proposed in the IETF RATS working group, where the trustworthiness of routers is attested based on the evidence received via remote attestation protocols[I-D.draft-voit-rats-trustworthy-path-routing-09]. However, simply classifying routers into two levels, trusted or untrusted, are too coarse-grained to satisfy the requrements of diversified applications. Data packets from different applications have different requirements on the trustworthiness. For instance, military or secret government applications may have very strict requirements on the data confidentiality and integrity, therefore require the routers to be very highly trusted. On the other hand, some kinds of entertainment applications like web browsing may only require the routers to be moderately or even minimally trusted. In this case, it is appropraite to introcude the concept of trust- enhanced path routing, to create a mechanism by which end-to-end routing path with different trust levels can be established to satisfy the diversed applications. This raises the question of how to select end-to-end routing path for diverse services and end users with different requirement for trust level. To be more specific, the question can be further divided into three parts. * First, how different service providers and end users can quantatively evaluate their trust requirements, and then map their requirements to the trust level of the routing path * Second, for a specific routing and transmission task, how to implement trust-aware end-to-end routing. The may exist two approaches. The first is that the sender and recipient can be Liu, et al. Expires 1 September 2024 [Page 3] Internet-Draft Trust enhanced Path Routing February 2024 aware of the trust-related information of the network, and then selecta path which can meet their requirement. The second is that the sender may convey the requirements to the network, and the network controller or path calculation element can derive the path accordingly. * Third, given a routing path for a specific service, how can the sender and recipient be sure that the data traffic is strictly steered along it. 2. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 3. Design Goals The trust-enhanced path routing mechanism aims to achieve three main goals. 1. Measurable: The trust value of any given object or entity can be quantitatively measured. 2. Configurable: Mechanisms should be provided to enable trust configuration, including but not limited to: (1) interfaces, protocols, or extensions supporting exchange of trust-related information between transmission-layer and control-layer; (2) interfaces, protocols and extensions supporting network devices to exchange trust-related information ,both intra-domain and inter-domain; (3) mechanisms supporting trust-aware routing and path calculation 3. Verifiable: Given a routing path calculated according to the specific trust requirement of the service, it can be verified that the traffic is exactly steered along this path. 4. Use Cases Liu, et al. Expires 1 September 2024 [Page 4] Internet-Draft Trust enhanced Path Routing February 2024 4.1. Use case 1: end-to-end routing paths with different trust levels to meet diverse service requirements There are various types of services consumed by various end uers, which relying on the underlying Internet to provide data transmission capability. In essence, different Internet services and applications have different requirements on the trust level of routing paths and network devices. For instance, some applications where highly sensitive data are exchanged might require the network devices to be high trusted, whereas other applications like on-line gaming and video streaming do not have stringent requirement on the trust level. As shown in Figure 1, for customers with different requirements on the trust level of network devices, ISPs need to provide different options for them to choose the data transmission path which can satisfy their demands. In this example, assuming that the requirements on the trust levle of User A, B, and C are high-trust, medium-trust and low-trust respectively, then the network domain can provide different end-to-end path for them to meet their diversified requirements. +--------+ +---------+ +----+----+ +--------+ +-----------+ | User A |<--->| |<--->| Router |<--->| |<--->| Service A | +--------+ | | +----+----+ | | +-----------+ | | | | | | | | +--------+ | | +----+----+ | | +-----------+ | User B |<--->| Ingress |<--->| Router |<--->| Egress |<--->| Service B | +--------+ | | +----+----+ | | +-----------+ | | | | | | | | +--------+ | | +----+----+ | | +-----------+ | User C |<--->| |<--->| Router |<--->| |<--->| Service C | +--------+ +---------+ +----+----+ +-----+--+ +-----------+ Figure 1: Different services with different trust levels 4.2. Use case 2: Wireless network with heterogeneous equipment in both radio access network and core network Wireless networks are one of the most critical part of communication infrastructure. Over billions of devices are connected to the internet via wireless networks, such as Wi-Fi networks at home, coffee shop, airport or shopping malls. In these networks, many equipment are manufectured by different vendors, and comply with different specifications or generations. For example, wireless Liu, et al. Expires 1 September 2024 [Page 5] Internet-Draft Trust enhanced Path Routing February 2024 access point (AP) may consists of Wi-Fi APs which comply with different specifications, e.g. 802.11n, 802.11ac, 802.11ad, etc. The technologies used in these equipment span over 20 years and have signifgicant differences. One example is that some Wi-Fi deployed at coffee shop does not require authentication and data packets are transmitted over the air without protection. On the other hand, Wi- Fi APs deployed by operators or enterprises provide solid authentication and encryption algorithms, and data packets and user privacy are well protected. Obviously, equally treating the network equipment of different generations and different deployment scenario in the sense of trustworthiness is not appropriate. The level of trust of those heterogenous network equipment should be evaluated, and end-users and service providers should be aware of the evaluation results so that the appropriate network equipment with required trust level can be used to perform data transmission tasks. +--------+ +-------------+ +----------------+ +----------+ | |<--->| Wi-Fi AP |<--->| Core Network 1 |<--->| | | | | (Operators) | | | | | | | +-------------+ +----------------+ | | | | | | | | +-------------+ +----------------+ | | | Mobile | | Wi-Fi AP | | | |Internet | | Device |<--->| (Home) |<--->| Core Network 2 |<--->| | | | +-------------+ +----------------+ | | | | | | | | +-------------+ +----------------+ | | | | | Wi-Fi AP | | | | | | |<--->| (Shop) |<--->| Core Network 3 |<--->| | +--------+ +-------------+ +----------------+ +----------+ Figure 2: Mobile devices access to the Internet via different generations of mobile communication networks 4.3. Use case 3: Proof of Service Funtion Chaining with Different Trust Level Assurance Service Function Chaining enables the provisioning of a series of services to a specific data flow, such as firewall filtering and intrusion detection/prevention systems. For any kind of service, service Providers may have different service nodes with different service qualities or trust assurance levels, and deservedly with different prices. In this context, it is reasonable for the customers to choose services with specific trust auusrance levels which can optimally map their requirements, from both technical and financial aspects. And for the service providers, it is obligated to provide end-to-end service functions with demanding trust assurance levels to the customers and provide a method such that customers can Liu, et al. Expires 1 September 2024 [Page 6] Internet-Draft Trust enhanced Path Routing February 2024 verify that all requirements are satified. 5. IANA Considerations This memo includes no request to IANA. 6. Security Considerations As discussed above, the core spirit of trust-enhanced path routing is to enable applications choose an end-to-end path with a certain trust level that can meet its requirement, and at the same time it can verify that the selected path is indeed validated without any unintended modifications. In this context, several key security issues should be considered. 1. Authentication and authorization: when a user or application request to build a tansmission path with a certain trust level, it should be authenticated and verified to be authority-granted. 2. Path verification: the user or application should be able to verify that the data flow is exactly traversed along the designated path. An IETF draft where a mechanism call "path validation" has been introduced has recently been proposed to address this problem [I-D.draft-liu-path-validation-problem-statement-00]. 7. References 7.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 7.2. Informative References [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, . Liu, et al. Expires 1 September 2024 [Page 7] Internet-Draft Trust enhanced Path Routing February 2024 [RFC9217] Trammell, B., "Current Open Questions in Path-Aware Networking", RFC 9217, DOI 10.17487/RFC9217, March 2022, . [I-D.draft-voit-rats-trustworthy-path-routing-09] Voit, E., Gaddam, G., Fedorkow, G., Birkholz, H., and M. Chen, "Trusted path routing", February 2024. [I-D.draft-liu-path-validation-problem-statement-00] Liu, C., Wu, Q., and L. Xia, "Path validation problem statement history gap analysis and use cases", October 2023. Authors' Addresses Xiang Liu (editor) Pengcheng Laboratory No.2 Xingke 1 Street Shenzhen 518055 China Email: liux15@pcl.ac.cn Yanchen Qiao (editor) Pengcheng Laboratory No.2 Xingke 1 Street Shenzhen 518055 China Email: qiaoych@pcl.ac.cn Yu Zhang (editor) Pengcheng Laboratory No.2 Xingke 1 Street Shenzhen 518055 China Email: zhangy08@pcl.ac.cn Liu, et al. Expires 1 September 2024 [Page 8]