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]