idnits 2.17.1 draft-madi-sidr-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 215: '... MUST be present. No other CRL exte...' RFC 2119 keyword, line 217: '...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 (April 12, 2016) is 2929 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC6480' is defined on line 431, but no explicit reference was found in the text ** Obsolete normative reference: RFC 6485 (Obsoleted by RFC 7935) ** Obsolete normative reference: RFC 6486 (Obsoleted by RFC 9286) ** Obsolete normative reference: RFC 7730 (Obsoleted by RFC 8630) Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIDR D. Ma 3 Internet-Draft ZDNS 4 Intended status: Informational S. Kent 5 Expires: October 14, 2016 BBN 6 April 12, 2016 8 Requirements for Resource Public Key Infrastructure (RPKI) Relying 9 Parties 10 draft-madi-sidr-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. 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 http://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 October 14, 2016. 37 Copyright Notice 39 Copyright (c) 2016 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 (http://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 . . . . . . . . . . . . . 3 57 2.2. Locating RPKI Objects Using Authority and Subject 58 Information Extensions . . . . . . . . . . . . . . . . . 3 59 2.3. Dealing with Key Rollover . . . . . . . . . . . . . . . . 4 60 2.4. Dealing with Algorithm Transition . . . . . . . . . . . . 4 61 2.5. Strategies for Efficient Cache Maintenance . . . . . . . 4 62 3. Certificate and CRL Processing . . . . . . . . . . . . . . . 4 63 3.1. Verifying Resource Certificate and Syntax . . . . . . . . 4 64 3.2. Certificate Path Validation . . . . . . . . . . . . . . . 5 65 3.3. CRL Processing . . . . . . . . . . . . . . . . . . . . . 5 66 4. Processing RPKI Repository Signed Objects . . . . . . . . . . 5 67 4.1. Basic Signed Object Syntax Checks . . . . . . . . . . . . 5 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 . . . . . . . . . . . . . . . . . . . . 6 72 4.2.4. Verifying BGPsec Router Certificate . . . . . . . . . 6 73 4.3. How to Make Use of Manifest Data . . . . . . . . . . . . 7 74 4.4. What to Do with Ghostbusters Information . . . . . . . . 7 75 5. Delivering Validated Cache to BGP Speakers . . . . . . . . . 7 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 Relying party 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, allows 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 The follow sections present requirements imposed on RPs as defined in 95 the following RFCs: 97 RFC 6480 (RPKI Architecture) 98 RFC 6481 (Repository Structure) 99 RFC 6482 (ROA format) 100 RFC 6485 (Algorithms) 101 RFC 6486 (Manifests) 102 RFC 6487 (Certificate and CRL profile) 103 RFC 6488 (RPKI Signed Objects) 104 RFC 6489 (Key Rollover) 105 RFC 6810 (RPKI to Router Protocol) 106 RFC 6916 (Algorithm Agility) 107 RFC 7730 (Trust Anchor Locator) 108 RFC XXXX (Router Certificates) 110 This document will be update to reflect new or changed requirements 111 as these RFCs are updated, or new RFCs are written. 113 2. Fetching and Caching RPKI Repository Objects 115 RP software uses synchronization mechanisms supported by targeted 116 repositories (e.g., [rsync]) to download all RPKI changed data 117 objects in the repository system and cache them locally. The 118 software validates the RPKI data and uses it to generate 119 authenticated data identifying which ASes are authorized to originate 120 routes for address prefixes, and which routers are authorized to sign 121 BGP updates on behalf of ASes. 123 2.1. TAL Acquisition and Processing 125 In the RPKI, each relying party (RP) chooses its own set of trust 126 anchors (TAs). Consistent with the extant INR allocation hierarchy, 127 the IANA and/or the five RIRs are obvious candidates to be default 128 TAs for the RP. 130 An RP does not retrieve TAs directly. A set of Trust Anchor Locators 131 (TALs) is used by each RP to retrieve and verify the authenticity of 132 each trust anchor. 134 TAL acquisition and processing are specified in Section 3 of 135 [RFC7730]. 137 2.2. Locating RPKI Objects Using Authority and Subject Information 138 Extensions 140 The RPKI repository system is a distributed one, consisting of 141 multiple repository instances. Each repository instance contains one 142 or more repository publication points. An RP discovers publication 143 points using the SIA and AIA extensions from (validated) 144 certificates. 146 Section 5 of [RFC6481] specifies how an RP locates all RPKI objects 147 by using the SIA and AIA extensions. Detailed specifications of SIA 148 and AIA extensions in a resource certificate are described in section 149 4 of [RFC6487]. 151 2.3. Dealing with Key Rollover 153 An RP takes the key rollover period into account with regard to its 154 frequency of synchronization with RPKI repository system. 156 RP requirements in dealing with key rollover are described in section 157 3 of [RFC6489]. 159 2.4. Dealing with Algorithm Transition 161 The set of cryptographic algorithms used with the RPKI is expected to 162 change over time. Each RP is expected to be aware of the milestones 163 established for the algorithm transition and what actions are 164 required at every juncture. 166 RP requirements for dealing with algorithm transition are specified 167 in section 4 of [RFC6916]. 169 2.5. Strategies for Efficient Cache Maintenance 171 Each RP is expected to maintain a local cache of RPKI objects. The 172 cache needs to be as up to date and consistent with repository 173 publication point data as the RP's frequency of checking permits. 175 The last paragraph of section 5 of [RFC6481] provides guidance for 176 maintenance of a local cache. 178 3. Certificate and CRL Processing 180 The RPKI make use of X.509 certificates and CRLs, but it profiles 181 these standard formats [RFC6487]. The major change to the profile 182 established in [RFC5280] is the mandatory use of a new extension to 183 X.509 certificate [RFC3779]. 185 3.1. Verifying Resource Certificate and Syntax 187 Certificates in the RPKI are called resource certificates, and they 188 are required to conform to the profile [RFC6487]. An RP is required 189 to verify that a resource certificate adheres to the profile 190 established by [RFC6487]. This means that all extensions mandated by 191 [RFC6487] must be present and value of each extension must be within 192 the range specified by this RFC. Moreover, any extension excluded by 193 [RFC6487] must be omitted. 195 Section 7.1 of [RFC6487] gives the procedure that the RP should 196 follow to verify resource certificate and syntax. 198 3.2. Certificate Path Validation 200 In the RPKI, issuer can only assign and/or allocate public INRs 201 belong to it, thus the INRs in issuer's certificate are required to 202 encompass the INRs in the subject's certificate. This is one of 203 necessary principles of certificate path validation in addition to 204 cryptographic verification i.e., verification of the signature on 205 each certificate using the public key of the parent certificate). 207 Section 7.2 of [RFC6487] gives the procedure that the RP should 208 follow to perform certificate path validation. 210 3.3. CRL Processing 212 The CRL processing requirements imposed on CAs and RP are described 213 in [RFC6487]. CRLs in the RPKI are tightly constrained; only the 214 AuthorityKeyIndetifier and CRLNumber extensions are allowed, and they 215 MUST be present. No other CRL extensions are allowed, and no 216 CRLEntry extensions are permitted. RPs are required to verify that 217 these constraints have been met. Each CRL in the RPI MUST be 218 verified using the public key from the certificate of the CA that 219 issued the CRL. 221 In the RPKI, RPs are expected to pay extra attention when dealing 222 with a CRL that is not consistent with the Manifest associated with 223 the publication point associated with the CRL. 225 Processing of a CRL that is not consistent with a manifest is a 226 matter of local policy, as described in the fourth paragraph of 227 Section 6.6 of [RFC6486]. 229 4. Processing RPKI Repository Signed Objects 231 4.1. Basic Signed Object Syntax Checks 233 Before an RP can use a signed object from the RPKI repository, the RP 234 is required to check the signed object syntax. 236 Section 3 of [RFC6488] lists all the steps that the RP is required to 237 execute in order to validate the top level syntax of a repository 238 signed object. 240 Note that these checks are necessary, but not sufficient. Additional 241 validation checks must be performed based on the specific type of 242 signed object. 244 4.2. Syntax and Validation for Each Type of Signed Object 246 4.2.1. Manifest 248 To determine whether a manifest is valid, the RP is required to 249 perform manifest-specific checks in addition to those specified in 250 [RFC6488]. 252 Specific checks for a Manifest are described in section 4 of 253 [RFC6486]. If any of these checks fails, indicating that the 254 manifest is invalid, then the manifest will be discarded and treated 255 as though no manifest were present. 257 4.2.2. ROA 259 To validate a ROA, the RP is required perform all the checks 260 specified in [RFC6488] as well as the additional ROA-specific 261 validation steps. The IP address delegation extension [RFC3779] 262 present in the end-entity (EE) certificate (contained within the 263 ROA), must encompass each of the IP address prefix(es) in the ROA. 265 More details for ROA validation are specified in section 2 of 266 [RFC6482]. 268 4.2.3. Ghostbusters 270 The Ghostbusters Record is optional; a publication point in the RPKI 271 can have zero or more associated Ghostbuster Records. If a CA has at 272 least one Ghostbuster Record, RP is required to verify that this 273 Ghostbusters Record conforms to the syntax of signed object defined 274 in [RFC6488]. 276 The payload of this signed object is a (severely) profiled vCard. An 277 RP is required to verify that the payload of Ghostbusters conforms to 278 format as profiled in [RFC6493]. 280 4.2.4. Verifying BGPsec Router Certificate 282 A BGPsec Router Certificate is a resource certificate, so it is 283 required to comply with [RFC6487]. Additionally, the certificate 284 must contain an AS Identifier Delegation extension, and must not 285 contain an IP Address Delegation extension. The validation procedure 286 used for BGPsec Router Certificates is identical to the validation 287 procedure described in Section 7 of [RFC6487], but using the 288 constraints applied come from specification of section 7 of 289 [ID.sidr-bgpsec-pki-profiles]. 291 Note that the cryptographic algorithms used by BGPsec routers are 292 found in [ID.sidr-bgpsec-algs]. Currently, the algorithms specified 293 in [ID.sidr-bgpsec-algs] and [ID.sidr-rfc6485bis] are different. 294 BGPsec RPs will need to support algorithms that are used to validate 295 BGPsec signatures as well as the algorithms that are needed to 296 validate signatures on BGPsec certificates, RPKI CA certificates, and 297 RPKI CRLs. 299 4.3. How to Make Use of Manifest Data 301 For a given publication point, the RP ought to perform tests to 302 determine the state of the Manifest at the publication point. A 303 Manifest can be classified as either valid or invalid, and a valid 304 Manifest is either current and stale. An RP decides how to make use 305 of a Manifest based on its state, according to local (RP) policy. 307 If there are valid objects in a publication point that are not 308 present on a Manifest, [RFC6486] does not mandate specific RP 309 behavior with respect to such objects. However, most RP software 310 ignores such objects and this document recommends that this behavior 311 be adopted uniformly. 313 In the absence of a Manifest, an RP is expected to accept all valid 314 signed objects present in the publication point. If a Manifest is 315 stale (see [RFC6486]) and an RP has no way to acquire a more recent 316 Manifest, the RP is expected to (TBD). 318 4.4. What to Do with Ghostbusters Information 320 An RP may encounter a stale Manifest or CRL, or an expired CA 321 certificate or ROA at a publication point. An RP is expected to use 322 the information from the Ghostbusters record to contact the 323 maintainer of the publication point where any stale/expired objects 324 were encountered. The intent here is to encourage the relevant CA 325 and/or repository manager to update the slate or expired objects. 327 5. Delivering Validated Cache to BGP Speakers 329 On a periodic basis, BGP speakers within an AS request updated 330 validated origin AS data and router/ASN data from the RP's cache. 331 The RP passes this information to BGP speakers to enable them to 332 verify the authenticity of routing announcements. The specification 333 of the protocol designed to deliver validated cache data from an RP 334 to a BGP Speaker is provided in [RFC6810]. 336 6. Security considerations 338 TBD 340 7. IANA Considerations 342 This document has no actions for IANA. 344 8. Acknowledgements 346 The authors thank David Mandelberg and Wei Wang for their review, 347 feedback and editorial assistance in preparing this document. 349 9. References 351 9.1. Normative References 353 [ID.sidr-bgpsec-algs] 354 Turner, S., "BGPsec Algorithms, Key Formats and Signature 355 Formats", work-in-progress, . 357 [ID.sidr-bgpsec-pki-profiles] 358 Turner, S., "A Profile for BGPsec Router Certificates, 359 Certificate Revocation Lists, and Certification Requests", 360 work-in-progress, . 362 [ID.sidr-rfc6485bis] 363 Huston, G. and G. Michaelson, "The Profile for Algorithms 364 and Key Sizes for use in the Resource Public Key 365 Infrastructure", work-in-progress, . 368 [RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP 369 Addresses and AS Identifiers", RFC 3779, 370 DOI 10.17487/RFC3779, June 2004, 371 . 373 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 374 Housley, R., and W. Polk, "Internet X.509 Public Key 375 Infrastructure Certificate and Certificate Revocation List 376 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 377 . 379 [RFC6481] Huston, G., Loomans, R., and G. Michaelson, "A Profile for 380 Resource Certificate Repository Structure", RFC 6481, 381 DOI 10.17487/RFC6481, February 2012, 382 . 384 [RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route 385 Origin Authorizations (ROAs)", RFC 6482, 386 DOI 10.17487/RFC6482, February 2012, 387 . 389 [RFC6486] Austein, R., Huston, G., Kent, S., and M. Lepinski, 390 "Manifests for the Resource Public Key Infrastructure 391 (RPKI)", RFC 6486, DOI 10.17487/RFC6486, February 2012, 392 . 394 [RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for 395 X.509 PKIX Resource Certificates", RFC 6487, 396 DOI 10.17487/RFC6487, February 2012, 397 . 399 [RFC6488] Lepinski, M., Chi, A., and S. Kent, "Signed Object 400 Template for the Resource Public Key Infrastructure 401 (RPKI)", RFC 6488, DOI 10.17487/RFC6488, February 2012, 402 . 404 [RFC6489] Huston, G., Michaelson, G., and S. Kent, "Certification 405 Authority (CA) Key Rollover in the Resource Public Key 406 Infrastructure (RPKI)", BCP 174, RFC 6489, 407 DOI 10.17487/RFC6489, February 2012, 408 . 410 [RFC6493] Bush, R., "The Resource Public Key Infrastructure (RPKI) 411 Ghostbusters Record", RFC 6493, DOI 10.17487/RFC6493, 412 February 2012, . 414 [RFC6810] Bush, R. and R. Austein, "The Resource Public Key 415 Infrastructure (RPKI) to Router Protocol", RFC 6810, 416 DOI 10.17487/RFC6810, January 2013, 417 . 419 [RFC6916] Gagliano, R., Kent, S., and S. Turner, "Algorithm Agility 420 Procedure for the Resource Public Key Infrastructure 421 (RPKI)", BCP 182, RFC 6916, DOI 10.17487/RFC6916, April 422 2013, . 424 [RFC7730] Huston, G., Weiler, S., Michaelson, G., and S. Kent, 425 "Resource Public Key Infrastructure (RPKI) Trust Anchor 426 Locator", RFC 7730, DOI 10.17487/RFC7730, January 2016, 427 . 429 9.2. Informative References 431 [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support 432 Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480, 433 February 2012, . 435 [rsync] "rsync web page", . 437 Authors' Addresses 439 Di Ma 440 ZDNS 441 4 South 4th St. Zhongguancun 442 Haidian, Beijing 100190 443 China 445 Email: madi@zdns.cn 447 Stephen Kent 448 BBN 449 10 Moulton St 450 Cambridge, MA 02138-1119 451 USA 453 Email: kent@bbn.com