idnits 2.17.1 draft-pmohapat-sidr-pfx-validate-07.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 (April 29, 2010) is 5105 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: October 31, 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 April 29, 2010 13 BGP Prefix Origin Validation 14 draft-pmohapat-sidr-pfx-validate-07 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 October 31, 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 84 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5 85 2. Prefix-to-AS Mapping Database . . . . . . . . . . . . . . . . 5 86 3. Policy Control . . . . . . . . . . . . . . . . . . . . . . . . 7 87 4. Route Aggregation . . . . . . . . . . . . . . . . . . . . . . 7 88 5. Interaction with Local Cache . . . . . . . . . . . . . . . . . 8 89 6. Deployment Considerations . . . . . . . . . . . . . . . . . . 8 90 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 9 91 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 92 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 93 10. Security Considerations . . . . . . . . . . . . . . . . . . . 9 94 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 95 11.1. Normative References . . . . . . . . . . . . . . . . . . . 10 96 11.2. Informative References . . . . . . . . . . . . . . . . . . 10 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 99 1. Introduction 101 A BGP route associates an address prefix with a set of autonomous 102 systems (AS) that identify the interdomain path the prefix has 103 traversed in the form of BGP announcements. This set is represented 104 as the AS_PATH attribute in BGP [RFC4271] and starts with the AS that 105 originated the prefix. To help reduce well-known threats against BGP 106 including prefix mis-announcing and monkey-in-the-middle attacks, one 107 of the security requirements is the ability to validate the 108 origination AS of BGP routes. More specifically, one needs to 109 validate that the AS number claiming to originate an address prefix 110 (as derived from the AS_PATH attribute of the BGP route) is in fact 111 authorized by the prefix holder to do so. This document describes a 112 simple validation mechanism to partially satisfy this requirement. 114 The Resource Public Key Infrastructure (RPKI) describes an approach 115 to build a formally verifyable database of IP addresses and AS 116 numbers as resources. The overall architecture of RPKI as defined in 117 [I-D.ietf-sidr-arch] consists of three main components: 119 o A public key infrastructure (PKI) with the necessary certificate 120 objects, 122 o Digitally signed routing objects, 124 o A distributed repository system to hold the objects that would 125 also support periodic retrieval. 127 The RPKI system is based on resource certificates that define 128 extensions to X.509 to represent IP addresses and AS identifiers 129 [RFC3779], thus the name RPKI. Route Origin Authorizations (ROA) 130 [I-D.ietf-sidr-roa-format] are separate digitally signed objects that 131 define associations between ASes and IP address blocks. Finally the 132 repository system is operated in a distributed fashion through the 133 IANA, RIR hierarchy, and ISPs. 135 In order to benefit from the RPKI system, it is envisioned that 136 relying parties either at AS or organization level obtain a local 137 copy of the signed object collection, verify the signatures, and 138 process them. The cache must also be refreshed periodically. The 139 exact access mechanism used to retrieve the local cache is beyond the 140 scope of this document. 142 Individual BGP speakers can utilize the processed data contained in 143 the local cache to validate BGP announcements. The protocol details 144 to retrieve the processed data from the local cache to the BGP 145 speakers is beyond the scope of this document (refer to 146 [I-D.ymbk-rpki-rtr-protocol] for such a mechanism). This document 147 proposes a means by which a BGP speaker can make use of the processed 148 data in order to assign a "validity state" to each prefix in a 149 received BGP UPDATE message. 151 Note that the complete path attestation against the AS_PATH attribute 152 of a route is outside the scope of this document. 154 Although RPKI provides the context for this draft, it is equally 155 possible to use any other database which is able to map prefixes to 156 their authorized origin ASes. Each distinct database will have its 157 own particular operational and security characteristics; such 158 characteristics are beyond the scope of this document. 160 1.1. Requirements Language 162 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 163 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 164 document are to be interpreted as described in RFC 2119 [RFC2119]. 166 2. Prefix-to-AS Mapping Database 168 In loading the validated objects from the local cache to the BGP 169 speaker, the BGP speaker will store this data in the form of a 170 database that maintains the relationship between prefixes and the 171 corresponding set of authorized origin ASes. The primary key for 172 this database is a prefix set represented as (IP prefix)/[min. 173 length, max. length]. The value stored against each prefix set is 174 the set of AS numbers that is assigned or sub-allocated the 175 corresponding IP address block. An AS may originate more than one 176 prefix set. Thus, multiple prefix sets in the database may contain 177 the same origin AS(es). 179 Whenever UPDATEs are received from peers, a BGP speaker is expected 180 to perform a lookup in this database for each of the prefixes in the 181 UPDATE message. To aid with better description, we define terms 182 "UPDATE prefix" and "UPDATE origin AS number" to denote the values 183 derived from the received UPDATE message, and "database prefix set" 184 and "database origin AS number set" to mean the values derived from 185 the database lookup. Note that in the presence of overlapping 186 prefixes, the database lookup against the "UPDATE prefix" may yield 187 multiple matches. 189 The following are the different types of results expected from such a 190 lookup operation: 192 o If the "UPDATE prefix" finds no matching or covering prefixes in 193 the database (i.e. the "UPDATE prefix" is not a sub-block of any 194 of the database prefixes), the lookup result is returned as "not 195 found". Due to incremental deployment model of the RPKI 196 repository, it is expected that a complete registry of all IP 197 address blocks and their AS associations is not available at a 198 given point of time. 200 o If there are "database prefix sets" that cover the "UPDATE 201 prefix", and one of them has the "UPDATE origin AS number" in the 202 "database origin AS number sets", then the lookup result is 203 returned as "valid". 205 o If there are "database prefix sets" which cover the "UPDATE 206 prefix", but none of them has the "UPDATE origin AS number" in the 207 "database origin AS number set", then the lookup result is 208 returned as "invalid". 210 Depending on the lookup result, we define a property for each route, 211 called the "validity state". It can assume the values "valid", "not 212 found", or "invalid". 214 Note that all the routes, regardless of their "validity state" will 215 be stored in the local BGP speaker's Adj-RIB-In. 217 Following is a sample pseudo code for prefix validation function: 219 //Input are the variables derived from a BGP UPDATE message 220 //that need to be validated. 221 //origin_as is the rightmost AS in the final AS_SEQUENCE of 222 //the AS_PATH attribute in the UPDATE message. 223 // 224 //If the UPDATE message carries [AS4_]AGGREGATOR attribute, 225 //origin_as is derived from the AS field of that attribute. 226 // 227 //origin_as is NONE if the AS_PATH begins with a non-trivial 228 //AS_SET and has no [AS4_]AGGREGATOR attribute. 229 input = {bgp_prefix, masklen, origin_as}; 231 //Initialize result to "not found" state 232 result = BGP_PFXV_STATE_NOT_FOUND; 234 //pfx_validate_table organizes all the ROA entries retrieved 235 //from RPKI cache based on the IP address and the minLength 236 //field. There can be multiple such entries that match the 237 //input. Iterate through all of them. 238 entry = next_lookup_result(pfx_validate_table, 239 input.bgp_prefix, input.masklen); 241 while (entry != NULL) { 242 prefix_exists = TRUE; 244 //Each entry stores multiple records sorted by the ROA 245 //maxLength field. i.e. there can be multiple ROA records 246 //with the same IPaddress and minLength fields, but different 247 //maxLength field. Iterate through all records of the entry 248 //to check if there is one range that matches the input. 249 record = next_in_entry_record_list(entry); 250 while (record != NULL) { 251 if (input.masklen <= record->max_length) { 252 if (input.origin_as == record->origin_as) { 253 result = BGP_PFXV_STATE_VALID; 254 return (result); 255 } 256 } 257 } 258 } 260 //If pfx_validate_table contains one or more prefixes that 261 //match the input, but none of them resulted in a "valid" 262 //outcome since the origin_as did not match, return the 263 //result state as "invalid". Else the initialized state of 264 //"not found" applies to this validation operation. 265 if (prefix_exists == TRUE) { 266 result = BGP_PFXV_STATE_INVALID; 267 } 269 return (result); 271 3. Policy Control 273 An implementation MUST provide the ability to match and set the 274 validation state of routes as part of its route policy filtering 275 function. Use of validation state in route policy is elaborated in 276 Section 6. 278 4. Route Aggregation 280 When an UPDATE message carries AGGREGATOR attribute, the "UPDATE 281 origin AS number" is set to the value encoded in the AGGREGATOR 282 instead of being derived from the AS_PATH attribute. 284 5. Interaction with Local Cache 286 Each BGP speaker supporting prefix validation as described in this 287 document is expected to communicate with one or multiple local caches 288 that store a database of RPKI signed objects. The protocol 289 mechanisms used to fetch the data and store them locally at the BGP 290 speaker is beyond the scope of this document (please refer 291 [I-D.ymbk-rpki-rtr-protocol]). Irrespective of the protocol, the 292 prefix validation algorithm as outlined in this document is expected 293 to function correctly in the event of failures and other timing 294 conditions that may result in an empty and/or partial prefix-to-AS 295 mapping database. Indeed, if the (in-PoP) cache is not available and 296 the mapping database is empty on the BGP speaker, all the lookups 297 will result in "not found" state and the prefixes will be advertised 298 to rest of the network (unless restricted by policy configuration). 299 Similarly, if BGP UPDATEs arrive at the speaker while the fetch 300 operation from the cache is in progress, some prefix lookups will 301 also result in "not found" state. The implementation is expected to 302 handle these timing conditions and MUST re-validate affected prefixes 303 once the fetch operation is complete. The same applies during any 304 subsequent incremental updates of the validation database. 306 In the event that connectivity to the cache is lost, the router 307 should make a reasonable effort to fetch a new validation database 308 (either from the same, or a different cache), and SHOULD wait until 309 the new validation database has been fetched before purging the 310 previous one. A configurable timer MUST be provided to bound the 311 length of time the router will wait before purging the previous 312 validation database. 314 6. Deployment Considerations 316 Once a route is received from an EBGP peer it is categorized 317 according the procedure given in Section 2. Subsequently, routing 318 policy as discussed in Section 3 can be used to take action based on 319 the validation state. 321 Policies which could be implemented include filtering routes based on 322 validation state (for example, rejecting all "invalid" routes) or 323 adjusting a route's degree of preference in the selection algorithm 324 based on its validation state. The latter could be accomplished by 325 adjusting the value of such attributes as LOCAL_PREF. 327 In some cases (particularly when the selection algorithm is 328 influenced by the adjustment of a route property that is not 329 propagated into IBGP) it could be necessary for routing correctness 330 to propagate the validation state to the IBGP peer. This can be 331 accomplished on the sending side by setting a community or extended 332 community based on the validation state, and on the receiving side by 333 matching the (extended) community and setting the validation state. 335 7. Contributors 337 Rex Fernando rex@cisco.com 338 Keyur Patel keyupate@cisco.com 339 Cisco Systems 341 Miya Kohno mkohno@juniper.net 342 Juniper Networks 344 Shin Miyakawa miyakawa@nttv6.jp 345 Taka Mizuguchi 346 Tomoya Yoshida 347 NTT Communications 349 Russ Housley housley@vigilsec.com 350 Vigil Security 352 Junaid Israr jisra052@uottawa.ca 353 Mouhcine Guennoun mguennou@uottawa.ca 354 Hussein Mouftah mouftah@site.uottawa.ca 355 University of Ottawa School of Information Technology and 356 Engineering(SITE) 800 King Edward Avenue, Ottawa, Ontario, Canada, 357 K1N 6N5 359 8. Acknowledgements 361 Junaid Israr's contribution to this specification is part of his PhD 362 research work and thesis at University of Ottawa, Canada. 364 9. IANA Considerations 366 10. Security Considerations 368 Although this specification discusses one portion of a system to 369 validate BGP routes, it should be noted that it relies on a database 370 (RPKI or other) to provide validation information. As such, the 371 security properties of that database must be considered in order to 372 determine the security provided by the overall solution. If 373 "invalid" routes are blocked as this specification suggests, the 374 overall system provides a possible denial-of-service vector, for 375 example if an attacker is able to inject one or more spoofed records 376 into the validation database which lead a good route to be declared 377 invalid. In addition, this system is only able to provide limited 378 protection against a determined attacker -- the attacker need only 379 prepend the "valid" source AS to a forged BGP route announcement in 380 order to defeat the protection provided by this system. This 381 mechanism does not protect against "AS in the middle attacks" or 382 provide any path validation. It only attempts to verify the origin. 383 In general, this system should be thought of more as a protection 384 against misconfiguration than as true "security" in the strong sense. 386 11. References 388 11.1. Normative References 390 [I-D.ietf-sidr-arch] 391 Lepinski, M. and S. Kent, "An Infrastructure to Support 392 Secure Internet Routing", draft-ietf-sidr-arch-09 (work in 393 progress), October 2009. 395 [I-D.ietf-sidr-roa-format] 396 Lepinski, M., Kent, S., and D. Kong, "A Profile for Route 397 Origin Authorizations (ROAs)", 398 draft-ietf-sidr-roa-format-06 (work in progress), 399 October 2009. 401 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 402 Requirement Levels", BCP 14, RFC 2119, March 1997. 404 [RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP 405 Addresses and AS Identifiers", RFC 3779, June 2004. 407 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 408 Protocol 4 (BGP-4)", RFC 4271, January 2006. 410 11.2. Informative References 412 [I-D.ymbk-rpki-rtr-protocol] 413 Bush, R. and R. Austein, "The RPKI/Router Protocol", 414 draft-ymbk-rpki-rtr-protocol-04 (work in progress), 415 July 2009. 417 Authors' Addresses 419 Pradosh Mohapatra (editor) 420 Cisco Systems 421 170 W. Tasman Drive 422 San Jose, CA 95134 423 USA 425 Email: pmohapat@cisco.com 427 John Scudder (editor) 428 Juniper Networks 429 1194 N. Mathilda Ave 430 Sunnyvale, CA 94089 431 USA 433 Email: jgs@juniper.net 435 David Ward (editor) 436 Juniper Networks 437 1194 N. Mathilda Ave 438 Sunnyvale, CA 94089 439 USA 441 Email: dward@juniper.net 443 Randy Bush (editor) 444 Internet Initiative Japan, Inc. 445 5147 Crystral Springs 446 Bainbridge Island, Washington 98110 447 USA 449 Email: randy@psg.com 451 Rob Austein (editor) 452 Internet Systems Consortium 453 950 Charter Street 454 Redwood City, CA 94063 455 USA 457 Email: sra@isc.org