idnits 2.17.1 draft-ietf-sidr-roa-format-12.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 seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 9, 2011) is 4698 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) -- Looks like a reference, but probably isn't: '0' on line 305 Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Secure Inter-Domain Routing (sidr) M. Lepinski 2 Internet Draft S. Kent 3 Expires: November 9, 2011 D. Kong 4 Intended Status: Proposed Standard BBN Technologies 5 May 9, 2011 7 A Profile for Route Origin Authorizations (ROAs) 8 draft-ietf-sidr-roa-format-12.txt 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with the 13 provisions of BCP 78 and BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html 31 This Internet-Draft will expire on November 9, 2011. 33 Copyright Notice 35 Copyright (c) 2011 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Abstract 50 This document defines a standard profile for Route Origin 51 Authorizations (ROAs). A ROA is a digitally signed object that 52 provides a means of verifying that an IP address block holder has 53 authorized an Autonomous System (AS) to originate routes to one or 54 more prefixes within the address block. 56 Table of Contents 58 1. Introduction...................................................2 59 1.1. Terminology...............................................3 60 2. The ROA ContentType............................................3 61 3. The ROA eContent...............................................3 62 3.1. version...................................................4 63 3.2. asID......................................................4 64 3.3. ipAddrBlocks..............................................4 65 4. ROA Validation.................................................5 66 5. Security Considerations........................................5 67 6. IANA Considerations............................................6 68 7. Acknowledgments................................................6 69 8. References.....................................................7 70 8.1. Normative References......................................7 71 8.2. Informative References....................................7 72 APPENDIX A: ASN.1 Module..........................................8 73 Authors' Addresses................................................9 75 1. Introduction 77 The primary purpose of the Internet IP Address and Autonomous System 78 (AS) Number Resource Public Key Infrastructure (RPKI) system is to 79 improve routing security. (See [ARCH] for more information.) As part 80 of this system, a mechanism is needed to allow entities to verify 81 that an AS has been given permission by an IP address block holder to 82 advertise routes to one or more prefixes within that block. A ROA 83 provides this function. 85 The ROA makes use of the template for RPKI digitally signed objects 86 [SIGNOBJ], which defines a Crytopgraphic Message Syntax (CMS) 87 [RFC5652] wrapper for the ROA content as well as a generic validation 88 procedure for RPKI signed objects. Therefore, to complete the 89 specification of the ROA (see Section 4 of [SIGNOBJ]), this document 90 defines: 92 1. The OID that identifies the signed object as being a ROA. (This 93 OID appears within the eContentType in the encapContentInfo 94 object as well as the ContentType signed attribute in the 95 signerInfo object.) 97 2. The ASN.1 syntax for the ROA eContent. (This is the payload 98 that specifies the AS being authorized to originate routes as 99 well as the prefixes to which the AS may originate routes.) 101 3. An additional step required to validate ROAs (in addition to 102 the validation steps specified in [SIGNOBJ]). 104 1.1. Terminology 106 It is assumed that the reader is familiar with the terms and concepts 107 described in "Internet X.509 Public Key Infrastructure Certificate 108 and Certificate Revocation List (CRL) Profile" [RFC5280] and "X.509 109 Extensions for IP Addresses and AS Identifiers" [RFC3779]. 111 Additionally, this document makes use of the RPKI signed object 112 profile [SIGNOBJ] and thus familiarity with that document is assumed. 113 Note that the RPKI signed object profile makes use of certificates 114 adhering to the RPKI resource certificate profile [RESCERT] and thus 115 familiarly with this profile is also assumed. 117 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 118 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 119 "OPTIONAL" in this document are to be interpreted as described in 120 RFC-2119 [RFC2119]. 122 2. The ROA ContentType 124 The ContentType for a ROA is defined as routeOriginAuthz and has the 125 numerical value of 1.2.840.113549.1.9.16.1.24. 127 This OID MUST appear both within the eContentType in the 128 encapContentInfo object as well as the ContentType signed attribute 129 in the signerInfo object (see [SIGNOBJ]). 131 3. The ROA eContent 133 The content of a ROA identifies a single AS that has been authorized 134 by the address space holder to originate routes and a list of one or 135 more IP address prefixes that will be advertised. If the address 136 space holder needs to authorize multiple ASes to advertise the same 137 set of address prefixes, the holder issues multiple ROAs, one per AS 138 number. A ROA is formally defined as: 140 RouteOriginAttestation ::= SEQUENCE { 141 version [0] INTEGER DEFAULT 0, 142 asID ASID, 143 ipAddrBlocks SEQUENCE (SIZE(1..MAX)) OF ROAIPAddressFamily } 145 ASID ::= INTEGER 147 ROAIPAddressFamily ::= SEQUENCE { 148 addressFamily OCTET STRING (SIZE (2..3)), 149 addresses SEQUENCE (SIZE (1..MAX)) OF ROAIPAddress } 151 ROAIPAddress ::= SEQUENCE { 152 address IPAddress, 153 maxLength INTEGER OPTIONAL } 155 IPAddress ::= BIT STRING 157 Note that this content appears as the eContent within the 158 encapContentInfo (see [SIGNOBJ]). 160 3.1. version 162 The version number of the RouteOriginAttestation MUST be 0. 164 3.2. asID 166 The asID field contains the AS number that is authorized to originate 167 routes to the given IP address prefixes. 169 3.3. ipAddrBlocks 171 The ipAddrBlocks field encodes the set of IP address prefixes to 172 which the AS is authorized to originate routes. Note that the syntax 173 here is more restrictive than that used in the IP Address Delegation 174 extension defined in RFC 3779. That extension can represent arbitrary 175 address ranges, whereas ROAs need to represent only prefixes. 177 Within the ROAIPAddressFamily structure, addressFamily contains the 178 Address Family Identifier (AFI) of an IP address family. This 179 specification only supports IPv4 and IPv6. Therefore, addressFamily 180 MUST be either 0001 or 0002. 182 Within a ROAIPAddress structure, the addresses field represents 183 prefixes as a sequence of type IPAddress. (See [RFC3779] for more 184 details). If present, the maxLength MUST be an integer greater than 185 or equal to the length of the accompanying prefix and less than or 186 equal to the length (in bits) of an IP address in the address family 187 (32 for IPv4 and 128 for IPv6). When present, the maxLength specifies 188 the maximum length of IP address prefix that the AS is authorized to 189 advertise. (For example, if the IP Address prefix is 203.0.113/24 and 190 the maxLength is 26, the AS is authorized to advertise any more 191 specific prefix having length at most 26. That is, in this example, 192 the AS would be authorized to advertise 203.0.113/24, 193 203.0.113.128/25, or 203.0.113.0/25, but not 203.0.113.0/27.) When 194 the maxLength is not present, the AS is only authorized to advertise 195 exactly the prefix specified in the ROA. 197 Note that a valid ROA may contain an IP Address prefix (within a 198 ROAIPAddress element) that is encompassed by another IP Address 199 prefix (within a separate ROAIPAddress element). For example, a ROA 200 may contain the prefix 203.0.113/24 with maxLength 26, as well as the 201 prefix 203.0.113.0/28 with maxLength 28. (Such a ROA would authorize 202 the indicated AS to advertise any prefix beginning with 203.0.113 203 with length at least 24 and no greater than 26, as well as the 204 specific prefix 203.0.113.0/28.) Additionally, a ROA MAY contain two 205 ROAIPAddress elements where the IP Address prefix is identical in 206 both cases. However, this is NOT RECOMMENDED as in such a case the 207 ROAIPAddress with the shorter maxLength grants no additional 208 privileges to the indicated AS and thus can be omitted without 209 changing the meaning of the ROA. 211 4. ROA Validation 213 Before a relying party can use a ROA to validate a routing 214 announcement, the relying party MUST first validate the ROA. To 215 validate a ROA the relying party MUST perform all the validation 216 checks specified in [SIGNOBJ] as well as the following additional 217 ROA-specific validation step. 219 o The IP Address Delegation extension [RFC3779] is present in the 220 End-Entity (EE) certificate (contained within the ROA) and each IP 221 address prefix(es) in ROA is contained within the set of IP 222 addresses specified by the EE certificate's IP address delegation 223 extension. 225 5. Security Considerations 227 There is no assumption of confidentiality for the data in a ROA; it 228 is anticipated that ROAs will be stored in repositories that are 229 accessible to all ISPs, and perhaps to all Internet users. There is 230 no explicit authentication associated with a ROA, since the PKI used 231 for ROA validation provides authorization but not authentication. 232 Although the ROA is a signed, application layer object, there is no 233 intent to convey non-repudiation via a ROA. 235 The purpose of a ROA is to convey authorization for an AS to 236 originate a route to the prefix(es) in the ROA. Thus the integrity of 237 a ROA MUST be established. The ROA specification makes use of the 238 RPKI signed object format, thus all security considerations in 239 [SIGNOBJ] also apply to ROAs. Additionally, the signed object profile 240 uses the CMS signed message format for integrity, and thus ROA 241 inherit all security considerations associated with that data 242 structure. 244 The right of the ROA signer to authorize the target AS to originate 245 routes to the prefix(es) is established through use of the address 246 space and AS number PKI described in [ARCH]. Specifically one MUST 247 verify the signature on the ROA using an X.509 certificate issued 248 under this PKI, and check that the prefix(es) in the ROA match those 249 in the address space extension in the certificate. 251 6. IANA Considerations 253 None. 255 7. Acknowledgments 257 The authors wish to thank Charles Gardiner and Russ Housley for their 258 help and contributions. Additionally, the authors would like to thank 259 Rob Austein, Roque Gagliano, Danny McPherson and Sam Weiler for their 260 careful reviews and helpful comments. 262 8. References 264 8.1. Normative References 266 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 267 Requirement Levels", BCP 14, RFC 2119, March 1997. 269 [RFC5652] Housley, R., "Cryptographic Message Syntax", RFC 5652, 270 September 2009. 272 [RFC3779] Lynn, C., Kent, S., and Seo, K., "X.509 Extensions for IP 273 Addresses and AS Identifiers", RFC 3779, June 2004. 275 [RFC5280] Cooper, D., et. al., "Internet X.509 Public Key 276 Infrastructure and Certificate Revocation List (CRL) 277 Profile", RFC 5280, May 2008. 279 [RESCERT] Huston, G., Michaelson, G., and Loomans, R., "A Profile for 280 X.509 PKIX Resource Certificates", draft-ietf-sidr-res- 281 certs, November 2010. 283 [SIGNOBJ] Lepinski, M., Chi, A., and Kent, S., "Generic Signed 284 Objects for the Resource Public Key Infrastructure", draft- 285 ietf-sidr-signed-object, February 2011. 287 8.2. Informative References 289 [ARCH] Lepinski, M. and Kent, S., "An Infrastructure to Support 290 Secure Internet Routing," draft-ietf-sidr-arch, February 291 2011. 293 APPENDIX A: ASN.1 Module 295 This normative appendix provides an ASN.1 module that specifies the 296 ROA content in ASN.1 syntax. 298 RPKI-ROA { iso(1) member-body(2) us(840) rsadsi(113549) 299 pkcs(1) pkcs9(9) smime(16) mod(0) 61 } 301 DEFINITIONS EXPLICIT TAGS ::= 302 BEGIN 304 RouteOriginAttestation ::= SEQUENCE { 305 version [0] INTEGER DEFAULT 0, 306 asID ASID, 307 ipAddrBlocks SEQUENCE (SIZE(1..MAX)) OF ROAIPAddressFamily } 309 ASID ::= INTEGER 311 ROAIPAddressFamily ::= SEQUENCE { 312 addressFamily OCTET STRING (SIZE (2..3)), 313 addresses SEQUENCE (SIZE (1..MAX)) OF ROAIPAddress } 315 ROAIPAddress ::= SEQUENCE { 316 address IPAddress, 317 maxLength INTEGER OPTIONAL } 319 IPAddress ::= BIT STRING 321 END 323 Authors' Addresses 325 Matt Lepinski 326 BBN Technologies 327 10 Moulton Street 328 Cambridge MA 02138 330 Email: mlepinski@bbn.com 332 Stephen Kent 333 BBN Technologies 334 10 Moulton Street 335 Cambridge MA 02138 337 Email: skent@bbn.com 339 Derrick Kong 340 BBN Technologies 341 10 Moulton Street 342 Cambridge MA 02138 344 Email: dkong@bbn.com