Cisco Systems, Inc.

evoit@cisco.com

Security RATS Working Group Internet-Draft There are end-users who believe encryption technologies like IPSec alone are insufficient to protect the confidentiality of their highly sensitive traffic flows. These end-users want their flows to traverse devices which have been freshly appraised and verified. This specification describes Trusted Path Routing. Trusted Path Routing protects sensitive flows as they transit a network by forwarding traffic to/from sensitive subnets across network devices recently appraised as trustworthy.

There are end-users who believe encryption technologies like IPSec alone are insufficient to protect the confidentiality of their highly sensitive traffic flows. These customers want their highly sensitive flows to be transported over only network devices recently verified as trustworthy. With the inclusion of TPM based cryptoprocessors into network devices, it is now possible for network providers to identify potentially compromised devices as well as potentially exploitable (or even exploited) vulnerabilities. Using this knowledge, it then becomes possible to redirect sensitive flows around these devices. Trusted Path Routing provides a method of establishing Trusted Topologies which only include trust-verified network devices. Membership in a Trusted Topology is established and maintained via an exchange of Stamped Passports at the link layer between peering network devices. As links to Attesting Devices are appraised as meeting at least a minimum set of formally defined Trustworthiness Levels, the links are then included as members of this Trusted Topology. Routing protocols like can then used to propagate topology state throughout a network. IP Packets to and from end-user designated Sensitive Subnets are then forwarded into this Trusted Topology at each network boundary. The specification works under the following assumptions: A set of network devices supporting the TPM remote attestation profile as laid out in are connected within a network domain. A routing protocol capable of maintaining multiple forwarding topologies connects these network devices. One or more Verifiers continuously appraise each of network devices, and these Verifiers can return the Attestation Results back to the attesting network device.

The following terms are imported from : Attester, Evidence, Passport, Relying Party, and Verifier. Newly defined terms for this document: a device where a Verifier’s most recent appraisal of Evidence has returned a Trustworthiness Vector. a bundle of Evidence which includes at least signed Attestation Results from a Verifier, and two independent TPM quotes from an Attester. an IP address range where IP packets to or from that range desire confidentially guarantees beyond those of non-identified subnets. In practice, flows to or from a Sensitive Subnet must only have their IP headers and encapsulated payloads accessible/visible only by Attested Devices supporting one or more Trustworthiness Vectors. a network device within an network domain where any packets originally passed into that network domain are completely opaque on that network device at Layer 3 and above. a topology which includes only Attested Devices and Transparently-Transited Devices. a specific quanta of trustworthiness which can be assigned by a Verifier. a set of Trustworthiness Levels assigned during a single assessment cycle by a Verfier using Evidence and Claims related to an Attested Device. The vector is included within Attestation Results.

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.

An end user identifies sensitive IP subnets where flows with applications using these IP subnets need enhanced privacy guarantees. Trusted Path Routing passes flows to/from these Sensitive Subnets over a Trusted Topology able to meet these guarantees. The Trusted Topology itself consists of the interconnection of network devices where each potentially transited device has passed a recent trustworthiness appraisal. Different guarantees of end-to-end trustworthiness appraisal may be offered to network users. These guarantees are network operator specific, but might include options such as: all transited devices are currently boot integrity verified all transited devices are from a specific set of vendors and are running known software containing the latest patches no guarantees provided

To be included in a Trusted Topology, Evidence of trustworthiness is shared between network device peers (such as routers). Upon receiving and appraising this Evidence as part of link layer authentication, the network device peer decides if this link should be added as an active adjacency for the Trusted Topology. When enough links have been successfully added, a Trusted Topology will come into existence as routing protocols flood the adjacency information across the network domain.

---------------====================

Traffic exchanged with Sensitive Subnets can then be forwarded into that Trusted Topology from all edges of the network domain.

Critical to the establishment and maintenance of a Trusted Topology is the Stamped Passport. A Stamped Passport is comprised of Evidence from both an Attester and a Verifier. Stamped Passports are exchanged between adjacent network devices over a link layer protocols like 802.1x or MACSEC. As both sides of a link may need might need to appraise the other, independent Stamped Passports will often be transmitted from either side of the link. Additionally, as link layer protocols will continuously re-authenticate the link, this allows for fresh Stamped Passports to be constantly appraised by either side of the connection. Each Stamped Passport will include the most recent Verifier provided Attestation Results, as well as the most recent TPM Quote for that Attester. Upon receiving this information as part of link layer authentication, the Relying Party Router appraises the results and decides if this link should be added to a Trusted Topology. describes this flow of information using the time definitions described in , and the information flows defined in Section 7 of .

