idnits 2.17.00 (12 Aug 2021) /tmp/idnits50908/draft-ietf-sidrops-rp-06.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 7, 2019) is 950 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 8208 (Obsoleted by RFC 8608) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIDROPS D. Ma 3 Internet-Draft ZDNS 4 Intended status: Informational S. Kent 5 Expires: April 9, 2020 Independent 6 October 7, 2019 8 Requirements for Resource Public Key Infrastructure (RPKI) Relying 9 Parties 10 draft-ietf-sidrops-rp-06 12 Abstract 14 This document provides a single reference point for requirements for 15 Relying Party (RP) software for use in the Resource Public Key 16 Infrastructure (RPKI) in the context of securing Internet routing. 17 It cites requirements that appear in several RPKI RFCs, making it 18 easier for implementers to become aware of these requirements that 19 are segmented with orthogonal functionalities. 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 April 9, 2020. 38 Copyright Notice 40 Copyright (c) 2019 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. Fetching and Caching RPKI Repository Objects . . . . . . . . 3 57 2.1. TAL Acquisition and Processing . . . . . . . . . . . . . 4 58 2.2. Locating RPKI Objects Using Authority and Subject 59 Information Extensions . . . . . . . . . . . . . . . . . 4 60 2.3. Dealing with Key Rollover . . . . . . . . . . . . . . . . 4 61 2.4. Dealing with Algorithm Transition . . . . . . . . . . . . 4 62 2.5. Strategies for Efficient Cache Maintenance . . . . . . . 5 63 3. Certificate and CRL Processing . . . . . . . . . . . . . . . 5 64 3.1. Verifying Resource Certificate and Syntax . . . . . . . . 5 65 3.2. Certificate Path Validation . . . . . . . . . . . . . . . 5 66 3.3. CRL Processing . . . . . . . . . . . . . . . . . . . . . 6 67 4. Processing RPKI Repository Signed Objects . . . . . . . . . . 6 68 4.1. Basic Signed Object Syntax Checks . . . . . . . . . . . . 6 69 4.2. Syntax and Validation for Each Type of Signed Object . . 6 70 4.2.1. Manifest . . . . . . . . . . . . . . . . . . . . . . 6 71 4.2.2. ROA . . . . . . . . . . . . . . . . . . . . . . . . . 7 72 4.2.3. Ghostbusters . . . . . . . . . . . . . . . . . . . . 7 73 4.2.4. Verifying BGPsec Router Certificate . . . . . . . . . 7 74 4.3. How to Make Use of Manifest Data . . . . . . . . . . . . 7 75 4.4. What to Do with Ghostbusters Information . . . . . . . . 8 76 5. Distributing Validated Cache . . . . . . . . . . . . . . . . 8 77 6. Local Control . . . . . . . . . . . . . . . . . . . . . . . . 8 78 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 79 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 80 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 81 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 82 10.1. Normative References . . . . . . . . . . . . . . . . . . 9 83 10.2. Informative References . . . . . . . . . . . . . . . . . 11 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 86 1. Introduction 88 The RPKI Relying Party (RP) software is used by network operators and 89 others to acquire and verify Internet Number Resource (INR) data 90 stored in the RPKI repository system. RPKI data, when verified, 91 allow an RP to verify assertions about which Autonomous Systems 92 (ASes) are authorized to originate routes for IP address prefixes. 93 RPKI data also establishes binding between public keys and BGP 94 routers, and indicates the AS numbers that each router is authorized 95 to represent. 97 Noting that the essential requirements imposed on RPs to support 98 securing Internet routing ([RFC6480]) are scattered throughout 99 numerous RFC documents that are protocol specific or provide best 100 practices, as follows: 102 RFC 6481 (Repository Structure) 103 RFC 6482 (ROA format) 104 RFC 6486 (Manifests) 105 RFC 6487 (Certificate and CRL profile) 106 RFC 6488 (RPKI Signed Objects) 107 RFC 6489 (Key Rollover) 108 RFC 6810 (RPKI to Router Protocol) 109 RFC 6916 (Algorithm Agility) 110 RFC 7935 (Algorithms) 111 RFC 8209 (Router Certificates) 112 RFC 8210 (RPKI to Router Protocol,Version 1) 113 RFC 8360 (Certificate Validation Procedure) 114 RFC 8630 (Trust Anchor Locator) 116 This makes it hard for an implementer to be confident that he/she has 117 addressed all of these generalized requirements. Besides, software 118 engineering calls for how to segment the RP system into components 119 with orthogonal functionalities, so that those components could be 120 distributed across the operational timeline of the user. Taxonomy of 121 generalized RP requirements is going to help have 'the role of the 122 RP' well framed. 124 To consolidate RP requirements in one document, with pointers to all 125 the relevant RFCs, this document outlines a set of baseline 126 requirements imposed on RPs and provides a single reference point for 127 requirements for RP software for use in the RPKI, as segmented with 128 orthogonal functionalities: 130 o Fetching and Caching RPKI Repository Objects 131 o Processing Certificates and CRLs 132 o Processing RPKI Repository Signed Objects 133 o Distributing Validated Cache of the RPKI Data 135 This document will be update to reflect new or changed requirements 136 as these RFCs are updated, or new RFCs are written. 138 2. Fetching and Caching RPKI Repository Objects 140 RP software uses synchronization mechanisms supported by targeted 141 repositories (e.g., [rsync], RRDP [RFC8182]) to download all RPKI 142 changed data objects in the repository system and cache them locally. 143 The software validates the RPKI data and uses it to generate 144 authenticated data identifying which ASes are authorized to originate 145 routes for address prefixes, and which routers are authorized to sign 146 BGP updates on behalf of ASes. 148 2.1. TAL Acquisition and Processing 150 In the RPKI, each RP chooses its own set of trust anchors (TAs). 151 Consistent with the extant INR allocation hierarchy, the IANA and/or 152 the five RIRs are obvious candidates to be default TAs for the RP. 154 An RP does not retrieve TAs directly. A set of Trust Anchor Locators 155 (TALs) is used by each RP to retrieve and verify the authenticity of 156 each TA. 158 TAL acquisition and processing are specified in Section 3 of 159 [RFC8630]. 161 2.2. Locating RPKI Objects Using Authority and Subject Information 162 Extensions 164 The RPKI repository system is a distributed one, consisting of 165 multiple repository instances. Each repository instance contains one 166 or more repository publication points. An RP discovers publication 167 points using the Subject Information Access (SIA) and the Authority 168 Information Access (AIA) extensions from (validated) certificates. 170 Section 5 of [RFC6481] specifies how an RP locates all RPKI objects 171 by using the SIA and AIA extensions. Detailed specifications of SIA 172 and AIA extensions in a resource certificate are described in 173 Section 4 of [RFC6487]. 175 2.3. Dealing with Key Rollover 177 An RP takes the key rollover period into account with regard to its 178 frequency of synchronization with RPKI repository system. 180 RP requirements in dealing with key rollover are described in 181 Section 3 of [RFC6489] and Section 3 of [RFC8634]. 183 2.4. Dealing with Algorithm Transition 185 The set of cryptographic algorithms used with the RPKI is expected to 186 change over time. Each RP is expected to be aware of the milestones 187 established for the algorithm transition and what actions are 188 required at every juncture. 190 RP requirements for dealing with algorithm transition are specified 191 in Section 4 of [RFC6916]. 193 2.5. Strategies for Efficient Cache Maintenance 195 Each RP is expected to maintain a local cache of RPKI objects. The 196 cache needs to be as up to date and consistent with repository 197 publication point data as the RP's frequency of checking permits. 199 The last paragraph of Section 5 of [RFC6481] provides guidance for 200 maintenance of a local cache. 202 3. Certificate and CRL Processing 204 The RPKI make use of X.509 certificates and CRLs, but it profiles 205 these standard formats [RFC6487]. The major change to the profile 206 established in [RFC5280] is the mandatory use of a new extension to 207 X.509 certificate [RFC3779]. 209 3.1. Verifying Resource Certificate and Syntax 211 Certificates in the RPKI are called resource certificates, and they 212 are required to conform to the profile [RFC6487]. An RP is required 213 to verify that a resource certificate adheres to the profile 214 established by Section 4 of [RFC6487]. This means that all 215 extensions mandated by Section 4.8 of [RFC6487] must be present and 216 value of each extension must be within the range specified by this 217 RFC. Moreover, any extension excluded by Section 4.8 of [RFC6487] 218 must be omitted. 220 Section 7.1 of [RFC6487] gives the procedure that the RP should 221 follow to verify resource certificate and syntax. 223 3.2. Certificate Path Validation 225 The INRs in issuer's certificate are required to encompass the INRs 226 in the subject's certificate. This is one of necessary principles of 227 certificate path validation in addition to cryptographic verification 228 i.e., verification of the signature on each certificate using the 229 public key of the parent certificate). 231 Section 7.2 of [RFC6487] gives the procedure that the RP should 232 follow to perform certificate path validation. 234 Certificate Authorities that want to reduce aspects of operational 235 fragility will migrate to the new OIDs [RFC8360], informing the RP of 236 using an alternative RPKI validation algorithm. An RP is expected to 237 support the amended procedure to handle with accidental over-claim. 239 3.3. CRL Processing 241 The CRL processing requirements imposed on CAs and RP are described 242 in Section 5 of [RFC6487]. CRLs in the RPKI are tightly constrained; 243 only the AuthorityKeyIndetifier and CRLNumber extensions are allowed, 244 and they are required to be present. No other CRL extensions are 245 allowed, and no CRLEntry extensions are permitted. RPs are required 246 to verify that these constraints have been met. Each CRL in the RPKI 247 must be verified using the public key from the certificate of the CA 248 that issued the CRL. 250 In the RPKI, RPs are expected to pay extra attention when dealing 251 with a CRL that is not consistent with the Manifest associated with 252 the publication point associated with the CRL. 254 Processing of a CRL that is not consistent with a manifest is a 255 matter of local policy, as described in the fourth paragraph of 256 Section 6.6 of [RFC6486]. 258 4. Processing RPKI Repository Signed Objects 260 4.1. Basic Signed Object Syntax Checks 262 Before an RP can use a signed object from the RPKI repository, the RP 263 is required to check the signed object syntax. 265 Section 3 of [RFC6488] lists all the steps that the RP is required to 266 execute in order to validate the top level syntax of a repository 267 signed object. 269 Note that these checks are necessary, but not sufficient. Additional 270 validation checks must be performed based on the specific type of 271 signed object. 273 4.2. Syntax and Validation for Each Type of Signed Object 275 4.2.1. Manifest 277 To determine whether a manifest is valid, the RP is required to 278 perform manifest-specific checks in addition to those specified in 279 [RFC6488]. 281 Specific checks for a Manifest are described in Section 4 of 282 [RFC6486]. If any of these checks fails, indicating that the 283 manifest is invalid, then the manifest will be discarded and treated 284 as though no manifest were present. 286 4.2.2. ROA 288 To validate a ROA, the RP is required perform all the checks 289 specified in [RFC6488] as well as the additional ROA-specific 290 validation steps. The IP address delegation extension [RFC3779] 291 present in the end-entity (EE) certificate (contained within the 292 ROA), must encompass each of the IP address prefix(es) in the ROA. 294 More details for ROA validation are specified in Section 4 of 295 [RFC6482]. 297 4.2.3. Ghostbusters 299 The Ghostbusters Record is optional; a publication point in the RPKI 300 can have zero or more associated Ghostbuster Records. If a CA has at 301 least one Ghostbuster Record, RP is required to verify that this 302 Ghostbusters Record conforms to the syntax of signed object defined 303 in [RFC6488]. 305 The payload of this signed object is a (severely) profiled vCard. An 306 RP is required to verify that the payload of Ghostbusters conforms to 307 format as profiled in [RFC6493]. 309 4.2.4. Verifying BGPsec Router Certificate 311 A BGPsec Router Certificate is a resource certificate, so it is 312 required to comply with [RFC6487]. Additionally, the certificate 313 must contain an AS Identifier Delegation extension, and must not 314 contain an IP Address Delegation extension. The validation procedure 315 used for BGPsec Router Certificates is identical to the validation 316 procedure described in Section 7 of [RFC6487], but using the 317 constraints applied come from specification of Section 7 of 318 [RFC8209]. 320 Note that the cryptographic algorithms used by BGPsec routers are 321 found in [RFC8208]. Currently, the algorithms specified in 322 [RFC8208]and [RFC7935] are different. BGPsec RPs will need to 323 support algorithms that are used to validate BGPsec signatures as 324 well as the algorithms that are needed to validate signatures on 325 BGPsec certificates, RPKI CA certificates, and RPKI CRLs. 327 4.3. How to Make Use of Manifest Data 329 For a given publication point, the RP ought to perform tests, as 330 specified in Section 6.1 of [RFC6486], to determine the state of the 331 Manifest at the publication point. A Manifest can be classified as 332 either valid or invalid, and a valid Manifest is either current and 333 stale. An RP decides how to make use of a Manifest based on its 334 state, according to local (RP) policy. 336 If there are valid objects in a publication point that are not 337 present on a Manifest, [RFC6486] does not mandate specific RP 338 behavior with respect to such objects. However, most RP software 339 ignores such objects and the authors of this document suggest this 340 behavior be adopted uniformly. 342 In the absence of a Manifest, an RP is expected to accept all valid 343 signed objects present in the publication point. If a Manifest is 344 stale or invalid (see [RFC6486]) and an RP has no way to acquire a 345 more recently valid Manifest, the RP is expected to contact the 346 repository manager via Ghostbusters record and thereafter make 347 decision according to local (RP) policy. 349 4.4. What to Do with Ghostbusters Information 351 An RP may encounter a stale Manifest or CRL, or an expired CA 352 certificate or ROA at a publication point. An RP is expected to use 353 the information from the Ghostbusters record to contact the 354 maintainer of the publication point where any stale/expired objects 355 were encountered. The intent here is to encourage the relevant CA 356 and/or repository manager to update the slate or expired objects. 358 5. Distributing Validated Cache 360 On a periodic basis, BGP speakers within an AS request updated 361 validated origin AS data and router/ASN data from the validated cache 362 of RPKI data. The RP may either transfer the validated data to the 363 BGP speakers directly, or it may transfer the validated data to a 364 cache server that is responsible for provisioning such data to BGP 365 speakers. The specification of the protocol designed to deliver 366 validated cache data to a BGP Speaker is provided in [RFC6810] and 367 [RFC8210]. 369 6. Local Control 371 ISPs may want to establish a local view of exceptions to the RPKI 372 data in the form of local filters and additions. For instance, a 373 network operator might wish to make use of a local override 374 capability to protect routes from adverse actions [RFC8211] . The 375 mechanisms developed to provide this capability to network operators 376 are called "Simplified Local Internet Number Resource Management with 377 the RPKI (SLURM). If an ISP wants to implement SLURM, its RP system 378 can follow the instruction specified in [RFC8416] . 380 7. Security Considerations 382 The RP links the RPKI provisioning side and the routing system, 383 establishing the local view of global RPKI data to BGP speakers. The 384 security of the RP is critical to BGP messages exchanging. The RP 385 implementation is expected to offer cache backup management to 386 facilitate recovery from outage state. The RP implementation also 387 should support application of secure transport (e.g., IPsec 388 [RFC4301]) that is able to protect validated cache delivery in a 389 unsafe environment. 391 8. IANA Considerations 393 This document has no actions for IANA. 395 9. Acknowledgements 397 The authors thank David Mandelberg, Wei Wang, Tim Bruijnzeels, George 398 Michaelson and Oleg Muravskiy for their review, feedback and 399 editorial assistance in preparing this document. 401 10. References 403 10.1. Normative References 405 [RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP 406 Addresses and AS Identifiers", RFC 3779, 407 DOI 10.17487/RFC3779, June 2004, 408 . 410 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 411 Housley, R., and W. Polk, "Internet X.509 Public Key 412 Infrastructure Certificate and Certificate Revocation List 413 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 414 . 416 [RFC6481] Huston, G., Loomans, R., and G. Michaelson, "A Profile for 417 Resource Certificate Repository Structure", RFC 6481, 418 DOI 10.17487/RFC6481, February 2012, 419 . 421 [RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route 422 Origin Authorizations (ROAs)", RFC 6482, 423 DOI 10.17487/RFC6482, February 2012, 424 . 426 [RFC6486] Austein, R., Huston, G., Kent, S., and M. Lepinski, 427 "Manifests for the Resource Public Key Infrastructure 428 (RPKI)", RFC 6486, DOI 10.17487/RFC6486, February 2012, 429 . 431 [RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for 432 X.509 PKIX Resource Certificates", RFC 6487, 433 DOI 10.17487/RFC6487, February 2012, 434 . 436 [RFC6488] Lepinski, M., Chi, A., and S. Kent, "Signed Object 437 Template for the Resource Public Key Infrastructure 438 (RPKI)", RFC 6488, DOI 10.17487/RFC6488, February 2012, 439 . 441 [RFC6493] Bush, R., "The Resource Public Key Infrastructure (RPKI) 442 Ghostbusters Record", RFC 6493, DOI 10.17487/RFC6493, 443 February 2012, . 445 [RFC6810] Bush, R. and R. Austein, "The Resource Public Key 446 Infrastructure (RPKI) to Router Protocol", RFC 6810, 447 DOI 10.17487/RFC6810, January 2013, 448 . 450 [RFC7935] Huston, G. and G. Michaelson, Ed., "The Profile for 451 Algorithms and Key Sizes for Use in the Resource Public 452 Key Infrastructure", RFC 7935, DOI 10.17487/RFC7935, 453 August 2016, . 455 [RFC8208] Turner, S. and O. Borchert, "BGPsec Algorithms, Key 456 Formats, and Signature Formats", RFC 8208, 457 DOI 10.17487/RFC8208, September 2017, 458 . 460 [RFC8209] Reynolds, M., Turner, S., and S. Kent, "A Profile for 461 BGPsec Router Certificates, Certificate Revocation Lists, 462 and Certification Requests", RFC 8209, 463 DOI 10.17487/RFC8209, September 2017, 464 . 466 [RFC8210] Bush, R. and R. Austein, "The Resource Public Key 467 Infrastructure (RPKI) to Router Protocol, Version 1", 468 RFC 8210, DOI 10.17487/RFC8210, September 2017, 469 . 471 [RFC8360] Huston, G., Michaelson, G., Martinez, C., Bruijnzeels, T., 472 Newton, A., and D. Shaw, "Resource Public Key 473 Infrastructure (RPKI) Validation Reconsidered", RFC 8360, 474 DOI 10.17487/RFC8360, April 2018, 475 . 477 [RFC8630] Huston, G., Weiler, S., Michaelson, G., Kent, S., and T. 478 Bruijnzeels, "Resource Public Key Infrastructure (RPKI) 479 Trust Anchor Locator", RFC 8630, DOI 10.17487/RFC8630, 480 August 2019, . 482 10.2. Informative References 484 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 485 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 486 December 2005, . 488 [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support 489 Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480, 490 February 2012, . 492 [RFC6489] Huston, G., Michaelson, G., and S. Kent, "Certification 493 Authority (CA) Key Rollover in the Resource Public Key 494 Infrastructure (RPKI)", BCP 174, RFC 6489, 495 DOI 10.17487/RFC6489, February 2012, 496 . 498 [RFC6916] Gagliano, R., Kent, S., and S. Turner, "Algorithm Agility 499 Procedure for the Resource Public Key Infrastructure 500 (RPKI)", BCP 182, RFC 6916, DOI 10.17487/RFC6916, April 501 2013, . 503 [RFC8182] Bruijnzeels, T., Muravskiy, O., Weber, B., and R. Austein, 504 "The RPKI Repository Delta Protocol (RRDP)", RFC 8182, 505 DOI 10.17487/RFC8182, July 2017, 506 . 508 [RFC8211] Kent, S. and D. Ma, "Adverse Actions by a Certification 509 Authority (CA) or Repository Manager in the Resource 510 Public Key Infrastructure (RPKI)", RFC 8211, 511 DOI 10.17487/RFC8211, September 2017, 512 . 514 [RFC8416] Ma, D., Mandelberg, D., and T. Bruijnzeels, "Simplified 515 Local Internet Number Resource Management with the RPKI 516 (SLURM)", RFC 8416, DOI 10.17487/RFC8416, August 2018, 517 . 519 [RFC8634] Weis, B., Gagliano, R., and K. Patel, "BGPsec Router 520 Certificate Rollover", BCP 224, RFC 8634, 521 DOI 10.17487/RFC8634, August 2019, 522 . 524 [rsync] "rsync web page", . 526 Authors' Addresses 528 Di Ma 529 ZDNS 530 4 South 4th St. Zhongguancun 531 Haidian, Beijing 100190 532 China 534 Email: madi@zdns.cn 536 Stephen Kent 537 Independent 539 Email: kent@alum.mit.edu