idnits 2.17.1 draft-huston-sidr-roa-validation-00.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 408. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 419. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 426. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 432. 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 (February 8, 2008) is 5921 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Duplicate reference: draft-ietf-sidr-roa-format, mentioned in 'ID.ietf-rpsec-bgpsecrec', was also mentioned in 'I-D.ietf-sidr-roa-format'. ** Obsolete normative reference: RFC 3280 (Obsoleted by RFC 5280) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Individual Submission G. Huston 3 Internet-Draft G. Michaelson 4 Intended status: Informational APNIC 5 Expires: August 11, 2008 February 8, 2008 7 Validation of Route Origin Authorizations in BGP using the Resource 8 Certificate PKI 9 draft-huston-sidr-roa-validation-00.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 August 11, 2008. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2008). 40 Abstract 42 This document defines an application of the Resource Public Key 43 Infrastructure to validate the origination of routes advertised in 44 the Border Gateway Protocol. The proposed application is intended to 45 fit within the requirements for adding security to inter-domain 46 routing, including the ability to support incremental and piecemeal 47 deployment, and does not require any changes to the specification of 48 BGP. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Validation Outcomes of a BGP Route Object using ROAs . . . . . 3 54 3. Applying Validation Outcomes to BGP Route Selection . . . . . 5 55 3.1. Using ROA Validation Outcomes to reject BGP 56 advertisements . . . . . . . . . . . . . . . . . . . . . . 7 57 4. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 8 58 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 59 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 60 7. Normative References . . . . . . . . . . . . . . . . . . . . . 9 61 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 62 Intellectual Property and Copyright Statements . . . . . . . . . . 11 64 1. Introduction 66 This document defines an application of the Resource Public Key 67 Infrastructure (RPKI) to validate the origination of routes 68 advertised in the Border Gateway Protocol (BGP) [RFC4271]. 70 The RPKI is based on on Resource Certificates. Resource Certificates 71 are X.509 certificates that conform to the PKIX profile [RFC3280], 72 and to the extensions for IP addresses and AS identifiers [RFC3779]. 73 A Resource Certificate describes an action by an Issuer that binds a 74 list of IP address blocks and Autonomous System (AS) numbers to the 75 Subject of a certificate, identified by the unique association of the 76 Subject's private key with the public key contained in the Resource 77 Certificate. The PKI is structured such that each current Resource 78 Certificate matches a current resource allocation or assignment. 79 This is described in [I-D.ietf-sidr-arch]. 81 Route Origin Authorizations (ROAs) are digitally signed objects that 82 bind an address to an AS number, signed by the address holder. A ROA 83 provides a means of verifying that an IP address block holder has 84 authorized an AS to originate route objects in the inter-domain 85 routing environment for that address block. ROAs are described in 86 [I-D.ietf-sidr-roa-format]. 88 This document describes how ROA validation outcomes can be used in 89 the BGP route selection process, and how the proposed application are 90 intended to fit within the requirements for adding security to inter- 91 domain routing [ID.ietf-rpsec-bgpsecrec], including the ability to 92 support incremental and piecemeal deployment, and, furthermore, does 93 not require any changes to the specification of BGP. 95 2. Validation Outcomes of a BGP Route Object using ROAs 97 A BGP Route Object is an address prefix and a set of attributes. In 98 terms of ROA validation the prefix value and the origin AS are used 99 in the validation operation. 101 [Note: If the origination of the prefix is an AS Set then ??. The 102 draft authors do not have a clear idea as to what to propose here!] 104 ROA validation is described in [I-D.ietf-sidr-roa-format], and the 105 outcome of the validation operation is that the ROA is valid in the 106 context of the RPKI or validation has failed. 108 There appears to be two means of matching a route object to a ROA: 109 decoupled and linked. 111 The decoupled approach where the ROAs are managed and distributed 112 independently of the operation of the routing protocol and a local 113 BGP speaker has access to a local cache of the complete set of ROAs 114 and the RPKI data set when performing a validation operation. In 115 this case the route object does not refer to a ROA, a certificate 116 validation path, CRLs nor Trust Anchors, and it is the role of the 117 relying party to match a route object to one or more candidate ROAs 118 and perform the validation operation on a selected ROA in order to 119 determine the appropriate local actions to perform on the route 120 object. The second approach is where the route object references a 121 ROA, either by explicit inclusion of the ROA itself as an attribute 122 of the route object that is carried in BGP or by reference where some 123 identification of the ROA is carried as an attribute of the object. 125 The more general case here is the decoupled approach where a set of 126 ROAs are selected where the address prefix in the ROA is an exact 127 match, or the address prefix in the ROA is a covering aggregate of 128 the address prefix in the route object and the ROA has the 129 requireExactMatch set to FALSE.The following outcomes are possible 130 using the defined ROA validation procedure for each ROA in this set: 132 o An "exact match" is a valid ROA where the address prefix in the 133 route object exactly matches a prefix listed in the ROA and the 134 origin AS in the route object matches the origin AS listed in the 135 ROA. 137 o A "covering match" is a valid ROA where the address prefix in the 138 ROA is a covering aggregate of the prefix in the route object, and 139 the ROA has the requireExactMatch value of TRUE, and the origin AS 140 in the route object matches the AS listed in the ROA. 142 o An "exact failure" is a ROA where the address prefix in the route 143 object exactly matches a prefix listed in the ROA, the origin AS 144 matches the AS listed in the ROA, but the EE certificate of the 145 ROA signature fails to validate within the context of the RPKI. 147 o A "covering failure" is a ROA where the address prefix in the ROA 148 is a covering aggregate of the prefix in the update, and the ROA 149 has the requireExactMatch value FALSE, and the origin AS in the 150 update matches the origin AS listed in the ROA, but the EE 151 certificate that is associated with the ROA's digital signature 152 fails to validate within the context of the RPKI. 154 o An "exact mismatch" is a ROA where the address prefix in the route 155 object exactly matches a prefix listed in the ROA and the origin 156 AS of the route object does not match the AS listed in the ROA. 158 o A "covering mismatch" is a ROA where the address prefix in the ROA 159 is a covering aggregate of the prefix in the route object, the ROA 160 has the requireExactMatch value FALSE, and the origin AS of the 161 route object does not match the AS listed in the ROA. 163 o "ROA missing" is where there are no exact or covering matches, no 164 exact or covering mismatches and no exact of covering failures in 165 the RPKI repository. 167 In this case the ROA that would be used for the validation function 168 is selected from the set such that the most specific valid ROA that 169 matches or covers the route object address prefix and where the route 170 object origin AS matches the ROA AS. If there is no such ROA in the 171 set, then the most specific valid ROA is selected. If there is no 172 such ROA in the set then the most specific ROA is selected. 174 The linked approach requires the route object to reference a ROA 175 either buy inclusion of the ROA as an attribute of the route object, 176 or inclusion of a identity field as a means of identifying a 177 particular ROA. In this case the set of outcomes of ROA validation 178 is a subset of the decoupled approach, as follows: 180 o "exact match" 182 o "covering match" 184 o "exact failure" 186 o "covering failure" 188 o "ROA missing" 190 3. Applying Validation Outcomes to BGP Route Selection 192 Within the framework of the abstract model of BGP operation, a 193 received prefix announcement from a peer is compared to all 194 announcements for this prefix received from other peers and a route 195 selection procedure is used to select the "best" route object from 196 this candiudate set which is then used locally by placing it in the 197 loc-RIB, and is announced to peers as the local "best" route. 199 It is proposed that the validation outcome be used as part of the 200 determination of the local degree of preference as defined in section 201 9.1.1 of the BGP specification [RFC4271]. 203 In the case of a partial deployment scenario, when some prefixes are 204 described in ROAs and others are not, then the relative ranking of 205 validation outcomes from the highest (most preferred) to the lowest 206 (least preferred) degree of preference are proposed as follows: 208 1. "exact match" 210 An exact match indicates that the prefix has been allocated and 211 is routeable, and that the prefix right-of-use holder has 212 authorized the originating AS to originate precisely this 213 announcement. 215 2. "covering match" 217 A covering match is slightly less preferred becuase it is 218 possible that the address holder of the aggregate has allocated 219 the prefix in question to a different party, and both the 220 aggregate address holder and the prefix holder have signed ROAs 221 and are advertising the prefix. 223 3. "ROA missing" 225 In the case of partial deployment of ROAs the absence of 226 validation credentials is neutral, in that there is no grounds to 227 increase or decrease the relative degree of preference for the 228 prefix. 230 4. "covering mismatch" 232 A covering mismatch is considered to be less preferable than a 233 neutral position in that the address holder of a covering 234 aggregate has indicated an originating AS that is not the 235 originating AS of this announcement. On the other hand it may be 236 the case that this prefix has been validly allocated to another 237 party who has not generated a ROA for this prefix even through 238 the announcement is valid. 240 5. "covering failure" 242 A convering failure indicates that the ROA is not valid in terms 243 of the PKI, but this still admit the possibility that the prefix 244 has been allocated to another party who has not generated a ROA. 246 6. An "exact mismatch" 248 Here the exact match prefix holder has validly provided an 249 authority for origination by an AS that is not the AS that is 250 originating this announcement. This would appear to be a bogus 251 announcement by inference. 253 7. "exact failure" 255 Here the authority to originate is not valid, indicating t6hat 256 either the authority has expired or that the authority infomation 257 has been constructed by someone other than the prefix owner. 258 This implies that the announcement is made without authority. 260 In the case of comprehensive deployment of ROAs the relative local 261 degree of preference can be adjusted such that cases 3 through 5 of 262 the above list have an equal level of lesser preference, as in this 263 case there is no "missing" ROA so that a validation failure need not 264 be interpreted as a potentially valid route object that does not have 265 an associated ROA. 267 3.1. Using ROA Validation Outcomes to reject BGP advertisements 269 In the case of partial deployment of ROAs there are a very limited 270 set of circumstances where the outcome of ROA validation can be used 271 as grounds to reject all consideration of the route object as an 272 invalid advertisement. While the presence of a valid ROA that 273 matches the advertisement is astrong indication that an advertisement 274 matches the authority provided by the prefix holder to advertise the 275 prefix into the routing system, the absence of a ROA or the 276 invalidity of a covering ROA does not provide a conclusive indication 277 that the advertisement has been undertaken without the address 278 holder's permission. 280 In the case of comprehensive deployment of ROAs an invalid ROA could 281 be considered grounds for rejection of the route object advertisement 282 were it not for the issue of circular dependence. If the 283 authoritative publication point of the repository of ROAs or any 284 certificates used to related to an address prefix is stored at a 285 location that lies within the address prefix, then the repository can 286 only be accessed once a route for the prefix has been accepted. If 287 the local BGP speaker is in a position to use some mechanism to check 288 for circular dependencies then in the case of comprehensive 289 deployment of ROAs an invalid ROA would be sufficient grounds to 290 reject a route object. 292 It is noted that validation of a ROA infers two properties of the 293 address, namely that the address prefix itself is "valid" and is not 294 part of a "reserved" pool held by the IANA, an RIR or any LIR, and 295 secondly that the origination of the address in the routing system 296 has been undertaken with the explicit permission of the address 297 holder. Accepting an advertisement of an address prefix that has 298 failed ROA validation admits the possibility of accepting an 299 advertisment for an invalid address that is drawn from a reserved 300 pool. In the case of comprehensive deployment of ROAS the validation 301 outcome of "ROA missing" is a strong indication that the address 302 itself is invalid, as in the comprehensive deployment model all 303 validly advertised address space is, by definition, covered by a ROA. 304 The issue of circularity dependency between the address and the 305 publication point of the ROA would still need to be addressed in this 306 case. 308 4. Open Issues 310 This document provides a description of how ROA validation could be 311 used by a BGP speaker. It is noted that the proposed procedure 312 requires no changes to the operation of BGP. It is also noted that 313 the decoupled and linked approach are not mutually exclusive, and the 314 same procedure can be applied to route objects that contain an 315 explicit pointer to the associated ROA and route objects where the 316 local BGP speaker has to create a set of candidate ROAs that could be 317 applied to a route object. However, there are a number of ques5tions 318 about this approach that are not resolved here. 320 Some open issues at this point are: 322 o When should validation of an advertised prefix be performed by a 323 BGP speaker? Is it strictly necessary to perform validation at a 324 point prior to loading the object into the Adj-RIB-In structure, 325 or once the object has been loaded into Adj-RIB-IN, or at a later 326 time that is determined by a local configuration setting? Should 327 validation be performed each time a route object is updated by a 328 peer even when the origin AS has not altered? 330 o What is the lifetime of a validation outcome? When should the 331 routing object be revalidated? Should the validation outcome be 332 regarded as valid until the route object is withdrawn or further 333 updated, or should validation occur at more frequent intervals? 335 o Are there circumstances that would allow a route object to be 336 removed from further consideration in route selection upon a 337 validation failure, similar to the actions of Route Flap Damping? 339 o Can ROA validation be performed on a per-AS basis rather than a 340 per-BGP speaker? What BGP mechanisms would be appropriate to 341 support such a mode of operation? 343 5. Security Considerations 345 [to be completed] 347 6. IANA Considerations 349 [There are no IANA considerations in this document at this stage. 350 Later iterations of this draft propose to add a ROA identifier into 351 the BGP route attribute set] 353 7. Normative References 355 [I-D.ietf-sidr-arch] 356 Lepinski, M., Kent, S., and R. Barnes, "An Infrastructure 357 to Support Secure Internet Routing", draft-ietf-sidr-arch 358 (work in progress), November 2007. 360 [I-D.ietf-sidr-roa-format] 361 Lepinski, M., Kent, S., and D. Kong, "An Infrastructure to 362 Support Secure Internet Routing", 363 draft-ietf-sidr-roa-format (work in progress), July 2007. 365 [ID.ietf-rpsec-bgpsecrec] 366 Christian, B. and T. Tauber, "BGP Security Requirements", 367 draft-ietf-sidr-roa-format (work in progress), 368 November 2007. 370 [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet 371 X.509 Public Key Infrastructure Certificate and 372 Certificate Revocation List (CRL) Profile", RFC 3280, 373 April 2002. 375 [RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP 376 Addresses and AS Identifiers", RFC 3779, June 2004. 378 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 379 Protocol 4 (BGP-4)", RFC 4271, January 2006. 381 Authors' Addresses 383 Geoff Huston 384 Asia Pacific Network Information Centre 386 Email: gih@apnic.net 387 URI: http://www.apnic.net 388 George Michaelson 389 Asia Pacific Network Information Centre 391 Email: ggm@apnic.net 392 URI: http://www.apnic.net 394 Full Copyright Statement 396 Copyright (C) The IETF Trust (2008). 398 This document is subject to the rights, licenses and restrictions 399 contained in BCP 78, and except as set forth therein, the authors 400 retain all their rights. 402 This document and the information contained herein are provided on an 403 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 404 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 405 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 406 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 407 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 408 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 410 Intellectual Property 412 The IETF takes no position regarding the validity or scope of any 413 Intellectual Property Rights or other rights that might be claimed to 414 pertain to the implementation or use of the technology described in 415 this document or the extent to which any license under such rights 416 might or might not be available; nor does it represent that it has 417 made any independent effort to identify any such rights. Information 418 on the procedures with respect to rights in RFC documents can be 419 found in BCP 78 and BCP 79. 421 Copies of IPR disclosures made to the IETF Secretariat and any 422 assurances of licenses to be made available, or the result of an 423 attempt made to obtain a general license or permission for the use of 424 such proprietary rights by implementers or users of this 425 specification can be obtained from the IETF on-line IPR repository at 426 http://www.ietf.org/ipr. 428 The IETF invites any interested party to bring to its attention any 429 copyrights, patents or patent applications, or other proprietary 430 rights that may cover technology that may be required to implement 431 this standard. Please address the information to the IETF at 432 ietf-ipr@ietf.org. 434 Acknowledgment 436 Funding for the RFC Editor function is provided by the IETF 437 Administrative Support Activity (IASA).