idnits 2.17.1 draft-pmohapat-sidr-pfx-validate-02.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 (July 27, 2009) is 5388 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: January 28, 2010 Juniper Networks 6 G. Huston, Ed. 7 APNIC 8 July 27, 2009 10 BGP Prefix Origin Validation 11 draft-pmohapat-sidr-pfx-validate-02 13 Status of this Memo 15 This Internet-Draft is submitted to IETF in full conformance with the 16 provisions of BCP 78 and BCP 79. This document may contain material 17 from IETF Documents or IETF Contributions published or made publicly 18 available before November 10, 2008. The person(s) controlling the 19 copyright in some of this material may not have granted the IETF 20 Trust the right to allow modifications of such material outside the 21 IETF Standards Process. Without obtaining an adequate license from 22 the person(s) controlling the copyright in such materials, this 23 document may not be modified outside the IETF Standards Process, and 24 derivative works of it may not be created outside the IETF Standards 25 Process, except to format it for publication as an RFC or to 26 translate it into languages other than English. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF), its areas, and its working groups. Note that 30 other groups may also distribute working documents as Internet- 31 Drafts. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 The list of current Internet-Drafts can be accessed at 39 http://www.ietf.org/ietf/1id-abstracts.txt. 41 The list of Internet-Draft Shadow Directories can be accessed at 42 http://www.ietf.org/shadow.html. 44 This Internet-Draft will expire on January 28, 2010. 46 Copyright Notice 48 Copyright (c) 2009 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents in effect on the date of 53 publication of this document (http://trustee.ietf.org/license-info). 54 Please review these documents carefully, as they describe your rights 55 and restrictions with respect to this document. 57 Abstract 59 A BGP route associates an address prefix with a set of autonomous 60 systems (AS) that identify the interdomain path the prefix has 61 traversed in the form of BGP announcements. This set is represented 62 as the AS_PATH attribute in BGP and starts with the AS that 63 originated the prefix. To help reduce well-known threats against BGP 64 including prefix hijacking and monkey-in-the-middle attacks, one of 65 the security requirements is the ability to validate the origination 66 AS of BGP routes. More specifically, one needs to validate that the 67 AS number claiming to originate an address prefix (as derived from 68 the AS_PATH attribute of the BGP route) is in fact authorized by the 69 prefix holder to do so. This document describes a simple validation 70 mechanism to partially satisfy this requirement. 72 Table of Contents 74 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 75 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5 76 2. Prefix-to-AS Mapping Database . . . . . . . . . . . . . . . . 5 77 3. Changes to the BGP Decision Process . . . . . . . . . . . . . 6 78 3.1. Policy Control . . . . . . . . . . . . . . . . . . . . . . 7 79 4. Route Aggregation . . . . . . . . . . . . . . . . . . . . . . 7 80 5. Interaction with Local Cache . . . . . . . . . . . . . . . . . 7 81 6. Deployment Considerations . . . . . . . . . . . . . . . . . . 8 82 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 8 83 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 84 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 85 10. Security Considerations . . . . . . . . . . . . . . . . . . . 9 86 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 87 11.1. Normative References . . . . . . . . . . . . . . . . . . . 9 88 11.2. Informative References . . . . . . . . . . . . . . . . . . 10 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 91 1. Introduction 93 A BGP route associates an address prefix with a set of autonomous 94 systems (AS) that identify the interdomain path the prefix has 95 traversed in the form of BGP announcements. This set is represented 96 as the AS_PATH attribute in BGP and starts with the AS that 97 originated the prefix. To help reduce well-known threats against BGP 98 including prefix hijacking and monkey-in-the-middle attacks, one of 99 the security requirements is the ability to validate the origination 100 AS of BGP routes. More specifically, one needs to validate that the 101 AS number claiming to originate an address prefix (as derived from 102 the AS_PATH attribute of the BGP route) is in fact authorized by the 103 prefix holder to do so. This document describes a simple validation 104 mechanism to partially satisfy this requirement. 106 The Resource Public Key Infrastructure (RPKI) describes an approach 107 to build a formally verifyable database of IP addresses and AS 108 numbers as resources. The overall architecture of RPKI as defined in 109 [I-D.ietf-sidr-arch] consists of three main components: 111 o A public key infrastructure (PKI) with the necessary certificate 112 objects, 114 o Digitally signed routing objects, 116 o A distributed repository system to hold the objects that would 117 also support periodic retrieval. 119 The RPKI system is based on resource certificates that define 120 extensions to X.509 to represent IP addresses and AS identifiers 121 [RFC3779], thus the name RPKI. Route Origin Authorizations (ROA) 122 [I-D.ietf-sidr-roa-format] are separate digitally signed objects that 123 define associations between ASes and IP address blocks. Finally the 124 repository system is operated in a distributed fashion through the 125 IANA, RIR hierarchy, and ISPs. 127 In order to benefit from the RPKI system, it is envisioned that 128 relying parties either at AS or organization level obtain a local 129 copy of the signed object collection, verify the signatures, and 130 process them. The cache must also be refreshed periodically. The 131 exact access mechanism used to retrieve the local cache is beyond the 132 scope of this document. 134 Individual BGP speakers can utilize the processed data contained in 135 the local cache to validate BGP announcements. The protocol details 136 to retrieve the processed data from the local cache to the BGP 137 speakers is beyond the scope of this document (refer to 138 [I-D.ymbk-rpki-rtr-protocol] for such a mechanism). This document 139 proposes a simple modification to the BGP decision process that makes 140 use of the processed data from signed objects and validates prefix 141 origination of received BGP UPDATE messages. 143 Note that the complete path attestation against the AS_PATH attribute 144 of a route is outside the scope of this document. 146 Although RPKI provides the context for this draft, it is equally 147 possible to use any other database which is able to map prefixes to 148 their authorized origin ASes. Each distinct database will have its 149 own particular operational and security characteristics; such 150 characteristics are beyond the scope of this document. 152 1.1. Requirements Language 154 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 155 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 156 document are to be interpreted as described in RFC 2119 [RFC2119]. 158 2. Prefix-to-AS Mapping Database 160 In loading the validated objects from the local cache to the BGP 161 speaker, the BGP speaker will store this data in the form of a 162 database that maintains the relationship between prefixes and the 163 corresponding set of authorized origin ASes. The primary key for 164 this database is a prefix set represented as (IP prefix)/[min. 165 length, max. length]. The value stored against each prefix set is 166 the set of AS numbers that is assigned or sub-allocated the 167 corresponding IP address block. This database can be implemented as 168 a prefix trie structure. 170 Whenever UPDATEs are received from peers, a BGP speaker is expected 171 to perform a lookup in this database for each of the prefixes in the 172 UPDATE message. To aid with better description, we define terms 173 "UPDATE prefix" and "UPDATE origin AS number" to denote the values 174 derived from the received UPDATE message, and "database prefix set" 175 and "database origin AS number set" to mean the values derived from 176 the database lookup. Note that in the presence of overlapping 177 prefixes, the database lookup against the "UPDATE prefix" may yield 178 multiple matches. 180 The following are the different types of results expected from such a 181 lookup operation: 183 o If the "UPDATE prefix" finds no matching or covering prefixes in 184 the database, the lookup result is returned as "not found". Due 185 to incremental deployment model of the RPKI repository, it is 186 expected that a complete registry of all IP address blocks and 187 their AS associations is not available at a given point of time. 189 o If there are "database prefix sets" that cover the "UPDATE 190 prefix", and one of them has the "UPDATE origin AS number" in the 191 "database origin AS number sets", then the lookup result is 192 returned as "valid". 194 o If there are "database prefix sets" which cover the "UPDATE 195 prefix", but none of them has the "UPDATE origin AS number" in the 196 "database origin AS number set", then the lookup result is 197 returned as "invalid". 199 Depending on the lookup result, we define a property for each "UPDATE 200 prefix", called as the "validity state" of the prefix. It can assume 201 the following values: 203 +-------+-----------------------------+ 204 | Value | Meaning | 205 +-------+-----------------------------+ 206 | 0 | Lookup result = "valid" | 207 | 1 | Lookup result = "not found" | 208 | 2 | Lookup result = "invalid" | 209 +-------+-----------------------------+ 211 Note that all the routes, regardless of their "validity state" will 212 be stored in the local BGP speaker's Adj-RIB-In. 214 3. Changes to the BGP Decision Process 216 If a BGP router supports prefix validation and is configured to do 217 so, the validation check MUST be performed prior to any of the steps 218 defined in the decision process of [RFC4271]. The validation step is 219 stated as follows: 221 When comparing a pair of routes for a BGP destination, if both 222 routes are received via EBGP and have had their "validity state" 223 computed, the route with the lowest "validity state" value is 224 preferred. As prefix validation procedures are not performed on 225 IBGP learnt routes, their "validity state" is not computed and 226 compared. Refer to Section 6 for IBGP considerations. 228 In all other respects, the decision process remains unchanged. 230 3.1. Policy Control 232 It MUST be possible to enable or disable the validation step as 233 defined in Section 3 through configuration. The default SHOULD be 234 for the validation step to be enabled. An implementation MAY also 235 support disabling validation for a subset of prefixes or for routes 236 received from a particular EBGP peer. The validity state of such 237 routes for which validation is disabled MUST be set to "not found". 239 It MUST be possible to exclude routes from the BGP decision process 240 based on their validation state. In particular it is anticipated 241 that it will be desirable to exclude routes from consideration when 242 their validation state is "invalid"; however it may also be desirable 243 to exclude routes whose validation state is "not found" as well. The 244 default SHOULD be to exclude routes whose validation state is 245 "invalid". 247 4. Route Aggregation 249 When an UPDATE message carries AGGREGATOR attribute, the "UPDATE 250 origin AS number" is set to the value encoded in the AGGREGATOR 251 instead of being derived from the AS_PATH attribute. 253 5. Interaction with Local Cache 255 Each BGP speaker supporting prefix validation as described in this 256 document is expected to communicate with one or multiple local caches 257 that store a database of RPKI signed objects. The protocol 258 mechanisms used to fetch the data and store them locally at the BGP 259 speaker is beyond the scope of this document. Irrespective of the 260 protocol, the prefix validation algorithm as outlined in this 261 document is expected to function correctly in the event of failures 262 and other timing conditions that may result in an empty and/or 263 partial prefix-to-AS mapping database. Indeed, if the (in-PoP) cache 264 is not available and the mapping database is empty on the BGP 265 speaker, all the lookups will result in "not found" state and the 266 prefixes will be advertised to rest of the network (unless restricted 267 by policy configuration). Similarly, if BGP UPDATEs arrive at the 268 speaker while the fetch operation from the cache is in progress, some 269 prefix lookups will also result in "not found" state. The 270 implementation is expected to handle these timing conditions and re- 271 validate the prefixes once the fetch operation is complete (in an 272 event-driven manner). 274 6. Deployment Considerations 276 It is critical that IBGP speakers within an AS have a consistent 277 routing view of the BGP destinations and do not make conflicting 278 decisions regarding the BGP best path selection that might cause 279 forwarding loops. Thus, the best practice in BGP deployment does not 280 run any policy on IBGP sessions which could potentially create an 281 inconsistent view. Going by the same rules, the prefix validation 282 procedures MUST NOT be performed on IBGP learnt routes in an AS. As 283 a general principle, prefix validation SHOULD be executed on EBGP 284 boundaries. In some cases, it may be desirable to run the validation 285 on centralized route servers within an AS to offload the computation. 286 Care should be taken to ensure routing consistency in such cases. 288 7. Contributors 290 David Ward dward@cisco.com 291 Cisco Systems 293 Rex Fernando rex@juniper.net 294 Miya Kohno mkohno@juniper.net 295 Juniper Networks 297 Shin Miyakawa miyakawa@nttv6.jp 298 Taka Mizuguchi 299 Tomoya Yoshida 300 NTT Communications 302 Randy Bush randy@psg.com 303 Internet Initiative Japan 305 Rob Austein sra@isc.org 306 ISC 308 Russ Housley housley@vigilsec.com 309 Vigil Security 311 Junaid Israr jisra052@uottawa.ca 312 Mouhcine Guennoun mguennou@uottawa.ca 313 Hussein Mouftah mouftah@site.uottawa.ca 314 University of Ottawa School of Information Technology and 315 Engineering(SITE) 800 King Edward Avenue, Ottawa, Ontario, Canada, 316 K1N 6N5 318 8. Acknowledgements 320 Junaid Israr's contribution to this specification is part of his PhD 321 research work and thesis at University of Ottawa, Canada. 323 9. IANA Considerations 325 10. Security Considerations 327 Although this specification discusses one portion of a system to 328 validate BGP routes, it should be noted that it relies on a database 329 (RPKI or other) to provide validation information. As such, the 330 security properties of that database must be considered in order to 331 determine the security provided by the overall solution. If 332 "invalid" routes are blocked as this specification suggests, the 333 overall system provides a possible denial-of-service vector, for 334 example if an attacker is able to inject one or more spoofed records 335 into the validation database which lead a good route to be declared 336 invalid. In addition, this system is only able to provide limited 337 protection against a determined attacker -- the attacker need only 338 prepend the "valid" source AS to a forged BGP route announcement in 339 order to defeat the protection provided by this system. This 340 mechanism does not protect against "AS in the middle attacks" or 341 provide any path validation. It only attempts to verify the origin. 342 In general, this system should be thought of more as a protection 343 against misconfiguration than as true "security" in the strong sense. 345 11. References 347 11.1. Normative References 349 [I-D.ietf-sidr-arch] 350 Lepinski, M. and S. Kent, "An Infrastructure to Support 351 Secure Internet Routing", draft-ietf-sidr-arch-07 (work in 352 progress), July 2009. 354 [I-D.ietf-sidr-roa-format] 355 Lepinski, M., Kent, S., and D. Kong, "A Profile for Route 356 Origin Authorizations (ROAs)", 357 draft-ietf-sidr-roa-format-05 (work in progress), 358 July 2009. 360 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 361 Requirement Levels", BCP 14, RFC 2119, March 1997. 363 [RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP 364 Addresses and AS Identifiers", RFC 3779, June 2004. 366 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 367 Protocol 4 (BGP-4)", RFC 4271, January 2006. 369 11.2. Informative References 371 [I-D.ymbk-rpki-rtr-protocol] 372 Bush, R. and R. Austein, "The RPKI/Router Protocol", 373 draft-ymbk-rpki-rtr-protocol-04 (work in progress), 374 July 2009. 376 Authors' Addresses 378 Pradosh Mohapatra (editor) 379 Cisco Systems 380 170 W. Tasman Drive 381 San Jose, CA 95134 382 USA 384 Email: pmohapat@cisco.com 386 John Scudder (editor) 387 Juniper Networks 388 1194 N. Mathilda Ave 389 Sunnyvale, CA 94089 390 USA 392 Email: jgs@juniper.net 394 Geoff Huston (editor) 395 Asia Pacific Network Information Center 397 Email: gih@apnic.net