idnits 2.17.1 draft-voit-rats-trusted-path-routing-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 7 instances of too long lines in the document, the longest one being 4 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 10, 2020) is 1409 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'RATS-Arch' -- Possible downref: Non-RFC (?) normative reference: ref. 'RATS-YANG' == Outdated reference: A later version (-07) exists of draft-birkholz-rats-tuda-02 == Outdated reference: A later version (-26) exists of draft-ietf-idr-segment-routing-te-policy-09 == Outdated reference: A later version (-26) exists of draft-ietf-lsr-flex-algo-07 Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 RATS Working Group E. Voit 3 Internet-Draft Cisco 4 Intended status: Standards Track June 10, 2020 5 Expires: December 12, 2020 7 Trusted Path Routing 8 draft-voit-rats-trusted-path-routing-02 10 Abstract 12 There are end-users who believe encryption technologies like IPSec 13 alone are insufficient to protect the confidentiality of their highly 14 sensitive traffic flows. These end-users want their flows to 15 traverse devices which have been freshly appraised and verified. 16 This specification describes Trusted Path Routing. Trusted Path 17 Routing protects sensitive flows as they transit a network by 18 forwarding traffic to/from sensitive subnets across network devices 19 recently appraised as trustworthy. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on December 12, 2020. 38 Copyright Notice 40 Copyright (c) 2020 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (https://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2.1. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2.2. Requirements Notation . . . . . . . . . . . . . . . . . . 4 59 3. Distributed Trusted Path Routing . . . . . . . . . . . . . . 4 60 3.1. Trusted Topology . . . . . . . . . . . . . . . . . . . . 4 61 3.2. Trustworthiness Vector . . . . . . . . . . . . . . . . . 5 62 3.3. Stamped Passport . . . . . . . . . . . . . . . . . . . . 7 63 3.4. Passport Protocol Bindings . . . . . . . . . . . . . . . 11 64 3.5. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 13 65 4. Security Considerations . . . . . . . . . . . . . . . . . . . 16 66 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 67 5.1. Normative References . . . . . . . . . . . . . . . . . . 17 68 5.2. Informative References . . . . . . . . . . . . . . . . . 17 69 Appendix A. Centralized Trusted Path Routing . . . . . . . . . . 18 70 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 20 71 Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 20 72 Appendix D. Open Questions . . . . . . . . . . . . . . . . . . . 21 73 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 21 75 1. Introduction 77 There are end-users who believe encryption technologies like IPSec 78 alone are insufficient to protect the confidentiality of their highly 79 sensitive traffic flows. These customers want their highly sensitive 80 flows to be transported over only network devices recently verified 81 as trustworthy. 83 With the inclusion of TPM based cryptoprocessors into network 84 devices, it is now possible for network providers to identify 85 potentially compromised devices as well as potentially exploitable 86 (or even exploited) vulnerabilities. Using this knowledge, it then 87 becomes possible to redirect sensitive flows around these devices. 89 Trusted Path Routing (TPR) provides a method of establishing Trusted 90 Topologies which only include trust-verified network devices. This 91 specification describes a distributed variant of TPR. With this 92 variant, membership in a Trusted Topology is established and 93 maintained via an exchange of Stamped Passports at the link layer 94 between peering network devices. As links to Attesting Devices are 95 appraised as meeting at least a minimum set of formally defined 96 Trustworthiness Levels, the links are then included as members of 97 this Trusted Topology. [I-D.ietf-lsr-flex-algo] is then used to 98 propogate topology state throughout an IGP domain. IP Packets to and 99 from end-user designated Sensitive Subnets are then forwarded into 100 this Trusted Topology at each IGP boundary. 102 The specification works under the following assumptions: 104 1. All network devices supports the TPM remote attestation profile 105 as laid out in [RATS-Device] 107 2. A [I-D.ietf-lsr-flex-algo] topology spans network devices within 108 an IGP domain. 110 3. One or more Verifiers continuously appraise the set of network 111 devices in the IGP domain, and the Verifiers canse return the 112 Attestation Results back to the attesting network device. 114 4. 802.1x or MACSEC is used to communicate EAP credentials 115 containing a Stamped Passport between network peers. 117 Beyond the distributed variant of TPR, there is another method to 118 accomplish Trusted Path Routing. A controller-based TPR variant is 119 described in the appendicies. 121 2. Terminology 123 2.1. Terms 125 The following terms are imported from [RATS-Arch]: Attester, 126 Evidence, Passport, Relying Party, and Verifier. 128 The following terms at imported from [RFC8639]: Event Stream. 130 Newly defined terms for this document: 132 Attested Device - a device where a Verifier's most recent appraisal 133 of Evidence has returned a Trustworthiness Vector. 135 Stamped Passport - a bundle of Evidence which includes at least 136 signed Attestation Results from a Verifier, and two independent 137 TPM quotes from an Attester. 139 Sensitive Subnet - an IP address range where IP packets to or from 140 that range must only have their IP headers and encapsulated 141 payloads accessible/visible only by Attested Devices. 143 Transparently-Transited Device - a network device within an IGP 144 domain where any packets passed into that IGP domain are 145 completely opaque at Layer 3 and above. 147 Trusted Topology - A topology which includes only Attested Devices 148 and Transparently-Transited Devices. 150 Trustworthiness Level - a specific quanta of trustworthiness which 151 can be assigned by a Verifier. 153 Trustworthiness Vector - a set of Trustworthiness Levels assigned 154 during a single assessment cycle by a Verfier using Evidence and 155 Claims related to an Attested Device. The vector is included 156 within Attestation Results. 158 2.2. Requirements Notation 160 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 161 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 162 "OPTIONAL" in this document are to be interpreted as described in 163 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 164 capitals, as shown here. 166 3. Distributed Trusted Path Routing 168 3.1. Trusted Topology 170 To be included in a Trusted Topology, a Stamped Passport Section 3.3 171 is assembled by an Attested Device. This Stamped Passport will 172 include the most recent Verifier provided Trustworthiness Vector 173 Section 3.2 for that Attested Device. Upon receiving and appraising 174 this Stamped Passport as part of link layer authentication, the 175 Relying Party decides if this link should be added to a Trusted 176 Topology. 178 When enough links on enough Relying Parties have been so appraised, a 179 Trusted Topology will now exist within an IGP domain. And traffic 180 exchanged with Sensitive Subnets can be forwarded into that Trusted 181 Topology from all edges of an IGP domain. 183 .--------. .---------. 184 | Hacked | | Edge | 185 .---------. | Router | | Router | 186 | Router | | | | | 187 | | | trust>---------------===============| | 358 | '-----' | | (5) | 359 '-------------' '---------------' 361 Figure 2: Stamped Passport Generation and Appraisal 363 In Figure 2 above, Evidence from a TPM1.2 or TPM2.0 is generated and 364 signed by that TPM. This Evidence is appraised by Verifier A, and 365 the Attester is given a Trustworthiness Vector which is signed and 366 returned as Attestation Results to the Attester. Later, when a 367 request comes in from a Relying Party, the Attester assembles and 368 returns three independently signed elements of Evidence. These three 369 comprise the Stamped Passport which when taken together allow 370 Verifier B to appraise and set the current Trustworthiness Vector of 371 the Attester. 373 More details on the mechanisms used in the construction and 374 verification of the Stamped Passport match to the numbered steps of 375 Figure 2: 377 1. An Attester sends a signed TPM Quote which includes PCR 378 measurements to Verifier A at time(x). 380 2. Verifier A appraises (1), then sends the following items back to 381 that Attester as Attestation Results: 383 1. the Trustworthiness Vector of an Attester, 384 2. the signature from the TPM Quote of (1), 386 3. a Verifier signature across (2.1) and (2.2). 388 3. A nonce known to the Relying Party is received by the Attester at 389 time(y). 391 4. The Attester generates and sends a Stamped Passport. This 392 passport includes: 394 1. (1) 396 2. (2) 398 3. New signed, verifiably fresh PCR measurements at time(y), 399 which incorporates the nonce from (3). 401 5. On receipt of (4), the Relying Party makes its determination of 402 how the Stamped Passport will impact adjacencies within a Trusted 403 Topology. The decision process is: 405 1. Verify that (4.3) includes the nonce from (3). 407 2. Verify the TPM signature within (4.2) matches the signature 408 of (4.1). 410 3. Validate the signatures of (4.1), (4.2), (4.3). 412 4. Failure of (5.1), (5.2), or (5.3) means the link does not 413 meet minimum criteria, appraise the link as having a null 414 Trustworthiness Vector, and additionally jump to step (5.8). 416 5. If selected PCR values of (1) match (4.3), then Relying Party 417 can accept (2.1) as the link's Trustworthiness Vector. 419 6. When the PCR values are different, and not much time has 420 passed between time(x) and time(y), the Relying Party can 421 either accept any previous Trustworthiness Vector, or attempt 422 to acquire a new Stamped Passport. Where 423 [stream-subscription] is used, it should only be a few 424 seconds before a new Attestation Results should be delivered 425 to an Attester via (2). 427 7. When the PCR values are different, but there is a large time 428 gap between time(x) and time(y), the link should be assigned 429 a null Trustworthiness Vector. 431 8. Based on the link's Trustworthiness Vector: 433 1. include it within any Trusted Topology which accepts that 434 Trustworthiness Vector. 436 2. remove it from any Trusted Topology which does not accept 437 that Trustworthiness Vector. 439 3.4. Passport Protocol Bindings 441 This section provides details of how a Stamped Passport described in 442 Section 3.3 interacts with link layer protocols like [MACSEC] or 443 [IEEE-802.1X], YANG subscriptions [RFC8639], and [RFC3748] methods. 444 Additional linkages to the YANG module defined in Section 3.5 are 445 described. 447 .--------------. 448 | Verifier A | 449 '--------------' 450 ^ (2) 451 | Verifier A signed Attestation Results @time(x) ( 452 Evidence( | Trustworthiness Level, 453 TpmQuote | signature from TpmQuote@time(x) ) 454 @time(x)) | 455 (1) V 456 .-------------. .---------------. 457 | Attester |<------nonce @time(y)---(3)| Relying Party | 458 | .-----. | | / Verifier B | 459 | | Tpm | |(4)-Stamped Passport ( --->| (Router) | 460 | '-----' | TpmQuote@time(y), | (5) | 461 '-------------' TpmQuote@time(x), '---------------' 462 Verifier A signed Attestation Results @time(x) ) 464 Figure 3: Details of Stamped Passport Generation 466 Figure 3 above expands upon the previously described Figure 2. The 467 numbering in both figures is the same. 469 Step (1) 471 Verifier A acquires Evidence including a TPM Quote from the attester 472 via [RATS-YANG] and/or [stream-subscription]. 474 Step (2) 476 As the Evidence changes, Verifier A evaluates the totality of the 477 Evidence received. Verifier A then sets the Trustworthiness Vector 478 of the Attester. Subsequently it sends back a signed Attestation 479 Result which includes the Trustworthiness Vector and the signature 480 sent as part of (1) from the Attester. It is this signature which 481 allows the Trustworthiness Vector to be later provably associated 482 with a recent TPM Quote. 484 The delivery of Attestation Results back to the Attester can be done 485 via a YANG operational datastore write of the following objects: 487 +--rw attestation-results! {passport}? 488 +--rw trustworthiness-vector* identityref 489 +--rw timestamp yang:date-and-time 490 +--rw tpmt-signature? binary 491 +--rw verifier-signature? binary 492 +--rw verifier-signature-key-name? binary 494 Figure 4: Attestation Results Tree 496 Step (3) 498 At time(y) a Relying Party makes a Link Layer connection request to 499 an Attester via a protocol such as [MACSEC] or [IEEE-802.1X]. This 500 connection request must include [RFC3748] credentials. Specifics of 501 the EAP credentials are TBD. If there is no central distribution of 502 time via [I-D.birkholz-rats-tuda] a nonce must be included to ensure 503 freshness of a response. 505 This step can repeat periodically independently of any subsequent 506 iteration (1) and (2). This allows for periodic reauthentication of 507 the link layer in a way not bound to the updating of Verifier A's 508 Attestation Results. 510 Step (4) 512 Upon receipt of (3), a Stamped Passport is generated as per 513 Section 3.3, and sent to the Relying Party. 515 Step (5) 517 Upon receipt of (4), the Relying Party verifies the Stamped Passport 518 as per Section 3.3. Most often, the relevant PCR values at time(x) 519 will be the same as the PCR values at time(y). In this case, the 520 Relying Party can simply accept the Trustworthiness Vector assigned 521 by the Verifier A. When the PCR values are different, and not much 522 time has passed between time(x) and time(y), the Relying Party can 523 either accept the previous Trustworthiness Vector, or attempt another 524 EAP request in a few seconds as new Attestation Results are delivered 525 by Step (2). When there is a large time gap between time(x) and 526 time(y) and the PCR values are different, the Attester should be 527 given a blank Trustworthiness Vector. 529 Based on the link's Trustworthiness Vector, the Relying Party may 530 adjust the link affinity of the corresponding 531 [I-D.ietf-lsr-flex-algo] topology. 533 3.5. YANG Module 535 This YANG module imports modules from [RATS-YANG] and [RFC8639]. 537 ietf-rats-attestation-results-vector@2020-06-03.yang 538 module ietf-rats-attestation-results-vector { 539 yang-version 1.1; 540 namespace 541 "urn:ietf:params:xml:ns:yang:ietf-rats-attestation-results-vector"; 542 prefix arv; 544 import ietf-yang-types { 545 prefix yang; 546 } 548 organization "IETF"; 549 contact 550 "WG Web: 551 WG List: 553 Editor: Eric Voit 554 "; 556 description 557 "This module contains conceptual YANG specifications for 558 subscribing to attestation streams being generated from TPM chips. 560 Copyright (c) 2020 IETF Trust and the persons identified as authors 561 of the code. All rights reserved. 563 Redistribution and use in source and binary forms, with or without 564 modification, is permitted pursuant to, and subject to the license 565 terms contained in, the Simplified BSD License set forth in Section 566 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents 567 (https://trustee.ietf.org/license-info). 569 This version of this YANG module is part of RFC XXXX; see the RFC 570 itself for full legal notices."; 572 revision 2020-06-03 { 573 description 574 "Initial version."; 575 reference 576 "draft-voit-rats-trusted-path-routing"; 578 } 580 /* 581 * IDENTITIES 582 */ 584 identity trustworthiness-level { 585 description 586 "Base identity for a verifier assessed trustworthiness level."; 587 } 589 identity trustworthiness-pass { 590 description 591 "Identity for a verifier assessed trustworthiness pass."; 592 } 594 identity trustworthiness-fail { 595 description 596 "Base identity for a verifier assessed trustworthiness fail."; 597 } 599 identity boot-verified { 600 base trustworthiness-pass; 601 description 602 "A Verifier has assessed an Attester as Boot Integrity Verified."; 603 } 605 identity boot-verification-fail { 606 base trustworthiness-fail; 607 description 608 "A Verifier has assessed an Attester has failed its Boot Integrity 609 verification."; 610 } 612 identity hw-authentic { 613 base trustworthiness-pass; 614 description 615 "A Verifier has assessed an Attester as having authentic hardware."; 616 } 618 identity fw-authentic { 619 base trustworthiness-pass; 620 description 621 "A Verifier has assessed an Attester as having authentic firmware."; 622 } 624 identity hw-verification-fail { 625 base trustworthiness-fail; 626 description 627 "A Verifier has assessed an Attester has failed its hardware or 628 firmware verification."; 629 } 630 identity identity-verified { 631 base trustworthiness-pass; 632 description 633 "A Verifier has assessed and verified an Attester's unique identity."; 634 } 636 identity identity-fail { 637 base trustworthiness-fail; 638 description 639 "A Verifier has been unable to assess or verify an Attester's unique 640 identity"; 641 } 643 identity files-verified { 644 base trustworthiness-pass; 645 description 646 "A Verifier has assessed an Attester's file system, and asserts that 647 it recognizes relevant files."; 648 } 650 identity file-blacklisted { 651 base trustworthiness-fail; 652 description 653 "A Verifier has found a file on an Attester which should not be 654 present."; 655 } 657 /* 658 * DATA NODES 659 */ 661 container attestation-results { 662 presence 663 "An attestation Verifier has appraised the security posture of the 664 device, and returned the results within this container."; 665 description 666 "Containes the latest Verifier appraisal of an Attester."; 667 leaf-list trustworthiness-vector { 668 type identityref { 669 base trustworthiness-level; 670 } 671 ordered-by system; 672 description 673 "One or more Trustworthiness Levels assigned which expose the 674 Verifiers evaluation of the Evidence associated with the 675 'tpmt-signature'."; 676 } 677 leaf timestamp { 678 type yang:date-and-time; 679 mandatory true; 680 description 681 "The timestamp of the Verifier's appraisal."; 682 } 683 leaf tpmt-signature { 684 type binary; 685 description 686 "Must match a recent tpmt-signature sent in a notification to 687 a Verifier. This allows correlation of the Attestation Results to 688 a recent PCR change."; 689 } 690 leaf verifier-signature { 691 type binary; 692 mandatory true; 693 description 694 "Signature of the Verifier across all the current objects in the 695 attestation-results container."; 696 } 697 leaf verifier-signature-key-name { 698 type binary; 699 description 700 "Name of the key the Verifier used to sign the results."; 701 } 702 } 703 } 704 706 4. Security Considerations 708 Successful attacks on an IGP domain Verifier has the potential of 709 affecting traffic on the Trusted Topology. 711 For Distributed Trusted Path Routing, links which are part of the 712 FlexAlgo are visible across the entire IGP domain. Therefore a 713 compromised device will know when it is being bypassed. 715 Access control for the objects in Figure 4 should be tightly 716 controlled so that it becomes difficult for the Stamped Passport to 717 become a denial of service vector. 719 5. References 721 5.1. Normative References 723 [RATS-Arch] 724 "Remote Attestation Procedures Architecture", July 2020, 725 . 728 [RATS-YANG] 729 "A YANG Data Model for Challenge-Response-based Remote 730 Attestation Procedures using TPMs", January 2020, 731 . 734 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 735 Requirement Levels", BCP 14, RFC 2119, 736 DOI 10.17487/RFC2119, March 1997, 737 . 739 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 740 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 741 May 2017, . 743 [RFC8639] Voit, E., Clemm, A., Gonzalez Prieto, A., Nilsen-Nygaard, 744 E., and A. Tripathy, "Subscription to YANG Notifications", 745 RFC 8639, DOI 10.17487/RFC8639, September 2019, 746 . 748 [TPM1.2] TCG, ., "TPM 1.2 Main Specification", October 2003, 749 . 752 [TPM2.0] TCG, ., "TPM 2.0 Library Specification", March 2013, 753 . 756 5.2. Informative References 758 [I-D.birkholz-rats-tuda] 759 Fuchs, A., Birkholz, H., McDonald, I., and C. Bormann, 760 "Time-Based Uni-Directional Attestation", draft-birkholz- 761 rats-tuda-02 (work in progress), March 2020. 763 [I-D.ietf-idr-segment-routing-te-policy] 764 Previdi, S., Filsfils, C., Talaulikar, K., Mattes, P., 765 Rosen, E., Jain, D., and S. Lin, "Advertising Segment 766 Routing Policies in BGP", draft-ietf-idr-segment-routing- 767 te-policy-09 (work in progress), May 2020. 769 [I-D.ietf-lsr-flex-algo] 770 Psenak, P., Hegde, S., Filsfils, C., Talaulikar, K., and 771 A. Gulko, "IGP Flexible Algorithm", draft-ietf-lsr-flex- 772 algo-07 (work in progress), April 2020. 774 [IEEE-802.1X] 775 Parsons, G., "802.1AE: MAC Security (MACsec)", January 776 2020, 777 . 779 [MACSEC] Seaman, M., "802.1AE: MAC Security (MACsec)", January 780 2006, . 782 [RATS-Device] 783 Fedorkow, G., Voit, E., and J. Fitzgerald-McKay, "Network 784 Device Remote Integrity Verification", n.d., 785 . 788 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 789 Levkowetz, Ed., "Extensible Authentication Protocol 790 (EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004, 791 . 793 [stream-subscription] 794 "Attestation Event Stream Subscription", June 2020, 795 . 798 Appendix A. Centralized Trusted Path Routing 800 Trusted Path Routing does not require integration with Routing 801 protocols as is done with Distributed Trusted Path Routing. It is 802 also possible for a Controller to choose a path through a network. 803 This architural alternative is called Centralized Trusted Path 804 Routing. 806 With Centralized Trusted Path Routing, trusted end-to-end paths are 807 pre-assigned through a network provider domain. Along these paths, 808 Evidence of potentially transited components has been assessed. Each 809 path is guaranteed to only include devices which achieve at least a 810 minimum set of a formally defined Trustworthiness Levels. 812 In this alternative, a controller-based Verifier ensures 813 communications with Sensitive Subnets traverses a Trusted Topology 814 within the controller's routing domain. To do this, the Verifier 815 continuously acquires Evidence about each potentially transited 816 device. This access is done via the context established within 817 [RATS-Device]. The controller then appraises the Evidence and 818 decides on a Trustworthiness Vector for each device. The controller 819 then identifies end-to-end path(s) which avoid any devices which are 820 unable to meet the minimum Trustworthiness Levels. Finally, the 821 controller provisions network policy so that flows to and from 822 Sensitive Subnet to use just these end-to-end paths. 824 Evidence passed to the Verifier which are used to establish a 825 device's Trustworthiness Vector will include but is not limited to: 827 o An Attester's security measurements being extended into [TPM1.2] 828 or [TPM2.0] compliant Platform Configuration Registers (PCR). 830 o An Attester's current PCR measurements. 832 The prerequisites for this solution are: 834 1. Customer designated Sensitive Subnet ranges and their acceptable 835 Trustworthiness Vectors have been identified and associated with 836 external interfaces to/from the edge of a routing domain. 838 2. A Verifier which can continuously acquire Evidence and appraise 839 the Trustworthiness Levels of all network devices within the 840 routing domain. 842 3. A Verifier which continuously optimizes a set of network paths/ 843 tunnels. These paths must traverse only Attested Devices or 844 Transparently-Transited Devices while on their way to an egress 845 interface for a routing Domain. 847 4. A Verifier which can provision and maintain the set of Sensitive 848 Subnets associated with specific network paths/tunnels. 850 Figure 5 provides a network diagram of where these four sit within a 851 network topology. 853 .------------------------------------------------. 854 | Verifier + Relying Party (3) | 855 '------------------------------------------------' 856 (4) ^ ^ ^ ^ ^ (4) 857 | | (2) | | | | 858 | | .-------. | | (2) V 859 V (2) |Hacked | (2) (2) .--------. 860 .--------. |Router | .-------. .-------. | Edge | 861 | Edge | |(Attest| |Router | |Switch | | Router | 862 | Router | | =Fail)| |(Attest| |(Attest| | (Attest| 863 | | '-------' | =OK) | | =OK) | | =OK) | 864 (1) path==================================> (1)--- Sensitive 865 | <==================================path | Subnet 866 '--------' '-------' '-------' '--------' 868 Figure 5: Centralized Trusted Path Routing 870 The feature functionality describing how to achieve (1) - (4) are 871 outside the scope of this specification. The reasoning is that each 872 of these can be accomplished via technologies specified elsewhere. 873 For example, in step (4), it is possible for a Verifier to provision 874 each ingress device with the set of Sensitive Subnets for which 875 traffic would be placed into a specific 876 [I-D.ietf-idr-segment-routing-te-policy] tunnel. As another example, 877 consider prerequisite (2): network devices can stream changes in 878 Evidence to a Verifier by establishing an [RFC8639] subscription to 879 the Event Stream as described in [stream-subscription]. 881 Appendix B. Acknowledgements 883 Shwetha Bhandari, Henk Birkholz, Chennakesava Reddy Gaddam, Sujal 884 Sheth, Peter Psenak, Nancy Cam Winget, Ned Smith, Guy Fedorkow, Liang 885 Xia. 887 Appendix C. Change Log 889 [THIS SECTION TO BE REMOVED BY THE RFC EDITOR.] 891 v01-v02 893 o Extracted the attestation stream, and placed into draft-birkholz- 894 rats-network-device-subscription 896 o Introduced the Trustworthiness Vector 898 v00-v01 899 o Move all FlexAlgo terminology to Section 3.4. This allows 900 Section 3.3 to be more generic. 902 o Edited Figure 1 so that (4) points to the egress router. 904 o Added text freshness mechanisms, and articulated configured 905 subscription support. 907 o Minor YANG model clarifications. 909 o Added a few open questions which Frank thinks interesting to work. 911 Appendix D. Open Questions 913 Do we need functional requirements on how to handle traffic to/from 914 Sensitive Subnets when no Trusted Topology exists between IGP edges? 915 The network typically can make this unnecessary. For example it is 916 possible to construct a local IPSec tunnel to make untrusted devices 917 appear as Transparently-Transited Devices. This way Secure Subnets 918 could be tunneled between FlexAlgo nodes where an end-to-end path 919 doesn't currently exist. However there still is a corner case where 920 all IGP egress points are not considered sufficiently trustworthy. 922 Author's Address 924 Eric Voit 925 Cisco Systems, Inc. 927 Email: evoit@cisco.com