idnits 2.17.1 draft-ietf-sidrops-rp-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 a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 245: '... and they MUST be present. No other...' RFC 2119 keyword, line 247: '...een met. Each CRL in the RPKI MUST be...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (August 20, 2018) is 2076 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 6486 (Obsoleted by RFC 9286) ** Obsolete normative reference: RFC 7730 (Obsoleted by RFC 8630) ** Obsolete normative reference: RFC 8208 (Obsoleted by RFC 8608) Summary: 4 errors (**), 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: February 21, 2019 Independent 6 August 20, 2018 8 Requirements for Resource Public Key Infrastructure (RPKI) Relying 9 Parties 10 draft-ietf-sidrops-rp-02 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 February 21, 2019. 38 Copyright Notice 40 Copyright (c) 2018 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. Delivering Validated Cache to BGP Speakers . . . . . . . . . 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 7730 (Trust Anchor Locator) 110 RFC 7935 (Algorithms) 111 RFC 8209 (Router Certificates) 112 RFC 8210 (RPKI to Router Protocol,Version 1) 113 RFC 8360 (Certificate Validation Procedure) 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 Delivering Validated Cache Data to BGP Speakers 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 [RFC7730]. 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 In the RPKI, issuer can only assign and/or allocate public INRs 226 belong to it, thus the INRs in issuer's certificate are required to 227 encompass the INRs in the subject's certificate. This is one of 228 necessary principles of certificate path validation in addition to 229 cryptographic verification i.e., verification of the signature on 230 each certificate using the public key of the parent certificate). 232 Section 7.2 of [RFC6487] gives the procedure that the RP should 233 follow to perform certificate path validation. 235 Certificate Authorities that want to reduce aspects of operational 236 fragility will migrate to the new OIDs [RFC8360], informing the RP of 237 using an alternative RPKI validation algorithm. An RP is expected to 238 support the amended procedure to handle with accidental over-claim. 240 3.3. CRL Processing 242 The CRL processing requirements imposed on CAs and RP are described 243 in Section 5 of [RFC6487]. CRLs in the RPKI are tightly constrained; 244 only the AuthorityKeyIndetifier and CRLNumber extensions are allowed, 245 and they MUST be present. No other CRL extensions are allowed, and 246 no CRLEntry extensions are permitted. RPs are required to verify 247 that these constraints have been met. Each CRL in the RPKI MUST be 248 verified using the public key from the certificate of the CA that 249 issued the CRL. 251 In the RPKI, RPs are expected to pay extra attention when dealing 252 with a CRL that is not consistent with the Manifest associated with 253 the publication point associated with the CRL. 255 Processing of a CRL that is not consistent with a manifest is a 256 matter of local policy, as described in the fourth paragraph of 257 Section 6.6 of [RFC6486]. 259 4. Processing RPKI Repository Signed Objects 261 4.1. Basic Signed Object Syntax Checks 263 Before an RP can use a signed object from the RPKI repository, the RP 264 is required to check the signed object syntax. 266 Section 3 of [RFC6488] lists all the steps that the RP is required to 267 execute in order to validate the top level syntax of a repository 268 signed object. 270 Note that these checks are necessary, but not sufficient. Additional 271 validation checks must be performed based on the specific type of 272 signed object. 274 4.2. Syntax and Validation for Each Type of Signed Object 276 4.2.1. Manifest 278 To determine whether a manifest is valid, the RP is required to 279 perform manifest-specific checks in addition to those specified in 280 [RFC6488]. 282 Specific checks for a Manifest are described in Section 4 of 283 [RFC6486]. If any of these checks fails, indicating that the 284 manifest is invalid, then the manifest will be discarded and treated 285 as though no manifest were present. 287 4.2.2. ROA 289 To validate a ROA, the RP is required perform all the checks 290 specified in [RFC6488] as well as the additional ROA-specific 291 validation steps. The IP address delegation extension [RFC3779] 292 present in the end-entity (EE) certificate (contained within the 293 ROA), must encompass each of the IP address prefix(es) in the ROA. 295 More details for ROA validation are specified in Section 2 of 296 [RFC6482]. 298 4.2.3. Ghostbusters 300 The Ghostbusters Record is optional; a publication point in the RPKI 301 can have zero or more associated Ghostbuster Records. If a CA has at 302 least one Ghostbuster Record, RP is required to verify that this 303 Ghostbusters Record conforms to the syntax of signed object defined 304 in [RFC6488]. 306 The payload of this signed object is a (severely) profiled vCard. An 307 RP is required to verify that the payload of Ghostbusters conforms to 308 format as profiled in [RFC6493]. 310 4.2.4. Verifying BGPsec Router Certificate 312 A BGPsec Router Certificate is a resource certificate, so it is 313 required to comply with [RFC6487]. Additionally, the certificate 314 must contain an AS Identifier Delegation extension, and must not 315 contain an IP Address Delegation extension. The validation procedure 316 used for BGPsec Router Certificates is identical to the validation 317 procedure described in Section 7 of [RFC6487], but using the 318 constraints applied come from specification of Section 7 of 319 [RFC8209]. 321 Note that the cryptographic algorithms used by BGPsec routers are 322 found in [RFC8208]. Currently, the algorithms specified in 323 [RFC8208]and [RFC7935] are different. BGPsec RPs will need to 324 support algorithms that are used to validate BGPsec signatures as 325 well as the algorithms that are needed to validate signatures on 326 BGPsec certificates, RPKI CA certificates, and RPKI CRLs. 328 4.3. How to Make Use of Manifest Data 330 For a given publication point, the RP ought to perform tests, as 331 specified in Section 6.1 of [RFC6486], to determine the state of the 332 Manifest at the publication point. A Manifest can be classified as 333 either valid or invalid, and a valid Manifest is either current and 334 stale. An RP decides how to make use of a Manifest based on its 335 state, according to local (RP) policy. 337 If there are valid objects in a publication point that are not 338 present on a Manifest, [RFC6486] does not mandate specific RP 339 behavior with respect to such objects. However, most RP software 340 ignores such objects and this document recommends that this behavior 341 be adopted uniformly. 343 In the absence of a Manifest, an RP is expected to accept all valid 344 signed objects present in the publication point. If a Manifest is 345 stale or invalid (see [RFC6486]) and an RP has no way to acquire a 346 more recently valid Manifest, the RP is expected to contact the 347 repository manager via Ghostbusters record and thereafter make 348 decision according to local (RP) policy. 350 4.4. What to Do with Ghostbusters Information 352 An RP may encounter a stale Manifest or CRL, or an expired CA 353 certificate or ROA at a publication point. An RP is expected to use 354 the information from the Ghostbusters record to contact the 355 maintainer of the publication point where any stale/expired objects 356 were encountered. The intent here is to encourage the relevant CA 357 and/or repository manager to update the slate or expired objects. 359 5. Delivering Validated Cache to BGP Speakers 361 On a periodic basis, BGP speakers within an AS request updated 362 validated origin AS data and router/ASN data from the RP's cache. 363 The RP passes this information to BGP speakers to enable them to 364 verify the authenticity of routing announcements. The specification 365 of the protocol designed to deliver validated cache data from an RP 366 to a BGP Speaker is provided in [RFC6810] and [RFC8210]. 368 6. Security Considerations 370 The RP links the RPKI provisioning side and the routing system, 371 establishing the local view of global RPKI data to BGP speakers. The 372 security of the RP is critical to BGP messages exchanging. The RP 373 implementation is expected to offer cache backup management to 374 facilitate recovery from outage state. The RP implementation also 375 should support application of secure transport (e.g., IPsec 376 [RFC4301]) that is able to protect validated cache delivery in a 377 unsafe environment. 379 7. IANA Considerations 381 This document has no actions for IANA. 383 8. Acknowledgements 385 The authors thank David Mandelberg, Wei Wang and Tim Bruijnzeels for 386 their review, feedback and editorial assistance in preparing this 387 document. 389 9. References 391 9.1. Normative References 393 [RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP 394 Addresses and AS Identifiers", RFC 3779, 395 DOI 10.17487/RFC3779, June 2004, 396 . 398 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 399 Housley, R., and W. Polk, "Internet X.509 Public Key 400 Infrastructure Certificate and Certificate Revocation List 401 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 402 . 404 [RFC6481] Huston, G., Loomans, R., and G. Michaelson, "A Profile for 405 Resource Certificate Repository Structure", RFC 6481, 406 DOI 10.17487/RFC6481, February 2012, 407 . 409 [RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route 410 Origin Authorizations (ROAs)", RFC 6482, 411 DOI 10.17487/RFC6482, February 2012, 412 . 414 [RFC6486] Austein, R., Huston, G., Kent, S., and M. Lepinski, 415 "Manifests for the Resource Public Key Infrastructure 416 (RPKI)", RFC 6486, DOI 10.17487/RFC6486, February 2012, 417 . 419 [RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for 420 X.509 PKIX Resource Certificates", RFC 6487, 421 DOI 10.17487/RFC6487, February 2012, 422 . 424 [RFC6488] Lepinski, M., Chi, A., and S. Kent, "Signed Object 425 Template for the Resource Public Key Infrastructure 426 (RPKI)", RFC 6488, DOI 10.17487/RFC6488, February 2012, 427 . 429 [RFC6493] Bush, R., "The Resource Public Key Infrastructure (RPKI) 430 Ghostbusters Record", RFC 6493, DOI 10.17487/RFC6493, 431 February 2012, . 433 [RFC6810] Bush, R. and R. Austein, "The Resource Public Key 434 Infrastructure (RPKI) to Router Protocol", RFC 6810, 435 DOI 10.17487/RFC6810, January 2013, 436 . 438 [RFC7730] Huston, G., Weiler, S., Michaelson, G., and S. Kent, 439 "Resource Public Key Infrastructure (RPKI) Trust Anchor 440 Locator", RFC 7730, DOI 10.17487/RFC7730, January 2016, 441 . 443 [RFC7935] Huston, G. and G. Michaelson, Ed., "The Profile for 444 Algorithms and Key Sizes for Use in the Resource Public 445 Key Infrastructure", RFC 7935, DOI 10.17487/RFC7935, 446 August 2016, . 448 [RFC8208] Turner, S. and O. Borchert, "BGPsec Algorithms, Key 449 Formats, and Signature Formats", RFC 8208, 450 DOI 10.17487/RFC8208, September 2017, 451 . 453 [RFC8209] Reynolds, M., Turner, S., and S. Kent, "A Profile for 454 BGPsec Router Certificates, Certificate Revocation Lists, 455 and Certification Requests", RFC 8209, 456 DOI 10.17487/RFC8209, September 2017, 457 . 459 [RFC8210] Bush, R. and R. Austein, "The Resource Public Key 460 Infrastructure (RPKI) to Router Protocol, Version 1", 461 RFC 8210, DOI 10.17487/RFC8210, September 2017, 462 . 464 [RFC8360] Huston, G., Michaelson, G., Martinez, C., Bruijnzeels, T., 465 Newton, A., and D. Shaw, "Resource Public Key 466 Infrastructure (RPKI) Validation Reconsidered", RFC 8360, 467 DOI 10.17487/RFC8360, April 2018, 468 . 470 9.2. Informative References 472 [I-D.ietf-sidrops-bgpsec-rollover] 473 Weis, B., Gagliano, R., and K. Patel, "BGPsec Router 474 Certificate Rollover", draft-ietf-sidrops-bgpsec- 475 rollover-04 (work in progress), December 2017. 477 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 478 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 479 December 2005, . 481 [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support 482 Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480, 483 February 2012, . 485 [RFC6489] Huston, G., Michaelson, G., and S. Kent, "Certification 486 Authority (CA) Key Rollover in the Resource Public Key 487 Infrastructure (RPKI)", BCP 174, RFC 6489, 488 DOI 10.17487/RFC6489, February 2012, 489 . 491 [RFC6916] Gagliano, R., Kent, S., and S. Turner, "Algorithm Agility 492 Procedure for the Resource Public Key Infrastructure 493 (RPKI)", BCP 182, RFC 6916, DOI 10.17487/RFC6916, April 494 2013, . 496 [RFC8182] Bruijnzeels, T., Muravskiy, O., Weber, B., and R. Austein, 497 "The RPKI Repository Delta Protocol (RRDP)", RFC 8182, 498 DOI 10.17487/RFC8182, July 2017, 499 . 501 [rsync] "rsync web page", . 503 Authors' Addresses 505 Di Ma 506 ZDNS 507 4 South 4th St. Zhongguancun 508 Haidian, Beijing 100190 509 China 511 Email: madi@zdns.cn 513 Stephen Kent 514 Independent 516 Email: kent@alum.mit.edu