idnits 2.17.1 draft-spaghetti-sidrops-rpki-doa-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 : ---------------------------------------------------------------------------- ** There are 6 instances of too long lines in the document, the longest one being 14 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (7 March 2022) is 781 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC6268' is mentioned on line 156, but not defined -- Looks like a reference, but probably isn't: '0' on line 195 -- Looks like a reference, but probably isn't: '1' on line 196 -- Looks like a reference, but probably isn't: '2' on line 179 == Missing Reference: 'TBD' is mentioned on line 406, but not defined == Missing Reference: 'RFC-TBD' is mentioned on line 449, but not defined ** Downref: Normative reference to an Informational RFC: RFC 3882 ** Downref: Normative reference to an Informational RFC: RFC 7999 Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Snijders 3 Internet-Draft Fastly 4 Intended status: Standards Track M. Abrahamsson 5 Expires: 8 September 2022 NTT 6 B. Maddison 7 Workonline 8 7 March 2022 10 Resource Public Key Infrastructure (RPKI) object profile for Discard 11 Origin Authorizations (DOA) 12 draft-spaghetti-sidrops-rpki-doa-00 14 Abstract 16 This document defines a Cryptographic Message Syntax (CMS) profile 17 for Discard Origin Authorizations (DOAs), for use with the Resource 18 Public Key Infrastructure (RPKI). A DOA is a digitally signed object 19 that provides a means of verifying that an IP address block holder 20 has authorized an Autonomous System (AS) to originate routes to one 21 or more prefixes within the address block tagged with a specific set 22 of Border Gateway Protocol (BGP) Communities, to signal a request to 23 discard IP traffic destined towards the tagged IP prefix. 25 Requirements Language 27 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 28 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 29 "OPTIONAL" in this document are to be interpreted as described in BCP 30 14 [RFC2119] [RFC8174] when, and only when, they appear in all 31 capitals, as shown here. 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at https://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on 8 September 2022. 50 Copyright Notice 52 Copyright (c) 2022 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 57 license-info) in effect on the date of publication of this document. 58 Please review these documents carefully, as they describe your rights 59 and restrictions with respect to this document. Code Components 60 extracted from this document must include Revised BSD License text as 61 described in Section 4.e of the Trust Legal Provisions and are 62 provided without warranty as described in the Revised BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 67 2. DOA EncapsulatedContentInfo . . . . . . . . . . . . . . . . . 3 68 2.1. ASN.1 Module . . . . . . . . . . . . . . . . . . . . . . 3 69 2.2. The DOA eContentType . . . . . . . . . . . . . . . . . . 5 70 2.3. The DOA eContent . . . . . . . . . . . . . . . . . . . . 5 71 2.3.1. version . . . . . . . . . . . . . . . . . . . . . . . 5 72 2.3.2. ipAddrBlocks . . . . . . . . . . . . . . . . . . . . 5 73 2.3.3. originAsID . . . . . . . . . . . . . . . . . . . . . 5 74 2.3.4. peerAsIDs . . . . . . . . . . . . . . . . . . . . . . 6 75 2.3.5. communities . . . . . . . . . . . . . . . . . . . . . 6 76 3. DOA Validation . . . . . . . . . . . . . . . . . . . . . . . 6 77 4. RPKI-RTR protocol extensions . . . . . . . . . . . . . . . . 6 78 5. BGP Route Matching . . . . . . . . . . . . . . . . . . . . . 6 79 6. Route Origin Validation Co-Existance . . . . . . . . . . . . 7 80 7. Exporting RTBH Routes . . . . . . . . . . . . . . . . . . . . 8 81 8. Operational Considerations . . . . . . . . . . . . . . . . . 8 82 9. Security Considerations . . . . . . . . . . . . . . . . . . . 8 83 10. Implementation status . . . . . . . . . . . . . . . . . . . . 8 84 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 85 11.1. SMI Security for S/MIME CMS Module Identifier 86 (1.2.840.113549.1.9.16.0) . . . . . . . . . . . . . . . 9 87 11.2. SMI Security for S/MIME CMS Content Type 88 (1.2.840.113549.1.9.16.1) . . . . . . . . . . . . . . . 9 89 11.3. RPKI Signed Objects registry . . . . . . . . . . . . . . 9 90 11.4. RPKI Repository Name Schemes registry . . . . . . . . . 10 91 11.5. Media Types registry . . . . . . . . . . . . . . . . . . 10 92 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 93 12.1. Normative References . . . . . . . . . . . . . . . . . . 11 94 12.2. Informative References . . . . . . . . . . . . . . . . . 11 95 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 12 96 Appendix B. Document Changelog . . . . . . . . . . . . . . . . . 12 97 B.1. Individual Submission Phase . . . . . . . . . . . . . . . 12 99 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 101 1. Introduction 103 Internet operators commonly provide a means for adjacent networks to 104 advertise routes in BGP with the intention that traffic matching such 105 a route be discarded, rather than being forwarded towards the 106 advertising network. This is referred to as Remotely Triggered 107 Blackholing (RTBH), and is typically acheived through the use of a 108 BGP Community [RFC1997]. [RFC7999] defines a "well known" community 109 value for this purpose. The route used to signal an RTBH request is 110 referred to as an RTBH route. 112 Inter-AS RTBH signalling, however, is in tension with the deployment 113 of Route Origin Validation (ROV) based on the Resource Public Key 114 Infrastructure (RPKI) [RFC6811]. Because a blackhole route is likely 115 to have a prefix length greater than permitted in any covering ROA, 116 an operator wishing to deploy routing policy to discard BGP paths 117 with an ROV status of "Invalid", and simultaneously maintain a 118 blackhole signalling service must choose either: 120 1. to exempt blackhole routes from processing based on ROV status, 121 thus foregoing the benefit of ROV altogether; or 123 2. to insist that users of the blackhole signalling service create 124 ROAs with a sufficiently large "maxLength" values to accomodate 125 blackhole routes. 127 This document defines a Cryptographic Message Syntax (CMS) [RFC5652] 128 profile for Discard Origin Authorizations (DOAs), for use with the 129 Resource Public Key Infrastructure (RPKI) [RFC6480], along with 130 associated processing rules. 132 DOAs can be used to validate whether incoming BGP route announcements 133 carrying specific BGP Communities are meant to signify a request to 134 discard IP traffic towards the IP destination carried in the BGP 135 route. This enhances the concepts of [RFC3882] and [RFC7999], and 136 can co-exist with deployed ROV policy. 138 2. DOA EncapsulatedContentInfo 140 DOA follows the Signed Object Template for the RPKI [RFC6488]. 142 2.1. ASN.1 Module 144 The following ASN.1 module specifies the encapContentInfo component 145 for DOA objects: 147 RpkiDiscardOriginAuthorization-2021 148 { iso(1) member-body(2) us(840) rsadsi(113549) 149 pkcs(1) pkcs9(9) smime(16) mod(0) TBD } 151 DEFINITIONS EXPLICIT TAGS ::= 152 BEGIN 154 IMPORTS 155 CONTENT-TYPE 156 FROM CryptographicMessageSyntax-2010 -- in [RFC6268] 157 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 158 pkcs-9(9) smime(16) modules(0) id-mod-cms-2009(58) } 160 IPAddressOrRange, IPAddressRange, IPAddress, ASId 161 FROM IPAddrAndASCertExtn -- in [RFC3779] 162 { iso(1) identified-organization(3) dod(6) internet(1) 163 security(5) mechanisms(5) pkix(7) mod(0) 164 id-mod-ip-addr-and-as-ident(30) } ; 166 ct-discardOriginAuthorization CONTENT-TYPE ::= 167 { TYPE DiscardOriginAuthorization IDENTIFIED BY 168 id-ct-discardOriginAuthorization } 170 id-ct-discardOriginAuthorization OBJECT IDENTIFIER ::= 171 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 172 pkcs-9(9) id-smime(16) id-ct(1) TBD } 174 DiscardOriginAuthorization ::= SEQUENCE { 175 version [0] INTEGER DEFAULT 0, 176 ipAddrBlocks IPListRange, 177 originAsID ASId, 178 peerAsIDs [1] SEQUENCE SIZE(1..MAX) OF ASId OPTIONAL, 179 communities [2] SEQUENCE SIZE(1..MAX) OF Community 180 } 182 IPListRange ::= SEQUENCE (SIZE(1..MAX)) OF IPAddressFamilyRange 184 IPAddressFamilyRange ::= SEQUENCE { 185 addressFamily OCTET STRING (SIZE(2..3)), 186 addressOrRange IPAddressOrRange, 187 prefixLengthRange PrefixLengthRange OPTIONAL -- if omitted, assume hostroutes 188 } 190 PrefixLengthRange ::= SEQUENCE { 191 minLength INTEGER, 192 maxLength INTEGER 193 } 194 Community ::= CHOICE { 195 bgpCommunity [0] OCTET STRING (SIZE(4)), 196 bgpLargeCommunity [1] OCTET STRING (SIZE(12)) 197 } 199 END 201 2.2. The DOA eContentType 203 The eContentType for a DOA is defined as id-ct- 204 discardOriginAuthorization as specified in Section 2.1. 206 This OID MUST appear both within the eContentType in the 207 encapContentInfo object as well as the ContentType signed attribute 208 in the signerInfo object (see [RFC6488]). 210 2.3. The DOA eContent 212 The content of a DOA is formally defined as 213 DiscardOriginAuthorization as specified in Section 2.1 215 2.3.1. version 217 The version number of the DiscardOriginAuthorization MUST be 0. 219 2.3.2. ipAddrBlocks 221 The IP address prefixes for which the announcement of RTBH routes is 222 authorized. The IP address resources contained here are the 223 resources used to mark the authorization, and MUST match the set of 224 resources listed by the EE certificate carried in the CMS 225 certificates field. See [RFC6482] Section 3.3 for a similar, but not 226 entirely similar appraoch. A notable difference is the absense of 227 MaxLength, and instead a PrefixLengthRange is used. If no 228 PrefixLengthRange is present, only the "host route" prefix length 229 (i.e. 32 for IPv4 and 128 for IPv6) is authorized. 231 2.3.3. originAsID 233 The asID field contains the AS number that is authorized to originate 234 RTBH routes for the given IP address prefixes. The asID does not 235 have to be contained by the resources listed on the EE certificate. 237 2.3.4. peerAsIDs 239 The peerAsIDs field contains zero or more AS numbers that are 240 authorized to propagate routes intended to signal an RTBH request for 241 the given IP address prefixes. The peerAsIDs do not have to be 242 contained by the resources listed on the EE certificate. Network 243 operators MUST only accept the RTBH request if it was received from 244 any listed peerAsIDs. The peerAsIDs field allows DOAs to be used to 245 validate RTBH routes with one AS hop between originator and 246 receipient. 248 2.3.5. communities 250 The communities field contains the Classic BGP communities or Large 251 BGP Communities which are to be the 'trigger' to start RTBH. TBD: 252 are communities 'and' or 'or'? 254 3. DOA Validation 256 To validate a DOA the relying party MUST perform all the validation 257 checks specified in [RFC6488] as well as the following additional 258 DOA-specific validation step: 260 * The IP delegation extension [RFC3779] MUST be present in the end- 261 entity certificate (contained in the DOA), and every IP address 262 prefix present in the ipAddrBlocks component of the DOA eContent 263 is contained within the set of IP addresses specified in the EE 264 certificate's IP address delegation extension. 266 4. RPKI-RTR protocol extensions 268 TODO: Seperate document? 270 5. BGP Route Matching 272 TODO: Seperate document? 274 A BGP speaker MAY assign to each path it receives from its peers one 275 of 3 RTBH request validation states: 277 * Matched: a validated DOA object was found covering the prefix of 278 the received path, and matching the contraints of the DOA; 280 * Unmatched: a validated DOA object was found covering the prefix of 281 the received path, but the constraints of the DOA were not 282 matched; or 284 * NotFound: a validated DOA object covering the prefix of the 285 receieved path was not found. 287 Where "covering" is used as in its definition in Section 2 [RFC6811]. 289 In order for a BGP path to be considered to have matched the 290 constraints of a DOA object, the following conditions MUST be met: 292 * The route originated from the ASN listed in the ASId. 294 * The route was received from a PeerAS which is either the ASId or 295 listed in the peerAsIDs field. 297 * The route's prefix length matches the listed permissible prefix 298 lengths. 300 * The route is tagged with (TODO: one or more of?) the designated 301 BGP community. 303 6. Route Origin Validation Co-Existance 305 It is important to observe that ROAs and DOAs can and will be issued 306 for the same covered address space, and that the resulting ROV 307 validation state MUST be entirely independent of the resulting DOA 308 validation state. 310 In particular it is expected that legitimate RTBH routes will 311 commonly receive a DOA validation state of 'Matched' whilst also 312 receiving a ROV validation state of 'Invalid' due to the (likely) 313 longer prefix-length of an RTBH route. 315 For this reason, it is recommended that operators construct policy so 316 as to act on the DOA validation early in the routing policy 317 application process, such that routes that are 'Matched' may be 318 installed as RTBH routes, and routes that are 'Unmatched' or 319 'NotFound' can "fall-through" to be processed as "normal" routes, 320 including the possible application of policy based on their ROV 321 validation state. 323 Critically, in order that operators are able to construct policy 324 according to their needs conforming implementations MUST NOT take any 325 policy action on a route based on either its DOA or ROV validation 326 state by default. See also [RFC8481]. 328 7. Exporting RTBH Routes 330 The guidance of Section 3.2 [RFC7999] that, in general, RTBH routes 331 SHOULD NOT be propagated beyond the receiving AS continues to apply 332 to RTBH routes validated in terms of the above mechanisms. 334 The exception to this guidance is that an operator MAY propagate a 335 received RTBH route to neighboring ASes if its own AS number appears 336 in the peerAsIDs field of the matched DOA, since this indicates a 337 desire by the issuer that neighbors of the local AS honour the route 338 as a legitimate RTBH signal. 340 To facilitate the construction of routing policies by operators that 341 implemented this behaviour, conforming BGP speaker implementations 342 SHOULD provide a means of distinguishing between 'Matched' routes for 343 which the local AS appears in the peerAsIDs of the matched DOA from 344 those for which it does not. 346 8. Operational Considerations 348 TODO 350 9. Security Considerations 352 TODO 354 10. Implementation status 356 This section is to be removed before publishing as an RFC. 358 This section records the status of known implementations of the 359 protocol defined by this specification at the time of posting of this 360 Internet-Draft, and is based on a proposal described in RFC 7942. 361 The description of implementations in this section is intended to 362 assist the IETF in its decision processes in progressing drafts to 363 RFCs. Please note that the listing of any individual implementation 364 here does not imply endorsement by the IETF. Furthermore, no effort 365 has been spent to verify the information presented here that was 366 supplied by IETF contributors. This is not intended as, and must not 367 be construed to be, a catalog of available implementations or their 368 features. Readers are advised to note that other implementations may 369 exist. 371 According to RFC 7942, "this will allow reviewers and working groups 372 to assign due consideration to documents that have the benefit of 373 running code, which may serve as evidence of valuable experimentation 374 and feedback that have made the implemented protocols more mature. 375 It is up to the individual working groups to use this information as 376 they see fit". 378 * A signer implementation [rpkimancer-doa] written in Python has 379 been developed by Ben Maddison. 381 11. IANA Considerations 383 11.1. SMI Security for S/MIME CMS Module Identifier 384 (1.2.840.113549.1.9.16.0) 386 The IANA is requested to register the following entry for this 387 document in the "SMI Security for S/MIME CMS Module Identifier 388 (1.2.840.113549.1.9.16.0)" registry: 390 Decimal Description References 391 ----------------------------------------------------------------------------- 392 [TBD] id-mod-rpkiDOA [draft-spaghetti-sidrops-rpki-doa] 394 Upon publication of this document, IANA is requested to reference the 395 RFC publication instead of this draft. 397 11.2. SMI Security for S/MIME CMS Content Type 398 (1.2.840.113549.1.9.16.1) 400 The IANA is requested to register the following entry for this 401 document in the "SMI Security for S/MIME CMS Content Type 402 (1.2.840.113549.1.9.16.1)" registry: 404 Decimal Description References 405 ----------------------------------------------------------------------------- 406 [TBD] id-ct-discardOriginAuthorization [draft-spaghetti-sidrops-rpki-doa] 408 Upon publication of this document, IANA is requested to reference the 409 RFC publication instead of this draft. 411 11.3. RPKI Signed Objects registry 413 The IANA is requested to register the OID for the RPKI Discard Origin 414 Authorization in the "RPKI Signed Objects" registry ([RFC6488]) as 415 follows: 417 Name OID Reference 418 ---------------------------------------------------- 419 DOA 1.2.840.113549.1.9.16.1.TBD [RFC-TBD] 421 11.4. RPKI Repository Name Schemes registry 423 The IANA is requested to register the RPKI Discard Origin 424 Authorization file extension in the "RPKI Repository Name Schemes" 425 registry ([RFC6481]) as follows: 427 Filename Extension RPKI Object Reference 428 ---------------------------------------------------------- 429 .doa Discard Origin Authorization [RFC-TBD] 431 11.5. Media Types registry 433 The IANA is requested to register the media type application/rpki-doa 434 in the "Media Types" registry ([RFC6838]) as follows: 436 Type name: application 437 Subtype name: rpki-doa 438 Required parameters: None 439 Optional parameters: None 440 Encoding considerations: binary 441 Security considerations: Carries an RPKI Discard Origin Authorization 442 [RFC-TBD]. 443 Interoperability considerations: None 444 Published specification: This document. 445 Applications that use this media type: RPKI operators. 446 Additional information: 447 Content: This media type is a signed object, as defined 448 in [RFC6488], which contains a payload of a set of matching 449 criteria as defined above in [RFC-TBD]. 450 Magic number(s): None 451 File extension(s): .doa 452 Macintosh file type code(s): 453 Person & email address to contact for further information: 454 Job Snijders 455 Intended usage: COMMON 456 Restrictions on usage: None 457 Author: Job Snijders 458 Change controller: Job Snijders 460 12. References 461 12.1. Normative References 463 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 464 Requirement Levels", BCP 14, RFC 2119, 465 DOI 10.17487/RFC2119, March 1997, 466 . 468 [RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP 469 Addresses and AS Identifiers", RFC 3779, 470 DOI 10.17487/RFC3779, June 2004, 471 . 473 [RFC3882] Turk, D., "Configuring BGP to Block Denial-of-Service 474 Attacks", RFC 3882, DOI 10.17487/RFC3882, September 2004, 475 . 477 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 478 RFC 5652, DOI 10.17487/RFC5652, September 2009, 479 . 481 [RFC6481] Huston, G., Loomans, R., and G. Michaelson, "A Profile for 482 Resource Certificate Repository Structure", RFC 6481, 483 DOI 10.17487/RFC6481, February 2012, 484 . 486 [RFC6488] Lepinski, M., Chi, A., and S. Kent, "Signed Object 487 Template for the Resource Public Key Infrastructure 488 (RPKI)", RFC 6488, DOI 10.17487/RFC6488, February 2012, 489 . 491 [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type 492 Specifications and Registration Procedures", BCP 13, 493 RFC 6838, DOI 10.17487/RFC6838, January 2013, 494 . 496 [RFC7999] King, T., Dietzel, C., Snijders, J., Doering, G., and G. 497 Hankins, "BLACKHOLE Community", RFC 7999, 498 DOI 10.17487/RFC7999, October 2016, 499 . 501 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 502 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 503 May 2017, . 505 12.2. Informative References 507 [RFC1997] Chandra, R., Traina, P., and T. Li, "BGP Communities 508 Attribute", RFC 1997, DOI 10.17487/RFC1997, August 1996, 509 . 511 [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support 512 Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480, 513 February 2012, . 515 [RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route 516 Origin Authorizations (ROAs)", RFC 6482, 517 DOI 10.17487/RFC6482, February 2012, 518 . 520 [RFC6811] Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R. 521 Austein, "BGP Prefix Origin Validation", RFC 6811, 522 DOI 10.17487/RFC6811, January 2013, 523 . 525 [RFC8481] Bush, R., "Clarifications to BGP Origin Validation Based 526 on Resource Public Key Infrastructure (RPKI)", RFC 8481, 527 DOI 10.17487/RFC8481, September 2018, 528 . 530 [rpkimancer-doa] 531 Maddison, B., "rpkimancer-doa", June 2021, 532 . 534 Appendix A. Acknowledgements 536 TODO 538 Appendix B. Document Changelog 540 This section is to be removed before publishing as an RFC. 542 B.1. Individual Submission Phase 544 Authors' Addresses 546 Job Snijders 547 Fastly 548 Amsterdam 549 Netherlands 550 Email: job@fastly.com 551 Mikael Abrahamsson 552 NTT Ltd. 553 Stockholm 554 Sweden 555 Email: mikael@swm.pp.se 557 Ben Maddison 558 Workonline Communications 559 Cape Town 560 South Africa 561 Email: benm@workonline.africa