idnits 2.17.1 draft-ietf-sidr-pfx-validate-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, 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 (July 11, 2011) is 4673 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) ** Downref: Normative reference to an Informational draft: draft-ietf-sidr-arch (ref. 'I-D.ietf-sidr-arch') == Outdated reference: A later version (-23) exists of draft-ietf-sidr-origin-ops-10 == Outdated reference: A later version (-26) exists of draft-ietf-sidr-rpki-rtr-14 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). 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: January 12, 2012 D. Ward, Ed. 6 Juniper Networks 7 R. Bush, Ed. 8 Internet Initiative Japan, Inc. 9 R. Austein, Ed. 10 Internet Systems Consortium 11 July 11, 2011 13 BGP Prefix Origin Validation 14 draft-ietf-sidr-pfx-validate-02 16 Abstract 18 To help reduce well-known threats against BGP including prefix mis- 19 announcing and monkey-in-the-middle attacks, one of the security 20 requirements is the ability to validate the origination AS of BGP 21 routes. More specifically, one needs to validate that the AS number 22 claiming to originate an address prefix (as derived from the AS_PATH 23 attribute of the BGP route) is in fact authorized by the prefix 24 holder to do so. This document describes a simple validation 25 mechanism to partially satisfy this requirement. 27 Status of this Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on January 12, 2012. 44 Copyright Notice 46 Copyright (c) 2011 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 This document may contain material from IETF Documents or IETF 60 Contributions published or made publicly available before November 61 10, 2008. The person(s) controlling the copyright in some of this 62 material may not have granted the IETF Trust the right to allow 63 modifications of such material outside the IETF Standards Process. 64 Without obtaining an adequate license from the person(s) controlling 65 the copyright in such materials, this document may not be modified 66 outside the IETF Standards Process, and derivative works of it may 67 not be created outside the IETF Standards Process, except to format 68 it for publication as an RFC or to translate it into languages other 69 than English. 71 Table of Contents 73 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 74 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5 75 2. Prefix-to-AS Mapping Database . . . . . . . . . . . . . . . . 5 76 3. Policy Control . . . . . . . . . . . . . . . . . . . . . . . . 7 77 4. Interaction with Local Cache . . . . . . . . . . . . . . . . . 7 78 5. Deployment Considerations . . . . . . . . . . . . . . . . . . 8 79 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 8 80 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 81 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 82 9. Security Considerations . . . . . . . . . . . . . . . . . . . 9 83 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 84 10.1. Normative References . . . . . . . . . . . . . . . . . . . 10 85 10.2. Informational References . . . . . . . . . . . . . . . . . 10 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 88 1. Introduction 90 A BGP route associates an address prefix with a set of autonomous 91 systems (AS) that identify the interdomain path the prefix has 92 traversed in the form of BGP announcements. This set is represented 93 as the AS_PATH attribute in BGP [RFC4271] and starts with the AS that 94 originated the prefix. To help reduce well-known threats against BGP 95 including prefix mis-announcing and monkey-in-the-middle attacks, one 96 of the security requirements is the ability to validate the 97 origination AS of BGP routes. More specifically, one needs to 98 validate that the AS number claiming to originate an address prefix 99 (as derived from the AS_PATH attribute of the BGP route) is in fact 100 authorized by the prefix holder to do so. This document describes a 101 simple validation mechanism to partially satisfy this requirement. 103 The Resource Public Key Infrastructure (RPKI) describes an approach 104 to build a formally verifyable database of IP addresses and AS 105 numbers as resources. The overall architecture of RPKI as defined in 106 [I-D.ietf-sidr-arch] consists of three main components: 108 o A public key infrastructure (PKI) with the necessary certificate 109 objects, 111 o Digitally signed routing objects, 113 o A distributed repository system to hold the objects that would 114 also support periodic retrieval. 116 The RPKI system is based on resource certificates that define 117 extensions to X.509 to represent IP addresses and AS identifiers 118 [RFC3779], thus the name RPKI. Route Origin Authorizations (ROA) 119 [I-D.ietf-sidr-roa-format] are separate digitally signed objects that 120 define associations between ASes and IP address blocks. Finally the 121 repository system is operated in a distributed fashion through the 122 IANA, RIR hierarchy, and ISPs. 124 In order to benefit from the RPKI system, it is envisioned that 125 relying parties either at AS or organization level obtain a local 126 copy of the signed object collection, verify the signatures, and 127 process them. The cache must also be refreshed periodically. The 128 exact access mechanism used to retrieve the local cache is beyond the 129 scope of this document. 131 Individual BGP speakers can utilize the processed data contained in 132 the local cache to validate BGP announcements. The protocol details 133 to retrieve the processed data from the local cache to the BGP 134 speakers is beyond the scope of this document (refer to 135 [I-D.ietf-sidr-rpki-rtr] for such a mechanism). This document 136 proposes a means by which a BGP speaker can make use of the processed 137 data in order to assign a "validity state" to each prefix in a 138 received BGP UPDATE message. 140 Note that the complete path attestation against the AS_PATH attribute 141 of a route is outside the scope of this document. 143 Although RPKI provides the context for this draft, it is equally 144 possible to use any other database which is able to map prefixes to 145 their authorized origin ASes. Each distinct database will have its 146 own particular operational and security characteristics; such 147 characteristics are beyond the scope of this document. 149 1.1. Requirements Language 151 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 152 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 153 document are to be interpreted as described in RFC 2119 [RFC2119]. 155 2. Prefix-to-AS Mapping Database 157 In loading the validated objects from the local cache to the BGP 158 speaker, the BGP speaker will store this data in the form of a 159 database that maintains the relationship between prefixes and the 160 corresponding set of authorized origin ASes. The primary key for 161 this database is a prefix set represented as (IP prefix)/[min. 162 length, max. length]. The value stored against each prefix set is 163 the set of AS numbers that is assigned or sub-allocated the 164 corresponding IP address block. An AS can originate more than one 165 prefix set. Thus, multiple prefix sets in the database can contain 166 the same origin AS(es). 168 Whenever UPDATEs are received from peers, a BGP speaker is expected 169 to perform a lookup in this database for each of the prefixes in the 170 UPDATE message. To aid with better description, we define terms 171 "UPDATE prefix" and "UPDATE origin AS number" to denote the values 172 derived from the received UPDATE message, and "database prefix set" 173 and "database origin AS number set" to mean the values derived from 174 the database lookup. Note that in the presence of overlapping 175 prefixes, the database lookup against the "UPDATE prefix" can yield 176 multiple matches. 178 The following are the different types of results expected from such a 179 lookup operation: 181 o If the "UPDATE prefix" finds no matching or covering prefixes in 182 the database (i.e. the "UPDATE prefix" is not a sub-block of any 183 of the database prefixes), the lookup result is returned as "not 184 found". Due to incremental deployment model of the RPKI 185 repository, it is expected that a complete registry of all IP 186 address blocks and their AS associations is not available at a 187 given point of time. 189 o If there are "database prefix sets" that cover the "UPDATE 190 prefix", and one of them has the "UPDATE origin AS number" in the 191 "database origin AS number sets", then the lookup result is 192 returned as "valid". 194 o If there are "database prefix sets" which cover the "UPDATE 195 prefix", but none of them has the "UPDATE origin AS number" in the 196 "database origin AS number set", then the lookup result is 197 returned as "invalid". 199 Depending on the lookup result, we define a property for each route, 200 called the "validity state". It can assume the values "valid", "not 201 found", or "invalid". 203 Note that all the routes, regardless of their "validity state" will 204 be stored in the local BGP speaker's Adj-RIB-In. 206 Following is a sample pseudo code for prefix validation function: 208 //Input are the variables derived from a BGP UPDATE message 209 //that need to be validated. 210 // 211 //origin_as is the rightmost AS in the final AS_SEQUENCE of 212 //the AS_PATH attribute in the UPDATE message. 213 // 214 //origin_as is NONE if the AS_PATH contains an AS_SET 215 //path segment type. 216 input = {bgp_prefix, masklen, origin_as}; 218 //Initialize result to "not found" state 219 result = BGP_PFXV_STATE_NOT_FOUND; 221 //pfx_validate_table organizes all the ROA entries retrieved 222 //from RPKI cache based on the IP address and the minLength 223 //field. There can be multiple such entries that match the 224 //input. Iterate through all of them. 225 entry = next_lookup_result(pfx_validate_table, 226 input.bgp_prefix, input.masklen); 228 while (entry != NULL) { 229 prefix_exists = TRUE; 230 //Each entry stores multiple records sorted by the ROA 231 //maxLength field. i.e. there can be multiple ROA records 232 //with the same IPaddress and minLength fields, but different 233 //maxLength field. Iterate through all records of the entry 234 //to check if there is one range that matches the input. 235 record = next_in_entry_record_list(entry); 236 while (record != NULL) { 237 if (input.masklen <= record->max_length) { 238 if (input.origin_as == record->origin_as) { 239 result = BGP_PFXV_STATE_VALID; 240 return (result); 241 } 242 } 243 } 244 } 246 //If pfx_validate_table contains one or more prefixes that 247 //match the input, but none of them resulted in a "valid" 248 //outcome since the origin_as did not match, return the 249 //result state as "invalid". Else the initialized state of 250 //"not found" applies to this validation operation. 251 if (prefix_exists == TRUE) { 252 result = BGP_PFXV_STATE_INVALID; 253 } 255 return (result); 257 3. Policy Control 259 An implementation MUST provide the ability to match and set the 260 validation state of routes as part of its route policy filtering 261 function. Use of validation state in route policy is elaborated in 262 Section 5. For more details on operational policy considerations, 263 see [I-D.ietf-sidr-origin-ops]. 265 4. Interaction with Local Cache 267 Each BGP speaker supporting prefix validation as described in this 268 document is expected to communicate with one or multiple local caches 269 that store a database of RPKI signed objects. The protocol 270 mechanisms used to fetch the data and store them locally at the BGP 271 speaker is beyond the scope of this document (please refer 272 [I-D.ietf-sidr-rpki-rtr]). Irrespective of the protocol, the prefix 273 validation algorithm as outlined in this document is expected to 274 function correctly in the event of failures and other timing 275 conditions that may result in an empty and/or partial prefix-to-AS 276 mapping database. Indeed, if the (in-PoP) cache is not available and 277 the mapping database is empty on the BGP speaker, all the lookups 278 will result in "not found" state and the prefixes will be advertised 279 to rest of the network (unless restricted by policy configuration). 280 Similarly, if BGP UPDATEs arrive at the speaker while the fetch 281 operation from the cache is in progress, some prefix lookups will 282 also result in "not found" state. The implementation is expected to 283 handle these timing conditions and MUST re-validate affected prefixes 284 once the fetch operation is complete. The same applies during any 285 subsequent incremental updates of the validation database. 287 In the event that connectivity to the cache is lost, the router 288 should make a reasonable effort to fetch a new validation database 289 (either from the same, or a different cache), and SHOULD wait until 290 the new validation database has been fetched before purging the 291 previous one. A configurable timer MUST be provided to bound the 292 length of time the router will wait before purging the previous 293 validation database. 295 5. Deployment Considerations 297 Once a route is received from an EBGP peer it is categorized 298 according the procedure given in Section 2. Subsequently, routing 299 policy as discussed in Section 3 can be used to take action based on 300 the validation state. 302 Policies which could be implemented include filtering routes based on 303 validation state (for example, rejecting all "invalid" routes) or 304 adjusting a route's degree of preference in the selection algorithm 305 based on its validation state. The latter could be accomplished by 306 adjusting the value of such attributes as LOCAL_PREF. Considering 307 invalid routes for BGP decision process is a pure local policy matter 308 and should be done with utmost care. 310 In some cases (particularly when the selection algorithm is 311 influenced by the adjustment of a route property that is not 312 propagated into IBGP) it could be necessary for routing correctness 313 to propagate the validation state to the IBGP peer. This can be 314 accomplished on the sending side by setting a community or extended 315 community based on the validation state, and on the receiving side by 316 matching the (extended) community and setting the validation state. 318 6. Contributors 319 Rex Fernando rex@cisco.com 320 Keyur Patel keyupate@cisco.com 321 Cisco Systems 323 Miya Kohno mkohno@juniper.net 324 Juniper Networks 326 Shin Miyakawa miyakawa@nttv6.jp 327 Taka Mizuguchi 328 Tomoya Yoshida 329 NTT Communications 331 Russ Housley housley@vigilsec.com 332 Vigil Security 334 Junaid Israr jisra052@uottawa.ca 335 Mouhcine Guennoun mguennou@uottawa.ca 336 Hussein Mouftah mouftah@site.uottawa.ca 337 University of Ottawa School of Information Technology and 338 Engineering(SITE) 800 King Edward Avenue, Ottawa, Ontario, Canada, 339 K1N 6N5 341 7. Acknowledgements 343 Junaid Israr's contribution to this specification is part of his PhD 344 research work and thesis at University of Ottawa, Canada. 346 8. IANA Considerations 348 9. Security Considerations 350 Although this specification discusses one portion of a system to 351 validate BGP routes, it should be noted that it relies on a database 352 (RPKI or other) to provide validation information. As such, the 353 security properties of that database must be considered in order to 354 determine the security provided by the overall solution. If 355 "invalid" routes are blocked as this specification suggests, the 356 overall system provides a possible denial-of-service vector, for 357 example if an attacker is able to inject one or more spoofed records 358 into the validation database which lead a good route to be declared 359 invalid. In addition, this system is only able to provide limited 360 protection against a determined attacker -- the attacker need only 361 prepend the "valid" source AS to a forged BGP route announcement in 362 order to defeat the protection provided by this system. This 363 mechanism does not protect against "AS in the middle attacks" or 364 provide any path validation. It only attempts to verify the origin. 365 In general, this system should be thought of more as a protection 366 against misconfiguration than as true "security" in the strong sense. 368 10. References 370 10.1. Normative References 372 [I-D.ietf-sidr-arch] 373 Lepinski, M. and S. Kent, "An Infrastructure to Support 374 Secure Internet Routing", draft-ietf-sidr-arch-13 (work in 375 progress), May 2011. 377 [I-D.ietf-sidr-roa-format] 378 Lepinski, M., Kent, S., and D. Kong, "A Profile for Route 379 Origin Authorizations (ROAs)", 380 draft-ietf-sidr-roa-format-12 (work in progress), 381 May 2011. 383 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 384 Requirement Levels", BCP 14, RFC 2119, March 1997. 386 [RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP 387 Addresses and AS Identifiers", RFC 3779, June 2004. 389 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 390 Protocol 4 (BGP-4)", RFC 4271, January 2006. 392 10.2. Informational References 394 [I-D.ietf-sidr-origin-ops] 395 Bush, R., "RPKI-Based Origin Validation Operation", 396 draft-ietf-sidr-origin-ops-10 (work in progress), 397 July 2011. 399 [I-D.ietf-sidr-rpki-rtr] 400 Bush, R. and R. Austein, "The RPKI/Router Protocol", 401 draft-ietf-sidr-rpki-rtr-14 (work in progress), July 2011. 403 Authors' Addresses 405 Pradosh Mohapatra (editor) 406 Cisco Systems 407 170 W. Tasman Drive 408 San Jose, CA 95134 409 USA 411 Email: pmohapat@cisco.com 413 John Scudder (editor) 414 Juniper Networks 415 1194 N. Mathilda Ave 416 Sunnyvale, CA 94089 417 USA 419 Email: jgs@juniper.net 421 David Ward (editor) 422 Juniper Networks 423 1194 N. Mathilda Ave 424 Sunnyvale, CA 94089 425 USA 427 Email: dward@juniper.net 429 Randy Bush (editor) 430 Internet Initiative Japan, Inc. 431 5147 Crystral Springs 432 Bainbridge Island, Washington 98110 433 USA 435 Email: randy@psg.com 437 Rob Austein (editor) 438 Internet Systems Consortium 439 950 Charter Street 440 Redwood City, CA 94063 441 USA 443 Email: sra@isc.org