Network Working Group X. Li Internet-Draft X. Wei Updates: draft-li- Beijing University of Posts and Telecommunications trustwort 24 February 2025 hy- routing-d iscovery- 00 (if approved) Intended status: Standards Track Expires: 28 August 2025 Trustworthy Routing Discovery draft-li-trustworthy-routing-discovery-00 Abstract End users with high security and privacy requirements expect their data to be transmitted only through trusted devices to mitigate the risk of data leakage. Therefore, the development of trustworthy routing mechanisms is anticipated to be a key trend in the future evolution of the internet. This specification describes a network architecture that supports trustworthy routing and a scheme for carrying trustworthy routing information (TRI) using the BGP and BGPsec protocols. 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 28 August 2025. Copyright Notice Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved. Li & Wei Expires 28 August 2025 [Page 1] Internet-Draft Trustworthy Routing Discovery February 2025 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. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.2. Requirements Notation . . . . . . . . . . . . . . . . . . 3 3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Protocol Design . . . . . . . . . . . . . . . . . . . . . . . 5 4.1. BGP . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 4.2. BGPsec . . . . . . . . . . . . . . . . . . . . . . . . . 8 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 6.1. Normative References . . . . . . . . . . . . . . . . . . 9 6.2. Informative References . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 1. Introduction In the existing network system, data transmission security is almost entirely achieved through end-to-end encryption. However, users with high security and privacy requirements are no longer satisfied with this mechanism. They now demand that traffic be forwarded only by network devices that meet their expected security properties. For example, some clients may require their data to traverse through trusted devices and links only, to avoid data being exposed to insecure devices, causing leakage. By utilizing remote attestation technology [RFC9334], network Autonomous Systems (AS) can provide evidence of the level of security they support. This evidence can be exchanged between ASes through existing network protocols, such as BGP [RFC4271] or BGPsec [RFC8205], and parsed by ASes that support trustworthy routing. Through distributed management, ASes can perceive the trustworthiness of other ASes and plan appropriate transmission paths according to the security requirements of endpoints' traffic. Note that despite the extensive body of work on trust assessment for devices, there is still no standardized framework for trustworthiness evaluation among researchers. Therefore, in this draft, a more flexible solution-the Trust Assessment Profile (TAP) is proposed, which contains a set of evaluation rules designed to assess whether a device meets specific Li & Wei Expires 28 August 2025 [Page 2] Internet-Draft Trustworthy Routing Discovery February 2025 trust requirements. Any network domain can maintain a set of TAPs, provided they are recognized by other domains. Within a domain, the orchestrator evaluates network devices based on specific TAPs and classifies them as either "trusted" or "untrusted" according to the rules of the current TAP. Additionally, we recommend advancing towards a multi-level trust classification in future research to enable more granular control over trust management. This document presents a network architecture that supports trustworthy routing and a scheme for carrying trustworthy routing information (TRI) using the BGP and BGPsec protocols. 2. Terminology 2.1. Terms The following terms are imported from [RFC9334]: Attester, Evidence, Verifier. Newly defined terms for this document: Trust Assessment Profile --- a set of rules that specify how the verifier evaluates the trustworthiness of the attester based on the evidence provided during the remote attestation process. Trustworthy Routing Information --- a series of messages that are exchanged between Autonomous Systems (AS) to propagate information regarding the trustworthiness of forwarding devices within the domain. Trust Assessment Result --- whether a network device meets a specific trust assessment profile, with the result being either "trusted" or "untrusted". 2.2. Requirements Notation 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. Architecture Li & Wei Expires 28 August 2025 [Page 3] Internet-Draft Trustworthy Routing Discovery February 2025 +---------------------------------+ | +--------+ +-------+ | | | | | | | +-+ | TAP 1 | ... | TAP n | +--+ | | | | | | | | | | +--------+ +-------+ | | | +---------------------------------+ | | | +--------------+--------------------------------------+---------------+ | +------+-------+ +------v-------+ | | | Verifer | | Verifer | | | | | .. | <-------+---------------+ | | Vendor A | | Vendor B & C | | | | +------^-------+ +------^-------+ | | +--------------+--------------------------------------+---------------+ | | Inter AS | Inter AS | +--------------+---------------+ API +--------------+---------------+ API +-------+------+ | | | | | | | | | | AS A +-----v------+ | | +-----v------+ AS B | |+------v-----+| | | |<-------+-------+------->| <--------+-------+> || | |Orchestrator| | | |Orchestrator| | ||Orchestrator|| | +----->| |<-----+ | | +----->| |<-----+ | || || | | +-----^------+ | | | | +-----^------+ | | |+--^---------+| | | | | | | | | | | | | | +--+-v----+ +----v----+ +-----v-+-+ +--+-v----+ +----v----+ +-----v-+-+ +--+---v--+ | |Attester | |Attester | |Attester | |Attester | |Attester | |Attester | |Attester | | |Vendor A1<-->Vendor A2<-->Vendor A3| |Vendor B1<-->Vendor B2<-->Vendor B3<-->Vendor C1| AS C | | (BR) | | (IR) | | (BR) <--> (BR) | | (IR) | | (BR) | | (BR) | | +--+------+ +---------+ +-------+-+ +--+------+ +---------+ +-------+-+ +--+------+ | | | | | | | +------------------------------+Routing+------------------------------+Routing+--------------+ UPDTE Msg. UPDTE Msg. Figure 1: Example architecture of trustworthy-routing supported network Figure 1 illustrates an example architecture of a trustworthy-routing supported network in a scenario involving multiple ASes. Please note that the proposed architecture is based on the "multi client-multi operator" framework from [nasr-arch]. With this architecture, each orchestrator is operated by the AS's operator and is responsible for managing devices (Attesters) within its domain, providing TRI to other ASes, and communicating with other ASes' orchestrators via the Inter-AS API to negotiate trustworthy routing policy flexibly. Each attester holds a remote attestation report issued by the verifier of its respective domain, indicating its trustworthiness assessment results (TAR). The TAR of an attester is determined by a set of remote attestation rules, which are described in a trust assessment Li & Wei Expires 28 August 2025 [Page 4] Internet-Draft Trustworthy Routing Discovery February 2025 profile (TAP) and identified by a globally unique identifier, i.e., the trust assessment profile ID. All verifiers maintain consensus on the TAP. Note that within this framework, the TAR of a device is relative, determined by whether it is considered trusted under the specific rules of a given TAP. TRI is propagated among ASes through BGP UPDATE or BGPsec UPDATE messages. How the BGP and BGPsec protocol stacks are extended to carry TRI will be explained later. With the assistance of BGP or BGPsec, each AS can perceive the TAR of other ASes and select appropriate paths for transmission according to the service requirements of the client. It is important to note that the design of this architecture also allows non-adjacent ASes to establish an L3 logical link through orchestrator negotiation, thereby shielding the trustworthiness of intermediate domains from affecting the entire transmission chain. For example, in Fig 1, supposing AS A and AS C are considered trusted under a specific TAP T, while AS B is not. Without additional measures, the transmission path from A to C cannot support the TAP T due to the trust bottleneck at B. In this case, orchestrators in AS A and AS C can negotiate and establish a logical link between the edge routers (A3 - C1) of the two domains using L3 security technologies (such as IPsec), thereby satisfying the requirement of TAP T in the data transmission from A to C. 4. Protocol Design This draft presents the implementation of inter-domain propagation of TRI using the BGP or BGPsec protocols. Specifically, these protocols are extended to carry TRI segments. Each segment contains the TRI of an AS that supports trustworthy routing along the path. The format of the TRI segment is shown in Figure 2. The first three fields represent the AS identifier that publishes the TRI, the identifier of the verifier that conducts the remote attestation for the AS, and the remote attestation report identifier, respectively. The attestation report ID can be provided as a URL, allowing the administrators of the BGP router's domain to directly access the report and verify its authenticity. The trust assessment profile ID indicates the TAP identifier adopted by the AS. The TAR denotes whether this AS can be considered trusted under the given TAP. The timestamp denotes the publication time of the remote attestation result, serving to ensure the freshness of this information so that it consistently reflects the attester's latest state. Additionally, each TRI segment contains a signature field, where the AS sign the entire segment using its private key to ensure the authenticity of the TRI issuer's identity and prevents tampering of the TRI field during transmission. The selection of algorithms and key formats in the signing process can be guided by [RFC8205]. Li & Wei Expires 28 August 2025 [Page 5] Internet-Draft Trustworthy Routing Discovery February 2025 +-----------------------------------+ | AS Number | +-----------------------------------+ | Verifier Name/ID | +-----------------------------------+ | Attestation Report ID | +-----------------------------------+ | Trust Assessment Profile ID | +-----------------------------------+ | TAR | +-----------------------------------+ | Timestamp | +-----------------------------------+ | Signature | +-----------------------------------+ Figure 2: TRI segment format This draft follows the passport model outlined in [RFC9334] to construct the data flow diagram between network entities. As shown in Figure 3, when BGP router 1 seeks to prove the TAR of its AS to a router in another AS, such as BGP router 2, it first conveys its state information, known as "evidence", to a verifier that compares this evidence against a specific TAP. The verifier then returns the attestation result to BGP router 1. BGP router 1 does not consume the attestation result, but caches it and further encapsulates it into the TRI following the format outlined in Fig. 2. BGP router 1 then presents this TRI to BGP router 2 via BGP or BGPsec protocol, and BGP router 2 checks this information to determine whether to accept it. Specifically, BGP router 2 first compares the TAP ID contained in this message to determine whether the TAP is supported within BGP router 2's AS. It then verifies the signature field to ensure the authenticity of the TRI and subsequently updates the TAR associated with the AS of BGP router 1. Li & Wei Expires 28 August 2025 [Page 6] Internet-Draft Trustworthy Routing Discovery February 2025 +------------+ +------------+ +------------+ | | | | | | |BGP Router 1| | Verifier | |BGP Router 2| | | | | | | +------+-----+ +------+-----+ +------+-----+ | | | | Evidence | | +--------------------------->| | | | | | Verification | | | | | Attestaion results | | |<---------------------------+ | | | | Encapsulate the results | | into the TRI | | | TRI | +----------------------------+--------------------->| | | | | | Check the TRI | | | Figure 3: The data flow diagram between network entities 4.1. BGP +---------------------------------------+ | Path attribute type (2 octet) | +---------------------------------------+ | Path attribute length (1 or 2 octecs) | +---------------------------------------+ | TRI segments (variable) | +---------------------------------------+ Figure 4: TRI path attribute format in BGP When using the BGP protocol, an extended field called the trustworthy routing path attribute is introduced to carry TRI. This extended field follows the TLV format and [RFC4271], as shown in Figure 4. The path attribute type is a 2 octets field that consists of the attribute flags and attribute type code, as shown in Figure 5. +---------------------------------------+ | Attribute Flags (1 octet) | +---------------------------------------+ | Attribute type code (1 octet) | +---------------------------------------+ Li & Wei Expires 28 August 2025 [Page 7] Internet-Draft Trustworthy Routing Discovery February 2025 Figure 5: Path attribute type format Since the trustworthy routing path attribute is an optional transitive BGP path attribute, the first two bits of its attribute flags are set to 11. The remaining 6 bits of the path flags are configured according to [RFC4271]. The attribute type code indicates that this path attribute carries TRI. The path attribute length is a 1-octet or 2-octet field that indicates the total length of the value field. The value field of the trustworthy routing path attribute contains a series of consecutively arranged TRI segments that represent the TRI along the path. 4.2. BGPsec +-------------------+-------------------+ | pCount (1 octet) | Flags (1 octet) | +-------------------+-------------------+ | AS Number (4 octets) | +---------------------------------------+ | TRI segment | +---------------------------------------+ Figure 6: The secure_path segment format of trustworthy-routing supported BGPsec When using the BGPsec protocol, the TRI segment for each AS is separately placed within the corresponding secure_path segment, as shown in Figure 6. One of the seven unassigned bits in the Flags field is used to indicate whether the AS supports trustworthy routing, referred to as the E_T_R Flag in Figure 7. If E_T_R Flag = 0, the AS does not support trustworthy routing, and the routing update message will be parsed according to the original BGPsec protocol. If E_T_R Flag = 1, the AS supports trustworthy routing, and its TRI will be included in the corresponding secure_path segment. +-------------------+-------------------+-----------------------+ | C_S Flag (1 bit) | E_T_R Flag (1 bit)| Unassigned (6 bits) | +-------------------+-------------------+-----------------------+ Figure 7: Flags format It is important to note that the AS number is already included in the secure_path segment of BGPsec, so this information is omitted from the TRI. Additionally, since BGPsec already applies a signature mechanism to ensure the authenticity of the secure_path, the signature field in the TRI segment is also omitted. Li & Wei Expires 28 August 2025 [Page 8] Internet-Draft Trustworthy Routing Discovery February 2025 5. Security Considerations This document has no further security considerations. 6. References 6.1. Normative References [RFC9334] Birkholz, H., Thaler, D., Richardson, M., Smith, N., and W. Pan, "Remote ATtestation procedureS (RATS) Architecture", RFC 9334, DOI 10.17487/RFC9334, January 2023, . [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, . 6.2. Informative References [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, DOI 10.17487/RFC4271, January 2006, . [RFC8205] Lepinski, M., Ed. and K. Sriram, Ed., "BGPsec Protocol Specification", RFC 8205, DOI 10.17487/RFC8205, September 2017, . [nasr-arch] Liu, C., Chen, M., Richardson, M., and D. Lopez, "Network Attestation for Secure Routing (NASR) Architecture", October 2024, . Authors' Addresses Xiaoyong Li Beijing University of Posts and Telecommunications No.10 Xitucheng Road Beijing 100876 China Email: lixiaoyong@bupt.edu.cn Li & Wei Expires 28 August 2025 [Page 9] Internet-Draft Trustworthy Routing Discovery February 2025 Xinghai Wei Beijing University of Posts and Telecommunications No.10 Xitucheng Road Beijing 100876 China Email: junjuntvt@bupt.edu.cn Li & Wei Expires 28 August 2025 [Page 10]