Network Working Group P. Mohapatra, Ed.
Internet-Draft Cisco Systems
Intended status: Standards Track J. Scudder, Ed.
Expires: January 28, 2010 Juniper Networks
G. Huston, Ed.
APNIC
July 27, 2009
BGP Prefix Origin Validation
draft-pmohapat-sidr-pfx-validate-02
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 January 28, 2010.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
Mohapatra, et al. Expires January 28, 2010 [Page 1]
Internet-Draft BGP Prefix Origin Validation July 2009
document authors. All rights reserved.
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 by the
prefix holder to do so. This document describes a simple validation
mechanism to partially satisfy this requirement.
Mohapatra, et al. Expires January 28, 2010 [Page 2]
Internet-Draft BGP Prefix Origin Validation July 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 . . . . . . . . . . . . . . . . . . 8
7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 8
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
10. Security Considerations . . . . . . . . . . . . . . . . . . . 9
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
11.1. Normative References . . . . . . . . . . . . . . . . . . . 9
11.2. Informative References . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
Mohapatra, et al. Expires January 28, 2010 [Page 3]
Internet-Draft BGP Prefix Origin Validation July 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 by the
prefix holder to do so. 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.
Individual BGP speakers can utilize the processed data contained in
the local cache 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, et al. Expires January 28, 2010 [Page 4]
Internet-Draft BGP Prefix Origin Validation July 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
In loading the validated objects from the local cache to the BGP
speaker, the BGP speaker will store this data in the form of a
database that maintains the relationship between prefixes and the
corresponding set of authorized origin ASes. 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:
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
Mohapatra, et al. Expires January 28, 2010 [Page 5]
Internet-Draft BGP Prefix Origin Validation July 2009
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 a pair of routes for a BGP destination, if both
routes are received via EBGP and have had their "validity state"
computed, the route with the lowest "validity state" value is
preferred. As prefix validation procedures are not performed on
IBGP learnt routes, their "validity state" is not computed and
compared. Refer to Section 6 for IBGP considerations.
In all other respects, the decision process remains unchanged.
Mohapatra, et al. Expires January 28, 2010 [Page 6]
Internet-Draft BGP Prefix Origin Validation July 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. An implementation MAY also
support disabling validation for a subset of prefixes or for routes
received from a particular EBGP peer. The validity state of such
routes for which validation is disabled MUST be set to "not found".
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. The
default SHOULD be to exclude routes whose validation state is
"invalid".
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).
Mohapatra, et al. Expires January 28, 2010 [Page 7]
Internet-Draft BGP Prefix Origin Validation July 2009
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
run any policy on IBGP sessions which could potentially create an
inconsistent view. Going by the same rules, the prefix validation
procedures MUST 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
Mohapatra, et al. Expires January 28, 2010 [Page 8]
Internet-Draft BGP Prefix Origin Validation July 2009
8. Acknowledgements
Junaid Israr's contribution to this specification is part of his PhD
research work and thesis at University of Ottawa, Canada.
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. References
11.1. Normative References
[I-D.ietf-sidr-arch]
Lepinski, M. and S. Kent, "An Infrastructure to Support
Secure Internet Routing", draft-ietf-sidr-arch-07 (work in
progress), July 2009.
[I-D.ietf-sidr-roa-format]
Lepinski, M., Kent, S., and D. Kong, "A Profile for Route
Origin Authorizations (ROAs)",
draft-ietf-sidr-roa-format-05 (work in progress),
July 2009.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Mohapatra, et al. Expires January 28, 2010 [Page 9]
Internet-Draft BGP Prefix Origin Validation July 2009
[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.
11.2. Informative References
[I-D.ymbk-rpki-rtr-protocol]
Bush, R. and R. Austein, "The RPKI/Router Protocol",
draft-ymbk-rpki-rtr-protocol-04 (work in progress),
July 2009.
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
Geoff Huston (editor)
Asia Pacific Network Information Center
Email: gih@apnic.net
Mohapatra, et al. Expires January 28, 2010 [Page 10]