idnits 2.17.1 draft-ietf-sidrops-rp-00.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 234: '... MUST be present. No other CRL exte...' RFC 2119 keyword, line 236: '...been met. Each CRL in the RPI MUST be...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 11, 2017) is 2358 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC6480' is defined on line 451, but no explicit reference was found in the text ** 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 (~~), 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: May 15, 2018 BBN 6 November 11, 2017 8 Requirements for Resource Public Key Infrastructure (RPKI) Relying 9 Parties 10 draft-ietf-sidrops-rp-00 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). It cites requirements that appear in several 17 RPKI RFCs, making it easier for implementers to become aware of these 18 requirements that are segmented with orthogonal functionalities. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at https://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on May 15, 2018. 37 Copyright Notice 39 Copyright (c) 2017 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (https://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Fetching and Caching RPKI Repository Objects . . . . . . . . 3 56 2.1. TAL Acquisition and Processing . . . . . . . . . . . . . 4 57 2.2. Locating RPKI Objects Using Authority and Subject 58 Information Extensions . . . . . . . . . . . . . . . . . 4 59 2.3. Dealing with Key Rollover . . . . . . . . . . . . . . . . 4 60 2.4. Dealing with Algorithm Transition . . . . . . . . . . . . 4 61 2.5. Strategies for Efficient Cache Maintenance . . . . . . . 5 62 3. Certificate and CRL Processing . . . . . . . . . . . . . . . 5 63 3.1. Verifying Resource Certificate and Syntax . . . . . . . . 5 64 3.2. Certificate Path Validation . . . . . . . . . . . . . . . 5 65 3.3. CRL Processing . . . . . . . . . . . . . . . . . . . . . 5 66 4. Processing RPKI Repository Signed Objects . . . . . . . . . . 6 67 4.1. Basic Signed Object Syntax Checks . . . . . . . . . . . . 6 68 4.2. Syntax and Validation for Each Type of Signed Object . . 6 69 4.2.1. Manifest . . . . . . . . . . . . . . . . . . . . . . 6 70 4.2.2. ROA . . . . . . . . . . . . . . . . . . . . . . . . . 6 71 4.2.3. Ghostbusters . . . . . . . . . . . . . . . . . . . . 7 72 4.2.4. Verifying BGPsec Router Certificate . . . . . . . . . 7 73 4.3. How to Make Use of Manifest Data . . . . . . . . . . . . 7 74 4.4. What to Do with Ghostbusters Information . . . . . . . . 8 75 5. Delivering Validated Cache to BGP Speakers . . . . . . . . . 8 76 6. Security considerations . . . . . . . . . . . . . . . . . . . 8 77 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 78 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 79 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 80 9.1. Normative References . . . . . . . . . . . . . . . . . . 8 81 9.2. Informative References . . . . . . . . . . . . . . . . . 10 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 84 1. Introduction 86 The RPKI RP software is used by network operators and others to 87 acquire and verify Internet Number Resource (INR) data stored in the 88 RPKI repository system. RPKI data, when verified, allow an RP to 89 verify assertions about which Autonomous Systems (ASes) are 90 authorized to originate routes for IP address prefixes. RPKI data 91 also establishes binding between public keys and BGP routers, and 92 indicates the AS numbers that each router is authorized to represent. 94 Noting that the essential requirements imposed on RPs are scattered 95 throughout numerous RFC documents that are protocol specific or 96 provide best practices, as follows: 98 RFC 6481 (Repository Structure) 99 RFC 6482 (ROA format) 100 RFC 6486 (Manifests) 101 RFC 6487 (Certificate and CRL profile) 102 RFC 6488 (RPKI Signed Objects) 103 RFC 6489 (Key Rollover) 104 RFC 6810 (RPKI to Router Protocol) 105 RFC 6916 (Algorithm Agility) 106 RFC 7730 (Trust Anchor Locator) 107 RFC 7935 (Algorithms) 108 RFC 8209 (Router Certificates) 110 This makes it hard for an implementer to be confident that he/she has 111 addressed all of these generalized requirements. Besides, software 112 engineering calls for how to segment the RP system into components 113 with orthogonal functionalities, so that those components could be 114 distributed across the operational timeline of the user. Taxonomy of 115 generalized RP requirements is going to help have 'RP role' well 116 framed. 118 To consolidate RP requirements in one document, with pointers to all 119 the relevant RFCs, this document outlines a set of baseline 120 requirements imposed on RPs and provides a single reference point for 121 requirements for RP software for use in the RPKI, as segmented with 122 orthogonal functionalities: 124 o Fetching and Caching RPKI Repository Objects 125 o Processing Certificates and CRLs 126 o Processing RPKI Repository Signed Objects 127 o Delivering Validated Cache Data to BGP Speakers 129 This document will be update to reflect new or changed requirements 130 as these RFCs are updated, or new RFCs are written. 132 2. Fetching and Caching RPKI Repository Objects 134 RP software uses synchronization mechanisms supported by targeted 135 repositories (e.g., [rsync]) to download all RPKI changed data 136 objects in the repository system and cache them locally. The 137 software validates the RPKI data and uses it to generate 138 authenticated data identifying which ASes are authorized to originate 139 routes for address prefixes, and which routers are authorized to sign 140 BGP updates on behalf of ASes. 142 2.1. TAL Acquisition and Processing 144 In the RPKI, each relying party (RP) chooses its own set of trust 145 anchors (TAs). Consistent with the extant INR allocation hierarchy, 146 the IANA and/or the five RIRs are obvious candidates to be default 147 TAs for the RP. 149 An RP does not retrieve TAs directly. A set of Trust Anchor Locators 150 (TALs) is used by each RP to retrieve and verify the authenticity of 151 each trust anchor. 153 TAL acquisition and processing are specified in Section 3 of 154 [RFC7730]. 156 2.2. Locating RPKI Objects Using Authority and Subject Information 157 Extensions 159 The RPKI repository system is a distributed one, consisting of 160 multiple repository instances. Each repository instance contains one 161 or more repository publication points. An RP discovers publication 162 points using the SIA and AIA extensions from (validated) 163 certificates. 165 Section 5 of [RFC6481] specifies how an RP locates all RPKI objects 166 by using the SIA and AIA extensions. Detailed specifications of SIA 167 and AIA extensions in a resource certificate are described in section 168 4 of [RFC6487]. 170 2.3. Dealing with Key Rollover 172 An RP takes the key rollover period into account with regard to its 173 frequency of synchronization with RPKI repository system. 175 RP requirements in dealing with key rollover are described in section 176 3 of [RFC6489]. 178 2.4. Dealing with Algorithm Transition 180 The set of cryptographic algorithms used with the RPKI is expected to 181 change over time. Each RP is expected to be aware of the milestones 182 established for the algorithm transition and what actions are 183 required at every juncture. 185 RP requirements for dealing with algorithm transition are specified 186 in section 4 of [RFC6916]. 188 2.5. Strategies for Efficient Cache Maintenance 190 Each RP is expected to maintain a local cache of RPKI objects. The 191 cache needs to be as up to date and consistent with repository 192 publication point data as the RP's frequency of checking permits. 194 The last paragraph of section 5 of [RFC6481] provides guidance for 195 maintenance of a local cache. 197 3. Certificate and CRL Processing 199 The RPKI make use of X.509 certificates and CRLs, but it profiles 200 these standard formats [RFC6487]. The major change to the profile 201 established in [RFC5280] is the mandatory use of a new extension to 202 X.509 certificate [RFC3779]. 204 3.1. Verifying Resource Certificate and Syntax 206 Certificates in the RPKI are called resource certificates, and they 207 are required to conform to the profile [RFC6487]. An RP is required 208 to verify that a resource certificate adheres to the profile 209 established by [RFC6487]. This means that all extensions mandated by 210 [RFC6487] must be present and value of each extension must be within 211 the range specified by this RFC. Moreover, any extension excluded by 212 [RFC6487] must be omitted. 214 Section 7.1 of [RFC6487] gives the procedure that the RP should 215 follow to verify resource certificate and syntax. 217 3.2. Certificate Path Validation 219 In the RPKI, issuer can only assign and/or allocate public INRs 220 belong to it, thus the INRs in issuer's certificate are required to 221 encompass the INRs in the subject's certificate. This is one of 222 necessary principles of certificate path validation in addition to 223 cryptographic verification i.e., verification of the signature on 224 each certificate using the public key of the parent certificate). 226 Section 7.2 of [RFC6487] gives the procedure that the RP should 227 follow to perform certificate path validation. 229 3.3. CRL Processing 231 The CRL processing requirements imposed on CAs and RP are described 232 in [RFC6487]. CRLs in the RPKI are tightly constrained; only the 233 AuthorityKeyIndetifier and CRLNumber extensions are allowed, and they 234 MUST be present. No other CRL extensions are allowed, and no 235 CRLEntry extensions are permitted. RPs are required to verify that 236 these constraints have been met. Each CRL in the RPI MUST be 237 verified using the public key from the certificate of the CA that 238 issued the CRL. 240 In the RPKI, RPs are expected to pay extra attention when dealing 241 with a CRL that is not consistent with the Manifest associated with 242 the publication point associated with the CRL. 244 Processing of a CRL that is not consistent with a manifest is a 245 matter of local policy, as described in the fourth paragraph of 246 Section 6.6 of [RFC6486]. 248 4. Processing RPKI Repository Signed Objects 250 4.1. Basic Signed Object Syntax Checks 252 Before an RP can use a signed object from the RPKI repository, the RP 253 is required to check the signed object syntax. 255 Section 3 of [RFC6488] lists all the steps that the RP is required to 256 execute in order to validate the top level syntax of a repository 257 signed object. 259 Note that these checks are necessary, but not sufficient. Additional 260 validation checks must be performed based on the specific type of 261 signed object. 263 4.2. Syntax and Validation for Each Type of Signed Object 265 4.2.1. Manifest 267 To determine whether a manifest is valid, the RP is required to 268 perform manifest-specific checks in addition to those specified in 269 [RFC6488]. 271 Specific checks for a Manifest are described in section 4 of 272 [RFC6486]. If any of these checks fails, indicating that the 273 manifest is invalid, then the manifest will be discarded and treated 274 as though no manifest were present. 276 4.2.2. ROA 278 To validate a ROA, the RP is required perform all the checks 279 specified in [RFC6488] as well as the additional ROA-specific 280 validation steps. The IP address delegation extension [RFC3779] 281 present in the end-entity (EE) certificate (contained within the 282 ROA), must encompass each of the IP address prefix(es) in the ROA. 284 More details for ROA validation are specified in section 2 of 285 [RFC6482]. 287 4.2.3. Ghostbusters 289 The Ghostbusters Record is optional; a publication point in the RPKI 290 can have zero or more associated Ghostbuster Records. If a CA has at 291 least one Ghostbuster Record, RP is required to verify that this 292 Ghostbusters Record conforms to the syntax of signed object defined 293 in [RFC6488]. 295 The payload of this signed object is a (severely) profiled vCard. An 296 RP is required to verify that the payload of Ghostbusters conforms to 297 format as profiled in [RFC6493]. 299 4.2.4. Verifying BGPsec Router Certificate 301 A BGPsec Router Certificate is a resource certificate, so it is 302 required to comply with [RFC6487]. Additionally, the certificate 303 must contain an AS Identifier Delegation extension, and must not 304 contain an IP Address Delegation extension. The validation procedure 305 used for BGPsec Router Certificates is identical to the validation 306 procedure described in Section 7 of [RFC6487], but using the 307 constraints applied come from specification of section 7 of 308 [RFC8209]. 310 Note that the cryptographic algorithms used by BGPsec routers are 311 found in [RFC8208]. Currently, the algorithms specified in 312 [RFC8208]and [RFC7935] are different. BGPsec RPs will need to 313 support algorithms that are used to validate BGPsec signatures as 314 well as the algorithms that are needed to validate signatures on 315 BGPsec certificates, RPKI CA certificates, and RPKI CRLs. 317 4.3. How to Make Use of Manifest Data 319 For a given publication point, the RP ought to perform tests to 320 determine the state of the Manifest at the publication point. A 321 Manifest can be classified as either valid or invalid, and a valid 322 Manifest is either current and stale. An RP decides how to make use 323 of a Manifest based on its state, according to local (RP) policy. 325 If there are valid objects in a publication point that are not 326 present on a Manifest, [RFC6486] does not mandate specific RP 327 behavior with respect to such objects. However, most RP software 328 ignores such objects and this document recommends that this behavior 329 be adopted uniformly. 331 In the absence of a Manifest, an RP is expected to accept all valid 332 signed objects present in the publication point. If a Manifest is 333 stale (see [RFC6486]) and an RP has no way to acquire a more recent 334 Manifest, the RP is expected to (TBD). 336 4.4. What to Do with Ghostbusters Information 338 An RP may encounter a stale Manifest or CRL, or an expired CA 339 certificate or ROA at a publication point. An RP is expected to use 340 the information from the Ghostbusters record to contact the 341 maintainer of the publication point where any stale/expired objects 342 were encountered. The intent here is to encourage the relevant CA 343 and/or repository manager to update the slate or expired objects. 345 5. Delivering Validated Cache to BGP Speakers 347 On a periodic basis, BGP speakers within an AS request updated 348 validated origin AS data and router/ASN data from the RP's cache. 349 The RP passes this information to BGP speakers to enable them to 350 verify the authenticity of routing announcements. The specification 351 of the protocol designed to deliver validated cache data from an RP 352 to a BGP Speaker is provided in [RFC6810]. 354 6. Security considerations 356 TBD 358 7. IANA Considerations 360 This document has no actions for IANA. 362 8. Acknowledgements 364 The authors thank David Mandelberg, Wei Wang and Tim Bruijnzeels for 365 their review, feedback and editorial assistance in preparing this 366 document. 368 9. References 370 9.1. Normative References 372 [RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP 373 Addresses and AS Identifiers", RFC 3779, 374 DOI 10.17487/RFC3779, June 2004, 375 . 377 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 378 Housley, R., and W. Polk, "Internet X.509 Public Key 379 Infrastructure Certificate and Certificate Revocation List 380 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 381 . 383 [RFC6481] Huston, G., Loomans, R., and G. Michaelson, "A Profile for 384 Resource Certificate Repository Structure", RFC 6481, 385 DOI 10.17487/RFC6481, February 2012, 386 . 388 [RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route 389 Origin Authorizations (ROAs)", RFC 6482, 390 DOI 10.17487/RFC6482, February 2012, 391 . 393 [RFC6486] Austein, R., Huston, G., Kent, S., and M. Lepinski, 394 "Manifests for the Resource Public Key Infrastructure 395 (RPKI)", RFC 6486, DOI 10.17487/RFC6486, February 2012, 396 . 398 [RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for 399 X.509 PKIX Resource Certificates", RFC 6487, 400 DOI 10.17487/RFC6487, February 2012, 401 . 403 [RFC6488] Lepinski, M., Chi, A., and S. Kent, "Signed Object 404 Template for the Resource Public Key Infrastructure 405 (RPKI)", RFC 6488, DOI 10.17487/RFC6488, February 2012, 406 . 408 [RFC6489] Huston, G., Michaelson, G., and S. Kent, "Certification 409 Authority (CA) Key Rollover in the Resource Public Key 410 Infrastructure (RPKI)", BCP 174, RFC 6489, 411 DOI 10.17487/RFC6489, February 2012, 412 . 414 [RFC6493] Bush, R., "The Resource Public Key Infrastructure (RPKI) 415 Ghostbusters Record", RFC 6493, DOI 10.17487/RFC6493, 416 February 2012, . 418 [RFC6810] Bush, R. and R. Austein, "The Resource Public Key 419 Infrastructure (RPKI) to Router Protocol", RFC 6810, 420 DOI 10.17487/RFC6810, January 2013, 421 . 423 [RFC6916] Gagliano, R., Kent, S., and S. Turner, "Algorithm Agility 424 Procedure for the Resource Public Key Infrastructure 425 (RPKI)", BCP 182, RFC 6916, DOI 10.17487/RFC6916, April 426 2013, . 428 [RFC7730] Huston, G., Weiler, S., Michaelson, G., and S. Kent, 429 "Resource Public Key Infrastructure (RPKI) Trust Anchor 430 Locator", RFC 7730, DOI 10.17487/RFC7730, January 2016, 431 . 433 [RFC7935] Huston, G. and G. Michaelson, Ed., "The Profile for 434 Algorithms and Key Sizes for Use in the Resource Public 435 Key Infrastructure", RFC 7935, DOI 10.17487/RFC7935, 436 August 2016, . 438 [RFC8208] Turner, S. and O. Borchert, "BGPsec Algorithms, Key 439 Formats, and Signature Formats", RFC 8208, 440 DOI 10.17487/RFC8208, September 2017, 441 . 443 [RFC8209] Reynolds, M., Turner, S., and S. Kent, "A Profile for 444 BGPsec Router Certificates, Certificate Revocation Lists, 445 and Certification Requests", RFC 8209, 446 DOI 10.17487/RFC8209, September 2017, 447 . 449 9.2. Informative References 451 [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support 452 Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480, 453 February 2012, . 455 [rsync] "rsync web page", . 457 Authors' Addresses 459 Di Ma 460 ZDNS 461 4 South 4th St. Zhongguancun 462 Haidian, Beijing 100190 463 China 465 Email: madi@zdns.cn 466 Stephen Kent 467 BBN 468 10 Moulton St 469 Cambridge, MA 02138-1119 470 USA 472 Email: kent@alum.mit.edu