Trust-enhanced Path Routing: Problem Statement and Use Cases
draft-liu-trust-enhanced-path-routing-00
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Xiang Liu , Yanchen Qiao , Yu Zhang | ||
| Last updated | 2024-02-29 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-liu-trust-enhanced-path-routing-00
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,
<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,
May 2017, <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, June
2016, <https://www.rfc-editor.org/rfc/rfc7908>.
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,
<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", 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]