| | | time(RG) | |<------Attestation Result--(2) | ~ ~ ~ time(VG')? | | ~ ~ ~ |<------nonce---------------------------------(3)time(NS') | | | time(EG')(4)------Stamped Pat--------------------------->| | | (5)time(RG',RA') (6) ~ time(RX') ]]>

Specifics for each one of these information flows, including details on what happens at the items numbered (1) through (5) are described in .

For Trusted Path Routing to operate, fresh Attestation Results need to be communicated by a Verifier back to the Attester. These Attestation Results must be encoded in a way which is known and actionable. To support this requirement, specific levels of appraised trustworthiness have been defined. These are known as Trustworthiness Levels. It is these Trustworthiness Levels which are asserted as part of the Attestation Results by a Verifier. It is out of the scope of this document for the Verifier to provide proof or logic on how the assertion was derived. Following are the set of available Trustworthiness Levels: Trustworthiness Level Definition hw-authentic A Verifier has appraised an Attester as having authentic hardware fw-authentic A Verifier has appraised an Attester as having authentic firmware hw-verification-fail A Verifier has appraised an Attester has failed its hardware or firmware verification identity-verified A Verifier has appraised and verified an Attester’s unique identity identity-fail A Verifier has been unable to assess or verify an Attester’s unique identity boot-verified A Verifier has appraised an Attester as Boot Integrity Verified boot-verification-fail A Verifier has appraised an Attester has failed its Boot Integrity verification files-verified A Verifier has appraised an Attester’s file system, and asserts that it recognizes relevant files file-repudiated A Verifier has found a file on an Attester which should not be present A quick look at the list above shows that multiple Trustworthiness Level will often be applicable at single point in time. To support this, the Attestation Results will include a single Trustworthiness Vector consisting of a set of Trustworthiness Levels. The establishment of this Trustworthiness Vector follows the following logic on the Verifier:

As Evidence changes, a new Trustworthiness Vector needs to be returned to the Attester as Attestation Results. But this Trustworthiness Vector is not all that needs to be returned. Following is a YANG tree for all the returned objects. Each of these objects will later be used as Evidence by another Verifier which is co-resident with the Relying Party.

Looking at the objects above, if the Attester has a TPM2, then the values of the TPM PCRs are included (i.e., <TPM2B_DIGEST>, <TPM2_Algo>, and <pcr-index>), as are the timing counters from the TPM (i.e., <clock>, <reset-counter>, <restart-counter>, and <safe>). Likewise if the Attester has a TPM1.2, the TPM PCR values of the <pcr-index> and <pcr-value> are included. Timing information comes from the Verifier itself via the <timestamp> object. For both the TPM1.2 and the TPM2, there are other Attestation Results which are sent. These are the Attester’s TPM key (i.e., <public-key>, <public-key-format>, and <public-key-algorithm-type>). This key later will allow the Relying Party router to appraise a subsequent TPM Quote. It is this signature which allows the Trustworthiness Vector to be later provably associated with a recent TPM Quote.

The Attestation Results are not the only item which a Relying Party needs to consider during its appraisal. A provably recent TPM Quote from the Attester must also be included. With these two items, the resulting Stamped Passports formats described below must be converted to CDDL and passed over EAP. If an Attester includes a TPM2, the objects are:

And if the Attester is a TPM1.2, the object are:

With either of these passport formats, if the <latest-tpm-quote> is verifiably fresh, then the state of the Attester can be appraised by a network peer.

When it receives a Stamped Passport, a Verifier co-resident with the Relying Party on a network peer can make nuanced decisions about how to handle traffic coming from that link. For example, when the Attester’s TPM hardware identity credentials can be verified, it might choose to accept link layer connections and forward generic Internet traffic. Additionally, if the Attester’s Trustworthiness Vector is acceptable to the Relying Party, and it hasn’t been too long since the Verifier has provided a Stamped Passport, the Relying Party can include that link in a Trusted Topology. As the process described above repeats across the set of links within a network domain, Trusted Topologies can be extended and maintained. Traffic to and from Sensitive Subnets is then identified at the edges of the network domain and passed into this Trusted Topology.

| | | '-----' | | (5) & (6) | '-------------' '---------------' ]]>

