idnits 2.17.1 draft-pmohapat-sidr-pfx-validate-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, 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 26, 2009) is 5294 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 (-13) exists of draft-ietf-sidr-arch-07 ** Downref: Normative reference to an Informational draft: draft-ietf-sidr-arch (ref. 'I-D.ietf-sidr-arch') == Outdated reference: A later version (-12) exists of draft-ietf-sidr-roa-format-05 == Outdated reference: A later version (-06) exists of draft-ymbk-rpki-rtr-protocol-04 Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). 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: April 29, 2010 Juniper Networks 6 D. Ward, Ed. 7 Cisco Systems 8 R. Bush, Ed. 9 Internet Initiative Japan, Inc. 10 R. Austein, Ed. 11 Internet Systems Consortium 12 October 26, 2009 14 BGP Prefix Origin Validation 15 draft-pmohapat-sidr-pfx-validate-03 17 Status of this Memo 19 This Internet-Draft is submitted to IETF in full conformance with the 20 provisions of BCP 78 and BCP 79. This document may contain material 21 from IETF Documents or IETF Contributions published or made publicly 22 available before November 10, 2008. The person(s) controlling the 23 copyright in some of this material may not have granted the IETF 24 Trust the right to allow modifications of such material outside the 25 IETF Standards Process. Without obtaining an adequate license from 26 the person(s) controlling the copyright in such materials, this 27 document may not be modified outside the IETF Standards Process, and 28 derivative works of it may not be created outside the IETF Standards 29 Process, except to format it for publication as an RFC or to 30 translate it into languages other than English. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF), its areas, and its working groups. Note that 34 other groups may also distribute working documents as Internet- 35 Drafts. 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 The list of current Internet-Drafts can be accessed at 43 http://www.ietf.org/ietf/1id-abstracts.txt. 45 The list of Internet-Draft Shadow Directories can be accessed at 46 http://www.ietf.org/shadow.html. 48 This Internet-Draft will expire on April 29, 2010. 50 Copyright Notice 52 Copyright (c) 2009 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents in effect on the date of 57 publication of this document (http://trustee.ietf.org/license-info). 58 Please review these documents carefully, as they describe your rights 59 and restrictions with respect to this document. 61 Abstract 63 A BGP route associates an address prefix with a set of autonomous 64 systems (AS) that identify the interdomain path the prefix has 65 traversed in the form of BGP announcements. This set is represented 66 as the AS_PATH attribute in BGP and starts with the AS that 67 originated the prefix. To help reduce well-known threats against BGP 68 including prefix hijacking and monkey-in-the-middle attacks, one of 69 the security requirements is the ability to validate the origination 70 AS of BGP routes. More specifically, one needs to validate that the 71 AS number claiming to originate an address prefix (as derived from 72 the AS_PATH attribute of the BGP route) is in fact authorized by the 73 prefix holder to do so. This document describes a simple validation 74 mechanism to partially satisfy this requirement. 76 Table of Contents 78 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 79 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5 80 2. Prefix-to-AS Mapping Database . . . . . . . . . . . . . . . . 5 81 3. Changes to the BGP Decision Process . . . . . . . . . . . . . 6 82 3.1. Policy Control . . . . . . . . . . . . . . . . . . . . . . 7 83 4. Route Aggregation . . . . . . . . . . . . . . . . . . . . . . 7 84 5. Interaction with Local Cache . . . . . . . . . . . . . . . . . 7 85 6. Deployment Considerations . . . . . . . . . . . . . . . . . . 8 86 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 8 87 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 88 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 89 10. Security Considerations . . . . . . . . . . . . . . . . . . . 9 90 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 91 11.1. Normative References . . . . . . . . . . . . . . . . . . . 9 92 11.2. Informative References . . . . . . . . . . . . . . . . . . 10 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 95 1. Introduction 97 A BGP route associates an address prefix with a set of autonomous 98 systems (AS) that identify the interdomain path the prefix has 99 traversed in the form of BGP announcements. This set is represented 100 as the AS_PATH attribute in BGP and starts with the AS that 101 originated the prefix. To help reduce well-known threats against BGP 102 including prefix hijacking and monkey-in-the-middle attacks, one of 103 the security requirements is the ability to validate the origination 104 AS of BGP routes. More specifically, one needs to validate that the 105 AS number claiming to originate an address prefix (as derived from 106 the AS_PATH attribute of the BGP route) is in fact authorized by the 107 prefix holder to do so. This document describes a simple validation 108 mechanism to partially satisfy this requirement. 110 The Resource Public Key Infrastructure (RPKI) describes an approach 111 to build a formally verifyable database of IP addresses and AS 112 numbers as resources. The overall architecture of RPKI as defined in 113 [I-D.ietf-sidr-arch] consists of three main components: 115 o A public key infrastructure (PKI) with the necessary certificate 116 objects, 118 o Digitally signed routing objects, 120 o A distributed repository system to hold the objects that would 121 also support periodic retrieval. 123 The RPKI system is based on resource certificates that define 124 extensions to X.509 to represent IP addresses and AS identifiers 125 [RFC3779], thus the name RPKI. Route Origin Authorizations (ROA) 126 [I-D.ietf-sidr-roa-format] are separate digitally signed objects that 127 define associations between ASes and IP address blocks. Finally the 128 repository system is operated in a distributed fashion through the 129 IANA, RIR hierarchy, and ISPs. 131 In order to benefit from the RPKI system, it is envisioned that 132 relying parties either at AS or organization level obtain a local 133 copy of the signed object collection, verify the signatures, and 134 process them. The cache must also be refreshed periodically. The 135 exact access mechanism used to retrieve the local cache is beyond the 136 scope of this document. 138 Individual BGP speakers can utilize the processed data contained in 139 the local cache to validate BGP announcements. The protocol details 140 to retrieve the processed data from the local cache to the BGP 141 speakers is beyond the scope of this document (refer to 142 [I-D.ymbk-rpki-rtr-protocol] for such a mechanism). This document 143 proposes a simple modification to the BGP decision process that makes 144 use of the processed data from signed objects and validates prefix 145 origination of received BGP UPDATE messages. 147 Note that the complete path attestation against the AS_PATH attribute 148 of a route is outside the scope of this document. 150 Although RPKI provides the context for this draft, it is equally 151 possible to use any other database which is able to map prefixes to 152 their authorized origin ASes. Each distinct database will have its 153 own particular operational and security characteristics; such 154 characteristics are beyond the scope of this document. 156 1.1. Requirements Language 158 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 159 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 160 document are to be interpreted as described in RFC 2119 [RFC2119]. 162 2. Prefix-to-AS Mapping Database 164 In loading the validated objects from the local cache to the BGP 165 speaker, the BGP speaker will store this data in the form of a 166 database that maintains the relationship between prefixes and the 167 corresponding set of authorized origin ASes. The primary key for 168 this database is a prefix set represented as (IP prefix)/[min. 169 length, max. length]. The value stored against each prefix set is 170 the set of AS numbers that is assigned or sub-allocated the 171 corresponding IP address block. This database can be implemented as 172 a prefix trie structure. 174 Whenever UPDATEs are received from peers, a BGP speaker is expected 175 to perform a lookup in this database for each of the prefixes in the 176 UPDATE message. To aid with better description, we define terms 177 "UPDATE prefix" and "UPDATE origin AS number" to denote the values 178 derived from the received UPDATE message, and "database prefix set" 179 and "database origin AS number set" to mean the values derived from 180 the database lookup. Note that in the presence of overlapping 181 prefixes, the database lookup against the "UPDATE prefix" may yield 182 multiple matches. 184 The following are the different types of results expected from such a 185 lookup operation: 187 o If the "UPDATE prefix" finds no matching or covering prefixes in 188 the database (i.e. the "UPDATE prefix" is not a sub-block of any 189 of the database prefixes), the lookup result is returned as "not 190 found". Due to incremental deployment model of the RPKI 191 repository, it is expected that a complete registry of all IP 192 address blocks and their AS associations is not available at a 193 given point of time. 195 o If there are "database prefix sets" that cover the "UPDATE 196 prefix", and one of them has the "UPDATE origin AS number" in the 197 "database origin AS number sets", then the lookup result is 198 returned as "valid". 200 o If there are "database prefix sets" which cover the "UPDATE 201 prefix", but none of them has the "UPDATE origin AS number" in the 202 "database origin AS number set", then the lookup result is 203 returned as "invalid". 205 Depending on the lookup result, we define a property for each "UPDATE 206 prefix", called as the "validity state" of the prefix. It can assume 207 the following values: 209 +-------+-----------------------------+ 210 | Value | Meaning | 211 +-------+-----------------------------+ 212 | 0 | Lookup result = "valid" | 213 | 1 | Lookup result = "not found" | 214 | 2 | Lookup result = "invalid" | 215 +-------+-----------------------------+ 217 Note that all the routes, regardless of their "validity state" will 218 be stored in the local BGP speaker's Adj-RIB-In. 220 3. Changes to the BGP Decision Process 222 If a BGP router supports prefix validation and is configured to do 223 so, the validation check MUST be performed prior to any of the steps 224 defined in the decision process of [RFC4271]. The validation step is 225 stated as follows: 227 When comparing a pair of routes for a BGP destination, if both 228 routes are received via EBGP and have had their "validity state" 229 computed, the route with the lowest "validity state" value is 230 preferred. As prefix validation procedures are not performed on 231 IBGP learnt routes, their "validity state" is not computed and 232 compared. Refer to Section 6 for IBGP considerations. 234 In all other respects, the decision process remains unchanged. 236 3.1. Policy Control 238 It MUST be possible to enable or disable the validation step as 239 defined in Section 3 through configuration. The default SHOULD be 240 for the validation step to be enabled. An implementation MAY also 241 support disabling validation for a subset of prefixes or for routes 242 received from a particular EBGP peer. The validity state of such 243 routes for which validation is disabled MUST be set to "not found". 245 It MUST be possible to exclude routes from the BGP decision process 246 based on their validation state. In particular it is anticipated 247 that it will be desirable to exclude routes from consideration when 248 their validation state is "invalid"; however it may also be desirable 249 to exclude routes whose validation state is "not found" as well. The 250 default SHOULD be to exclude routes whose validation state is 251 "invalid". 253 4. Route Aggregation 255 When an UPDATE message carries AGGREGATOR attribute, the "UPDATE 256 origin AS number" is set to the value encoded in the AGGREGATOR 257 instead of being derived from the AS_PATH attribute. 259 5. Interaction with Local Cache 261 Each BGP speaker supporting prefix validation as described in this 262 document is expected to communicate with one or multiple local caches 263 that store a database of RPKI signed objects. The protocol 264 mechanisms used to fetch the data and store them locally at the BGP 265 speaker is beyond the scope of this document. One such protocol is 266 defined in [I-D.ymbk-rpki-rtr-protocol]. Irrespective of the 267 protocol, the prefix validation algorithm as outlined in this 268 document is expected to function correctly in the event of failures 269 and other timing conditions that may result in an empty and/or 270 partial prefix-to-AS mapping database. Indeed, if the (in-PoP) cache 271 is not available and the mapping database is empty on the BGP 272 speaker, all the lookups will result in "not found" state and the 273 prefixes will be advertised to rest of the network (unless restricted 274 by policy configuration). Similarly, if BGP UPDATEs arrive at the 275 speaker while the fetch operation from the cache is in progress, some 276 prefix lookups will also result in "not found" state. The 277 implementation is expected to handle these timing conditions and re- 278 validate the prefixes once the fetch operation is complete (in an 279 event-driven manner). 281 6. Deployment Considerations 283 It is critical that IBGP speakers within an AS have a consistent 284 routing view of the BGP destinations and do not make conflicting 285 decisions regarding the BGP best path selection that might cause 286 forwarding loops. Thus, the best practice in BGP deployment does not 287 run any policy on IBGP sessions which could potentially create an 288 inconsistent view. Going by the same rules, the prefix validation 289 procedures MUST NOT be performed on IBGP learnt routes in an AS. As 290 a general principle, prefix validation SHOULD be executed on EBGP 291 boundaries. An implementation MAY (based on local configuration) 292 provide support to carry the prefix validation result in standard 293 communities or extended communities while advertising to IBGP for 294 monitoring and debug purposes. In some cases, it may be desirable to 295 run the validation on centralized route servers within an AS to 296 offload the computation. Care should be taken to ensure routing 297 consistency in such cases. 299 During gradual transition phase of an autonomous system to support 300 prefix validation, if some edge routers support validation and some 301 don't, it is possible to get into a situation where an invalid path 302 is preferred over a valid path. This happens when an edge router 303 does not support prefix validation and receives an invalid path from 304 its EBGP peer and transparently announces that to the IBGP mesh. The 305 same situation can also arise in an environment where all edge 306 routers are migrated to support prefix validation due to asynchronous 307 nature of the RPKI cache updates. For example, the correct validity 308 state of a prefix may have been updated by the cache on one edge 309 router, but not another. However, this is a transient phenomenon and 310 self-correcting. 312 7. Contributors 314 Rex Fernando rex@juniper.net 315 Miya Kohno mkohno@juniper.net 316 Juniper Networks 318 Shin Miyakawa miyakawa@nttv6.jp 319 Taka Mizuguchi 320 Tomoya Yoshida 321 NTT Communications 323 Russ Housley housley@vigilsec.com 324 Vigil Security 325 Junaid Israr jisra052@uottawa.ca 326 Mouhcine Guennoun mguennou@uottawa.ca 327 Hussein Mouftah mouftah@site.uottawa.ca 328 University of Ottawa School of Information Technology and 329 Engineering(SITE) 800 King Edward Avenue, Ottawa, Ontario, Canada, 330 K1N 6N5 332 8. Acknowledgements 334 Junaid Israr's contribution to this specification is part of his PhD 335 research work and thesis at University of Ottawa, Canada. 337 9. IANA Considerations 339 10. 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 one or more spoofed records 349 into the validation database which lead a good route to be declared 350 invalid. In addition, this system is only able to provide limited 351 protection against a determined attacker -- the attacker need only 352 prepend the "valid" source AS to a forged BGP route announcement in 353 order to defeat the protection provided by this system. This 354 mechanism does not protect against "AS in the middle attacks" or 355 provide any path validation. It only attempts to verify the origin. 356 In general, this system should be thought of more as a protection 357 against misconfiguration than as true "security" in the strong sense. 359 11. References 361 11.1. Normative References 363 [I-D.ietf-sidr-arch] 364 Lepinski, M. and S. Kent, "An Infrastructure to Support 365 Secure Internet Routing", draft-ietf-sidr-arch-07 (work in 366 progress), July 2009. 368 [I-D.ietf-sidr-roa-format] 369 Lepinski, M., Kent, S., and D. Kong, "A Profile for Route 370 Origin Authorizations (ROAs)", 371 draft-ietf-sidr-roa-format-05 (work in progress), 372 July 2009. 374 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 375 Requirement Levels", BCP 14, RFC 2119, March 1997. 377 [RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP 378 Addresses and AS Identifiers", RFC 3779, June 2004. 380 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 381 Protocol 4 (BGP-4)", RFC 4271, January 2006. 383 11.2. Informative References 385 [I-D.ymbk-rpki-rtr-protocol] 386 Bush, R. and R. Austein, "The RPKI/Router Protocol", 387 draft-ymbk-rpki-rtr-protocol-04 (work in progress), 388 July 2009. 390 Authors' Addresses 392 Pradosh Mohapatra (editor) 393 Cisco Systems 394 170 W. Tasman Drive 395 San Jose, CA 95134 396 USA 398 Email: pmohapat@cisco.com 400 John Scudder (editor) 401 Juniper Networks 402 1194 N. Mathilda Ave 403 Sunnyvale, CA 94089 404 USA 406 Email: jgs@juniper.net 407 David Ward (editor) 408 Cisco Systems 409 170 W. Tasman Drive 410 San Jose, CA 95134 411 USA 413 Email: wardd@cisco.com 415 Randy Bush (editor) 416 Internet Initiative Japan, Inc. 417 5147 Crystral Springs 418 Bainbridge Island, Washington 98110 419 USA 421 Email: randy@psg.com 423 Rob Austein (editor) 424 Internet Systems Consortium 425 950 Charter Street 426 Redwood City, CA 94063 427 USA 429 Email: sra@isc.org