idnits 2.17.1 draft-ietf-sidr-pfx-validate-03.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 (October 31, 2011) is 4560 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 (-23) exists of draft-ietf-sidr-origin-ops-12 == Outdated reference: A later version (-26) exists of draft-ietf-sidr-rpki-rtr-19 Summary: 0 errors (**), 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: May 3, 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 October 31, 2011 13 BGP Prefix Origin Validation 14 draft-ietf-sidr-pfx-validate-03 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 May 3, 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 2.1. Pseudo-Code . . . . . . . . . . . . . . . . . . . . . . . 6 77 3. Policy Control . . . . . . . . . . . . . . . . . . . . . . . . 9 78 4. Interaction with Local Cache . . . . . . . . . . . . . . . . . 9 79 5. Deployment Considerations . . . . . . . . . . . . . . . . . . 9 80 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 10 81 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 82 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 83 9. Security Considerations . . . . . . . . . . . . . . . . . . . 11 84 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 85 10.1. Normative References . . . . . . . . . . . . . . . . . . . 11 86 10.2. Informational References . . . . . . . . . . . . . . . . . 12 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 89 1. Introduction 91 A BGP route associates an address prefix with a set of autonomous 92 systems (AS) that identify the interdomain path the prefix has 93 traversed in the form of BGP announcements. This set is represented 94 as the AS_PATH attribute in BGP [RFC4271] and starts with the AS that 95 originated the prefix. To help reduce well-known threats against BGP 96 including prefix mis-announcing and monkey-in-the-middle attacks, one 97 of the security requirements is the ability to validate the 98 origination AS of BGP routes. More specifically, one needs to 99 validate that the AS number claiming to originate an address prefix 100 (as derived from the AS_PATH attribute of the BGP route) is in fact 101 authorized by the prefix holder to do so. This document describes a 102 simple validation mechanism to partially satisfy this requirement. 104 The Resource Public Key Infrastructure (RPKI) describes an approach 105 to build a formally verifyable database of IP addresses and AS 106 numbers as resources. The overall architecture of RPKI as defined in 107 [I-D.ietf-sidr-arch] consists of three main components: 109 o A public key infrastructure (PKI) with the necessary certificate 110 objects, 112 o Digitally signed routing objects, 114 o A distributed repository system to hold the objects that would 115 also support periodic retrieval. 117 The RPKI system is based on resource certificates that define 118 extensions to X.509 to represent IP addresses and AS identifiers 119 [RFC3779], thus the name RPKI. Route Origin Authorizations (ROA) 120 [I-D.ietf-sidr-roa-format] are separate digitally signed objects that 121 define associations between ASes and IP address blocks. Finally the 122 repository system is operated in a distributed fashion through the 123 IANA, RIR hierarchy, and ISPs. 125 In order to benefit from the RPKI system, it is envisioned that 126 relying parties either at AS or organization level obtain a local 127 copy of the signed object collection, verify the signatures, and 128 process them. The cache must also be refreshed periodically. The 129 exact access mechanism used to retrieve the local cache is beyond the 130 scope of this document. 132 Individual BGP speakers can utilize the processed data contained in 133 the local cache to validate BGP announcements. The protocol details 134 to retrieve the processed data from the local cache to the BGP 135 speakers is beyond the scope of this document (refer to 136 [I-D.ietf-sidr-rpki-rtr] for such a mechanism). This document 137 proposes a means by which a BGP speaker can make use of the processed 138 data in order to assign a "validity state" to each prefix in a 139 received BGP UPDATE message. 141 Note that the complete path attestation against the AS_PATH attribute 142 of a route is outside the scope of this document. 144 Although RPKI provides the context for this draft, it is equally 145 possible to use any other database which is able to map prefixes to 146 their authorized origin ASes. Each distinct database will have its 147 own particular operational and security characteristics; such 148 characteristics are beyond the scope of this document. 150 1.1. Requirements Language 152 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 153 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 154 document are to be interpreted as described in RFC 2119 [RFC2119]. 156 2. Prefix-to-AS Mapping Database 158 The BGP speaker loads validated objects from the cache into local 159 storage. The objects loaded have the content (IP address, prefix 160 length, maximum length, origin AS number). We refer to such a 161 locally stored object colloquially as a "ROA" in the discussion below 162 although we note that this is not a strictly accurate use of the 163 term. 165 We define several terms in addition to "ROA". Where these terms are 166 used, they are capitalized: 168 o Prefix: (IP address, prefix length), interpreted as is customary 169 (see [RFC4632]). 171 o Route: Data derived from a received BGP UPDATE, as defined in 172 [RFC4271], Section 1.1. The Route includes one Prefix and an 173 AS_PATH, among other things. 175 o ROA Prefix: The Prefix from a ROA. 177 o ROA ASN: The origin ASN from a ROA. 179 o Route Prefix: A Prefix derived from a route. 181 o Route Origin ASN: The origin AS number derived from a Route. The 182 origin AS number is the rightmost AS in the final segment of the 183 AS_PATH attribute in the Route if that segment is of type 184 AS_SEQUENCE, or NONE if the final segment of the AS_PATH attribute 185 is of any type other than AS_SEQUENCE. No ROA can match an origin 186 AS number of "NONE". No Route can match a ROA whose origin AS 187 number is zero. 189 o Covered: A Route Prefix is said to be Covered by a ROA when the 190 ROA prefix length is less than or equal to the Route prefix length 191 and the ROA prefix address matches the Route prefix address for 192 all bits specified by the ROA prefix length. (This is simply a 193 statement of the well-known concept of determining a prefix 194 match.) 196 o Matched: A Route Prefix is said to be Matched by a ROA when the 197 Route Prefix is Covered by that ROA and in addition, the Route 198 prefix length is less than or equal to the ROA maximum length and 199 the Route Origin ASN is equal to the ROA ASN, keeping in mind that 200 a ROA ASN of zero can never be matched, nor can a route origin AS 201 number of "NONE". 203 Given these definitions, any given BGP Route learned from an EBGP 204 peer will be found to have one of the following "validation states": 206 o Not found: No ROA Covers the Route Prefix. 208 o Valid: At least one ROA Matches the Route Prefix. 210 o Invalid: At least one ROA Covers the Route Prefix, but no ROA 211 Matches it. 213 When a BGP speaker receives an UPDATE from one of its EBGP peers, it 214 SHOULD perform a lookup as described above for each of the Routes in 215 the UPDATE message. The "validation state" of the Route SHOULD be 216 set to reflect the result of the lookup. Note that the validation 217 state of the Route does not determine whether the Route is stored in 218 the local BGP speaker's Adj-RIB-In. This procedure SHOULD NOT be 219 performed for Routes learned from peers of types other than EBGP. 220 (Any of these MAY be overridden by configuration.) 222 Use of the validation state is discussed in Section 3 and Section 5. 224 We observe that a Route can be Matched or Covered by more than one 225 ROA. This procedure does not mandate an order in which ROAs must be 226 visited; however, the "validation state" output is fully determined. 228 2.1. Pseudo-Code 230 The following pseudo-code illustrates the procedure above. In case 231 of ambiguity, the procedure above, rather than the pseudo-code, 232 should be taken as authoritative. 234 //Input are the variables derived from a BGP UPDATE message 235 //that need to be validated. 236 // 237 //The input prefix is comprised of prefix.address and 238 //prefix.length. 239 // 240 //origin_as is the rightmost AS in the final segment of the 241 //AS_PATH attribute in the UPDATE message if that segment is 242 //AS_SEQUENCE. If the final segment of AS_PATH is not an 243 //AS_SEQUENCE, origin_as is NONE. 244 // 245 //Collectively, the prefix and origin_as correspond to the 246 //Route defined in the preceding section. 247 input = {prefix, origin_as}; 249 //Initialize result to "not found" state 250 result = BGP_PFXV_STATE_NOT_FOUND; 252 //pfx_validate_table organizes all the ROA entries retrieved 253 //from the RPKI cache based on the IP address and the prefix 254 //length field. There can be multiple such entries that match 255 //the input. Iterate through all of them. 256 entry = next_lookup_result(pfx_validate_table, input.prefix); 258 while (entry != NULL) { 259 prefix_exists = TRUE; 261 if (input.prefix.length <= entry->max_length) { 262 if (input.origin_as != NONE 263 && entry->origin_as != 0 264 && input.origin_as == entry->origin_as) { 265 result = BGP_PFXV_STATE_VALID; 266 return (result); 267 } 268 } 269 entry = next_lookup_result(pfx_validate_table, input.prefix); 270 } 272 //If pfx_validate_table contains one or more prefixes that 273 //match the input, but none of them resulted in a "valid" 274 //outcome since the origin_as did not match, return the 275 //result state as "invalid". Else the initialized state of 276 //"not found" applies to this validation operation. 277 if (prefix_exists == TRUE) { 278 result = BGP_PFXV_STATE_INVALID; 279 } 281 return (result); 283 3. Policy Control 285 An implementation MUST provide the ability to match and set the 286 validation state of routes as part of its route policy filtering 287 function. Use of validation state in route policy is elaborated in 288 Section 5. For more details on operational policy considerations, 289 see [I-D.ietf-sidr-origin-ops]. 291 4. Interaction with Local Cache 293 Each BGP speaker supporting prefix validation as described in this 294 document is expected to communicate with one or multiple local caches 295 that store a database of RPKI signed objects. The protocol 296 mechanisms used to fetch the data and store them locally at the BGP 297 speaker is beyond the scope of this document (please refer 298 [I-D.ietf-sidr-rpki-rtr]). Irrespective of the protocol, the prefix 299 validation algorithm as outlined in this document is expected to 300 function correctly in the event of failures and other timing 301 conditions that may result in an empty and/or partial prefix-to-AS 302 mapping database. Indeed, if the (in-PoP) cache is not available and 303 the mapping database is empty on the BGP speaker, all the lookups 304 will result in "not found" state and the prefixes will be advertised 305 to rest of the network (unless restricted by policy configuration). 306 Similarly, if BGP UPDATEs arrive at the speaker while the fetch 307 operation from the cache is in progress, some prefix lookups will 308 also result in "not found" state. The implementation is expected to 309 handle these timing conditions and MUST re-validate affected prefixes 310 once the fetch operation is complete. The same applies during any 311 subsequent incremental updates of the validation database. 313 In the event that connectivity to the cache is lost, the router 314 should make a reasonable effort to fetch a new validation database 315 (either from the same, or a different cache), and SHOULD wait until 316 the new validation database has been fetched before purging the 317 previous one. A configurable timer MUST be provided to bound the 318 length of time the router will wait before purging the previous 319 validation database. 321 5. Deployment Considerations 323 Once a route is received from an EBGP peer it is categorized 324 according the procedure given in Section 2. Subsequently, routing 325 policy as discussed in Section 3 can be used to take action based on 326 the validation state. 328 Policies which could be implemented include filtering routes based on 329 validation state (for example, rejecting all "invalid" routes) or 330 adjusting a route's degree of preference in the selection algorithm 331 based on its validation state. The latter could be accomplished by 332 adjusting the value of such attributes as LOCAL_PREF. Considering 333 invalid routes for BGP decision process is a pure local policy matter 334 and should be done with utmost care. 336 In some cases (particularly when the selection algorithm is 337 influenced by the adjustment of a route property that is not 338 propagated into IBGP) it could be necessary for routing correctness 339 to propagate the validation state to the IBGP peer. This can be 340 accomplished on the sending side by setting a community or extended 341 community based on the validation state, and on the receiving side by 342 matching the (extended) community and setting the validation state. 344 6. Contributors 346 Rex Fernando rex@cisco.com 347 Keyur Patel keyupate@cisco.com 348 Cisco Systems 350 Miya Kohno mkohno@juniper.net 351 Juniper Networks 353 Shin Miyakawa miyakawa@nttv6.jp 354 Taka Mizuguchi 355 Tomoya Yoshida 356 NTT Communications 358 Russ Housley housley@vigilsec.com 359 Vigil Security 361 Junaid Israr jisra052@uottawa.ca 362 Mouhcine Guennoun mguennou@uottawa.ca 363 Hussein Mouftah mouftah@site.uottawa.ca 364 University of Ottawa School of Information Technology and 365 Engineering(SITE) 800 King Edward Avenue, Ottawa, Ontario, Canada, 366 K1N 6N5 368 7. Acknowledgements 370 Junaid Israr's contribution to this specification is part of his PhD 371 research work and thesis at University of Ottawa, Canada. Hannes 372 Gredler provided valuable feedback. 374 8. IANA Considerations 376 9. Security Considerations 378 Although this specification discusses one portion of a system to 379 validate BGP routes, it should be noted that it relies on a database 380 (RPKI or other) to provide validation information. As such, the 381 security properties of that database must be considered in order to 382 determine the security provided by the overall solution. If 383 "invalid" routes are blocked as this specification suggests, the 384 overall system provides a possible denial-of-service vector, for 385 example if an attacker is able to inject one or more spoofed records 386 into the validation database which lead a good route to be declared 387 invalid. In addition, this system is only able to provide limited 388 protection against a determined attacker -- the attacker need only 389 prepend the "valid" source AS to a forged BGP route announcement in 390 order to defeat the protection provided by this system. This 391 mechanism does not protect against "AS in the middle attacks" or 392 provide any path validation. It only attempts to verify the origin. 393 In general, this system should be thought of more as a protection 394 against misconfiguration than as true "security" in the strong sense. 396 10. References 398 10.1. Normative References 400 [I-D.ietf-sidr-roa-format] 401 Lepinski, M., Kent, S., and D. Kong, "A Profile for Route 402 Origin Authorizations (ROAs)", 403 draft-ietf-sidr-roa-format-12 (work in progress), 404 May 2011. 406 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 407 Requirement Levels", BCP 14, RFC 2119, March 1997. 409 [RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP 410 Addresses and AS Identifiers", RFC 3779, June 2004. 412 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 413 Protocol 4 (BGP-4)", RFC 4271, January 2006. 415 [RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing 416 (CIDR): The Internet Address Assignment and Aggregation 417 Plan", BCP 122, RFC 4632, August 2006. 419 10.2. Informational References 421 [I-D.ietf-sidr-arch] 422 Lepinski, M. and S. Kent, "An Infrastructure to Support 423 Secure Internet Routing", draft-ietf-sidr-arch-13 (work in 424 progress), May 2011. 426 [I-D.ietf-sidr-origin-ops] 427 Bush, R., "RPKI-Based Origin Validation Operation", 428 draft-ietf-sidr-origin-ops-12 (work in progress), 429 October 2011. 431 [I-D.ietf-sidr-rpki-rtr] 432 Bush, R. and R. Austein, "The RPKI/Router Protocol", 433 draft-ietf-sidr-rpki-rtr-19 (work in progress), 434 October 2011. 436 Authors' Addresses 438 Pradosh Mohapatra (editor) 439 Cisco Systems 440 170 W. Tasman Drive 441 San Jose, CA 95134 442 USA 444 Email: pmohapat@cisco.com 446 John Scudder (editor) 447 Juniper Networks 448 1194 N. Mathilda Ave 449 Sunnyvale, CA 94089 450 USA 452 Email: jgs@juniper.net 454 David Ward (editor) 455 Juniper Networks 456 1194 N. Mathilda Ave 457 Sunnyvale, CA 94089 458 USA 460 Email: dward@juniper.net 461 Randy Bush (editor) 462 Internet Initiative Japan, Inc. 463 5147 Crystral Springs 464 Bainbridge Island, Washington 98110 465 USA 467 Email: randy@psg.com 469 Rob Austein (editor) 470 Internet Systems Consortium 471 950 Charter Street 472 Redwood City, CA 94063 473 USA 475 Email: sra@isc.org