In above, Evidence from a TPM is generated and signed by that TPM. This Evidence is appraised by Verifier A, and the Attester is given a Trustworthiness Vector which is signed and returned as Attestation Results to the Attester. Later, when a request comes in from a Relying Party, the Attester assembles and returns three independently signed elements of Evidence. These three comprise the Stamped Passport which when taken together allow Verifier B to appraise and set the current Trustworthiness Vector of the Attester. More details on the mechanisms used in the construction and verification of the Stamped Passport are listed below. These numbers match to the numbered steps of : An Attester sends a signed TPM Quote which includes PCR measurements to Verifier A at time(EG). Verifier A appraises (1), then sends the following items back to that Attester as Attestation Results: the Trustworthiness Vector of an Attester, the PCR state information from the TPM Quote of (1), time information associated with the TPM Quote of (1), the Public Attestation Key which it used to validate the TPM Quote of (1), and a Verifier signature across (2.1) though (2.4). At time(EG’) a nonce known to the Relying Party is sent to the Attester . The Attester generates and sends a Stamped Passport. This Stamped Passport includes: The Attestation Results from (2) New signed, verifiably fresh PCR measurements from time(EG’), which incorporates the nonce from (3). On receipt of (4), the Relying Party makes its determination of how the Stamped Passport will impact adjacencies within a Trusted Topology. The decision process is: Verify that (4.2) includes the nonce from (3). Use a local certificate to validate the signature (4.1). Use the Attestation Results provided public key info of (2.4) to validate the signatures of (4.2). Failure of (5.1) through (5.3) means the link does not meet minimum validation criteria, therefore appraise the link as having a null Trustworthiness Vector. Jump to step (6). If all PCR values from (2.2) equal those (4.2), then Relying Party can accept (2.1) as the link’s Trustworthiness Vector. Jump to step (6). If the PCR state information of (2.2) doesn’t equal (4.2), and not much time has passed between time(EG) and time(EG’), the Relying Party accepts any previous Trustworthiness Vector. (Note: rather than accepting, it is also viable to attempt to acquire a new Stamped Passport. Where is used, it should only be a few seconds before a new Attestation Results are delivered to an Attester via (2).) When the PCR state information is different, and there is a large or uncertain time gap between time(EG) and time(EG’), the link should be assigned a null Trustworthiness Vector. Take action based on Verifier B’s appraised Trustworthiness Vector: Include the link within any Trusted Topology for which that Trustworthiness Vector is qualified. Remove the link from any Trusted Topology for which that Trustworthiness Vector is not qualified.

This section defines one set of protocols which can be used for Trusted Path Routing. The protocols include or , ISIS , YANG subscriptions , and methods. Other alternatives are also viable.

A Trusted Topology such as one established by ISIS exists in an IGP domain for the forwarding of Sensitive Subnet traffic. This Topology will carry traffic across a set of devices which currently meet at a defined set of Trustworthiness Vectors. Customer designated Sensitive Subnets and their requested Trustworthiness Vectors have been identified and associated with external interfaces to/from the edge of a network. Traffic to a Sensitive Subnet can be passed into the Trusted Topology. Verifiers A and B are able to verify or signatures of an Attester. Verifier B trusts information signed by Verifier A. Verifier B has also been pre-provisioned with certificates or public keys necessary to confirm that Stamped Passports came from Verifier A Within a network, a Relying Party is able to use affinity to include/exclude links as part of the Trusted Topology based on this appraisal.

