idnits 2.17.00 (12 Aug 2021) /tmp/idnits28827/draft-ietf-sidr-roa-validation-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 504. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 515. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 522. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 528. 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 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 (October 6, 2008) is 4974 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: draft-ietf-sidr-arch has been published as RFC 6480 == Outdated reference: draft-ietf-sidr-roa-format has been published as RFC 6482 == Outdated reference: draft-ietf-sidr-roa-format has been published as RFC 6482 -- Duplicate reference: draft-ietf-sidr-roa-format, mentioned in 'ID.ietf-rpsec-bgpsecrec', was also mentioned in 'I-D.ietf-sidr-roa-format'. Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 8 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: April 9, 2009 October 6, 2008 7 Validation of Route Origination in BGP using the Resource Certificate 8 PKI 9 draft-ietf-sidr-roa-validation-01.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on April 9, 2009. 36 Abstract 38 This document defines an application of the Resource Public Key 39 Infrastructure to validate the origination of routes advertised in 40 the Border Gateway Protocol. The proposed application is intended to 41 fit within the requirements for adding security to inter-domain 42 routing, including the ability to support incremental and piecemeal 43 deployment, and does not require any changes to the specification of 44 BGP. 46 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 49 2. Validation Outcomes of a BGP Route Object . . . . . . . . . . 3 50 2.1. Decoupled Validation . . . . . . . . . . . . . . . . . . . 4 51 2.2. Linked Validation . . . . . . . . . . . . . . . . . . . . 6 52 3. Applying Validation Outcomes to BGP Route Selection . . . . . 6 53 3.1. Validation Outcomes and Rejection of BGP Route Objects . . 9 54 4. Further Considerations . . . . . . . . . . . . . . . . . . . . 9 55 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 56 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 57 7. Normative References . . . . . . . . . . . . . . . . . . . . . 11 58 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 59 Intellectual Property and Copyright Statements . . . . . . . . . . 13 61 1. Introduction 63 This document defines an application of the Resource Public Key 64 Infrastructure (RPKI) to validate the origination of routes 65 advertised in the Border Gateway Protocol (BGP) [RFC4271]. 67 The RPKI is based on Resource Certificates. Resource Certificates 68 are X.509 certificates that conform to the PKIX profile [RFC5280], 69 and to the extensions for IP addresses and AS identifiers [RFC3779]. 70 A Resource Certificate describes an action by an issuer that binds a 71 list of IP address blocks and Autonomous System (AS) numbers to the 72 Subject of a certificate, identified by the unique association of the 73 Subject's private key with the public key contained in the Resource 74 Certificate. The PKI is structured such that each current Resource 75 Certificate matches a current resource allocation or assignment. 76 This is described in [I-D.ietf-sidr-arch]. 78 Route Origin Authorizations (ROAs) are digitally signed objects that 79 bind an address to an AS number, signed by the address holder. A ROA 80 provides a means of verifying that an IP address block holder has 81 authorized an AS to originate route objects in the inter-domain 82 routing environment for that address block. ROAs are described in 83 [I-D.ietf-sidr-roa-format]. 85 Bogon Origin Attestations (BOAs) are digitally signed objects that 86 describe a collection of address prefixes and AS numbers that are not 87 authorised by the right-of-use holder to be advertised in the inter- 88 domain routing system [I-D.ietf-sidr-boa]. 90 This document describes how ROA and BOA validation outcomes can be 91 used in the BGP route selection process, and how the proposed 92 application of ROAs and BOAs are intended to fit within the 93 requirements for adding security to inter-domain routing 94 [ID.ietf-rpsec-bgpsecrec], including the ability to support 95 incremental and piecemeal deployment. This proposed application does 96 not require any changes to the specification of BGP protocol 97 elements. The application may be used as part of BGP's local route 98 selection algorithm [RFC4271]. 100 2. Validation Outcomes of a BGP Route Object 102 A BGP Route Object is an address prefix and a set of attributes. In 103 terms of ROA and BOA validation the prefix value and the origin AS 104 are used in the validation operation. 106 If the route object is an aggregate and the AS Path contains an AS 107 Set, then the origin AS is considered to be the AS described as the 108 AGGREGATOR [RFC4271] of the route object. 110 ROA validation is described in [I-D.ietf-sidr-roa-format], and the 111 outcome of the validation operation is that the ROA is valid in the 112 context of the RPKI, or validation has failed. 114 BOA validation is described in [I-D.ietf-sidr-boa], and the outcome 115 of the validation operation is that the BOA is valid in the context 116 of the RPKI, or validation has failed. 118 There appears to be two means of matching a route object to a ROA: 119 decoupled and linked. 121 2.1. Decoupled Validation 123 The decoupled approach is where the ROAs are managed and distributed 124 independently of the operation of the routing protocol and a local 125 BGP speaker has access to a local cache of the complete set of ROAs 126 and the RPKI data set when performing a validation operation. 128 In this case the BGP route object does not refer to a specific ROA. 129 The relying party to match a route object to one or more candidate 130 valid ROAs and BOAs in order to determine the appropriate local 131 actions to perform on the route object. 133 The relying party selects the set of ROAs where the address prefix in 134 the route object either exactly matches an ROAIPAddress (matching 135 both the address prefix value and the prefix length), or where the 136 route object spans a block of addresses that is included in the span 137 described by the ROA's address prefix value and length and where the 138 route object's prefix length is less than the ROA's prefix length and 139 greater then or equal to the ROA's corresponding maxLength attribute. 141 The following outcomes are possible using the defined ROA validation 142 procedure for each ROA in this set: 144 Exact Match: 145 A valid ROA exists, where the address prefix in the route object 146 exactly matches a prefix listed in the ROA, or the ROA contains a 147 covering aggregate and the prefix length of the route object is 148 smaller than or equal to the ROA's associated maxLength attribute, 149 and the origin AS in the route object matches the origin AS listed 150 in the ROA. 152 Covering Match: 153 A valid ROA exists, where an address prefix in the ROA is a 154 covering aggregate of the prefix in the route object, and the 155 prefix length of the route object is greater than the ROA's 156 associated maxLength attribute, and the origin AS in the route 157 object matches the AS listed in the ROA. 159 Exact Mismatch: 160 A valid ROA exists where the address prefix in the route object 161 exactly matches a prefix listed in the ROA, or the ROA contains a 162 covering aggregate and the prefix length of the route object is 163 smaller than or equal to the ROA's associated maxLength attribute, 164 and the origin AS of the route object does not match the AS listed 165 in the ROA. 167 Covering Mismatch: 168 A valid ROA exists where an address prefix in the ROA is a 169 covering aggregate of the prefix in the route object, the prefix 170 length of the route object is greater than the ROA's associated 171 maxLength attribute, and the origin AS of the route object does 172 not match the AS listed in the ROA. 174 No ROA: 175 There are no Exact Matches, Covering Matches, no Exact Mismatches 176 or Covering Mismatches in the RPKI repository. 178 The ROA to be used for the validation function is selected from the 179 set of ROAs in the order given above. In other words an Exact Match 180 is preferred over a Covering Match, which, in turn, is preferred over 181 an Exact Mismatch which is preferred over a Covering Mismatch. 183 The set of BOAs that are used for the validation function are 184 composed of the set of valid BOAs where the origin AS of the route 185 object matches an AS described in a BOA, or where an address prefix 186 in a valid BOA that is an exact match or a covering aggregate of the 187 route object. In the case that the validation outcome using ROAs is 188 one of Exact Mismatch, Covering Mismatch or No ROA, then the 189 validation outcome of the BOA changes the overall validation result 190 to "Bogon". 192 Bogon: 193 A valid BOA exists where an address prefix in the BOA is a an 194 exact match for the prefix in the route object, or is a covering 195 aggregate of the prefix in the route object, or an AS in the BOA 196 matches the originating AS in the BOA. In addition, there is no 197 valid ROA that is an Exact Match or a Covering Match with the 198 route object. 200 2.2. Linked Validation 202 The linked approach requires the route object to reference a ROA 203 either by inclusion of the ROA as an attribute of the route object, 204 or inclusion of a identity field in an attribute of the route object 205 as a means of identifying a particular ROA. 207 If the ROA can be located is valid within the context of the RPKI 208 then the route object can be compared against the ROA, as per the 209 previous section, giving one of five possible results: Exact Match, 210 Covering Match, Exact Mismatch, Covering Mismatch, and No Match, 211 which is defined as: 213 No Match: 214 The valid ROA does not comtain any address prefix that exactly 215 matches the address prefix in the route object, or is a covering 216 aggregate of the address prefix in the route object. 218 In the case of a Mismatch or a No Match condition, the relying party 219 should check for the presence of valid BOAs where the origin AS of 220 the route object matches an AS described in a BOA, or where an 221 address prefix in a valid BOA that is an exact match or a covering 222 aggregate of the route object. If a valid BOA can be found that 223 matches either of these conditions that the overall route object 224 validation of a route object with a linked ROA is changed to "Bogon". 226 3. Applying Validation Outcomes to BGP Route Selection 228 Within the framework of the abstract model of BGP operation, a 229 received prefix announcement from a peer is compared to all 230 announcements for this prefix received from other peers and a route 231 selection procedure is used to select the "best" route object from 232 this candidate set which is then used locally by placing it in the 233 loc-RIB, and is announced to peers as the local "best" route. 235 It is proposed here that the validation outcome be used as part of 236 the determination of the local degree of preference as defined in 237 section 9.1.1 of the BGP specification [RFC4271]. 239 In the case of partial deployment of ROAs there are a very limited 240 set of circumstances where the outcome of ROA validation can be used 241 as grounds to reject all consideration of the route object as an 242 invalid advertisement. While the presence of a valid ROA that 243 matches the advertisement is a strong indication that an 244 advertisement matches the authority provided by the prefix holder to 245 advertise the prefix into the routing system, the absence of a ROA or 246 the invalidity of a covering ROA does not provide a conclusive 247 indication that the advertisement has been undertaken without the 248 address holder's permission, unless the object is described in a BOA. 250 In the case of a partial deployment scenario of RPKI route 251 attestation objects, where some address prefixes and AS numbers are 252 described in ROAs or BOAs and others are not, then the relative 253 ranking of validation outcomes from the highest (most preferred) to 254 the lowest (least preferred) degree of preference are proposed to be 255 as specified int he following list. The exact values to apply to a 256 Local Preference setting are left as a matter of local policy and 257 local configuration. 259 1. Exact Match 261 The prefix has been allocated and is routeable, and that the 262 prefix right-of-use holder has authorized the originating AS to 263 originate precisely this announcement. 265 2. Covering Match 267 This is slightly less preferred because it is possible that the 268 address holder of the aggregate has allocated the prefix in 269 question to a different party. It is also possible that the 270 originating AS is using more specific advertisements as part of a 271 traffic engineering scenario. 273 3. No ROA 275 In the case of partial deployment of ROAs, the absence of 276 validation credentials is a neutral outcome, in that there is no 277 grounds to increase or decrease the relative degree of preference 278 for the route object. 280 4. Covering Mismatch 282 A Covering Mismatch is considered to be less preferable than a 283 neutral position in that the address holder of a covering 284 aggregate has indicated an originating AS that is not the 285 originating AS of this announcement. On the other hand it may be 286 the case that this prefix has been validly allocated to another 287 party who has not generated a ROA for this prefix even through 288 the announcement is valid. 290 5. Exact Mismatch 292 Here the exact match prefix holder has validly provided an 293 authority for origination by an AS that is not the AS that is 294 originating this announcement. This would appear to be a bogus 295 announcement by inference. 297 6. No Match 299 Here the route object has referenced a ROA that is not valid, or 300 does not include an address prefix that matcehs the route object, 301 or the referenced ROA could not be located. This could be an 302 attempt to create a false route object and use an invalid ROA. 304 7. Bogon 306 Here the right-of-use holder of the AS or address prefix has 307 explicitly tagged the address prefix or the AS as a "bogon". 308 This implies that the announcement has been made without the 309 appropriate authority, and the local preference of the route 310 object should be ranked at a level commensurate with rejecting 311 the route object. 313 In the case of comprehensive deployment of RPKI route attestion 314 objects the absence of a specific ROA origination authority for the 315 route object should render it as an unusable for routing. In this 316 case the local preference setting for the route object is as follows: 318 1. Exact Match 320 The prefix has been allocated and is routeable, and that the 321 prefix right-of-use holder has authorized the originating AS to 322 originate precisely this announcement. 324 2. Covering Match, No ROA, Covering Mismatch, Exact Mismatch, No 325 Match 327 The local preference of the route object should be ranked at a 328 level of least preferred, due to the constraints noted in the 329 following section. 331 3. Bogon 333 Here the right-of-use holder of the AS or address prefix has 334 explicitly tagged the address prefix or the AS as a "bogon". 335 This implies that the announcement has been made without the 336 appropriate authority, and the local preference of the route 337 object should be ranked at a level commensurate with rejecting 338 the route object. 340 3.1. Validation Outcomes and Rejection of BGP Route Objects 342 In the case of comprehensive deployment of ROAs, the use of a 343 validation outcome other than an Exact Match as sufficient grounds to 344 reject a route object should be undertaken with care. 346 The consideration here is one of potential circularity of dependence. 347 If the authoritative publication point of the repository of ROAs or 348 any certificates used in relation to an address prefix is stored at a 349 location that lies within the address prefix described in a ROA, then 350 the repository can only be accessed once a route for the prefix has 351 been accepted by the local routing domain. It is also noted that the 352 propagation time of RPKI objects may be different to the propagation 353 time of route objects in BGP, and that route objects may be received 354 before the relying party's local repository cache picks up the 355 associated ROAs and recognises them as valid within the RPKI. 357 For these reasons it is proposed that, even in the case of 358 comprehensive deployment of ROAs, a missing ROA or a mismatch should 359 not be considered as sufficient grounds to reject a route 360 advertisement outright. Alternate approaches may involve the use of 361 a local timer to accept the route for an interim period of time until 362 there is an acceptable level of assurance that all reasonable efforts 363 to local a valid ROA have been undertaken. 365 4. Further Considerations 367 This document provides a description of how ROAs and BOAs could be 368 used by a BGP speaker. 370 It is noted that the proposed procedure requires no changes to the 371 operation of BGP. 373 It is also noted that the decoupled and linked approach are not 374 mutually exclusive, and the same procedure can be applied to route 375 objects that contain an explicit pointer to the associated ROA and 376 route objects where the local BGP speaker has to create a set of 377 candidate ROAs that could be applied to a route object. However, 378 there are a number of considerations about this approach to 379 origination validation that are not specified here. 381 These considerations include: 383 o It is not specified when validation of an advertised prefix should 384 be performed by a BGP speaker. Is is considered to be a matter of 385 local policy whether it is considered to be strictly necessary to 386 perform validation at a point prior to loading the object into the 387 Adj-RIB-In structure, or once the object has been loaded into Adj- 388 RIB-In, or at a later time that is determined by a local 389 configuration setting. It is also not specified whether 390 origination validation should be performed each time a route 391 object is updated by a peer even when the origin AS has not 392 altered. 394 o The lifetime of a validation outcome is not specified here. This 395 specifically refers to the time period during which the original 396 validation outcome can be still applied, and the time when the 397 routing object be revalidated. It is a matter of local policy 398 setting as to whether a validation outcome be regarded as valid 399 until the route object is withdrawn or further updated, or whether 400 validation of a route object should occur at more frequent 401 intervals? 403 o It is a matter of local policy as to whther there are 404 circumstances that would allow a route object to be removed from 405 further consideration in route selection upon a validation 406 failure, similar to the actions of Route Flap Damping. 408 o It is a matter of local configuration as to whther ROA validation 409 is performed on a per-AS basis rather than a per-BGP speaker, and 410 the appropriate BGP mechanisms to support such a per-AS iBGP route 411 validation service are not considered here. 413 5. Security Considerations 415 This approach to orgination validation does not allow for 416 'deterministic' validation in terms of the ability of a BGP speker to 417 accept or reject an advertised route object outright, given that 418 there remains some issues of potential circularity of dependence and 419 time lags between the propagation of information in the routing 420 system and propagation of information in the RPKI. 422 There are also issues of the most appropirate interpretation of 423 outcomes where validation of the authenticity of the route object has 424 not been possible in the context of partial adoption of the RPKI, 425 where the absense of validation information does not necessarily 426 constitute sufficient grounds to interpret the route object as an 427 invalidly originated object. 429 The consequence of these considerations is that while the use of ROAs 430 can increase the confidence in the validity of origination of route 431 objects that match a valid ROA, ROAs cannot perform the opposite, 432 namely the rejection of route objects that cannot be validated by 433 ROAs. To assist in the case of rejecting some forms of route objects 434 that cannot be explicitly validated, the BOA has been used as a means 435 of explicit rejection of certain classes route objects. The 436 implication is that publishers in the RPKI should publish both ROAs 437 and BOAs in order to provide the greatest level of information that 438 will allow relying parties to make appropriate choices in terms of 439 route preference selection. 441 6. IANA Considerations 443 [There are no IANA considerations in this document.] 445 7. Normative References 447 [I-D.ietf-sidr-arch] 448 Lepinski, M., Kent, S., and R. Barnes, "An Infrastructure 449 to Support Secure Internet Routing", draft-ietf-sidr-arch 450 (work in progress), February 2008. 452 [I-D.ietf-sidr-boa] 453 Huston, G., Manderson, T., and G. Michaelson, "Profile for 454 Bogon Origin Attestations (BOAs)", draft-ietf-sidr-bogons 455 (work in progress), August 2008. 457 [I-D.ietf-sidr-roa-format] 458 Lepinski, M., Kent, S., and D. Kong, "An Infrastructure to 459 Support Secure Internet Routing", 460 draft-ietf-sidr-roa-format (work in progress), July 2008. 462 [ID.ietf-rpsec-bgpsecrec] 463 Christian, B. and T. Tauber, "BGP Security Requirements", 464 draft-ietf-sidr-roa-format (work in progress), 465 November 2007. 467 [RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP 468 Addresses and AS Identifiers", RFC 3779, June 2004. 470 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 471 Protocol 4 (BGP-4)", RFC 4271, January 2006. 473 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 474 Housley, R., and W. Polk, "Internet X.509 Public Key 475 Infrastructure Certificate and Certificate Revocation List 476 (CRL) Profile", RFC 5280, May 2008. 478 Authors' Addresses 480 Geoff Huston 481 Asia Pacific Network Information Centre 483 Email: gih@apnic.net 485 George Michaelson 486 Asia Pacific Network Information Centre 488 Email: ggm@apnic.net 490 Full Copyright Statement 492 Copyright (C) The IETF Trust (2008). 494 This document is subject to the rights, licenses and restrictions 495 contained in BCP 78, and except as set forth therein, the authors 496 retain all their rights. 498 This document and the information contained herein are provided on an 499 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 500 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 501 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 502 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 503 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 504 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 506 Intellectual Property 508 The IETF takes no position regarding the validity or scope of any 509 Intellectual Property Rights or other rights that might be claimed to 510 pertain to the implementation or use of the technology described in 511 this document or the extent to which any license under such rights 512 might or might not be available; nor does it represent that it has 513 made any independent effort to identify any such rights. Information 514 on the procedures with respect to rights in RFC documents can be 515 found in BCP 78 and BCP 79. 517 Copies of IPR disclosures made to the IETF Secretariat and any 518 assurances of licenses to be made available, or the result of an 519 attempt made to obtain a general license or permission for the use of 520 such proprietary rights by implementers or users of this 521 specification can be obtained from the IETF on-line IPR repository at 522 http://www.ietf.org/ipr. 524 The IETF invites any interested party to bring to its attention any 525 copyrights, patents or patent applications, or other proprietary 526 rights that may cover technology that may be required to implement 527 this standard. Please address the information to the IETF at 528 ietf-ipr@ietf.org.