Network Working Group P. Mohapatra, Ed. Internet-Draft Cisco Systems Intended status: Standards Track J. Scudder, Ed. Expires: April 30, 2009 Juniper Networks October 27, 2008 BGP Prefix Origin Validation draft-pmohapat-sidr-pfx-validate-00 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on April 30, 2009. Abstract A BGP route associates an address prefix with a set of autonomous systems (AS) that identify the interdomain path the prefix has traversed in the form of BGP announcements. This set is represented as the AS_PATH attribute in BGP and starts with the AS that originated the prefix. To help reduce well-known threats against BGP including prefix hijacking and monkey-in-the-middle attacks, one of the security requirements is the ability to validate the origination AS of BGP routes. More specifically, one needs to validate that the AS number claiming to originate an address prefix (as derived from the AS_PATH attribute of the BGP route) is in fact authorized. This document describes a simple validation mechanism to partially satisfy Mohapatra & Scudder Expires April 30, 2009 [Page 1] Internet-Draft BGP Prefix Origin Validation October 2008 this requirement. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . . 4 2. Prefix-to-AS Mapping Database . . . . . . . . . . . . . . . . . 4 3. Changes to the BGP Decision Process . . . . . . . . . . . . . . 5 3.1. Policy Control . . . . . . . . . . . . . . . . . . . . . . 6 4. Route Aggregation . . . . . . . . . . . . . . . . . . . . . . . 6 5. Deployment Considerations . . . . . . . . . . . . . . . . . . . 6 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 6 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 9. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 10. Normative References . . . . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 Intellectual Property and Copyright Statements . . . . . . . . . . 9 Mohapatra & Scudder Expires April 30, 2009 [Page 2] Internet-Draft BGP Prefix Origin Validation October 2008 1. Introduction A BGP route associates an address prefix with a set of autonomous systems (AS) that identify the interdomain path the prefix has traversed in the form of BGP announcements. This set is represented as the AS_PATH attribute in BGP and starts with the AS that originated the prefix. To help reduce well-known threats against BGP including prefix hijacking and monkey-in-the-middle attacks, one of the security requirements is the ability to validate the origination AS of BGP routes. More specifically, one needs to validate that the AS number claiming to originate an address prefix (as derived from the AS_PATH attribute of the BGP route) is in fact authorized. This document describes a simple validation mechanism to partially satisfy this requirement. The Resource Public Key Infrastructure (RPKI) describes an approach to build a formally verifyable database of IP addresses and AS numbers as resources. The overall architecture of RPKI as defined in [I-D.ietf-sidr-arch] consists of three main components: o A public key infrastructure (PKI) with the necessary certificate objects, o Digitally signed routing objects, o A distributed repository system to hold the objects that would also support periodic retrieval The RPKI system is based on resource certificates that define extensions to X.509 to represent IP addresses and AS identifiers [RFC3779], thus the name RPKI. Route Origin Authorizations (ROA) [I-D.ietf-sidr-roa-format] and possibly Bogon Origin Attestations (BOA) [I-D.ietf-sidr-bogons] are separate digitally signed objects that define positive and negative associations between ASes and IP address blocks. Finally the repository system is operated in a distributed fashion through the IANA, RIR hierarchy, and ISPs. In order to benefit from the RPKI system, it is envisioned that relying parties either at AS or organization level obtain a local copy of the signed object collection, verify the signatures, and process them. The cache must also be refreshed periodically. The exact access mechanism used to retrieve the local cache is beyond the scope of this document. Once the cache is made local, individual BGP speakers can utilize the processed data to validate BGP announcements. Again, the mechanism(s) to have the data available at the BGP routers is not defined in this document. This document proposes a simple Mohapatra & Scudder Expires April 30, 2009 [Page 3] Internet-Draft BGP Prefix Origin Validation October 2008 modification to the BGP decision process that makes use of the processed data from signed objects and validates prefix origination of received BGP UPDATE messages. Note that the complete path attestation against the AS_PATH attribute of a route is outside the scope of this document. Although RPKI provides the context for this draft, it is equally possible to use any other database which is able to map prefixes to their authorized origin ASes. Each distinct database will have its own particular operational and security characteristics; such characteristics are beyond the scope of this document. 1.1. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 2. Prefix-to-AS Mapping Database The resource certificates and other signed objects (e.g. ROAs) as received from the RPKI repository and stored in the local cache are not in a suitable format to be matched against the prefixes received. Moreover, further processing of the objects is necessary -- e.g. ROA validation is required, which involves checking against the corresponding EE certificate and so on up to configured trust anchors, presumably for the IANA and/or other registries. But a validated and normalized database can be created on the router for efficient lookup purposes. The primary key for this database is a prefix set represented as (IP prefix)/[min. length, max. length]. The value stored against each prefix set is the set of AS numbers that is assigned or sub-allocated the corresponding IP address block. This database can be implemented as a prefix trie structure. Whenever UPDATEs are received from peers, a BGP speaker is expected to perform a lookup in this database for each of the prefixes in the UPDATE message. To aid with better description, we define terms "UPDATE prefix" and "UPDATE origin AS number" to mean the values derived from the received UPDATE message, and "database prefix set" and "database origin AS number" to mean the values derived from the database lookup. The following are the different types of results expected from such a lookup operation: o If the prefix length of the "UPDATE prefix" is within the range of the most specific "database prefix set" found during the lookup, an exact match is declared and the "UPDATE origin AS number" is Mohapatra & Scudder Expires April 30, 2009 [Page 4] Internet-Draft BGP Prefix Origin Validation October 2008 compared against the "database origin AS number set". Depending on whether the UPDATE AS number is a member of the database AS set for that prefix, the lookup result should be returned as "valid" or "invalid". o Due to the incremental deployment model of the RPKI repository, the implementation should not expect that a complete registry of all IP address blocks and their AS associations is available at a given point of time. Thus, it is possible that a prefix set match is not found in the database. In this case, the lookup result should simply be "not found". o It is also possible that the prefix length of the "UPDATE prefix" is greater than the range of the most specific "database prefix set" found during the lookup. According to [I-D.ietf-sidr-roa-format], an AS is required to originate prefixes only in the range specified in the corresponding ROA object. Thus, if such a prefix match occurs and the "UPDATE origin AS number" is the same as the "database origin AS number", the lookup result is declared as "invalid". However, if the AS numbers are not the same, the lookup result is declared as "not found" since it may mean that the more specific address block has been sub-allocated to another party and the corresponding ROA object is not yet present in the database. Depending on the lookup result, we define a property for each "UPDATE prefix", called as the "validity state" of the prefix. It can assume the following values: +-------+-----------------------------+ | Value | Meaning | +-------+-----------------------------+ | 0 | Lookup result = "valid" | | 1 | Lookup result = "not found" | | 2 | Lookup result = "invalid" | +-------+-----------------------------+ Note that all the routes, regardless of their "validity state" will be stored in the local BGP speaker's Adj-RIB-In. 3. Changes to the BGP Decision Process If a BGP router supports prefix validation and is configured to do so, the validation check MUST be performed prior to any of the steps defined in the decision process of [RFC4271]. The validation step is stated as follows: Mohapatra & Scudder Expires April 30, 2009 [Page 5] Internet-Draft BGP Prefix Origin Validation October 2008 When comparing routes for a BGP destination, if both routes have had their "validity state" computed, the route with the lowest "validity state" value is preferred. In all other respects, the decision process remains unchanged. 3.1. Policy Control It MUST be possible to enable or disable the validation step as defined in Section 3 through configuration. The default SHOULD be for the validation step to be enabled. It MUST be possible to exclude routes from the BGP decision process based on their validation state. In particular it is anticipated that it will be desirable to exclude routes from consideration when their validation state is "invalid"; however it may also be desirable to exclude routes whose validation state is "not found" as well. 4. Route Aggregation When an UPDATE message carries AGGREGATOR attribute, the "UPDATE origin AS number" is set to the value encoded in the AGGREGATOR instead of being derived from the AS_PATH attribute. 5. Deployment Considerations 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. 6. Contributors David Ward dward@cisco.com Cisco Systems Mohapatra & Scudder Expires April 30, 2009 [Page 6] Internet-Draft BGP Prefix Origin Validation October 2008 Rex Fernando rex@juniper.net Robert Raszuk raszuk@juniper.net Miya Kohno mkohno@juniper.net Juniper Networks Shin Miyakawa miyakawa@nttv6.jp Taka Mizuguchi taka@nttv6.jp Tomoya Yoshida yoshida@nttv6.jp NTT Communications Randy Bush randy@psg.com Internet Initiative Japan Rob Austein sra@isc.org ISC Russ Housley housley@vigilsec.com Vigil Security 7. Acknowledgements 8. IANA Considerations 9. Security Considerations Although this specification discusses one portion of a system to validate BGP routes, it should be noted that it relies on a database (RPKI or other) to provide validation information. As such, the security properties of that database must be considered in order to determine the security provided by the overall solution. If "invalid" routes are blocked as this specification suggests, the overall system provides a possible denial-of-service vector, for example if an attacker is able to inject one or more spoofed records into the validation database which lead a good route to be declared invalid. In addition, this system is only able to provide limited protection against a determined attacker -- the attacker need only prepend the "valid" source AS to a forged BGP route announcement in order to defeat the protection provided by this system. This mechanism does not protect against "AS in the middle attacks" or provide any path validation. It only attempts to verify the origin. In general, this system should be thought of more as a protection against misconfiguration than as true "security" in the strong sense. Mohapatra & Scudder Expires April 30, 2009 [Page 7] Internet-Draft BGP Prefix Origin Validation October 2008 10. Normative References [I-D.ietf-sidr-arch] Lepinski, M., Kent, S., and R. Barnes, "An Infrastructure to Support Secure Internet Routing", draft-ietf-sidr-arch-03 (work in progress), February 2008. [I-D.ietf-sidr-bogons] Huston, G., Manderson, T., and G. Michaelson, "A Profile for Bogon Origin Attestations (BOAs)", draft-ietf-sidr-bogons-00 (work in progress), August 2008. [I-D.ietf-sidr-roa-format] Kent, S., "A Profile for Route Origin Authorizations (ROAs)", draft-ietf-sidr-roa-format-03 (work in progress), July 2008. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP Addresses and AS Identifiers", RFC 3779, June 2004. [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006. Authors' Addresses Pradosh Mohapatra (editor) Cisco Systems 170 W. Tasman Drive San Jose, CA 95134 USA Email: pmohapat@cisco.com John Scudder (editor) Juniper Networks 1194 N. Mathilda Ave Sunnyvale, CA 94089 USA Email: jgs@juniper.net Mohapatra & Scudder Expires April 30, 2009 [Page 8] Internet-Draft BGP Prefix Origin Validation October 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Mohapatra & Scudder Expires April 30, 2009 [Page 9]