idnits 2.17.1 draft-ietf-sidr-roa-validation-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) 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 256: '... prefix, SHOULD NOT be used in a rou...' RFC 2119 keyword, line 269: '...ion, an AS 0 ROA SHOULD have a maxLeng...' RFC 2119 keyword, line 275: '...ion, an AS 0 ROA SHOULD be the only RO...' RFC 2119 keyword, line 286: '...e routing object SHOULD be re-tested f...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 160 has weird spacing: '...atching non-...' -- 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 (March 3, 2010) is 5158 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Secure Inter-Domain Routing (SIDR) G. Huston 3 Internet-Draft G. Michaelson 4 Intended status: Informational APNIC 5 Expires: September 4, 2010 March 3, 2010 7 Validation of Route Origination using the Resource Certificate PKI and 8 ROAs 9 draft-ietf-sidr-roa-validation-05.txt 11 Abstract 13 This document defines the semantics of a Route Origin Authorization 14 in terms of the context of an application of the Resource Public Key 15 Infrastructure to validate the origination of routes advertised in 16 the Border Gateway Protocol. 18 Status of this Memo 20 This Internet-Draft is submitted to IETF in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet- 26 Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt. 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 This Internet-Draft will expire on September 4, 2010. 41 Copyright Notice 43 Copyright (c) 2010 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. ROA Validation Outcomes for a Route . . . . . . . . . . . . . . 3 60 3. Applying Validation Outcomes to Route Selection . . . . . . . . 6 61 4. Disavowal of Routing Origination . . . . . . . . . . . . . . . 6 62 5. Route Validation Lifetime . . . . . . . . . . . . . . . . . . . 7 63 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 64 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 65 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 66 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 67 9.1. Normative References . . . . . . . . . . . . . . . . . . . 8 68 9.2. Informative References . . . . . . . . . . . . . . . . . . 9 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 71 1. Introduction 73 This document defines the semantics of a Route Origin Authorization 74 (ROA) in terms of the context of an application of the Resource 75 Public Key Infrastructure (RPKI) [I-D.ietf-sidr-arch] to validate the 76 origination of routes advertised in the Border Gateway Protocol (BGP) 77 [RFC4271]. 79 The RPKI is based on a hierarchy of Resource Certificates that are 80 aligned to the Internet number resource allocation structure. 81 Resource Certificates are X.509 certificates that conform to the PKIX 82 profile [RFC5280], and to the extensions for IP addresses and AS 83 identifiers [RFC3779]. A Resource Certificate describes an action by 84 an issuer that binds a list of IP address blocks and Autonomous 85 System (AS) numbers to the Subject of a certificate, identified by 86 the unique association of the Subject's private key with the public 87 key contained in the Resource Certificate. The RPKI is structured 88 such that each current Resource Certificate matches a current 89 resource allocation or assignment. This is further described in 90 [I-D.ietf-sidr-arch]. 92 ROAs are digitally signed objects that bind an address to an AS 93 number, signed by the address holder. A ROA provides a means of 94 verifying that an IP address block holder has authorized a particular 95 AS to originate routes in the inter-domain routing environment for 96 that address block. ROAs are described in 97 [I-D.ietf-sidr-roa-format]. ROAs are intended to fit within the 98 requirements for adding security to inter-domain routing. 100 This document describes the semantic interpretation of a ROA, with 101 particular reference to application in inter-domain routing relating 102 to the origination of routes, and the intended scope of the authority 103 that is conveyed in the ROA. 105 2. ROA Validation Outcomes for a Route 107 A "route" is unit of information that associates a set of 108 destinations described by an IP address prefix with a set of 109 attributes of a path to those destinations, as defined in section 1.1 110 of [RFC4271]. 112 A route's "origin AS" is the final element of the route object's 113 AS_PATH attribute. If the final AS_PATH element is an AS Set, 114 indicating that the route is an aggregate, then the origin AS is 115 taken as the AS component of the AGGREGATOR attribute [RFC4271]. In 116 the case where there is an AS Set as the final AS_PATH element and no 117 AGGREGATOR attribute is present then the origin AS is the AS 118 immediately preceding the AS Set in the AS_PATH, and if there is no 119 such AS then the route's origin AS cannot be determined. 121 In terms of validation of a route in the context of a routing 122 environment, the address prefix value and the origin AS are used in 123 the ROA validation operation. 125 It is assumed here that a Relying Party (RP) has access to a local 126 cache of the complete set of valid ROAs when performing validation of 127 a route. (Valid ROAs are defined as ROAs that are determined to be 128 syntactically correct and are signed using a signature that can be 129 verified using the RPKI, as described in [I-D.ietf-sidr-roa-format].) 130 The RP needs to match a route to one or more candidate valid ROAs in 131 order to determine a validation outcome, which, in turn, can be used 132 to determine the appropriate local actions to perform on the route. 134 This approach to route origination validation uses a model of 135 "positive" attestations, with an associated inference that route that 136 cannot be validated within the RPKI framework would conventionally be 137 interpreted by a RP as "invalid". However, the considerations of 138 accommodating environments of partial adoption of the use of ROAs, 139 where only a subset of validly advertised address prefixes have 140 associated published ROAs within the structure of the RPKI, imply 141 some modification to this model of positive attestation. In the 142 context of route validation it is assumed that once an address prefix 143 is described in a ROA, then this ROA specifically encompasses all 144 address prefixes that are more specific than that described in the 145 ROA. Thus, any route for more specific address prefix than that 146 described by any valid ROA that does not itself have a matching valid 147 ROA is considered to be "invalid". However, routes objects for 148 address prefixes that are not fully described by any single ROA, 149 i.e., those route objects whose address prefixes may be an aggregate 150 of address prefixes described in a valid ROA, or have address 151 prefixes where there is no intersection with any ROA, and are not 152 matched by any ROA and are not a more specific of any ROA, cannot be 153 reliably classified as "invalid" in a partial deployment scenario. 154 Such routes have a validation outcome of "unknown". 156 The validation condition of a route with a prefix and an origin AS 157 when using single ROA for validation is summarized in the following 158 table: 160 Prefix matching non-matching 161 AS AS 162 +---------+-------------+ 163 Covering | unknown | unknown | 164 Aggregate | | | 165 +---------+-------------+ 166 match ROA | valid | invalid | 167 prefix | | | 168 +---------+-------------+ 169 More | invalid | invalid | 170 Specific | | | 171 than ROA | | | 172 +---------+-------------+ 174 In an environment of a collection of ROAs, a route is considered to 175 be "valid" if any ROA provides a "valid" outcome. It is considered 176 to be "invalid" if one (or more) ROAs provide an "invalid" outcome 177 and no ROAs provide a "valid" outcome. It is considered to be 178 "unknown" when no ROA produces either a "valid" or an "invalid" 179 outcome. 181 Route validation is defined by the following procedure: 183 1. Select all valid ROAs that include a ROAIPAddress value that 184 either matches, or is a covering aggregate of, the address 185 prefix in the route. 187 2. If the set of candidate ROAs is empty then the validation 188 procedure stops with an outcome of "unknown". 190 3. If any of the selected ROAs has an asID value that matches the 191 origin AS in the route, and the route object's address prefix 192 matches a ROAIPAddress in the ROA (where "match" is defined as 193 where the route object's address precisely matches the 194 ROAIPAddress, or where the ROAIPAddress includes a maxLength 195 element, and the route's address prefix is a more specific 196 prefix of the ROAIPAddress, and the route's address prefix 197 length value is less than or equal to the ROAIPAddress 198 maxLength value) then the validation procedure stops with an 199 outcome of "valid". 201 4. Otherwise, the validation procedure stops with an outcome of 202 "invalid". 204 3. Applying Validation Outcomes to Route Selection 206 Within the framework of the abstract model of the operation of inter- 207 domain routing using BGP [RFC4271], a received prefix announcement 208 from a routing peer is compared to all announcements for this prefix 209 received from other routing peers and a route selection procedure is 210 used to select the "best" route from this candidate set. 212 The route validation outcome, described in Section 2, of "unknown", 213 "valid" or "invalid" may be used as part of the determination of the 214 local degree of preference, in which case the local order of 215 preference is as follows: 216 "valid" is to be preferred over 217 "unknown", which itself is to be preferred over 218 "invalid". 220 It is a matter of local routing policy as to the actions to be 221 undertaken by a routing entity in processing routes with "unknown" 222 validation outcomes. Due to considerations of partial use of ROAs in 223 heterogeneous environments, such as in the public Internet, it is 224 advised that local policy settings should not result in "unknown" 225 validation outcomes being considered as sufficient grounds to reject 226 a route outright from further consideration as a local "best" route. 228 It is a matter of local routing policy as to whether "invalid" routes 229 are considered to be ineligible for further consideration in a route 230 selection process. A possible consideration here is one of potential 231 circularity of dependence. If the authoritative publication point of 232 the repository of ROAs, or that of any certificate used in relation 233 to an address prefix, is located at an address that lies within the 234 address prefix described in a ROA, then the repository can only be 235 accessed by the RP once a route for the prefix has been accepted by 236 the RP's local routing domain. It is also noted that the propagation 237 time of RPKI objects may be different to the propagation time of 238 routes, and that routes may be learned by an RP's routing system 239 before the RP's local RPKI repository cache picks up the associated 240 ROAs and recognises them as valid within the RPKI. 242 4. Disavowal of Routing Origination 244 A ROA is a positive attestation that a prefix holder has authorized 245 an AS to originate a route for this prefix into the inter-domain 246 routing system. It is possible for a prefix holder to construct an 247 authorization where no valid AS has been granted any such authority 248 to originate a route for an address prefix. This is achieved by 249 using a ROA where the ROA's subject AS is one that must never be used 250 in any routing context. Specifically, AS 0 is reserved by the IANA 251 such that it "may be use [sic] to identify non-routed networks" 252 [IANA.AS-Registry]. 254 A ROA with a subject of AS 0 is an attestation by the holder of a 255 prefix that the prefix described in the ROA, and any more specific 256 prefix, SHOULD NOT be used in a routing context. 258 The route validation procedure, described in Section 2, will provide 259 a "valid" outcome if any ROA matches the address prefix and origin 260 AS, even if other valid ROAs would provide an "invalid" validation 261 outcome if used in isolation. Consequently, an AS 0 ROA has a lower 262 preference than any other ROA that has a routeable AS as its subject. 263 This allows a prefix holder to use an AS 0 ROA to declare a default 264 condition that any route that is equal to, or more specific than the 265 prefix to be considered to be invalid, while also allowing other 266 concurrently issued ROAs to describe valid origination authorizations 267 for more specific prefixes. 269 By convention, an AS 0 ROA SHOULD have a maxLength value of 32 for 270 IPv4 addresses and 128 for IPv6 addresses, although in terms of route 271 validation the same outcome would be achieved with any valid 272 maxLength value, or even if the maxLength element were to be omitted 273 from the ROA. 275 Also by convention, an AS 0 ROA SHOULD be the only ROA issued for a 276 given address prefix, although again this is not a strict 277 requirement. An AS 0 ROA can coexist with ROAs that have different 278 subject AS values, although in such cases the presence of the AS 0 279 ROA does not alter the route validation outcome in any way. 281 5. Route Validation Lifetime 283 The "lifetime" of a validation outcome refers to the time period 284 during which the original validation outcome can be still applied. 285 The implicit assumption here is that when the validation lifetime 286 expires the routing object SHOULD be re-tested for validity. 288 The validation lifetime for a ROA is controlled by the Valid times 289 specified in the End Entity (EE) Certificate used to sign the ROA, 290 and the valid times of those certificates in the certification path 291 used to validate the EE Certificate. A ROA validation "expires" at 292 the Validity To field of the signing EE certificate, or at such a 293 time when there is no certification path that can validate the ROA. 294 A ROA issuer may prematurely invalidate a ROA by revoking the EE 295 certificate that was used to sign the ROA. 297 6. Security Considerations 299 ROA issuers should be aware of the validation implication in issuing 300 a ROA, in that a ROA implicitly invalidates all route objects that 301 have more specific prefixes with a prefix length greater than 302 maxLength, and all originating AS's other than the AS listed in the 303 collection of ROAs for this prefix. 305 A conservative operational practice would be to ensure the issuing of 306 ROAs for all more specific prefixes with distinct origination AS's 307 prior to the issuing of ROAs for larger encompassing address blocks, 308 in order to avoid inadvertent invalidation of valid routes during ROA 309 generation. 311 ROA issuers should also be aware that if they generate a ROA for one 312 origin AS, then if the address prefix holder authorises multiple AS's 313 to originate routes for a given address prefix, then is necessary for 314 a ROA be generated for every such authorized AS. 316 7. IANA Considerations 318 [There are no IANA Considerations.] 320 8. Acknowledgements 322 The authors would like to acknowledge the helpful contributions of 323 John Scudder and Stephen Kent in preparing this document, and also 324 the contributions of many members of the SIDR Working Group in 325 response to presentations of this material in SIDR WG sessions. The 326 authors also acknowledge prior work undertaken by Tony Bates, Randy 327 Bush, Tony Li, and Yakov Rekhter as the validation outcomes described 328 here reflect the authentication outcomes and semantics of origin AS 329 verification described in [exI-D.bates]. 331 9. References 333 9.1. Normative References 335 [I-D.ietf-sidr-arch] 336 Lepinski, M. and S. Kent, "An Infrastructure to Support 337 Secure Internet Routing", draft-ietf-sidr-arch (work in 338 progress), October 2009. 340 [I-D.ietf-sidr-roa-format] 341 Lepinski, M., Kent, S., and D. Kong, "An Infrastructure to 342 Support Secure Internet Routing", 343 draft-ietf-sidr-roa-format (work in progress), 344 October 2009. 346 [RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP 347 Addresses and AS Identifiers", RFC 3779, June 2004. 349 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 350 Protocol 4 (BGP-4)", RFC 4271, January 2006. 352 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 353 Housley, R., and W. Polk, "Internet X.509 Public Key 354 Infrastructure Certificate and Certificate Revocation List 355 (CRL) Profile", RFC 5280, May 2008. 357 9.2. Informative References 359 [IANA.AS-Registry] 360 IANA, "IANA Autonomous System Number Registry", 361 March 2010. 363 [exI-D.bates] 364 Bates, T., Bush, R., Li, T., and Y. Rekhter, "DNS-based 365 NLRI origin AS verification in BGP", 366 draft-bates-bgp4-nlri-orig-verif-00.txt (work in 367 progress), January 1998. 369 Authors' Addresses 371 Geoff Huston 372 Asia Pacific Network Information Centre 374 Email: gih@apnic.net 376 George Michaelson 377 Asia Pacific Network Information Centre 379 Email: ggm@apnic.net