idnits 2.17.1 draft-ietf-sidrops-rp-04.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 (April 17, 2019) is 1837 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-08) exists of draft-ietf-sidrops-https-tal-07 ** Obsolete normative reference: RFC 6486 (Obsoleted by RFC 9286) ** Obsolete normative reference: RFC 8208 (Obsoleted by RFC 8608) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 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: October 19, 2019 Independent 6 April 17, 2019 8 Requirements for Resource Public Key Infrastructure (RPKI) Relying 9 Parties 10 draft-ietf-sidrops-rp-04 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 October 19, 2019. 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. Security Considerations . . . . . . . . . . . . . . . . . . . 8 78 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 79 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 80 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 81 9.1. Normative References . . . . . . . . . . . . . . . . . . 9 82 9.2. Informative References . . . . . . . . . . . . . . . . . 11 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 85 1. Introduction 87 The RPKI Relying Party (RP) software is used by network operators and 88 others to acquire and verify Internet Number Resource (INR) data 89 stored in the RPKI repository system. RPKI data, when verified, 90 allow an RP to verify assertions about which Autonomous Systems 91 (ASes) are authorized to originate routes for IP address prefixes. 92 RPKI data also establishes binding between public keys and BGP 93 routers, and indicates the AS numbers that each router is authorized 94 to represent. 96 Noting that the essential requirements imposed on RPs to support 97 securing Internet routing ([RFC6480]) are scattered throughout 98 numerous RFC documents that are protocol specific or provide best 99 practices, as follows: 101 RFC 6481 (Repository Structure) 102 RFC 6482 (ROA format) 103 RFC 6486 (Manifests) 104 RFC 6487 (Certificate and CRL profile) 105 RFC 6488 (RPKI Signed Objects) 106 RFC 6489 (Key Rollover) 107 RFC 6810 (RPKI to Router Protocol) 108 RFC 6916 (Algorithm Agility) 109 RFC 7935 (Algorithms) 110 RFC 8209 (Router Certificates) 111 RFC 8210 (RPKI to Router Protocol,Version 1) 112 RFC 8360 (Certificate Validation Procedure) 113 I-D.ietf-sidrops-https-tal (Trust Anchor Locator) 115 This makes it hard for an implementer to be confident that he/she has 116 addressed all of these generalized requirements. Besides, software 117 engineering calls for how to segment the RP system into components 118 with orthogonal functionalities, so that those components could be 119 distributed across the operational timeline of the user. Taxonomy of 120 generalized RP requirements is going to help have 'the role of the 121 RP' well framed. 123 To consolidate RP requirements in one document, with pointers to all 124 the relevant RFCs, this document outlines a set of baseline 125 requirements imposed on RPs and provides a single reference point for 126 requirements for RP software for use in the RPKI, as segmented with 127 orthogonal functionalities: 129 o Fetching and Caching RPKI Repository Objects 130 o Processing Certificates and CRLs 131 o Processing RPKI Repository Signed Objects 132 o Distributing Validated Cache of the RPKI Data 134 This document will be update to reflect new or changed requirements 135 as these RFCs are updated, or new RFCs are written. 137 2. Fetching and Caching RPKI Repository Objects 139 RP software uses synchronization mechanisms supported by targeted 140 repositories (e.g., [rsync], RRDP [RFC8182]) to download all RPKI 141 changed data objects in the repository system and cache them locally. 142 The software validates the RPKI data and uses it to generate 143 authenticated data identifying which ASes are authorized to originate 144 routes for address prefixes, and which routers are authorized to sign 145 BGP updates on behalf of ASes. 147 2.1. TAL Acquisition and Processing 149 In the RPKI, each RP chooses its own set of trust anchors (TAs). 150 Consistent with the extant INR allocation hierarchy, the IANA and/or 151 the five RIRs are obvious candidates to be default TAs for the RP. 153 An RP does not retrieve TAs directly. A set of Trust Anchor Locators 154 (TALs) is used by each RP to retrieve and verify the authenticity of 155 each TA. 157 TAL acquisition and processing are specified in Section 3 of 158 [I-D.ietf-sidrops-https-tal]. 160 2.2. Locating RPKI Objects Using Authority and Subject Information 161 Extensions 163 The RPKI repository system is a distributed one, consisting of 164 multiple repository instances. Each repository instance contains one 165 or more repository publication points. An RP discovers publication 166 points using the Subject Information Access (SIA) and the Authority 167 Information Access (AIA) extensions from (validated) certificates. 169 Section 5 of [RFC6481] specifies how an RP locates all RPKI objects 170 by using the SIA and AIA extensions. Detailed specifications of SIA 171 and AIA extensions in a resource certificate are described in 172 Section 4 of [RFC6487]. 174 2.3. Dealing with Key Rollover 176 An RP takes the key rollover period into account with regard to its 177 frequency of synchronization with RPKI repository system. 179 RP requirements in dealing with key rollover are described in 180 Section 3 of [RFC6489] and Section 3 of 181 [I-D.ietf-sidrops-bgpsec-rollover]. 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. Security Considerations 371 The RP links the RPKI provisioning side and the routing system, 372 establishing the local view of global RPKI data to BGP speakers. The 373 security of the RP is critical to BGP messages exchanging. The RP 374 implementation is expected to offer cache backup management to 375 facilitate recovery from outage state. The RP implementation also 376 should support application of secure transport (e.g., IPsec 377 [RFC4301]) that is able to protect validated cache delivery in a 378 unsafe environment. 380 7. IANA Considerations 382 This document has no actions for IANA. 384 8. Acknowledgements 386 The authors thank David Mandelberg, Wei Wang, Tim Bruijnzeels, George 387 Michaelson and Oleg Muravskiy for their review, feedback and 388 editorial assistance in preparing this document. 390 9. References 392 9.1. Normative References 394 [I-D.ietf-sidrops-https-tal] 395 Huston, G., Weiler, S., Michaelson, G., Kent, S., and T. 396 Bruijnzeels, "Resource Public Key Infrastructure (RPKI) 397 Trust Anchor Locator", draft-ietf-sidrops-https-tal-07 398 (work in progress), March 2019. 400 [RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP 401 Addresses and AS Identifiers", RFC 3779, 402 DOI 10.17487/RFC3779, June 2004, 403 . 405 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 406 Housley, R., and W. Polk, "Internet X.509 Public Key 407 Infrastructure Certificate and Certificate Revocation List 408 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 409 . 411 [RFC6481] Huston, G., Loomans, R., and G. Michaelson, "A Profile for 412 Resource Certificate Repository Structure", RFC 6481, 413 DOI 10.17487/RFC6481, February 2012, 414 . 416 [RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route 417 Origin Authorizations (ROAs)", RFC 6482, 418 DOI 10.17487/RFC6482, February 2012, 419 . 421 [RFC6486] Austein, R., Huston, G., Kent, S., and M. Lepinski, 422 "Manifests for the Resource Public Key Infrastructure 423 (RPKI)", RFC 6486, DOI 10.17487/RFC6486, February 2012, 424 . 426 [RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for 427 X.509 PKIX Resource Certificates", RFC 6487, 428 DOI 10.17487/RFC6487, February 2012, 429 . 431 [RFC6488] Lepinski, M., Chi, A., and S. Kent, "Signed Object 432 Template for the Resource Public Key Infrastructure 433 (RPKI)", RFC 6488, DOI 10.17487/RFC6488, February 2012, 434 . 436 [RFC6493] Bush, R., "The Resource Public Key Infrastructure (RPKI) 437 Ghostbusters Record", RFC 6493, DOI 10.17487/RFC6493, 438 February 2012, . 440 [RFC6810] Bush, R. and R. Austein, "The Resource Public Key 441 Infrastructure (RPKI) to Router Protocol", RFC 6810, 442 DOI 10.17487/RFC6810, January 2013, 443 . 445 [RFC7935] Huston, G. and G. Michaelson, Ed., "The Profile for 446 Algorithms and Key Sizes for Use in the Resource Public 447 Key Infrastructure", RFC 7935, DOI 10.17487/RFC7935, 448 August 2016, . 450 [RFC8208] Turner, S. and O. Borchert, "BGPsec Algorithms, Key 451 Formats, and Signature Formats", RFC 8208, 452 DOI 10.17487/RFC8208, September 2017, 453 . 455 [RFC8209] Reynolds, M., Turner, S., and S. Kent, "A Profile for 456 BGPsec Router Certificates, Certificate Revocation Lists, 457 and Certification Requests", RFC 8209, 458 DOI 10.17487/RFC8209, September 2017, 459 . 461 [RFC8210] Bush, R. and R. Austein, "The Resource Public Key 462 Infrastructure (RPKI) to Router Protocol, Version 1", 463 RFC 8210, DOI 10.17487/RFC8210, September 2017, 464 . 466 [RFC8360] Huston, G., Michaelson, G., Martinez, C., Bruijnzeels, T., 467 Newton, A., and D. Shaw, "Resource Public Key 468 Infrastructure (RPKI) Validation Reconsidered", RFC 8360, 469 DOI 10.17487/RFC8360, April 2018, 470 . 472 9.2. Informative References 474 [I-D.ietf-sidrops-bgpsec-rollover] 475 Weis, B., Gagliano, R., and K. Patel, "BGPsec Router 476 Certificate Rollover", draft-ietf-sidrops-bgpsec- 477 rollover-04 (work in progress), December 2017. 479 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 480 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 481 December 2005, . 483 [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support 484 Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480, 485 February 2012, . 487 [RFC6489] Huston, G., Michaelson, G., and S. Kent, "Certification 488 Authority (CA) Key Rollover in the Resource Public Key 489 Infrastructure (RPKI)", BCP 174, RFC 6489, 490 DOI 10.17487/RFC6489, February 2012, 491 . 493 [RFC6916] Gagliano, R., Kent, S., and S. Turner, "Algorithm Agility 494 Procedure for the Resource Public Key Infrastructure 495 (RPKI)", BCP 182, RFC 6916, DOI 10.17487/RFC6916, April 496 2013, . 498 [RFC8182] Bruijnzeels, T., Muravskiy, O., Weber, B., and R. Austein, 499 "The RPKI Repository Delta Protocol (RRDP)", RFC 8182, 500 DOI 10.17487/RFC8182, July 2017, 501 . 503 [rsync] "rsync web page", . 505 Authors' Addresses 507 Di Ma 508 ZDNS 509 4 South 4th St. Zhongguancun 510 Haidian, Beijing 100190 511 China 513 Email: madi@zdns.cn 515 Stephen Kent 516 Independent 518 Email: kent@alum.mit.edu