idnits 2.17.1 draft-ietf-sidr-pfx-validate-10.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 lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (October 2012) is 4204 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) == Unused Reference: 'I-D.ietf-idr-as0' is defined on line 386, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-sidr-rpki-rtr' is defined on line 395, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4893 (Obsoleted by RFC 6793) == Outdated reference: A later version (-23) exists of draft-ietf-sidr-origin-ops-19 Summary: 1 error (**), 0 flaws (~~), 5 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: April 02, 2013 Juniper Networks 6 D. Ward 7 Cisco Systems 8 R. Bush 9 Internet Initiative Japan 10 R. Austein 11 Dragon Research Labs 12 October 2012 14 BGP Prefix Origin Validation 15 draft-ietf-sidr-pfx-validate-10 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 April 02, 2013. 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 (http://trustee.ietf.org/ 52 license-info) in effect on the date of publication of this document. 53 Please review these documents carefully, as they describe your rights 54 and restrictions with respect to this document. Code Components 55 extracted from this document must include Simplified BSD License text 56 as described in Section 4.e of the Trust Legal Provisions and are 57 provided without warranty as described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 62 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 63 2. Prefix-to-AS Mapping Database . . . . . . . . . . . . . . . . 4 64 2.1. Pseudo-Code . . . . . . . . . . . . . . . . . . . . . . . 6 65 3. Policy Control . . . . . . . . . . . . . . . . . . . . . . . . 6 66 4. Interaction with Local Cache . . . . . . . . . . . . . . . . . 7 67 5. Deployment Considerations . . . . . . . . . . . . . . . . . . 7 68 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 69 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 70 8. Security Considerations . . . . . . . . . . . . . . . . . . . 8 71 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 72 9.1. Normative References . . . . . . . . . . . . . . . . . . . 8 73 9.2. Informational References . . . . . . . . . . . . . . . . . 9 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 76 1. Introduction 78 A BGP route associates an address prefix with a set of autonomous 79 systems (AS) that identify the interdomain path the prefix has 80 traversed in the form of BGP announcements. This set is represented 81 as the AS_PATH attribute in BGP [RFC4271] and starts with the AS that 82 originated the prefix. To help reduce well-known threats against BGP 83 including prefix mis-announcing and monkey-in-the-middle attacks, one 84 of the security requirements is the ability to validate the 85 origination AS of BGP routes. More specifically, one needs to 86 validate that the AS number claiming to originate an address prefix 87 (as derived from the AS_PATH attribute of the BGP route) is in fact 88 authorized by the prefix holder to do so. This document describes a 89 simple validation mechanism to partially satisfy this requirement. 91 The Resource Public Key Infrastructure (RPKI) describes an approach 92 to build a formally verifiable database of IP addresses and AS 93 numbers as resources. The overall architecture of RPKI as defined in 94 [RFC6480] consists of three main components: 96 o A public key infrastructure (PKI) with the necessary certificate 97 objects, 99 o Digitally signed routing objects, 101 o A distributed repository system to hold the objects that would 102 also support periodic retrieval. 104 The RPKI system is based on resource certificates that define 105 extensions to X.509 to represent IP addresses and AS identifiers 106 [RFC3779], thus the name RPKI. Route Origin Authorizations (ROA) 107 [RFC6482] are separate digitally signed objects that define 108 associations between ASes and IP address blocks. Finally the 109 repository system is operated in a distributed fashion through the 110 IANA, RIR hierarchy, and ISPs. 112 In order to benefit from the RPKI system, it is envisioned that 113 relying parties either at AS or organization level obtain a local 114 copy of the signed object collection, verify the signatures, and 115 process them. The cache must also be refreshed periodically. The 116 exact access mechanism used to retrieve the local cache is beyond the 117 scope of this document. 119 Individual BGP speakers can utilize the processed data contained in 120 the local cache to validate BGP announcements. The protocol details 121 to retrieve the processed data from the local cache to the BGP 122 speakers is beyond the scope of this document (refer to [I-D.ietf- 123 sidr-rpki-rtr] for such a mechanism). This document proposes a means 124 by which a BGP speaker can make use of the processed data in order to 125 assign a "validation state" to each prefix in a received BGP UPDATE 126 message. 128 Note that the complete path attestation against the AS_PATH attribute 129 of a route is outside the scope of this document. 131 Like the DNS, the global RPKI presents only a loosely consistent 132 view, depending on timing, updating, fetching, etc. Thus, one cache 133 or router may have different data about a particular prefix than 134 another cache or router. There is no 'fix' for this, it is the 135 nature of distributed data with distributed caches. 137 Although RPKI provides the context for this draft, it is equally 138 possible to use any other database which is able to map prefixes to 139 their authorized origin ASes. Each distinct database will have its 140 own particular operational and security characteristics; such 141 characteristics are beyond the scope of this document. 143 1.1. Requirements Language 145 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 146 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to 147 be interpreted as described in RFC 2119 [RFC2119] only when they 148 appear in all upper case. They may also appear in lower or mixed 149 case as English words, without any normative meaning. 151 2. Prefix-to-AS Mapping Database 153 The BGP speaker loads validated objects from the cache into local 154 storage. The objects loaded have the content (IP address, prefix 155 length, maximum length, origin AS number). We refer to such a locally 156 stored object as a "Validated ROA Payload" or "VRP". 158 We define several terms in addition to "VRP". Where these terms are 159 used, they are capitalized: 161 o Prefix: (IP address, prefix length), interpreted as is customary 162 (see [RFC4632]). 164 o Route: Data derived from a received BGP UPDATE, as defined in 165 [RFC4271], Section 1.1. The Route includes one Prefix and an 166 AS_PATH; it may include other attributes to characterize the 167 prefix. 169 o VRP Prefix: The Prefix from a VRP. 171 o VRP ASN: The origin AS number from a VRP. 173 o Route Prefix: The Prefix derived from a route. 175 o Route Origin ASN: The origin AS number derived from a Route as 176 follows: 178 * the rightmost AS in the final segment of the AS_PATH attribute 179 in the Route if that segment is of type AS_SEQUENCE, or 181 * the BGP speaker's own AS number if that segment is of type 182 AS_CONFED_SEQUENCE or AS_CONFED_SET or if the AS_PATH is empty, 183 or 185 * the distinguished value "NONE" if the final segment of the 186 AS_PATH attribute is of any other type. 188 o Covered: A Route Prefix is said to be Covered by a VRP when the 189 VRP prefix length is less than or equal to the Route prefix 190 length, and the VRP prefix address and the Route prefix address 191 are identical for all bits specified by the VRP prefix 192 length.(I.e. the Route prefix is either identical to the VRP 193 prefix or a more specific of the VRP prefix.) 195 o Matched: A Route Prefix is said to be Matched by a VRP when the 196 Route Prefix is Covered by that VRP and in addition, the Route 197 prefix length is less than or equal to the VRP maximum length and 198 the Route Origin ASN is equal to the VRP ASN. 200 Given these definitions, any given BGP Route will be found to have 201 one of the following "validation states": 203 o NotFound: No VRP Covers the Route Prefix. 205 o Valid: At least one VRP Matches the Route Prefix. 207 o Invalid: At least one VRP Covers the Route Prefix, but no VRP 208 Matches it. 210 We observe that no VRP can have the value "NONE" as its VRP ASN. Thus 211 a Route whose Origin ASN is "NONE" cannot be Matched by any VRP. 212 Similarly, no valid Route can have an Origin ASN of zero [I-D.ietf- 213 idr-as0]. Thus no Route can be Matched by a VRP whose ASN is zero. 215 When a BGP speaker receives an UPDATE from a neighbor, it SHOULD 216 perform a lookup as described above for each of the Routes in the 217 UPDATE message. The lookup SHOULD also be applied to routes which 218 are redistributed into BGP from another source, such as another 219 protocol or a locally defined static route. An implementation MAY 220 provide configuration options to control which routes the lookup is 221 applied to. The "validation state" of the Route MUST be set to 222 reflect the result of the lookup. The implementation should consider 223 the "validation state" as described in the document as a local 224 property or attribute of the Route. If validation is not performed 225 on a Route, the implementation SHOULD initialize the "validation 226 state" of such a route to "NotFound". 228 Use of the validation state is discussed in Section 3 and Section 5. 229 An implementation MUST NOT exclude a route from the Adj-RIB-In or 230 from consideration in the decision process as a side-effect of its 231 validation state, unless explicitly configured to do so. 233 We observe that a Route can be Matched or Covered by more than one 234 VRP. This procedure does not mandate an order in which VRPs must be 235 visited; however, the "validation state" output is fully determined. 237 2.1. Pseudo-Code 239 The following pseudo-code illustrates the procedure above. In case 240 of ambiguity, the procedure above, rather than the pseudo-code, 241 should be taken as authoritative. 243 result = BGP_PFXV_STATE_NOT_FOUND; 245 //Iterate through all the Covering entries in the local VRP 246 //database, pfx_validate_table. 247 entry = next_lookup_result(pfx_validate_table, route_prefix); 249 while (entry != NULL) { 250 prefix_exists = TRUE; 252 if (route_prefix_length <= entry->max_length) { 253 if (route_origin_as != NONE 254 && entry->origin_as != 0 255 && route_origin_as == entry->origin_as) { 256 result = BGP_PFXV_STATE_VALID; 257 return (result); 258 } 259 } 260 entry = next_lookup_result(pfx_validate_table, input.prefix); 261 } 263 //If one or more VRP entries Covered the route prefix, but 264 //no one Matched, return "Invalid" validation state. 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 5. For more details on operational policy considerations, see 277 [I-D.ietf-sidr-origin-ops]. 279 An implementation MUST also support Four-Octet AS Numbers, [RFC4893]. 281 4. Interaction with Local Cache 283 Each BGP speaker supporting prefix validation as described in this 284 document is expected to communicate with one or more RPKI caches, 285 each of which stores a local copy of the global RPKI database. The 286 protocol mechanisms used to gather and validate these data and 287 present them to BGP speakers are described in [I-D.ietf-sidr-rpki- 288 rtr]. 290 The prefix-to-AS mappings used by the BGP speaker are expected to be 291 updated over time. When a mapping is added or deleted, the 292 implementation MUST re-validate any affected prefixes and run the BGP 293 decision process if needed. An "affected prefix" is any prefix that 294 was matched by a deleted or updated mapping, or could be matched by 295 an added or updated mapping. 297 5. Deployment Considerations 299 Once a Route is selected for validation, it is categorized according 300 the procedure given in Section 2. Subsequently, routing policy as 301 discussed in Section 3 can be used to take action based on the 302 validation state. 304 Policies which could be implemented include filtering routes based on 305 validation state (for example, rejecting all "invalid" routes) or 306 adjusting a route's degree of preference in the selection algorithm 307 based on its validation state. The latter could be accomplished by 308 adjusting the value of such attributes as LOCAL_PREF. Considering 309 invalid routes for BGP decision process is a pure local policy matter 310 and should be done with utmost care. 312 In some cases (particularly when the selection algorithm is 313 influenced by the adjustment of a route property that is not 314 propagated into IBGP) it could be necessary for routing correctness 315 to propagate the validation state to the IBGP peer. This can be 316 accomplished on the sending side by setting a community or extended 317 community based on the validation state, and on the receiving side by 318 matching the (extended) community and setting the validation state. 320 6. Acknowledgments 322 The authors wish to thank Rex Fernando, Hannes Gredler, Mouhcine 323 Guennoun, Russ Housley, Junaid Israr, Miya Kohno, Shin Miyakawa, Taka 324 Mizuguchi, Hussein Mouftah, Keyur Patel, Tomoya Yoshida, Kannan 325 Varadhan, Wes George, Jay Borkenhagen, and Sandra Murphy. The 326 authors are grateful for the feedback from the members of the SIDR 327 working group. 329 Junaid Israr's contribution to this specification was part of his PhD 330 research work and thesis at University of Ottawa. 332 7. IANA Considerations 334 [Note to RFC Editor: This section may be removed on publication] 336 This document has no IANA considerations. 338 8. Security Considerations 340 Although this specification discusses one portion of a system to 341 validate BGP routes, it should be noted that it relies on a database 342 (RPKI or other) to provide validation information. As such, the 343 security properties of that database must be considered in order to 344 determine the security provided by the overall solution. If 345 "invalid" routes are blocked as this specification suggests, the 346 overall system provides a possible denial-of-service vector, for 347 example if an attacker is able to inject or remove one or more 348 records in the validation database, it could lead an otherwise valid 349 route to be marked as invalid. 351 In addition, this system is only able to provide limited protection 352 against a determined attacker -- the attacker need only prepend the 353 "valid" source AS to a forged BGP route announcement in order to 354 defeat the protection provided by this system. 356 This mechanism does not protect against "AS in the middle attacks" or 357 provide any path validation. It only attempts to verify the origin. 358 In general, this system should be thought of more as a protection 359 against misconfiguration than as true "security" in the strong sense. 361 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.", Internet-Draft draft- 389 ietf-idr-as0-06, August 2012. 391 [I-D.ietf-sidr-origin-ops] 392 Bush, R., "RPKI-Based Origin Validation Operation", 393 Internet-Draft draft-ietf-sidr-origin-ops-19, August 2012. 395 [I-D.ietf-sidr-rpki-rtr] 396 Bush, R. and R. Austein, "The RPKI/Router Protocol", 397 Internet-Draft draft-ietf-sidr-rpki-rtr-26, February 2012. 399 [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support 400 Secure Internet Routing", RFC 6480, February 2012. 402 Authors' Addresses 404 Pradosh Mohapatra 405 Cisco Systems 406 170 W. Tasman Drive 407 San Jose, CA 95134 408 USA 410 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 427 Randy Bush 428 Internet Initiative Japan 429 5147 Crystal Springs 430 Bainbridge Island, WA 98110 431 USA 433 Email: randy@psg.com 435 Rob Austein 436 Dragon Research Labs 438 Email: sra@hactrn.net