Internet-Draft Trust enhanced Path Routing February 2024
Liu, et al. Expires 1 September 2024 [Page]
Workgroup:
Internet Engineering Task Force
Internet-Draft:
draft-liu-trust-enhanced-path-routing-00
Published:
Intended Status:
Informational
Expires:
Authors:
X. Liu, Ed.
Pengcheng Laboratory
Y. Qiao, Ed.
Pengcheng Laboratory
Y. Zhang, Ed.
Pengcheng Laboratory

Trust-enhanced Path Routing: Problem Statement and Use Cases

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.

Table of Contents

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.

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.

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

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 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 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, , <https://www.rfc-editor.org/info/rfc2119>.
[RFC8174]
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/info/rfc8174>.

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, , <https://www.rfc-editor.org/rfc/rfc7908>.
[RFC9217]
Trammell, B., "Current Open Questions in Path-Aware Networking", RFC 9217, DOI 10.17487/RFC9217, , <https://www.rfc-editor.org/rfc/rfc9217>.
[I-D.draft-voit-rats-trustworthy-path-routing-09]
Voit, E., Gaddam, G., Fedorkow, G., Birkholz, H., and M. Chen, "Trusted path routing", .
[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", .

Authors' Addresses

Xiang Liu (editor)
Pengcheng Laboratory
No.2 Xingke 1 Street
Shenzhen
518055
China
Yanchen Qiao (editor)
Pengcheng Laboratory
No.2 Xingke 1 Street
Shenzhen
518055
China
Yu Zhang (editor)
Pengcheng Laboratory
No.2 Xingke 1 Street
Shenzhen
518055
China