idnits 2.17.1 draft-huston-sidr-roa-validation-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. 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 : ---------------------------------------------------------------------------- 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 26, 2009) is 5449 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 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: November 27, 2009 May 26, 2009 7 Validation of Route Origination in BGP using the Resource Certificate 8 PKI 9 draft-huston-sidr-roa-validation-01.txt 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on November 27, 2009. 34 Copyright Notice 36 Copyright (c) 2009 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents in effect on the date of 41 publication of this document (http://trustee.ietf.org/license-info). 42 Please review these documents carefully, as they describe your rights 43 and restrictions with respect to this document. 45 Abstract 47 This document defines an application of the Resource Public Key 48 Infrastructure to validate the origination of routes advertised in 49 the Border Gateway Protocol. The proposed application is intended to 50 fit within the requirements for adding security to inter-domain 51 routing, including the ability to support incremental and piecemeal 52 deployment, and does not require any changes to the specification of 53 BGP. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Validation Outcomes of a BGP Route Object . . . . . . . . . . . 3 59 2.1. Decoupled Validation . . . . . . . . . . . . . . . . . . . 4 60 2.2. Linked Validation . . . . . . . . . . . . . . . . . . . . . 5 61 3. Applying Validation Outcomes to BGP Route 62 Selection . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 63 3.1. Validation Outcomes and Rejection of BGP Route 64 Objects . . . . . . . . . . . . . . . . . . . . . . . . . . 6 65 4. Further Considerations . . . . . . . . . . . . . . . . . . . . 6 66 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 67 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 68 7. Changes from draft-ietf-sidr-roa-validation-01 . . . . . . . . 8 69 8. Normative References . . . . . . . . . . . . . . . . . . . . . 8 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 72 1. Introduction 74 This document defines an application of the Resource Public Key 75 Infrastructure (RPKI) to validate the origination of routes 76 advertised in the Border Gateway Protocol (BGP) [RFC4271]. 78 The RPKI is based on Resource Certificates. Resource Certificates 79 are X.509 certificates that conform to the PKIX profile [RFC5280], 80 and to the extensions for IP addresses and AS identifiers [RFC3779]. 81 A Resource Certificate describes an action by an issuer that binds a 82 list of IP address blocks and Autonomous System (AS) numbers to the 83 Subject of a certificate, identified by the unique association of the 84 Subject's private key with the public key contained in the Resource 85 Certificate. The PKI is structured such that each current Resource 86 Certificate matches a current resource allocation or assignment. 87 This is described in [I-D.ietf-sidr-arch]. 89 Route Origin Authorizations (ROAs) are digitally signed objects that 90 bind an address to an AS number, signed by the address holder. A ROA 91 provides a means of verifying that an IP address block holder has 92 authorized an AS to originate route objects in the inter-domain 93 routing environment for that address block. ROAs are described in 94 [I-D.ietf-sidr-roa-format]. 96 This document describes how ROA validation outcomes can be used in 97 the BGP route selection process, and how the proposed application of 98 ROAs is intended to fit within the requirements for adding security 99 to inter-domain routing, including the ability to support incremental 100 and piecemeal deployment. This proposed application does not require 101 any changes to the specification of BGP protocol elements. The 102 application may be used as part of BGP's local route selection 103 algorithm [RFC4271]. 105 2. Validation Outcomes of a BGP Route Object 107 A BGP Route Object is an address prefix and a set of attributes. In 108 terms of ROA and BOA validation the prefix value and the origin AS 109 are used in the validation operation. 111 If the route object is an aggregate and the AS Path contains an AS 112 Set, then the origin AS is considered to be the AS described as the 113 AGGREGATOR [RFC4271] of the route object. 115 ROA validation is described in [I-D.ietf-sidr-roa-format], and the 116 outcome of the validation operation is that the ROA is valid in the 117 context of the RPKI, or validation has failed. 119 There appears to be two means of matching a route object to a ROA: 120 decoupled and linked. 122 2.1. Decoupled Validation 124 The decoupled approach is where the ROAs are managed and distributed 125 independently of the operation of the routing protocol and a local 126 BGP speaker has access to a local cache of the complete set of ROAs 127 and the RPKI data set when performing a validation operation. 129 In this case the BGP route object does not refer to a specific ROA. 130 The relying party needs to match a route object to one or more 131 candidate valid ROAs in order to determine the appropriate local 132 actions to perform on the route object. 134 The relying party selects a set of valid ROAs where the address 135 prefix in the route object either exactly matches an ROAIPAddress 136 (matching both the address prefix value and the prefix length), or 137 where the route object spans a block of addresses that is included in 138 the span described by the ROA's address prefix value and length and 139 where the route object's prefix length is less than the ROA's prefix 140 length. 142 If the set of ROAs is empty then the validation outcome can be 143 classified as "unknown". 145 Otherwise the route object should be tested against the set of valid 146 ROAS. The following outcomes are possible using the defined ROA 147 validation procedure for each ROA in this set: 149 Exact Match: 150 A valid ROA exists, where the address prefix in the route object 151 exactly matches a prefix listed in the ROA, or the ROA contains a 152 covering aggregate and the prefix length of the route object is 153 smaller than or equal to the ROA's associated maxLength attribute, 154 and the origin AS in the route object matches the origin AS listed 155 in the ROA. 157 More Specific: 158 A valid ROA exists, where an address prefix in the ROA is a 159 covering aggregate of the prefix in the route object, and the 160 prefix length of the route object is greater than the ROA's 161 associated maxLength attribute, and the origin AS in the route 162 object matches the AS listed in the ROA. 164 AS Mismatch: 165 A valid ROA exists where the address prefix in the route object 166 exactly matches a prefix listed in the ROA, or the ROA contains a 167 covering aggregate and the prefix length of the route object is 168 smaller than or equal to the ROA's associated maxLength attribute, 169 and the origin AS of the route object does not match the AS listed 170 in the ROA. 172 More Specific AS Mismatch: 173 A valid ROA exists where an address prefix in the ROA is a 174 covering aggregate of the prefix in the route object, the prefix 175 length of the route object is greater than the ROA's associated 176 maxLength attribute, and the origin AS of the route object does 177 not match the AS listed in the ROA. 179 If any of the ROAs in the set provide an "Exact Match" outcome then 180 the BGP route object can be interpreted by the Relying Party as 181 "valid", otherwise the route object can be regarded as "invalid". 183 2.2. Linked Validation 185 The linked approach requires the route object to reference a ROA 186 either by inclusion of the ROA as an attribute of the route object, 187 or inclusion of a identity field in an attribute of the route object 188 as a means of identifying a particular ROA. 190 If the ROA can be located is valid within the context of the RPKI 191 then the route object can be compared against the ROA, as per the 192 previous section, and can be validated if there is an "Exact Match" 193 and otherwise be regarded as invalid. 195 3. Applying Validation Outcomes to BGP Route Selection 197 Within the framework of the abstract model of BGP operation, a 198 received prefix announcement from a peer is compared to all 199 announcements for this prefix received from other peers and a route 200 selection procedure is used to select the "best" route object from 201 this candidate set which is then used locally by placing it in the 202 loc-RIB, and is announced to peers as the local "best" route. 204 It is proposed here that the validation outcome (or "unknown", 205 "valid" or "invalid") be used as part of the determination of the 206 local degree of preference as defined in section 9.1.1 of the BGP 207 specification [RFC4271]. 209 The proposed addition to the local degree of preference is "valid" is 210 to be preferred over "unknown" over "invalid". 212 3.1. Validation Outcomes and Rejection of BGP Route 213 Objects 215 It is a matter of local preference setting whether "invalid" route 216 objects are discarded from further consideration in the route 217 selection process, however the following consideration should be 218 taken into account in such a situation. 220 The consideration here is one of potential circularity of dependence. 221 If the authoritative publication point of the repository of ROAs or 222 any certificates used in relation to an address prefix is stored at a 223 location that lies within the address prefix described in a ROA, then 224 the repository can only be accessed once a route for the prefix has 225 been accepted by the local routing domain. It is also noted that the 226 propagation time of RPKI objects may be different to the propagation 227 time of route objects in BGP, and that route objects may be received 228 before the relying party's local repository cache picks up the 229 associated ROAs and recognises them as valid within the RPKI. 231 For these reasons it is advised that, even in the case of 232 comprehensive deployment of ROAs, "unknown" and "invalid" validations 233 should not be considered as sufficient grounds to reject a route 234 advertisement outright. Alternate approaches may involve the use of 235 a local timer to accept the route for an interim period of time until 236 there is an acceptable level of assurance that all reasonable efforts 237 to local a valid ROA have been undertaken. 239 4. Further Considerations 241 This document provides a description of how ROAs could be used by a 242 BGP speaker. 244 It is noted that the proposed procedure requires no changes to the 245 operation of BGP. 247 It is also noted that the decoupled and linked approach are not 248 mutually exclusive, and the same procedure can be applied to route 249 objects that contain an explicit pointer to the associated ROA and 250 route objects where the local BGP speaker has to create a set of 251 candidate ROAs that could be applied to a route object. However, 252 there are a number of considerations about this approach to 253 origination validation that are not specified here. 255 These considerations include: 257 o It is not specified when validation of an advertised prefix should 258 be performed by a BGP speaker. Is is considered to be a matter of 259 local policy whether it is considered to be strictly necessary to 260 perform validation at a point prior to loading the object into the 261 Adj-RIB-In structure, or once the object has been loaded into Adj- 262 RIB-In, or at a later time that is determined by a local 263 configuration setting. It is also not specified whether 264 origination validation should be performed each time a route 265 object is updated by a peer even when the origin AS has not 266 altered. 268 o The lifetime of a validation outcome is not specified here. This 269 specifically refers to the time period during which the original 270 validation outcome can be still applied, and the time when the 271 routing object be revalidated. It is a matter of local policy 272 setting as to whether a validation outcome be regarded as valid 273 until the route object is withdrawn or further updated, or whether 274 validation of a route object should occur at more frequent 275 intervals? 277 o It is a matter of local policy as to whether there are 278 circumstances that would allow a route object to be removed from 279 further consideration in route selection upon a validation 280 failure, similar to the actions of Route Flap Damping. 282 o It is a matter of local configuration as to whether ROA validation 283 is performed on a per-AS basis rather than a per-BGP speaker, and 284 the appropriate BGP mechanisms to support such a per-AS iBGP route 285 validation service are not considered here. 287 5. Security Considerations 289 This approach to origination validation does not allow for 290 'deterministic' validation in terms of the ability of a BGP speaker 291 to accept or reject an advertised route object outright, given that 292 there remains some issues of potential circularity of dependence and 293 time lags between the propagation of information in the routing 294 system and propagation of information in the RPKI. 296 There are also issues of the most appropriate interpretation of 297 outcomes where validation of the authenticity of the route object has 298 not been possible in the context of partial adoption of the RPKI, 299 where the absence of validation information does not necessarily 300 constitute sufficient grounds to interpret the route object as an 301 invalidly originated object. 303 6. IANA Considerations 305 [There are no IANA considerations in this document.] 307 7. Changes from draft-ietf-sidr-roa-validation-01 309 Following WG discussion at IETF 74 on the appropriate means of 310 specification of denial in routing authorizations in the context of 311 the RPKI, it appears to the authors that there is no general WG 312 support for the inclusion of an explicit denial capability. Instead, 313 the authors are of the view there was visible WG support, to the 314 level of some form of rough consensus, for the approach where a valid 315 ROA acts as an implicit "denial" for those route objects that have 316 address prefixes that are more specific than the set of prefixes 317 specified in the ROA, and for those route objects which have 318 originating AS numbers other than those listed in valid ROAs that 319 span the address prefix listed in the route object. This draft has 320 been revised to remove all references to the use of an explicit 321 denial object in ROA validation, and uses only the semantics of a ROA 322 to define an "invalid" route object in this context. The remainder 323 of the WG internet draft has been left largely intact. 325 8. Normative References 327 [I-D.ietf-sidr-arch] 328 Lepinski, M., Kent, S., and R. Barnes, "An Infrastructure 329 to Support Secure Internet Routing", draft-ietf-sidr-arch 330 (work in progress), March 2009. 332 [I-D.ietf-sidr-roa-format] 333 Lepinski, M., Kent, S., and D. Kong, "An Infrastructure to 334 Support Secure Internet Routing", 335 draft-ietf-sidr-roa-format (work in progress), 336 nOVEMBER 2008. 338 [RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP 339 Addresses and AS Identifiers", RFC 3779, June 2004. 341 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 342 Protocol 4 (BGP-4)", RFC 4271, January 2006. 344 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 345 Housley, R., and W. Polk, "Internet X.509 Public Key 346 Infrastructure Certificate and Certificate Revocation List 347 (CRL) Profile", RFC 5280, May 2008. 349 Authors' Addresses 351 Geoff Huston 352 Asia Pacific Network Information Centre 354 Email: gih@apnic.net 356 George Michaelson 357 Asia Pacific Network Information Centre 359 Email: ggm@apnic.net