The numbering in below matches to the steps in . Step (1) There are two alternatives for Verifier A to acquires Evidence including a TPM Quote from the Attester: Subscription to the <attestation> stream defined in . Note: this method is recommended as it will minimize the interval between when a PCR change is made in a TPM, and when the PCR change appraisal is incorporated within a subsequent Stamped Passport. The RPCs <tpm20-challenge-response-attestation> or <tpm12-challenge-response-attestation> defined in device Step (2) The delivery of these Attestation Results back to the Attester MAY be done via an operational datastore write to the YANG module <ietf-attestation-results-vector>. Step (3) At time(NS’) a Relying Party makes a Link Layer authentication request to an Attester via a either or . This connection request must include credentials. Specifics of the EAP mapping to the Stamped Passport is tbd. Step (4) Upon receipt of (3), a Stamped Passport is generated as per , and sent to the Relying Party. Note that with or , steps (3) & (4) will repeat periodically independently of any subsequent iteration (1) and (2). This allows for periodic reauthentication of the link layer in a way not bound to the updating of Verifier A’s Attestation Results. Step (5) Upon receipt of (4), the Relying Party appraises the Stamped Passport as per . Following are relevant mappings which replace generic steps from with specific objects available with a TPM1.2 or TPM2.0. TPM2.0 - Bindings/details (5.5): If the <TPM2B_DIGEST>, <TPML_PCR_SELECTION>, <reset-counter>, <restart-counter> and <safe> are equal between the Attestation Results and the TPM Quote at time(EG’) then Relying Party can accept (2.1) as the link’s Trustworthiness Vector. Jump to step (6). (5.6): If the <reset-counter>, <restart-counter> and <safe> are equal between the Attestation Results and the TPM Quote at time(EG’), and the <clock> object from time(EG’) has not incremented by an unacceptable number of seconds since the Attestation Result, then Relying Party can accept (2.1) as the link’s Trustworthiness Vector. Jump to step (6). (5.7): Assign the link a null Trustworthiness Vector. TPM1.2 - Bindings/details (5.5): If the <pcr-index>’s and <tpm12-pcr-value>’s are equal between the Attestation Results and the TPM Quote at time(EG’), then Relying Party can accept (2.1) as the link’s Trustworthiness Vector. Jump to step (6). (5.6): If the time hasn’t incremented an unacceptable number of seconds from the Attestation Results <timestamp> and the system clock of the Relying Party, then Relying Party can accept (2.1) as the link’s Trustworthiness Vector. Jump to step (6). (5.7): Assign the link a null Trustworthiness Vector. Step (6) After the Trustworthiness Vector has been validated or reset, based on the link’s Trustworthiness Vector, the Relying Party may adjust the link affinity of the corresponding ISIS topology. ISIS will then replicate the link state across the IGP domain. Traffic will then avoid links which do not have a qualifying Trustworthiness Vector.

This YANG module imports modules from , and .

