One document matched: draft-ietf-sidr-pfx-validate-03.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
There has to be one entity for each item to be referenced.
An alternate method (rfc include) is described in the references. -->
<!ENTITY RFC2119 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2629 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.2629.xml">
<!ENTITY RFC3552 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.3552.xml">
<!ENTITY RFC4271 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.4271.xml">
<!ENTITY RFC4632 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.4632.xml">
<!ENTITY RFC5065 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.5065.xml">
<!ENTITY RFC3779 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.3779.xml">
<!ENTITY I-D.ietf-sidr-arch SYSTEM
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-sidr-arch-13.xml">
<!ENTITY I-D.ietf-sidr-roa-format SYSTEM
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-sidr-roa-format-12.xml">
<!ENTITY I-D.ietf-sidr-rpki-rtr SYSTEM
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-sidr-rpki-rtr-19.xml">
<!ENTITY I-D.ietf-sidr-origin-ops SYSTEM
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-sidr-origin-ops-12.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that
most I-Ds might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="std" docName="draft-ietf-sidr-pfx-validate-03"
ipr="pre5378Trust200902">
<!-- category values: std, bcp, info, exp, and historic
ipr values: full3667, noModification3667, noDerivatives3667
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<!-- ***** FRONT MATTER ***** -->
<front>
<title abbrev="BGP Prefix Origin Validation">
BGP Prefix Origin Validation</title>
<!-- add 'role="editor"' below for the editors if appropriate -->
<!-- Another author who claims to be an editor -->
<author fullname="Pradosh Mohapatra" initials="P.M."
surname="Mohapatra" role="editor">
<organization>Cisco Systems</organization>
<address>
<postal>
<street>170 W. Tasman Drive</street>
<!-- Reorder these if your country does things differently -->
<city>San Jose</city>
<region>CA</region>
<code>95134</code>
<country>USA</country>
</postal>
<email>pmohapat@cisco.com</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="John Scudder" initials="J.S."
surname="Scudder" role="editor">
<organization>Juniper Networks</organization>
<address>
<postal>
<street>1194 N. Mathilda Ave</street>
<!-- Reorder these if your country does things differently -->
<city>Sunnyvale</city>
<region>CA</region>
<code>94089</code>
<country>USA</country>
</postal>
<email>jgs@juniper.net</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="David Ward" initials="D.W."
surname="Ward" role="editor">
<organization>Juniper Networks</organization>
<address>
<postal>
<street>1194 N. Mathilda Ave</street>
<!-- Reorder these if your country does things differently -->
<city>Sunnyvale</city>
<region>CA</region>
<code>94089</code>
<country>USA</country>
</postal>
<email>dward@juniper.net</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="Randy Bush" initials="R.B."
surname="Bush" role="editor">
<organization>Internet Initiative Japan, Inc.</organization>
<address>
<postal>
<street>5147 Crystral Springs</street>
<!-- Reorder these if your country does things differently -->
<city>Bainbridge Island</city>
<region>Washington</region>
<code>98110</code>
<country>USA</country>
</postal>
<email>randy@psg.com</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="Rob Austein" initials="R.A."
surname="Austein" role="editor">
<organization>Internet Systems Consortium</organization>
<address>
<postal>
<street>950 Charter Street</street>
<!-- Reorder these if your country does things differently -->
<city>Redwood City</city>
<region>CA</region>
<code>94063</code>
<country>USA</country>
</postal>
<email>sra@isc.org</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<date year="2011" />
<!-- Meta-data Declarations -->
<area>General</area>
<workgroup>Network Working Group</workgroup>
<keyword>IDR</keyword>
<!-- Keywords will be incorporated into HTML output
files in a meta tag but they have no effect on text or nroff
output. If you submit your draft to the RFC Editor, the
keywords will be used for the search engine. -->
<abstract>
<t>
To help reduce well-known
threats against BGP including prefix mis-announcing 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.
</t>
</abstract>
</front>
<middle>
<section anchor="introduction" title="Introduction">
<t>
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
<xref target="RFC4271"></xref> and
starts with the AS that originated the prefix. To help reduce well-known
threats against BGP including prefix mis-announcing 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.
</t>
<t>
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 <xref target="I-D.ietf-sidr-arch">
</xref> consists of three main components:
<list style="symbols">
<t>
A public key infrastructure (PKI) with the necessary certificate objects,
</t>
<t>
Digitally signed routing objects,
</t>
<t>
A distributed repository system to hold the objects that would also support
periodic retrieval.
</t>
</list>
</t>
<t>
The RPKI system is based on resource certificates that define extensions to
X.509 to represent IP addresses and AS
identifiers <xref target="RFC3779"></xref>, thus the name RPKI. Route Origin
Authorizations (ROA) <xref target="I-D.ietf-sidr-roa-format">
</xref> 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.
</t>
<t>
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.
</t>
<t>
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 <xref
target="I-D.ietf-sidr-rpki-rtr"></xref> for such a mechanism).
This document proposes a means by which a BGP speaker can make use of
the processed data in order to assign a "validity state" to each prefix
in a received BGP UPDATE message.
</t>
<t>
Note that the complete path attestation against the AS_PATH attribute of a
route is outside the scope of this document.
</t>
<t>
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.
</t>
<section title="Requirements Language">
<t>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 <xref
target="RFC2119">RFC 2119</xref>.</t>
</section>
</section> <!-- for Introductions section -->
<section title="Prefix-to-AS Mapping Database"
anchor="mapping_database">
<t>
The BGP speaker loads validated objects from the cache into local
storage. The objects loaded have the content (IP address, prefix length,
maximum length, origin AS number). We refer to such a locally stored
object colloquially as a "ROA" in the discussion below although we note
that this is not a strictly accurate use of the term.
</t>
<t>
We define several terms in addition to "ROA". Where these terms are used,
they are capitalized:
</t>
<t><list style="symbols">
<t>
Prefix: (IP address, prefix length), interpreted as is customary
(see <xref target="RFC4632"></xref>).
</t>
<t>
Route: Data derived from a received BGP UPDATE, as defined in
<xref target="RFC4271"></xref>, Section 1.1. The Route includes one Prefix
and an AS_PATH, among other things.
</t>
<t>
ROA Prefix: The Prefix from a ROA.
</t>
<t>
ROA ASN: The origin ASN from a ROA.
</t>
<t>
Route Prefix: A Prefix derived from a route.
</t>
<t>
Route Origin ASN: The origin AS number derived from a Route. The
origin AS number is the rightmost AS in the final segment of the
AS_PATH attribute in the Route if that segment is of type AS_SEQUENCE,
or NONE if the final segment of the AS_PATH attribute is of any type
other than AS_SEQUENCE. No ROA can match an origin AS number of "NONE".
No Route can match a ROA whose origin AS number is zero.
</t>
<t>
Covered: A Route Prefix is said to be Covered by a ROA when the ROA
prefix length is less than or equal to the Route prefix length and the
ROA prefix address matches the Route prefix address for all bits
specified by the ROA prefix length. (This is simply a statement of the
well-known concept of determining a prefix match.)
</t>
<t>
Matched: A Route Prefix is said to be Matched by a ROA when the Route
Prefix is Covered by that ROA and in addition, the Route prefix length
is less than or equal to the ROA maximum length and the Route Origin
ASN is equal to the ROA ASN, keeping in mind that a ROA ASN of zero
can never be matched, nor can a route origin AS number of "NONE".
</t>
</list></t>
<t>
Given these definitions, any given BGP Route learned from an EBGP peer
will be found to have one of the following "validation states":
</t>
<t><list style="symbols">
<t>
Not found: No ROA Covers the Route Prefix.
</t>
<t>
Valid: At least one ROA Matches the Route Prefix.
</t>
<t>
Invalid: At least one ROA Covers the Route Prefix, but no ROA Matches it.
</t>
</list></t>
<t>
When a BGP speaker receives an UPDATE from one of its EBGP peers, it
SHOULD perform a lookup as described above for each of the Routes in
the UPDATE message. The "validation state" of the Route SHOULD be set to
reflect the result of the lookup. Note that the validation state of the
Route does not determine whether the Route is stored in the local BGP
speaker's Adj-RIB-In. This procedure SHOULD NOT be performed for Routes
learned from peers of types other than EBGP. (Any of these MAY be
overridden by configuration.)
</t>
<t>
Use of the validation state is discussed in <xref
target="policy_control"></xref> and <xref
target="deployment_consideration"></xref>.
</t>
<t>
We observe that a Route can be Matched or Covered by more than one ROA.
This procedure does not mandate an order in which ROAs must be visited;
however, the "validation state" output is fully determined.
</t>
<section title="Pseudo-Code">
<t>
The following pseudo-code illustrates the procedure above. In case of
ambiguity, the procedure above, rather than the pseudo-code, should be
taken as authoritative.
<figure align="center">
<artwork align="left"><![CDATA[
//Input are the variables derived from a BGP UPDATE message
//that need to be validated.
//
//The input prefix is comprised of prefix.address and
//prefix.length.
//
//origin_as is the rightmost AS in the final segment of the
//AS_PATH attribute in the UPDATE message if that segment is
//AS_SEQUENCE. If the final segment of AS_PATH is not an
//AS_SEQUENCE, origin_as is NONE.
//
//Collectively, the prefix and origin_as correspond to the
//Route defined in the preceding section.
input = {prefix, origin_as};
//Initialize result to "not found" state
result = BGP_PFXV_STATE_NOT_FOUND;
//pfx_validate_table organizes all the ROA entries retrieved
//from the RPKI cache based on the IP address and the prefix
//length field. There can be multiple such entries that match
//the input. Iterate through all of them.
entry = next_lookup_result(pfx_validate_table, input.prefix);
while (entry != NULL) {
prefix_exists = TRUE;
if (input.prefix.length <= entry->max_length) {
if (input.origin_as != NONE
&& entry->origin_as != 0
&& input.origin_as == entry->origin_as) {
result = BGP_PFXV_STATE_VALID;
return (result);
}
}
entry = next_lookup_result(pfx_validate_table, input.prefix);
}
//If pfx_validate_table contains one or more prefixes that
//match the input, but none of them resulted in a "valid"
//outcome since the origin_as did not match, return the
//result state as "invalid". Else the initialized state of
//"not found" applies to this validation operation.
if (prefix_exists == TRUE) {
result = BGP_PFXV_STATE_INVALID;
}
return (result);
]]></artwork>
</figure>
</t>
</section>
</section>
<section anchor="policy_control" title="Policy Control">
<t>
An implementation MUST provide the ability to match and set the
validation state of routes as part of its route policy filtering
function. Use of validation state in route policy is elaborated
in <xref target="deployment_consideration"></xref>. For more
details on operational policy considerations, see <xref target=
"I-D.ietf-sidr-origin-ops"></xref>.
</t>
</section>
<section title="Interaction with Local Cache"
anchor="local_cache">
<t>
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 (please refer
<xref target="I-D.ietf-sidr-rpki-rtr"></xref>). 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 MUST re-validate affected prefixes once the fetch
operation is complete. The same applies during any subsequent
incremental updates of the validation database.
</t>
<t>
In the event that connectivity to the cache is lost, the router
should make a reasonable effort to fetch a new validation database
(either from the same, or a different cache), and SHOULD wait until
the new validation database has been fetched before purging the
previous one. A configurable timer MUST be provided to bound the
length of time the router will wait before purging the previous
validation database.
</t>
</section>
<section anchor="deployment_consideration"
title="Deployment Considerations">
<t>
Once a route is received from an EBGP peer it is categorized according
the procedure given in <xref target="mapping_database"></xref>.
Subsequently, routing policy
as discussed in <xref target="policy_control"></xref> can be used to take action
based on the validation state.
</t>
<t>
Policies which could be implemented include filtering routes based on
validation state (for example, rejecting all "invalid" routes) or
adjusting a route's degree of preference in the selection algorithm
based on its validation state. The latter could be accomplished by
adjusting the value of such attributes as LOCAL_PREF. Considering
invalid routes for BGP decision process is a pure local policy matter
and should be done with utmost care.
</t>
<t>
In some cases (particularly when the selection algorithm is
influenced by the adjustment of a route property that is not
propagated into IBGP) it could be necessary for routing correctness
to propagate the validation state to the IBGP peer. This can be
accomplished on the sending side by setting a community or extended
community based on the validation state, and on the receiving side by
matching the (extended) community and setting the validation state.
</t>
</section>
<section title="Contributors">
<t>
<?rfc subcompact="yes" ?>
</t>
<t>
<list style="empty">
<t>
Rex Fernando rex@cisco.com
</t>
<t>
Keyur Patel keyupate@cisco.com
</t>
<t>
Cisco Systems
</t>
</list>
</t>
<t>
<list style="empty">
<t>
Miya Kohno mkohno@juniper.net
</t>
<t>
Juniper Networks
</t>
</list>
</t>
<t>
<list style="empty">
<t>
Shin Miyakawa miyakawa@nttv6.jp
</t>
<t>
Taka Mizuguchi
</t>
<t>
Tomoya Yoshida
</t>
<t>
NTT Communications
</t>
</list>
</t>
<t>
<list style="empty">
<t>
Russ Housley housley@vigilsec.com
</t>
<t>
Vigil Security
</t>
</list>
</t>
<t>
<list style="empty">
<t>
Junaid Israr jisra052@uottawa.ca
</t>
<t>
Mouhcine Guennoun mguennou@uottawa.ca
</t>
<t>
Hussein Mouftah mouftah@site.uottawa.ca
</t>
<t>
University of Ottawa
School of Information Technology and Engineering(SITE)
800 King Edward Avenue, Ottawa, Ontario, Canada, K1N 6N5
</t>
</list>
</t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>
Junaid Israr's contribution to this specification is part of his PhD
research work and thesis at University of Ottawa, Canada. Hannes
Gredler provided valuable feedback.
</t>
</section>
<!-- Possibly a 'Contributors' section ... -->
<section anchor="IANA" title="IANA Considerations">
<t>
</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>
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.
</t>
</section>
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<!-- References split into informative and normative -->
<!-- There are 2 ways to insert reference entries from the citation libraries:
1. define an ENTITY at the top, and use "ampersand character"RFC2629;
here (as shown)
2. simply use a PI
"less than character"?rfc include="reference.RFC.2119.xml"?> here
(for I-Ds:
include="reference.I-D.narten-iana-considerations-rfc2434bis.xml")
Both are cited textually in the same manner: by using xref elements.
If you use the PI option, xml2rfc will, by default, try to find included
files in the same directory as the including file. You can also define
the XML_LIBRARY environment variable
with a value containing a set of directories to search. These can be
either in the local
filing system or remote ones accessed by http (http://domain/dir/... ).-->
<references title="Normative References">
<!--?rfc include=
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?-->
&RFC2119;
&RFC3779;
&RFC4271;
&RFC4632;
&I-D.ietf-sidr-roa-format;
</references>
<references title="Informational References">
&I-D.ietf-sidr-arch;
&I-D.ietf-sidr-rpki-rtr;
&I-D.ietf-sidr-origin-ops;
</references>
<!-- Change Log
v00 2008-10-01 PM Initial version
v01 2008-10-25 PM Revised version to delete the extcomm section and add
deployment section
v02 2008-10-26 jgs Overall revision
v03 2008-10-26 PM Added email addresses for contributors and formatted
that section
v04 2008-10-27 randy Overall revision
v05 2008-12-31 PM Changes to cover overlapping prefixes
-->
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-22 22:47:47 |