idnits 2.17.1 draft-pmohapat-sidr-pfx-validate-04.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 : ---------------------------------------------------------------------------- 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 contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 8, 2010) is 5156 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) == Outdated reference: A later version (-13) exists of draft-ietf-sidr-arch-09 ** Downref: Normative reference to an Informational draft: draft-ietf-sidr-arch (ref. 'I-D.ietf-sidr-arch') == Outdated reference: A later version (-12) exists of draft-ietf-sidr-roa-format-06 == Outdated reference: A later version (-06) exists of draft-ymbk-rpki-rtr-protocol-04 Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Mohapatra, Ed. 3 Internet-Draft Cisco Systems 4 Intended status: Standards Track J. Scudder, Ed. 5 Expires: September 9, 2010 D. Ward, Ed. 6 Juniper Networks 7 R. Bush, Ed. 8 Internet Initiative Japan, Inc. 9 R. Austein, Ed. 10 Internet Systems Consortium 11 March 8, 2010 13 BGP Prefix Origin Validation 14 draft-pmohapat-sidr-pfx-validate-04 16 Abstract 18 A BGP route associates an address prefix with a set of autonomous 19 systems (AS) that identify the interdomain path the prefix has 20 traversed in the form of BGP announcements. This set is represented 21 as the AS_PATH attribute in BGP and starts with the AS that 22 originated the prefix. To help reduce well-known threats against BGP 23 including prefix mis-announcing and monkey-in-the-middle attacks, one 24 of the security requirements is the ability to validate the 25 origination AS of BGP routes. More specifically, one needs to 26 validate that the AS number claiming to originate an address prefix 27 (as derived from the AS_PATH attribute of the BGP route) is in fact 28 authorized by the prefix holder to do so. This document describes a 29 simple validation mechanism to partially satisfy this requirement. 31 Status of this Memo 33 This Internet-Draft is submitted to IETF in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF), its areas, and its working groups. Note that 38 other groups may also distribute working documents as Internet- 39 Drafts. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 The list of current Internet-Drafts can be accessed at 47 http://www.ietf.org/ietf/1id-abstracts.txt. 49 The list of Internet-Draft Shadow Directories can be accessed at 50 http://www.ietf.org/shadow.html. 52 This Internet-Draft will expire on September 9, 2010. 54 Copyright Notice 56 Copyright (c) 2010 IETF Trust and the persons identified as the 57 document authors. All rights reserved. 59 This document is subject to BCP 78 and the IETF Trust's Legal 60 Provisions Relating to IETF Documents 61 (http://trustee.ietf.org/license-info) in effect on the date of 62 publication of this document. Please review these documents 63 carefully, as they describe your rights and restrictions with respect 64 to this document. Code Components extracted from this document must 65 include Simplified BSD License text as described in Section 4.e of 66 the Trust Legal Provisions and are provided without warranty as 67 described in the BSD License. 69 This document may contain material from IETF Documents or IETF 70 Contributions published or made publicly available before November 71 10, 2008. The person(s) controlling the copyright in some of this 72 material may not have granted the IETF Trust the right to allow 73 modifications of such material outside the IETF Standards Process. 74 Without obtaining an adequate license from the person(s) controlling 75 the copyright in such materials, this document may not be modified 76 outside the IETF Standards Process, and derivative works of it may 77 not be created outside the IETF Standards Process, except to format 78 it for publication as an RFC or to translate it into languages other 79 than English. 81 Table of Contents 83 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 84 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 85 2. Prefix-to-AS Mapping Database . . . . . . . . . . . . . . . . 4 86 3. Changes to the BGP Decision Process . . . . . . . . . . . . . 7 87 3.1. Policy Control . . . . . . . . . . . . . . . . . . . . . . 7 88 4. Route Aggregation . . . . . . . . . . . . . . . . . . . . . . 7 89 5. Interaction with Local Cache . . . . . . . . . . . . . . . . . 7 90 6. Deployment Considerations . . . . . . . . . . . . . . . . . . 8 91 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 9 92 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 93 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 94 10. Security Considerations . . . . . . . . . . . . . . . . . . . 9 95 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 96 11.1. Normative References . . . . . . . . . . . . . . . . . . . 10 97 11.2. Informative References . . . . . . . . . . . . . . . . . . 10 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 100 1. Introduction 102 A BGP route associates an address prefix with a set of autonomous 103 systems (AS) that identify the interdomain path the prefix has 104 traversed in the form of BGP announcements. This set is represented 105 as the AS_PATH attribute in BGP and starts with the AS that 106 originated the prefix. To help reduce well-known threats against BGP 107 including prefix mis-announcing and monkey-in-the-middle attacks, one 108 of the security requirements is the ability to validate the 109 origination AS of BGP routes. More specifically, one needs to 110 validate that the AS number claiming to originate an address prefix 111 (as derived from the AS_PATH attribute of the BGP route) is in fact 112 authorized by the prefix holder to do so. This document describes a 113 simple validation mechanism to partially satisfy this requirement. 115 The Resource Public Key Infrastructure (RPKI) describes an approach 116 to build a formally verifyable database of IP addresses and AS 117 numbers as resources. The overall architecture of RPKI as defined in 118 [I-D.ietf-sidr-arch] consists of three main components: 120 o A public key infrastructure (PKI) with the necessary certificate 121 objects, 123 o Digitally signed routing objects, 125 o A distributed repository system to hold the objects that would 126 also support periodic retrieval. 128 The RPKI system is based on resource certificates that define 129 extensions to X.509 to represent IP addresses and AS identifiers 130 [RFC3779], thus the name RPKI. Route Origin Authorizations (ROA) 131 [I-D.ietf-sidr-roa-format] are separate digitally signed objects that 132 define associations between ASes and IP address blocks. Finally the 133 repository system is operated in a distributed fashion through the 134 IANA, RIR hierarchy, and ISPs. 136 In order to benefit from the RPKI system, it is envisioned that 137 relying parties either at AS or organization level obtain a local 138 copy of the signed object collection, verify the signatures, and 139 process them. The cache must also be refreshed periodically. The 140 exact access mechanism used to retrieve the local cache is beyond the 141 scope of this document. 143 Individual BGP speakers can utilize the processed data contained in 144 the local cache to validate BGP announcements. The protocol details 145 to retrieve the processed data from the local cache to the BGP 146 speakers is beyond the scope of this document (refer to 147 [I-D.ymbk-rpki-rtr-protocol] for such a mechanism). This document 148 proposes a simple modification to the BGP decision process that makes 149 use of the processed data from signed objects and validates prefix 150 origination of received BGP UPDATE messages. 152 Note that the complete path attestation against the AS_PATH attribute 153 of a route is outside the scope of this document. 155 Although RPKI provides the context for this draft, it is equally 156 possible to use any other database which is able to map prefixes to 157 their authorized origin ASes. Each distinct database will have its 158 own particular operational and security characteristics; such 159 characteristics are beyond the scope of this document. 161 1.1. Requirements Language 163 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 164 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 165 document are to be interpreted as described in RFC 2119 [RFC2119]. 167 2. Prefix-to-AS Mapping Database 169 In loading the validated objects from the local cache to the BGP 170 speaker, the BGP speaker will store this data in the form of a 171 database that maintains the relationship between prefixes and the 172 corresponding set of authorized origin ASes. The primary key for 173 this database is a prefix set represented as (IP prefix)/[min. 174 length, max. length]. The value stored against each prefix set is 175 the set of AS numbers that is assigned or sub-allocated the 176 corresponding IP address block. An AS may originate more than one 177 prefix set. Thus, multiple prefix sets in the database may contain 178 the same origin AS(es). 180 Whenever UPDATEs are received from peers, a BGP speaker is expected 181 to perform a lookup in this database for each of the prefixes in the 182 UPDATE message. To aid with better description, we define terms 183 "UPDATE prefix" and "UPDATE origin AS number" to denote the values 184 derived from the received UPDATE message, and "database prefix set" 185 and "database origin AS number set" to mean the values derived from 186 the database lookup. Note that in the presence of overlapping 187 prefixes, the database lookup against the "UPDATE prefix" may yield 188 multiple matches. 190 The following are the different types of results expected from such a 191 lookup operation: 193 o If the "UPDATE prefix" finds no matching or covering prefixes in 194 the database (i.e. the "UPDATE prefix" is not a sub-block of any 195 of the database prefixes), the lookup result is returned as "not 196 found". Due to incremental deployment model of the RPKI 197 repository, it is expected that a complete registry of all IP 198 address blocks and their AS associations is not available at a 199 given point of time. 201 o If there are "database prefix sets" that cover the "UPDATE 202 prefix", and one of them has the "UPDATE origin AS number" in the 203 "database origin AS number sets", then the lookup result is 204 returned as "valid". 206 o If there are "database prefix sets" which cover the "UPDATE 207 prefix", but none of them has the "UPDATE origin AS number" in the 208 "database origin AS number set", then the lookup result is 209 returned as "invalid". 211 Depending on the lookup result, we define a property for each "UPDATE 212 prefix", called the "validity state" of the prefix. It can assume 213 the following values: 215 +-------+-----------------------------+ 216 | Value | Meaning | 217 +-------+-----------------------------+ 218 | 0 | Lookup result = "valid" | 219 | 1 | Lookup result = "not found" | 220 | 2 | Lookup result = "invalid" | 221 +-------+-----------------------------+ 223 Note that all the routes, regardless of their "validity state" will 224 be stored in the local BGP speaker's Adj-RIB-In. 226 Following is a sample pseudo code for prefix validation function: 228 //Input are the variables derived from a BGP UPDATE message 229 //that need to be validated. 230 input = {bgp_prefix, masklen, origin_as}; 232 //Initialize result to "not found" state 233 result = BGP_PFXV_STATE_NOT_FOUND; 235 //pfx_validate_table organizes all the ROA entries retrieved 236 //from RPKI cache based on the IP address and the minLength 237 //field. There can be multiple such entries that match the 238 //input. Iterate through all of them. 239 entry = next_lookup_result(pfx_validate_table, 240 input.bgp_prefix, input.masklen); 242 while (entry != NULL) { 243 prefix_exists = TRUE; 245 //Each entry stores multiple records sorted by the ROA 246 //maxLength field. i.e. there can be multiple ROA records 247 //with the same IPaddress and minLength fields, but different 248 //maxLength field. Iterate through all records of the entry 249 //to check if there is one range that matches the input. 250 record = next_in_entry_record_list(entry); 251 while (record != NULL) { 252 if (input.masklen <= record->max_length) { 253 if (input.origin_as == record->origin_as) { 254 result = BGP_PFXV_STATE_VALID; 255 return (result); 256 } 257 } 258 } 259 } 261 //If pfx_validate_table contains one or more prefixes that 262 //match the input, but none of them resulted in a "valid" 263 //outcome since the origin_as did not match, return the 264 //result state as "invalid". Else the initialized state of 265 //"not found" applies to this validation operation. 266 if (prefix_exists == TRUE) { 267 result = BGP_PFXV_STATE_INVALID; 268 } 270 return (result); 272 3. Changes to the BGP Decision Process 274 If a BGP router supports prefix validation and is configured to do 275 so, the validation check MUST be performed prior to any of the steps 276 defined in the decision process of [RFC4271]. The validation step is 277 stated as follows: 279 When comparing a pair of routes for a BGP destination, if both 280 routes are received via EBGP and have had their "validity state" 281 computed, the route with the lowest "validity state" value is 282 preferred. As prefix validation procedures are not performed on 283 IBGP learnt routes, their "validity state" is not computed and 284 compared. Refer to Section 6 for IBGP considerations. 286 In all other respects, the decision process remains unchanged. 288 3.1. Policy Control 290 It MUST be possible to enable or disable the validation step as 291 defined in Section 3 through configuration. The default SHOULD be 292 for the validation step to be enabled. An implementation MAY also 293 support disabling validation for a subset of prefixes or for routes 294 received from a particular EBGP peer. The validity state of such 295 routes for which validation is disabled MUST be set to "not found". 297 It MUST be possible to exclude routes from the BGP decision process 298 based on their validation state. In particular it is anticipated 299 that it will be desirable to exclude routes from consideration when 300 their validation state is "invalid"; however it may also be desirable 301 to exclude routes whose validation state is "not found" as well. The 302 default SHOULD be to exclude routes whose validation state is 303 "invalid". 305 An implementation MAY provide configuration knobs to match on the 306 validity state of a prefix or path and set certain attributes. 308 4. Route Aggregation 310 When an UPDATE message carries AGGREGATOR attribute, the "UPDATE 311 origin AS number" is set to the value encoded in the AGGREGATOR 312 instead of being derived from the AS_PATH attribute. 314 5. Interaction with Local Cache 316 Each BGP speaker supporting prefix validation as described in this 317 document is expected to communicate with one or multiple local caches 318 that store a database of RPKI signed objects. The protocol 319 mechanisms used to fetch the data and store them locally at the BGP 320 speaker is beyond the scope of this document (please refer 321 [I-D.ymbk-rpki-rtr-protocol]). Irrespective of the protocol, the 322 prefix validation algorithm as outlined in this document is expected 323 to function correctly in the event of failures and other timing 324 conditions that may result in an empty and/or partial prefix-to-AS 325 mapping database. Indeed, if the (in-PoP) cache is not available and 326 the mapping database is empty on the BGP speaker, all the lookups 327 will result in "not found" state and the prefixes will be advertised 328 to rest of the network (unless restricted by policy configuration). 329 Similarly, if BGP UPDATEs arrive at the speaker while the fetch 330 operation from the cache is in progress, some prefix lookups will 331 also result in "not found" state. The implementation is expected to 332 handle these timing conditions and re-validate the prefixes once the 333 fetch operation is complete (in an event-driven manner). 335 6. Deployment Considerations 337 It is critical that IBGP speakers within an AS have a consistent 338 routing view of the BGP destinations and do not make conflicting 339 decisions regarding the BGP best path selection that might cause 340 forwarding loops. Thus, the best practice in BGP deployment does not 341 run any policy on IBGP sessions which could potentially create an 342 inconsistent view. Going by the same rules, the prefix validation 343 procedures MUST NOT be performed on IBGP learnt routes in an AS. As 344 a general principle, prefix validation SHOULD be executed on EBGP 345 boundaries. An implementation MAY (based on local configuration) 346 provide support to carry the prefix validation result in standard 347 communities or extended communities while advertising to IBGP for 348 monitoring and debug purposes. In some cases, it may be desirable to 349 run the validation on centralized route servers within an AS to 350 offload the computation. Care should be taken to ensure routing 351 consistency in such cases. 353 During gradual transition phase of an autonomous system to support 354 prefix validation, if some edge routers support validation and some 355 don't, it is possible to get into a situation where an invalid path 356 is preferred over a valid path. This happens when an edge router 357 does not support prefix validation and receives an invalid path from 358 its EBGP peer and transparently announces that to the IBGP mesh. The 359 same situation can also arise in an environment where all edge 360 routers are migrated to support prefix validation due to asynchronous 361 nature of the RPKI cache updates. For example, the correct validity 362 state of a prefix may have been updated by the cache on one edge 363 router, but not another. However, this is a transient phenomenon and 364 self-correcting. 366 7. Contributors 368 Rex Fernando rex@cisco.com 369 Cisco Systems 371 Miya Kohno mkohno@juniper.net 372 Juniper Networks 374 Shin Miyakawa miyakawa@nttv6.jp 375 Taka Mizuguchi 376 Tomoya Yoshida 377 NTT Communications 379 Russ Housley housley@vigilsec.com 380 Vigil Security 382 Junaid Israr jisra052@uottawa.ca 383 Mouhcine Guennoun mguennou@uottawa.ca 384 Hussein Mouftah mouftah@site.uottawa.ca 385 University of Ottawa School of Information Technology and 386 Engineering(SITE) 800 King Edward Avenue, Ottawa, Ontario, Canada, 387 K1N 6N5 389 8. Acknowledgements 391 Junaid Israr's contribution to this specification is part of his PhD 392 research work and thesis at University of Ottawa, Canada. 394 9. IANA Considerations 396 10. Security Considerations 398 Although this specification discusses one portion of a system to 399 validate BGP routes, it should be noted that it relies on a database 400 (RPKI or other) to provide validation information. As such, the 401 security properties of that database must be considered in order to 402 determine the security provided by the overall solution. If 403 "invalid" routes are blocked as this specification suggests, the 404 overall system provides a possible denial-of-service vector, for 405 example if an attacker is able to inject one or more spoofed records 406 into the validation database which lead a good route to be declared 407 invalid. In addition, this system is only able to provide limited 408 protection against a determined attacker -- the attacker need only 409 prepend the "valid" source AS to a forged BGP route announcement in 410 order to defeat the protection provided by this system. This 411 mechanism does not protect against "AS in the middle attacks" or 412 provide any path validation. It only attempts to verify the origin. 413 In general, this system should be thought of more as a protection 414 against misconfiguration than as true "security" in the strong sense. 416 11. References 418 11.1. Normative References 420 [I-D.ietf-sidr-arch] 421 Lepinski, M. and S. Kent, "An Infrastructure to Support 422 Secure Internet Routing", draft-ietf-sidr-arch-09 (work in 423 progress), October 2009. 425 [I-D.ietf-sidr-roa-format] 426 Lepinski, M., Kent, S., and D. Kong, "A Profile for Route 427 Origin Authorizations (ROAs)", 428 draft-ietf-sidr-roa-format-06 (work in progress), 429 October 2009. 431 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 432 Requirement Levels", BCP 14, RFC 2119, March 1997. 434 [RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP 435 Addresses and AS Identifiers", RFC 3779, June 2004. 437 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 438 Protocol 4 (BGP-4)", RFC 4271, January 2006. 440 11.2. Informative References 442 [I-D.ymbk-rpki-rtr-protocol] 443 Bush, R. and R. Austein, "The RPKI/Router Protocol", 444 draft-ymbk-rpki-rtr-protocol-04 (work in progress), 445 July 2009. 447 Authors' Addresses 449 Pradosh Mohapatra (editor) 450 Cisco Systems 451 170 W. Tasman Drive 452 San Jose, CA 95134 453 USA 455 Email: pmohapat@cisco.com 456 John Scudder (editor) 457 Juniper Networks 458 1194 N. Mathilda Ave 459 Sunnyvale, CA 94089 460 USA 462 Email: jgs@juniper.net 464 David Ward (editor) 465 Juniper Networks 466 1194 N. Mathilda Ave 467 Sunnyvale, CA 94089 468 USA 470 Email: dward@juniper.net 472 Randy Bush (editor) 473 Internet Initiative Japan, Inc. 474 5147 Crystral Springs 475 Bainbridge Island, Washington 98110 476 USA 478 Email: randy@psg.com 480 Rob Austein (editor) 481 Internet Systems Consortium 482 950 Charter Street 483 Redwood City, CA 94063 484 USA 486 Email: sra@isc.org