ietf-attestation-results-vector@2020-09-17.yang module ietf-attestation-results-vector { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-attestation-results-vector"; prefix arv; import ietf-yang-types { prefix yang; } import ietf-tpm-remote-attestation { prefix tpm; reference "draft-ietf-rats-yang-tpm-charra"; } import ietf-crypto-types { prefix ct; reference "RFC XXXX: Common YANG Data Types for Cryptography (currently draft-ietf-netconf-crypto-types)"; } import ietf-tcg-algs { prefix taa; } organization "IETF"; contact "WG Web: WG List: Editor: Eric Voit "; description "This module contains conceptual YANG specifications for subscribing to attestation streams being generated from TPM chips. Copyright (c) 2020 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Simplified BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info). This version of this YANG module is part of RFC XXXX; see the RFC itself for full legal notices."; revision 2020-09-17 { description "Initial version."; reference "draft-voit-rats-trustworthy-path-routing"; } /* * IDENTITIES */ identity trustworthiness-level { description "Base identity for a Verifier that uses its Appraisal Policy for Evidence to establish a trustworthiness level."; } identity trustworthiness-pass { description "A trustworthiness-level which successfully meets an Appraisal Policy for Evidence."; } identity trustworthiness-fail { description "A trustworthiness-level which hit Appraisal Policy for Evidence necessary to fail an evaluation. Note: this failure might or might not consider whether sufficient Evidence has been provided. In other words having insufficient evidence might not drive the setting of this failing trustworthiness-level."; } identity boot-verified { base trustworthiness-pass; description "A Verifier has appraised an Attester as Boot Integrity Verified."; } identity boot-verification-fail { base trustworthiness-fail; description "A Verifier has appraised an Attester has failed its Boot Integrity verification."; } identity hw-authentic { base trustworthiness-pass; description "A Verifier has appraised an Attester as having authentic hardware."; } identity fw-authentic { base trustworthiness-pass; description "A Verifier has appraised an Attester as having authentic firmware."; } identity hw-verification-fail { base trustworthiness-fail; description "A Verifier has appraised an Attester has failed its hardware or firmware verification."; } identity identity-verified { base trustworthiness-pass; description "A Verifier has appraised and verified an Attester's unique identity."; } identity identity-fail { base trustworthiness-fail; description "A Verifier has been unable to assess or verify an Attester's unique identity"; } identity files-verified { base trustworthiness-pass; description "A Verifier has appraised an Attester's file system, and asserts that it recognizes relevant files."; } identity file-repudiated { base trustworthiness-fail; description "A Verifier has found a file on an Attester which should not be present."; } grouping TPM20-unsigned-internals { description "The unsigned extract of a TPM2 Quote."; leaf TPM2B_DIGEST { mandatory true; type binary; description "A hash of the latest PCR values (and the hash algorithm used) which have been returned from a Verifier for the selected PCRs identified within TPML_PCR_SELECTION."; reference "https://www.trustedcomputinggroup.org/wp-content/uploads/ TPM-Rev-2.0-Part-2-Structures-01.38.pdf Section 10.12.1"; } list tpm20-pcr-bank { min-elements 1; key "TPM-hash-algo"; description "Specifies the list of PCRs and Hash Algorithms used for the latest returned TPM2B_DIGEST. Identifying this object simplifies Stamped Passport troubleshooting if the same PCRs and Hash algorithms are not used when attempting to correlate independent TPM2B_DIGESTs."; reference "https://www.trustedcomputinggroup.org/wp-content/uploads/ TPM-Rev-2.0-Part-2-Structures-01.38.pdf Section 10.9.7"; leaf TPM-hash-algo { type identityref { base taa:hash; } description "The hash scheme actively being used to hash a PCRs."; } leaf-list pcr-index { type tpm:pcr; min-elements 1; description "Defines what TPM2 Banks are available. A bank is a set of PCRs which are extended using a particular hash algorithm."; } } leaf clock { mandatory true; type uint64; description "Clock is a monotonically increasing counter that advances whenever power is applied to a TPM2. The value of Clock is incremented each millisecond."; reference "https://www.trustedcomputinggroup.org/wp-content/uploads/ TPM-Rev-2.0-Part-2-Structures-01.38.pdf Section 10.11.2"; } leaf reset-counter { mandatory true; type uint32; description "This counter increments on each TPM Reset. The most common TPM Reset would be due to a hardware power cycle."; reference "https://www.trustedcomputinggroup.org/wp-content/uploads/ TPM-Rev-2.0-Part-2-Structures-01.38.pdf Section 10.11.3"; } leaf restart-counter { mandatory true; type uint32; description "This counter shall increment by one for each TPM Restart or TPM Resume. The restartCount shall be reset to zero on a TPM Reset."; reference "https://www.trustedcomputinggroup.org/wp-content/uploads/ TPM-Rev-2.0-Part-2-Structures-01.38.pdf Section 10.11.4"; } leaf safe { mandatory true; type boolean; description "This parameter is set to YES when the value reported in Clock is guaranteed to be unique for the current Owner. It is set to NO when the value of Clock may have been reported in a previous attestation or access."; reference "https://www.trustedcomputinggroup.org/wp-content/uploads/ TPM-Rev-2.0-Part-2-Structures-01.38.pdf Section 10.11.5"; } } grouping TPM12-unsigned-internals-extended { description "The unsigned extract of a TPM12 Quote, with extra content from the Verifier specific to a TPM12."; uses tpm:tpm12-pcr-selection; leaf-list tpm12-pcr-value { type binary; description "The list of TPM_PCRVALUEs from each PCR selected in sequence of tpm12-pcr-selection."; reference "https://www.trustedcomputinggroup.org/wp-content/uploads/ TPM-Main-Part-2-TPM-Structures_v1.2_rev116_01032011.pdf Section 10.9.7"; } leaf timestamp { type yang:date-and-time; mandatory true; description "The timestamp of the Verifier's appraisal. This can be used by a Relying Party to determine the freshness of the attestation results."; } } /* * DATA NODES */ container attestation-results { presence "Indicates that Verifier has appraised the security posture of the Attester, and returned the results within this container. If the Attester believes this information is no longer fresh, this container should automatically be deleted."; description "Retains the most recent Attestation Results for this Attester. It must only be written by a Verfier which is to be trusted by a Relying Party."; leaf-list trustworthiness-vector { type identityref { base trustworthiness-level; } ordered-by system; description "One or more Trustworthiness Levels assigned which expose the Verifier's evaluation of the Evidence associated with the 'tpmt-signature'."; } choice tpm-specification-version { description "Identifies the cryptoprocessor API set which drove the Attestation Results."; case TPM2.0 { if-feature "taa:TPM20"; description "The Attestation Results are from a TPM2."; uses TPM20-unsigned-internals; } case TPM1.2 { if-feature "taa:TPM12"; description "The most recent Attestation Results from a TPM1.2."; uses TPM12-unsigned-internals-extended; } } uses ct:public-key-grouping { description "In order to avoid having to provision AIK certificates on a Relying Party network device, it is possible to send the AIK public key as from the Verifier as part of the passport. This is safe because the key is signed by the Verifier (hence vouching for its validity.) The two objects within this group allow the Verifier to include this information as part of the Attestation Results."; } leaf public-key-algorithm-type { mandatory true; type identityref { base taa:asymmetric; } description "Indicates what kind of algorithm is used with the Attester's Public Key Value."; } leaf verifier-signature-key-name { type string; description "Name of the key the Verifier used to sign the results."; } leaf verifier-key-algorithm-type { mandatory true; type identityref { base taa:asymmetric; } description "Indicates what kind of algorithm was used for the 'verifier-signature'."; } leaf verifier-signature { type binary; mandatory true; description "Signature of the Verifier across all the other objects within the attestation-results container. The signature will assume the sequence of objects as defined in the YANG model schema."; } } } ]]>

