Trust-enhanced Path Routing: Problem Statement and Use Cases

Introduction In current Internet architecture, the network layer provides best-effort services to endpoints. 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,and etc.
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. 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 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.

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 when, and only when, they appear in all capitals, as shown here.

Design Goals The trust-enhanced path routing mechanism aims to achieve three main goals.

Measurable: The trust value of any given object or entity can be quantitatively measured.
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
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.

Use Cases

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. | |<--->| Router |<--->| |<--->| Service A | +--------+ | | +----+----+ | | +-----------+ | | | | | | | | +--------+ | | +----+----+ | | +-----------+ | User B |<--->| Ingress |<--->| Router |<--->| Egress |<--->| Service B | +--------+ | | +----+----+ | | +-----------+ | | | | | | | | +--------+ | | +----+----+ | | +-----------+ | User C |<--->| |<--->| Router |<--->| |<--->| Service C | +--------+ +---------+ +----+----+ +-----+--+ +-----------+ Figure 1: Different services with different trust levels ]]>

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 ]]>

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.

IANA Considerations This memo includes no request to IANA.

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.

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.
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 .