idnits 2.17.1 draft-ietf-sidr-pfx-validate-06.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 (May 22, 2012) is 4356 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 (-06) exists of draft-ietf-idr-as0-04 == Outdated reference: A later version (-23) exists of draft-ietf-sidr-origin-ops-15 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 3 Internet-Draft Cisco Systems 4 Intended status: Standards Track J. Scudder 5 Expires: November 23, 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 May 22, 2012 14 BGP Prefix Origin Validation 15 draft-ietf-sidr-pfx-validate-06 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 November 23, 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 "validation 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 as a "Validated ROA Payload" or "VRP". 163 We define several terms in addition to "VRP". Where these terms are 164 used, they are capitalized: 166 o Prefix: (IP address, prefix length), interpreted as is customary 167 (see [RFC4632]). 169 o Route: Data derived from a received BGP UPDATE, as defined in 170 [RFC4271], Section 1.1. The Route includes one Prefix and an 171 AS_PATH; it may include other attributes to characterize the 172 prefix. 174 o VRP Prefix: The Prefix from a VRP. 176 o VRP ASN: The origin AS number from a VRP. 178 o Route Prefix: The Prefix derived from a route. 180 o Route Origin ASN: The origin AS number derived from a Route as 181 follows: 183 * the rightmost AS in the final segment of the AS_PATH attribute 184 in the Route if that segment is of type AS_SEQUENCE, or 186 * the BGP speaker's own AS number if that segment is of type 187 AS_CONFED_SEQUENCE or AS_CONFED_SET or if the AS_PATH is empty, 188 or 190 * the distinguished value "NONE" if the final segment of the 191 AS_PATH attribute is of any other type. 193 o Covered: A Route Prefix is said to be Covered by a VRP when the 194 VRP prefix length is less than or equal to the Route prefix 195 length, and the VRP prefix address and the Route prefix address 196 are identical for all bits specified by the VRP prefix 197 length.(I.e. the Route prefix is either identical to the VRP 198 prefix or a more specific of the VRP prefix.) 200 o Matched: A Route Prefix is said to be Matched by a VRP when the 201 Route Prefix is Covered by that VRP and in addition, the Route 202 prefix length is less than or equal to the VRP maximum length and 203 the Route Origin ASN is equal to the VRP ASN. 205 Given these definitions, any given BGP Route will be found to have 206 one of the following "validation states": 208 o NotFound: No VRP Covers the Route Prefix. 210 o Valid: At least one VRP Matches the Route Prefix. 212 o Invalid: At least one VRP Covers the Route Prefix, but no VRP 213 Matches it. 215 We observe that no VRP can have the value "NONE" as its VRP ASN. 216 Thus a Route whose Origin ASN is "NONE" cannot be Matched by any VRP. 217 Similarly, no valid Route can have an Origin ASN of zero 218 [I-D.ietf-idr-as0]. Thus no Route can be Matched by a VRP whose ASN 219 is zero. 221 When a BGP speaker receives an UPDATE from a neighbor, it SHOULD 222 perform a lookup as described above for each of the Routes in the 223 UPDATE message. The lookup SHOULD also be applied to routes which 224 are redistributed into BGP from another source, such as another 225 protocol or a locally defined static route. An implementation MAY 226 provide configuration options to control which routes the lookup is 227 applied to. The "validation state" of the Route MUST be set to 228 reflect the result of the lookup. The implementation should consider 229 the "validation state" as described in the document as a local 230 property or attribute of the Route. If validation is not performed 231 on a Route, the implementation SHOULD initialize the "validation 232 state" of such a route to "NotFound". 234 Use of the validation state is discussed in Section 3 and Section 5. 235 An implementation MUST NOT exclude a route from the Adj-RIB-In or 236 from consideration in the decision process as a side-effect of its 237 validation state, unless explicitly configured to do so. 239 We observe that a Route can be Matched or Covered by more than one 240 VRP. This procedure does not mandate an order in which VRPs must be 241 visited; however, the "validation state" output is fully determined. 243 2.1. Pseudo-Code 245 The following pseudo-code illustrates the procedure above. In case 246 of ambiguity, the procedure above, rather than the pseudo-code, 247 should be taken as authoritative. 249 result = BGP_PFXV_STATE_NOT_FOUND; 251 //Iterate through all the Covering entries in the local VRP 252 //database, pfx_validate_table. 253 entry = next_lookup_result(pfx_validate_table, route_prefix); 255 while (entry != NULL) { 256 prefix_exists = TRUE; 258 if (route_prefix_length <= entry->max_length) { 259 if (route_origin_as != NONE 260 && entry->origin_as != 0 261 && route_origin_as == entry->origin_as) { 262 result = BGP_PFXV_STATE_VALID; 263 return (result); 264 } 265 } 266 entry = next_lookup_result(pfx_validate_table, input.prefix); 267 } 269 //If one or more VRP entries Covered the route prefix, but 270 //no one Matched, return "Invalid" validation state. 271 if (prefix_exists == TRUE) { 272 result = BGP_PFXV_STATE_INVALID; 273 } 275 return (result); 277 3. Policy Control 279 An implementation MUST provide the ability to match and set the 280 validation state of routes as part of its route policy filtering 281 function. Use of validation state in route policy is elaborated in 282 Section 5. For more details on operational policy considerations, 283 see [I-D.ietf-sidr-origin-ops]. 285 An implementation MUST support Four-Octet AS Numbers, [RFC4893]. 287 4. Interaction with Local Cache 289 Each BGP speaker supporting prefix validation as described in this 290 document is expected to communicate with one or more RPKI caches, 291 each of which stores a local copy of the global RPKI database. The 292 protocol mechanisms used to gather and validate these data and 293 present them to BGP speakers are described in 294 [I-D.ietf-sidr-rpki-rtr]. 296 The prefix-to-AS mappings used by the BGP speaker are expected to be 297 updated over time. When a mapping is added or deleted, the 298 implementation MUST re-validate any affected prefixes. An "affected 299 prefix" is any prefix that was matched by a deleted or updated 300 mapping, or could be matched by an added mapping. 302 5. Deployment Considerations 304 Once a Route is selected for validation, it is categorized according 305 the procedure given in Section 2. Subsequently, routing policy as 306 discussed in Section 3 can be used to take action based on the 307 validation state. 309 Policies which could be implemented include filtering routes based on 310 validation state (for example, rejecting all "invalid" routes) or 311 adjusting a route's degree of preference in the selection algorithm 312 based on its validation state. The latter could be accomplished by 313 adjusting the value of such attributes as LOCAL_PREF. Considering 314 invalid routes for BGP decision process is a pure local policy matter 315 and should be done with utmost care. 317 In some cases (particularly when the selection algorithm is 318 influenced by the adjustment of a route property that is not 319 propagated into IBGP) it could be necessary for routing correctness 320 to propagate the validation state to the IBGP peer. This can be 321 accomplished on the sending side by setting a community or extended 322 community based on the validation state, and on the receiving side by 323 matching the (extended) community and setting the validation state. 325 6. Acknowledgments 327 The authors wish to thank Rex Fernando, Hannes Gredler, Mouhcine 328 Guennoun, Russ Housley, Junaid Israr, Miya Kohno, Shin Miyakawa, Taka 329 Mizuguchi, Hussein Mouftah, Keyur Patel, Tomoya Yoshida, Kannan 330 Varadhan, Wes George, Jay Borkenhagen, and Sandra Murphy. The 331 authors are grateful for the feedback from the members of the SIDR 332 working group. 334 Junaid Israr's contribution to this specification was part of his PhD 335 research work and thesis at University of Ottawa. 337 7. IANA Considerations 339 8. Security Considerations 341 Although this specification discusses one portion of a system to 342 validate BGP routes, it should be noted that it relies on a database 343 (RPKI or other) to provide validation information. As such, the 344 security properties of that database must be considered in order to 345 determine the security provided by the overall solution. If 346 "invalid" routes are blocked as this specification suggests, the 347 overall system provides a possible denial-of-service vector, for 348 example if an attacker is able to inject or remove one or more 349 records in the validation database, it could lead an otherwise valid 350 route to be marked as invalid. 352 In addition, this system is only able to provide limited protection 353 against a determined attacker -- the attacker need only prepend the 354 "valid" source AS to a forged BGP route announcement in order to 355 defeat the protection provided by this system. 357 This mechanism does not protect against "AS in the middle attacks" or 358 provide any path validation. It only attempts to verify the origin. 359 In general, this system should be thought of more as a protection 360 against misconfiguration than as true "security" in the strong sense. 362 9. References 363 9.1. Normative References 365 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 366 Requirement Levels", BCP 14, RFC 2119, March 1997. 368 [RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP 369 Addresses and AS Identifiers", RFC 3779, June 2004. 371 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 372 Protocol 4 (BGP-4)", RFC 4271, January 2006. 374 [RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing 375 (CIDR): The Internet Address Assignment and Aggregation 376 Plan", BCP 122, RFC 4632, August 2006. 378 [RFC4893] Vohra, Q. and E. Chen, "BGP Support for Four-octet AS 379 Number Space", RFC 4893, May 2007. 381 [RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route 382 Origin Authorizations (ROAs)", RFC 6482, February 2012. 384 9.2. Informational References 386 [I-D.ietf-idr-as0] 387 Kumari, W., Bush, R., Schiller, H., and K. Patel, 388 "Codification of AS 0 processing.", draft-ietf-idr-as0-04 389 (work in progress), May 2012. 391 [I-D.ietf-sidr-origin-ops] 392 Bush, R., "RPKI-Based Origin Validation Operation", 393 draft-ietf-sidr-origin-ops-15 (work in progress), 394 March 2012. 396 [I-D.ietf-sidr-rpki-rtr] 397 Bush, R. and R. Austein, "The RPKI/Router Protocol", 398 draft-ietf-sidr-rpki-rtr-26 (work in progress), 399 February 2012. 401 [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support 402 Secure Internet Routing", RFC 6480, February 2012. 404 Authors' Addresses 406 Pradosh Mohapatra 407 Cisco Systems 408 170 W. Tasman Drive 409 San Jose, CA 95134 410 USA 412 Email: pmohapat@cisco.com 414 John Scudder 415 Juniper Networks 416 1194 N. Mathilda Ave 417 Sunnyvale, CA 94089 418 USA 420 Email: jgs@juniper.net 422 David Ward 423 Cisco Systems 424 170 W. Tasman Drive 425 San Jose, CA 95134 426 USA 428 Email: dward@cisco.com 430 Randy Bush 431 Internet Initiative Japan, Inc. 432 5147 Crystal Springs 433 Bainbridge Island, Washington 98110 434 USA 436 Email: randy@psg.com 438 Rob Austein 439 Dragon Research Labs 441 Email: sra@hactrn.net