idnits 2.17.1 draft-pmohapat-sidr-pfx-validate-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 353. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 364. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 371. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 377. 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 Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: It is critical that IBGP speakers within an AS have a consistent routing view of the BGP destinations and do not make conflicting decisions regarding the BGP best path selection that might cause forwarding loops. Thus, the best practice in BGP deployment does not run any policy on IBGP sessions which could potentially create an inconsistent view. Going by the same rules, the prefix validation procedures SHOULD not be performed on IBGP learnt routes in an AS. As a general principle, prefix validation SHOULD be executed on EBGP boundaries. In some cases, it may be desirable to run the validation on centralized route servers within an AS to offload the computation. Care should be taken to ensure routing consistency in such cases. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 27, 2008) is 5653 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-03 ** Downref: Normative reference to an Informational draft: draft-ietf-sidr-arch (ref. 'I-D.ietf-sidr-arch') == Outdated reference: A later version (-03) exists of draft-ietf-sidr-bogons-00 -- Possible downref: Normative reference to a draft: ref. 'I-D.ietf-sidr-bogons' == Outdated reference: A later version (-12) exists of draft-ietf-sidr-roa-format-03 Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 8 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 30, 2009 Juniper Networks 6 October 27, 2008 8 BGP Prefix Origin Validation 9 draft-pmohapat-sidr-pfx-validate-00 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on April 30, 2009. 36 Abstract 38 A BGP route associates an address prefix with a set of autonomous 39 systems (AS) that identify the interdomain path the prefix has 40 traversed in the form of BGP announcements. This set is represented 41 as the AS_PATH attribute in BGP and starts with the AS that 42 originated the prefix. To help reduce well-known threats against BGP 43 including prefix hijacking and monkey-in-the-middle attacks, one of 44 the security requirements is the ability to validate the origination 45 AS of BGP routes. More specifically, one needs to validate that the 46 AS number claiming to originate an address prefix (as derived from 47 the AS_PATH attribute of the BGP route) is in fact authorized. This 48 document describes a simple validation mechanism to partially satisfy 49 this requirement. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 1.1. Requirements Language . . . . . . . . . . . . . . . . . . . 4 55 2. Prefix-to-AS Mapping Database . . . . . . . . . . . . . . . . . 4 56 3. Changes to the BGP Decision Process . . . . . . . . . . . . . . 5 57 3.1. Policy Control . . . . . . . . . . . . . . . . . . . . . . 6 58 4. Route Aggregation . . . . . . . . . . . . . . . . . . . . . . . 6 59 5. Deployment Considerations . . . . . . . . . . . . . . . . . . . 6 60 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 6 61 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 62 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 63 9. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 64 10. Normative References . . . . . . . . . . . . . . . . . . . . . 8 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 66 Intellectual Property and Copyright Statements . . . . . . . . . . 9 68 1. Introduction 70 A BGP route associates an address prefix with a set of autonomous 71 systems (AS) that identify the interdomain path the prefix has 72 traversed in the form of BGP announcements. This set is represented 73 as the AS_PATH attribute in BGP and starts with the AS that 74 originated the prefix. To help reduce well-known threats against BGP 75 including prefix hijacking and monkey-in-the-middle attacks, one of 76 the security requirements is the ability to validate the origination 77 AS of BGP routes. More specifically, one needs to validate that the 78 AS number claiming to originate an address prefix (as derived from 79 the AS_PATH attribute of the BGP route) is in fact authorized. This 80 document describes a simple validation mechanism to partially satisfy 81 this requirement. 83 The Resource Public Key Infrastructure (RPKI) describes an approach 84 to build a formally verifyable database of IP addresses and AS 85 numbers as resources. The overall architecture of RPKI as defined in 86 [I-D.ietf-sidr-arch] consists of three main components: 88 o A public key infrastructure (PKI) with the necessary certificate 89 objects, 91 o Digitally signed routing objects, 93 o A distributed repository system to hold the objects that would 94 also support periodic retrieval 96 The RPKI system is based on resource certificates that define 97 extensions to X.509 to represent IP addresses and AS identifiers 98 [RFC3779], thus the name RPKI. Route Origin Authorizations (ROA) 99 [I-D.ietf-sidr-roa-format] and possibly Bogon Origin Attestations 100 (BOA) [I-D.ietf-sidr-bogons] are separate digitally signed objects 101 that define positive and negative associations between ASes and IP 102 address blocks. Finally the repository system is operated in a 103 distributed fashion through the IANA, RIR hierarchy, and ISPs. 105 In order to benefit from the RPKI system, it is envisioned that 106 relying parties either at AS or organization level obtain a local 107 copy of the signed object collection, verify the signatures, and 108 process them. The cache must also be refreshed periodically. The 109 exact access mechanism used to retrieve the local cache is beyond the 110 scope of this document. 112 Once the cache is made local, individual BGP speakers can utilize the 113 processed data to validate BGP announcements. Again, the 114 mechanism(s) to have the data available at the BGP routers is not 115 defined in this document. This document proposes a simple 116 modification to the BGP decision process that makes use of the 117 processed data from signed objects and validates prefix origination 118 of received BGP UPDATE messages. 120 Note that the complete path attestation against the AS_PATH attribute 121 of a route is outside the scope of this document. 123 Although RPKI provides the context for this draft, it is equally 124 possible to use any other database which is able to map prefixes to 125 their authorized origin ASes. Each distinct database will have its 126 own particular operational and security characteristics; such 127 characteristics are beyond the scope of this document. 129 1.1. Requirements Language 131 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 132 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 133 document are to be interpreted as described in RFC 2119 [RFC2119]. 135 2. Prefix-to-AS Mapping Database 137 The resource certificates and other signed objects (e.g. ROAs) as 138 received from the RPKI repository and stored in the local cache are 139 not in a suitable format to be matched against the prefixes received. 140 Moreover, further processing of the objects is necessary -- e.g. ROA 141 validation is required, which involves checking against the 142 corresponding EE certificate and so on up to configured trust 143 anchors, presumably for the IANA and/or other registries. But a 144 validated and normalized database can be created on the router for 145 efficient lookup purposes. The primary key for this database is a 146 prefix set represented as (IP prefix)/[min. length, max. length]. 147 The value stored against each prefix set is the set of AS numbers 148 that is assigned or sub-allocated the corresponding IP address block. 149 This database can be implemented as a prefix trie structure. 151 Whenever UPDATEs are received from peers, a BGP speaker is expected 152 to perform a lookup in this database for each of the prefixes in the 153 UPDATE message. To aid with better description, we define terms 154 "UPDATE prefix" and "UPDATE origin AS number" to mean the values 155 derived from the received UPDATE message, and "database prefix set" 156 and "database origin AS number" to mean the values derived from the 157 database lookup. The following are the different types of results 158 expected from such a lookup operation: 160 o If the prefix length of the "UPDATE prefix" is within the range of 161 the most specific "database prefix set" found during the lookup, 162 an exact match is declared and the "UPDATE origin AS number" is 163 compared against the "database origin AS number set". Depending 164 on whether the UPDATE AS number is a member of the database AS set 165 for that prefix, the lookup result should be returned as "valid" 166 or "invalid". 168 o Due to the incremental deployment model of the RPKI repository, 169 the implementation should not expect that a complete registry of 170 all IP address blocks and their AS associations is available at a 171 given point of time. Thus, it is possible that a prefix set match 172 is not found in the database. In this case, the lookup result 173 should simply be "not found". 175 o It is also possible that the prefix length of the "UPDATE prefix" 176 is greater than the range of the most specific "database prefix 177 set" found during the lookup. According to 178 [I-D.ietf-sidr-roa-format], an AS is required to originate 179 prefixes only in the range specified in the corresponding ROA 180 object. Thus, if such a prefix match occurs and the "UPDATE 181 origin AS number" is the same as the "database origin AS number", 182 the lookup result is declared as "invalid". However, if the AS 183 numbers are not the same, the lookup result is declared as "not 184 found" since it may mean that the more specific address block has 185 been sub-allocated to another party and the corresponding ROA 186 object is not yet present in the database. 188 Depending on the lookup result, we define a property for each "UPDATE 189 prefix", called as the "validity state" of the prefix. It can assume 190 the following values: 192 +-------+-----------------------------+ 193 | Value | Meaning | 194 +-------+-----------------------------+ 195 | 0 | Lookup result = "valid" | 196 | 1 | Lookup result = "not found" | 197 | 2 | Lookup result = "invalid" | 198 +-------+-----------------------------+ 200 Note that all the routes, regardless of their "validity state" will 201 be stored in the local BGP speaker's Adj-RIB-In. 203 3. Changes to the BGP Decision Process 205 If a BGP router supports prefix validation and is configured to do 206 so, the validation check MUST be performed prior to any of the steps 207 defined in the decision process of [RFC4271]. The validation step is 208 stated as follows: 210 When comparing routes for a BGP destination, if both routes have 211 had their "validity state" computed, the route with the lowest 212 "validity state" value is preferred. 214 In all other respects, the decision process remains unchanged. 216 3.1. Policy Control 218 It MUST be possible to enable or disable the validation step as 219 defined in Section 3 through configuration. The default SHOULD be 220 for the validation step to be enabled. 222 It MUST be possible to exclude routes from the BGP decision process 223 based on their validation state. In particular it is anticipated 224 that it will be desirable to exclude routes from consideration when 225 their validation state is "invalid"; however it may also be desirable 226 to exclude routes whose validation state is "not found" as well. 228 4. Route Aggregation 230 When an UPDATE message carries AGGREGATOR attribute, the "UPDATE 231 origin AS number" is set to the value encoded in the AGGREGATOR 232 instead of being derived from the AS_PATH attribute. 234 5. Deployment Considerations 236 It is critical that IBGP speakers within an AS have a consistent 237 routing view of the BGP destinations and do not make conflicting 238 decisions regarding the BGP best path selection that might cause 239 forwarding loops. Thus, the best practice in BGP deployment does not 240 run any policy on IBGP sessions which could potentially create an 241 inconsistent view. Going by the same rules, the prefix validation 242 procedures SHOULD not be performed on IBGP learnt routes in an AS. 243 As a general principle, prefix validation SHOULD be executed on EBGP 244 boundaries. In some cases, it may be desirable to run the validation 245 on centralized route servers within an AS to offload the computation. 246 Care should be taken to ensure routing consistency in such cases. 248 6. Contributors 250 David Ward dward@cisco.com 251 Cisco Systems 252 Rex Fernando rex@juniper.net 253 Robert Raszuk raszuk@juniper.net 254 Miya Kohno mkohno@juniper.net 255 Juniper Networks 257 Shin Miyakawa miyakawa@nttv6.jp 258 Taka Mizuguchi taka@nttv6.jp 259 Tomoya Yoshida yoshida@nttv6.jp 260 NTT Communications 262 Randy Bush randy@psg.com 263 Internet Initiative Japan 265 Rob Austein sra@isc.org 266 ISC 268 Russ Housley housley@vigilsec.com 269 Vigil Security 271 7. Acknowledgements 273 8. IANA Considerations 275 9. Security Considerations 277 Although this specification discusses one portion of a system to 278 validate BGP routes, it should be noted that it relies on a database 279 (RPKI or other) to provide validation information. As such, the 280 security properties of that database must be considered in order to 281 determine the security provided by the overall solution. If 282 "invalid" routes are blocked as this specification suggests, the 283 overall system provides a possible denial-of-service vector, for 284 example if an attacker is able to inject one or more spoofed records 285 into the validation database which lead a good route to be declared 286 invalid. In addition, this system is only able to provide limited 287 protection against a determined attacker -- the attacker need only 288 prepend the "valid" source AS to a forged BGP route announcement in 289 order to defeat the protection provided by this system. This 290 mechanism does not protect against "AS in the middle attacks" or 291 provide any path validation. It only attempts to verify the origin. 292 In general, this system should be thought of more as a protection 293 against misconfiguration than as true "security" in the strong sense. 295 10. Normative References 297 [I-D.ietf-sidr-arch] 298 Lepinski, M., Kent, S., and R. Barnes, "An Infrastructure 299 to Support Secure Internet Routing", 300 draft-ietf-sidr-arch-03 (work in progress), February 2008. 302 [I-D.ietf-sidr-bogons] 303 Huston, G., Manderson, T., and G. Michaelson, "A Profile 304 for Bogon Origin Attestations (BOAs)", 305 draft-ietf-sidr-bogons-00 (work in progress), August 2008. 307 [I-D.ietf-sidr-roa-format] 308 Kent, S., "A Profile for Route Origin Authorizations 309 (ROAs)", draft-ietf-sidr-roa-format-03 (work in progress), 310 July 2008. 312 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 313 Requirement Levels", BCP 14, RFC 2119, March 1997. 315 [RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP 316 Addresses and AS Identifiers", RFC 3779, June 2004. 318 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 319 Protocol 4 (BGP-4)", RFC 4271, January 2006. 321 Authors' Addresses 323 Pradosh Mohapatra (editor) 324 Cisco Systems 325 170 W. Tasman Drive 326 San Jose, CA 95134 327 USA 329 Email: pmohapat@cisco.com 331 John Scudder (editor) 332 Juniper Networks 333 1194 N. Mathilda Ave 334 Sunnyvale, CA 94089 335 USA 337 Email: jgs@juniper.net 339 Full Copyright Statement 341 Copyright (C) The IETF Trust (2008). 343 This document is subject to the rights, licenses and restrictions 344 contained in BCP 78, and except as set forth therein, the authors 345 retain all their rights. 347 This document and the information contained herein are provided on an 348 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 349 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 350 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 351 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 352 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 353 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 355 Intellectual Property 357 The IETF takes no position regarding the validity or scope of any 358 Intellectual Property Rights or other rights that might be claimed to 359 pertain to the implementation or use of the technology described in 360 this document or the extent to which any license under such rights 361 might or might not be available; nor does it represent that it has 362 made any independent effort to identify any such rights. Information 363 on the procedures with respect to rights in RFC documents can be 364 found in BCP 78 and BCP 79. 366 Copies of IPR disclosures made to the IETF Secretariat and any 367 assurances of licenses to be made available, or the result of an 368 attempt made to obtain a general license or permission for the use of 369 such proprietary rights by implementers or users of this 370 specification can be obtained from the IETF on-line IPR repository at 371 http://www.ietf.org/ipr. 373 The IETF invites any interested party to bring to its attention any 374 copyrights, patents or patent applications, or other proprietary 375 rights that may cover technology that may be required to implement 376 this standard. Please address the information to the IETF at 377 ietf-ipr@ietf.org.