idnits 2.17.1 draft-ietf-sidr-pfx-validate-04.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 (March 12, 2012) is 4427 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) ** Obsolete normative reference: RFC 4893 (Obsoleted by RFC 6793) == Outdated reference: A later version (-23) exists of draft-ietf-sidr-origin-ops-15 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Mohapatra 3 Internet-Draft Cisco Systems 4 Intended status: Standards Track J. Scudder 5 Expires: September 13, 2012 Juniper Networks 6 D. Ward 7 Cisco Systems 8 R. Bush 9 Internet Initiative Japan, Inc. 10 R. Austein 11 Dragon Research Labs 12 March 12, 2012 14 BGP Prefix Origin Validation 15 draft-ietf-sidr-pfx-validate-04 17 Abstract 19 To help reduce well-known threats against BGP including prefix mis- 20 announcing and monkey-in-the-middle attacks, one of the security 21 requirements is the ability to validate the origination AS of BGP 22 routes. More specifically, one needs to validate that the AS number 23 claiming to originate an address prefix (as derived from the AS_PATH 24 attribute of the BGP route) is in fact authorized by the prefix 25 holder to do so. This document describes a simple validation 26 mechanism to partially satisfy this requirement. 28 Status of this Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on September 13, 2012. 45 Copyright Notice 47 Copyright (c) 2012 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 This document may contain material from IETF Documents or IETF 61 Contributions published or made publicly available before November 62 10, 2008. The person(s) controlling the copyright in some of this 63 material may not have granted the IETF Trust the right to allow 64 modifications of such material outside the IETF Standards Process. 65 Without obtaining an adequate license from the person(s) controlling 66 the copyright in such materials, this document may not be modified 67 outside the IETF Standards Process, and derivative works of it may 68 not be created outside the IETF Standards Process, except to format 69 it for publication as an RFC or to translate it into languages other 70 than English. 72 Table of Contents 74 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 75 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5 76 2. Prefix-to-AS Mapping Database . . . . . . . . . . . . . . . . 5 77 2.1. Pseudo-Code . . . . . . . . . . . . . . . . . . . . . . . 7 78 3. Policy Control . . . . . . . . . . . . . . . . . . . . . . . . 8 79 4. Interaction with Local Cache . . . . . . . . . . . . . . . . . 8 80 5. Deployment Considerations . . . . . . . . . . . . . . . . . . 8 81 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 82 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 83 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 84 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 85 9.1. Normative References . . . . . . . . . . . . . . . . . . . 10 86 9.2. Informational References . . . . . . . . . . . . . . . . . 10 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 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 verifiable database of IP addresses and AS 106 numbers as resources. The overall architecture of RPKI as defined in 107 [RFC6480] 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 [RFC6482] are separate digitally signed objects that define 121 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; it may include other attributes to characterize the 174 prefix. 176 o ROA Prefix: The Prefix from a ROA. 178 o ROA ASN: The origin AS number from a ROA. 180 o Route Prefix: The Prefix derived from a route. 182 o Route Origin ASN: The origin AS number derived from a Route. The 183 origin AS number is the rightmost AS in the final segment of the 184 AS_PATH attribute in the Route if that segment is of type 185 AS_SEQUENCE, or NONE if the final segment of the AS_PATH attribute 186 is of any type other than AS_SEQUENCE. No ROA can match an origin 187 AS number of "NONE". No Route can match a ROA whose origin AS 188 number is zero. 190 o Covered: A Route Prefix is said to be Covered by a ROA when the 191 ROA prefix length is less than or equal to the Route prefix length 192 and the ROA prefix address matches the Route prefix address for 193 all bits specified by the ROA prefix length. (This is simply a 194 statement of the well-known concept of determining a prefix 195 match.) 197 o Matched: A Route Prefix is said to be Matched by a ROA when the 198 Route Prefix is Covered by that ROA and in addition, the Route 199 prefix length is less than or equal to the ROA maximum length and 200 the Route Origin ASN is equal to the ROA ASN, keeping in mind that 201 a ROA ASN of zero can never be matched, nor can a route origin AS 202 number of "NONE". 204 Given these definitions, any given BGP Route will be found to have 205 one of the following "validation states": 207 o NotFound: No ROA Covers the Route Prefix. 209 o Valid: At least one ROA Matches the Route Prefix. 211 o Invalid: At least one ROA Covers the Route Prefix, but no ROA 212 Matches it. 214 When a BGP speaker receives an UPDATE from one of its EBGP peers, it 215 SHOULD perform a lookup as described above for each of the Routes in 216 the UPDATE message. The "validation state" of the Route SHOULD be 217 set to reflect the result of the lookup. Note that the validation 218 state of the Route does not determine whether the Route is stored in 219 the local BGP speaker's Adj-RIB-In. This procedure SHOULD NOT be 220 performed for Routes learned from peers of types other than EBGP. 221 (Any of these MAY be overridden by configuration.) The suggested 222 implementation should consider the "validation state" as described in 223 the document as a local property or attribute of the Route. If 224 validation is not performed on a Route, the implementation SHOULD 225 initialize the validation state of such a route to "Valid". 227 Use of the validation state is discussed in Section 3 and Section 5. 229 We observe that a Route can be Matched or Covered by more than one 230 ROA. This procedure does not mandate an order in which ROAs must be 231 visited; however, the "validation state" output is fully determined. 233 2.1. Pseudo-Code 235 The following pseudo-code illustrates the procedure above. In case 236 of ambiguity, the procedure above, rather than the pseudo-code, 237 should be taken as authoritative. 239 //Input are the variables derived from a BGP UPDATE message 240 //that need to be validated. 241 // 242 //The input prefix is comprised of prefix.address and 243 //prefix.length. 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 "NotFound" 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 //"NotFound" applies to this validation operation. 277 if (prefix_exists == TRUE) { 278 result = BGP_PFXV_STATE_INVALID; 279 } 280 return (result); 282 3. Policy Control 284 An implementation MUST provide the ability to match and set the 285 validation state of routes as part of its route policy filtering 286 function. Use of validation state in route policy is elaborated in 287 Section 5. For more details on operational policy considerations, 288 see [I-D.ietf-sidr-origin-ops]. 290 An implementation MUST support Four-Octet AS Numbers, [RFC4893]. 292 4. Interaction with Local Cache 294 Each BGP speaker supporting prefix validation as described in this 295 document is expected to communicate with one or more RPKI caches, 296 each of which stores a local copy of the global RPKI database. The 297 protocol mechanisms used to gather and validate these data and 298 present them to BGP speakers are described in 299 [I-D.ietf-sidr-rpki-rtr]. 301 The prefix-to-AS mappings used by the BGP speaker are expected to be 302 updated over time. When a mapping is added or deleted, the 303 implementation MUST re-validate any affected prefixes. An "affected 304 prefix" is any prefix that was matched by a deleted or updated 305 mapping, or could be matched by an added mapping. 307 5. Deployment Considerations 309 Once a Route is selected for validation, it is categorized according 310 the procedure given in Section 2. Subsequently, routing policy as 311 discussed in Section 3 can be used to take action based on the 312 validation state. 314 Policies which could be implemented include filtering routes based on 315 validation state (for example, rejecting all "invalid" routes) or 316 adjusting a route's degree of preference in the selection algorithm 317 based on its validation state. The latter could be accomplished by 318 adjusting the value of such attributes as LOCAL_PREF. Considering 319 invalid routes for BGP decision process is a pure local policy matter 320 and should be done with utmost care. 322 In some cases (particularly when the selection algorithm is 323 influenced by the adjustment of a route property that is not 324 propagated into IBGP) it could be necessary for routing correctness 325 to propagate the validation state to the IBGP peer. This can be 326 accomplished on the sending side by setting a community or extended 327 community based on the validation state, and on the receiving side by 328 matching the (extended) community and setting the validation state. 330 6. Acknowledgments 332 The authors wish to thank Rex Fernando, Hannes Gredler, Mouhcine 333 Guennoun, Russ Housley, Junaid Israr, Miya Kohno, Shin Miyakawa, Taka 334 Mizuguchi, Hussein Mouftah, Keyur Patel, Tomoya Yoshida, and Kannan 335 Varadhan. The authors are grateful for the feedback from the members 336 of the SIDR working group. 338 Junaid Israr's contribution to this specification was part of his PhD 339 research work and thesis at University of Ottawa. 341 7. IANA Considerations 343 8. Security Considerations 345 Although this specification discusses one portion of a system to 346 validate BGP routes, it should be noted that it relies on a database 347 (RPKI or other) to provide validation information. As such, the 348 security properties of that database must be considered in order to 349 determine the security provided by the overall solution. If 350 "invalid" routes are blocked as this specification suggests, the 351 overall system provides a possible denial-of-service vector, for 352 example if an attacker is able to inject or remove one or more 353 records in the validation database, it could lead an otherwise valid 354 route to be marked as invalid. 356 In addition, this system is only able to provide limited protection 357 against a determined attacker -- the attacker need only prepend the 358 "valid" source AS to a forged BGP route announcement in order to 359 defeat the protection provided by this system. 361 This mechanism does not protect against "AS in the middle attacks" or 362 provide any path validation. It only attempts to verify the origin. 363 In general, this system should be thought of more as a protection 364 against misconfiguration than as true "security" in the strong sense. 366 9. References 367 9.1. Normative References 369 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 370 Requirement Levels", BCP 14, RFC 2119, March 1997. 372 [RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP 373 Addresses and AS Identifiers", RFC 3779, June 2004. 375 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 376 Protocol 4 (BGP-4)", RFC 4271, January 2006. 378 [RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing 379 (CIDR): The Internet Address Assignment and Aggregation 380 Plan", BCP 122, RFC 4632, August 2006. 382 [RFC4893] Vohra, Q. and E. Chen, "BGP Support for Four-octet AS 383 Number Space", RFC 4893, May 2007. 385 [RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route 386 Origin Authorizations (ROAs)", RFC 6482, February 2012. 388 9.2. Informational References 390 [I-D.ietf-sidr-origin-ops] 391 Bush, R., "RPKI-Based Origin Validation Operation", 392 draft-ietf-sidr-origin-ops-15 (work in progress), 393 March 2012. 395 [I-D.ietf-sidr-rpki-rtr] 396 Bush, R. and R. Austein, "The RPKI/Router Protocol", 397 draft-ietf-sidr-rpki-rtr-26 (work in progress), 398 February 2012. 400 [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support 401 Secure Internet Routing", RFC 6480, February 2012. 403 Authors' Addresses 405 Pradosh Mohapatra 406 Cisco Systems 407 170 W. Tasman Drive 408 San Jose, CA 95134 409 USA 411 Email: pmohapat@cisco.com 412 John Scudder 413 Juniper Networks 414 1194 N. Mathilda Ave 415 Sunnyvale, CA 94089 416 USA 418 Email: jgs@juniper.net 420 David Ward 421 Cisco Systems 422 170 W. Tasman Drive 423 San Jose, CA 95134 424 USA 426 Email: dward@cisco.com 428 Randy Bush 429 Internet Initiative Japan, Inc. 430 5147 Crystal Springs 431 Bainbridge Island, Washington 98110 432 USA 434 Email: randy@psg.com 436 Rob Austein 437 Dragon Research Labs 439 Email: sra@hactrn.net