Verifiers are limited to the Evidence available for appraisal from a Router. Although the state of the art is improving, some exploits may not be visible via Evidence. Only security measurements which are placed into PCRs are capable of being exposed via TPM Quote at time(EG’). Successful attacks on an Verifier have the potential of affecting traffic on the Trusted Topology. For Trusted Path Routing, links which are part of the FlexAlgo are visible across the entire IGP domain. Therefore a compromised device will know when it is being bypassed. Access control for the objects in should be tightly controlled so that it becomes difficult for the Stamped Passport to become a denial of service vector.

This document defines a YANG data model and associated mechanisms enabling subscriber-specific subscriptions to a publisher's event streams. Applying these elements allows a subscriber to request and receive a continuous, customized feed of publisher-generated information. This document introduces a collection of common data types to be used with the YANG data modeling language. [STANDARDS-TRACK] In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This document defines the Extensible Authentication Protocol (EAP), an authentication framework which supports multiple authentication methods. EAP typically runs directly over data link layers such as Point-to-Point Protocol (PPP) or IEEE 802, without requiring IP. EAP provides its own support for duplicate elimination and retransmission, but is reliant on lower layer ordering guarantees. Fragmentation is not supported within EAP itself; however, individual EAP methods may support this. This document obsoletes RFC 2284. A summary of the changes between this document and RFC 2284 is available in Appendix A. [STANDARDS-TRACK] IGP protocols traditionally compute best paths over the network based on the IGP metric assigned to the links. Many network deployments use RSVP-TE based or Segment Routing based Traffic Engineering to steer traffic over a path that is computed using different metrics or constraints than the shortest IGP path. This document proposes a solution that allows IGPs themselves to compute constraint-based paths over the network. This document also specifies a way of using Segment Routing (SR) Prefix-SIDs and SRv6 locators to steer packets along the constraint-based paths.

Shwetha Bhandari, Henk Birkholz, Chennakesava Reddy Gaddam, Sujal Sheth, Peter Psenak, Adwaith Gautham, Annu Singh, Nancy Cam Winget, Ned Smith, and Guy Fedorkow.

[THIS SECTION TO BE REMOVED BY THE RFC EDITOR.] v00-v01 Minor tweaks v02-v00 of draft-voit-rats-trustworthy-path-routing-00 file rename was due to an IETF tool submission glitch The Attester’s AIK is included within the Stamped Passport. This eliminates the need to provision to AIK certificate on the Relying Party. Removed Centralized variant Added timing diagram, and moved content around to match v01-v02 of draft-voit-rats-trusted-path-routing Extracted the attestation stream, and placed into draft-birkholz-rats-network-device-subscription Introduced the Trustworthiness Vector v00-v01 of draft-voit-rats-trusted-path-routing Move all FlexAlgo terminology to . This allows to be more generic. Edited Figure 1 so that (4) points to the egress router. Added text freshness mechanisms, and articulated configured subscription support. Minor YANG model clarifications. Added a few open questions which Frank thinks interesting to work.

(1) When there is no available Trusted Topology? Do we need functional requirements on how to handle traffic to/from Sensitive Subnets when no Trusted Topology exists between IGP edges? The network typically can make this unnecessary. For example it is possible to construct a local IPSec tunnel to make untrusted devices appear as Transparently-Transited Devices. This way Secure Subnets could be tunneled between FlexAlgo nodes where an end-to-end path doesn’t currently exist. However there still is a corner case where all IGP egress points are not considered sufficiently trustworthy. (2) Extension of the Stamped Passport? We might move to ‘verifier-certificate’ and ‘verifier-certificate-name’ based on WG desire to include more information in the Stamped Passport. The format used could be extracted from ietf-keystore.yang, grouping keystore-grouping.