Network Working Group P. Mohapatra, Ed. Internet-Draft Cisco Systems Intended status: Standards Track J. Scudder, Ed. Expires: September 6, 2009 Juniper Networks March 5, 2009 BGP Prefix Origin Validation draft-pmohapat-sidr-pfx-validate-01 Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. 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 September 6, 2009. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. Mohapatra & Scudder Expires September 6, 2009 [Page 1] Internet-Draft BGP Prefix Origin Validation March 2009 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. 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 this requirement. Mohapatra & Scudder Expires September 6, 2009 [Page 2] Internet-Draft BGP Prefix Origin Validation March 2009 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5 2. Prefix-to-AS Mapping Database . . . . . . . . . . . . . . . . 5 3. Changes to the BGP Decision Process . . . . . . . . . . . . . 6 3.1. Policy Control . . . . . . . . . . . . . . . . . . . . . . 7 4. Route Aggregation . . . . . . . . . . . . . . . . . . . . . . 7 5. Interaction with Local Cache . . . . . . . . . . . . . . . . . 7 6. Deployment Considerations . . . . . . . . . . . . . . . . . . 7 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 8 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 10. Security Considerations . . . . . . . . . . . . . . . . . . . 9 11. Normative References . . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 Mohapatra & Scudder Expires September 6, 2009 [Page 3] Internet-Draft BGP Prefix Origin Validation March 2009 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] are separate digitally signed objects that define 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. The protocol details to retrieve the processed data from the local cache to the BGP speakers is beyond the scope of this document (refer to [I-D.ymbk-rpki-rtr-protocol] for such a mechanism). This document Mohapatra & Scudder Expires September 6, 2009 [Page 4] Internet-Draft BGP Prefix Origin Validation March 2009 proposes a simple 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 denote the values derived from the received UPDATE message, and "database prefix set" and "database origin AS number set" to mean the values derived from the database lookup. Note that in the presence of overlapping prefixes, the database lookup against the "UPDATE prefix" may yield multiple matches. The following are the different types of results expected from such a lookup operation: Mohapatra & Scudder Expires September 6, 2009 [Page 5] Internet-Draft BGP Prefix Origin Validation March 2009 o If the "UPDATE prefix" finds no matching or covering prefixes in the database, the lookup result is returned as "not found". Due to incremental deployment model of the RPKI repository, it is expected that a complete registry of all IP address blocks and their AS associations is not available at a given point of time. o If there are "database prefix sets" that cover the "UPDATE prefix", and one of them has the "UPDATE origin AS number" in the "database origin AS number sets", then the lookup result is returned as "valid". o If there are "database prefix sets" which cover the "UPDATE prefix", but none of them has the "UPDATE origin AS number" in the "database origin AS number set", then the lookup result is returned as "invalid". 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: 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. Mohapatra & Scudder Expires September 6, 2009 [Page 6] Internet-Draft BGP Prefix Origin Validation March 2009 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. Interaction with Local Cache Each BGP speaker supporting prefix validation as described in this document is expected to communicate with one or multiple local caches that store a database of RPKI signed objects. The protocol mechanisms used to fetch the data and store them locally at the BGP speaker is beyond the scope of this document. Irrespective of the protocol, the prefix validation algorithm as outlined in this document is expected to function correctly in the event of failures and other timing conditions that may result in an empty and/or partial prefix-to-AS mapping database. Indeed, if the (in-PoP) cache is not available and the mapping database is empty on the BGP speaker, all the lookups will result in "not found" state and the prefixes will be advertised to rest of the network (unless restricted by policy configuration). Similarly, if BGP UPDATEs arrive at the speaker while the fetch operation from the cache is in progress, some prefix lookups will also result in "not found" state. The implementation is expected to handle these timing conditions and re- validate the prefixes once the fetch operation is complete (in an event-driven manner). 6. 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 Mohapatra & Scudder Expires September 6, 2009 [Page 7] Internet-Draft BGP Prefix Origin Validation March 2009 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. 7. Contributors David Ward dward@cisco.com Cisco Systems Rex Fernando rex@juniper.net Miya Kohno mkohno@juniper.net Juniper Networks Shin Miyakawa miyakawa@nttv6.jp Taka Mizuguchi Tomoya Yoshida NTT Communications Randy Bush randy@psg.com Internet Initiative Japan Rob Austein sra@isc.org ISC Russ Housley housley@vigilsec.com Vigil Security Junaid Israr jisra052@uottawa.ca Mouhcine Guennoun mguennou@uottawa.ca Hussein Mouftah mouftah@site.uottawa.ca University of Ottawa School of Information Technology and Engineering(SITE) 800 King Edward Avenue, Ottawa, Ontario, Canada, K1N 6N5 8. Acknowledgements Junaid Israr's contribution to this specification is part of his PhD research work and thesis at University of Ottawa, Canada. Mohapatra & Scudder Expires September 6, 2009 [Page 8] Internet-Draft BGP Prefix Origin Validation March 2009 9. IANA Considerations 10. 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. 11. 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-roa-format] Kent, S., "A Profile for Route Origin Authorizations (ROAs)", draft-ietf-sidr-roa-format-03 (work in progress), July 2008. [I-D.ymbk-rpki-rtr-protocol] Bush, R., "The RPKI/Router Protocol", draft-ymbk-rpki-rtr-protocol-00 (work in progress), March 2009. [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 Mohapatra & Scudder Expires September 6, 2009 [Page 9] Internet-Draft BGP Prefix Origin Validation March 2009 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 September 6, 2009 [Page 10]