draft-ietf-sidr-pfx-validate-04.txt   draft-ietf-sidr-pfx-validate-05.txt 
Network Working Group P. Mohapatra Network Working Group P. Mohapatra
Internet-Draft Cisco Systems Internet-Draft Cisco Systems
Intended status: Standards Track J. Scudder Intended status: Standards Track J. Scudder
Expires: September 13, 2012 Juniper Networks Expires: October 19, 2012 Juniper Networks
D. Ward D. Ward
Cisco Systems Cisco Systems
R. Bush R. Bush
Internet Initiative Japan, Inc. Internet Initiative Japan, Inc.
R. Austein R. Austein
Dragon Research Labs Dragon Research Labs
March 12, 2012 April 17, 2012
BGP Prefix Origin Validation BGP Prefix Origin Validation
draft-ietf-sidr-pfx-validate-04 draft-ietf-sidr-pfx-validate-05
Abstract Abstract
To help reduce well-known threats against BGP including prefix mis- To help reduce well-known threats against BGP including prefix mis-
announcing and monkey-in-the-middle attacks, one of the security announcing and monkey-in-the-middle attacks, one of the security
requirements is the ability to validate the origination AS of BGP requirements is the ability to validate the origination AS of BGP
routes. More specifically, one needs to validate that the AS number routes. More specifically, one needs to validate that the AS number
claiming to originate an address prefix (as derived from the AS_PATH claiming to originate an address prefix (as derived from the AS_PATH
attribute of the BGP route) is in fact authorized by the prefix attribute of the BGP route) is in fact authorized by the prefix
holder to do so. This document describes a simple validation holder to do so. This document describes a simple validation
skipping to change at page 1, line 44 skipping to change at page 1, line 44
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 13, 2012. This Internet-Draft will expire on October 19, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 11 skipping to change at page 3, line 11
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5
2. Prefix-to-AS Mapping Database . . . . . . . . . . . . . . . . 5 2. Prefix-to-AS Mapping Database . . . . . . . . . . . . . . . . 5
2.1. Pseudo-Code . . . . . . . . . . . . . . . . . . . . . . . 7 2.1. Pseudo-Code . . . . . . . . . . . . . . . . . . . . . . . 7
3. Policy Control . . . . . . . . . . . . . . . . . . . . . . . . 8 3. Policy Control . . . . . . . . . . . . . . . . . . . . . . . . 7
4. Interaction with Local Cache . . . . . . . . . . . . . . . . . 8 4. Interaction with Local Cache . . . . . . . . . . . . . . . . . 8
5. Deployment Considerations . . . . . . . . . . . . . . . . . . 8 5. Deployment Considerations . . . . . . . . . . . . . . . . . . 8
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
9.1. Normative References . . . . . . . . . . . . . . . . . . . 10 9.1. Normative References . . . . . . . . . . . . . . . . . . . 9
9.2. Informational References . . . . . . . . . . . . . . . . . 10 9.2. Informational References . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction 1. Introduction
A BGP route associates an address prefix with a set of autonomous A BGP route associates an address prefix with a set of autonomous
systems (AS) that identify the interdomain path the prefix has systems (AS) that identify the interdomain path the prefix has
traversed in the form of BGP announcements. This set is represented traversed in the form of BGP announcements. This set is represented
as the AS_PATH attribute in BGP [RFC4271] and starts with the AS that as the AS_PATH attribute in BGP [RFC4271] and starts with the AS that
originated the prefix. To help reduce well-known threats against BGP originated the prefix. To help reduce well-known threats against BGP
skipping to change at page 5, line 5 skipping to change at page 5, line 5
process them. The cache must also be refreshed periodically. The process them. The cache must also be refreshed periodically. The
exact access mechanism used to retrieve the local cache is beyond the exact access mechanism used to retrieve the local cache is beyond the
scope of this document. scope of this document.
Individual BGP speakers can utilize the processed data contained in Individual BGP speakers can utilize the processed data contained in
the local cache to validate BGP announcements. The protocol details the local cache to validate BGP announcements. The protocol details
to retrieve the processed data from the local cache to the BGP to retrieve the processed data from the local cache to the BGP
speakers is beyond the scope of this document (refer to speakers is beyond the scope of this document (refer to
[I-D.ietf-sidr-rpki-rtr] for such a mechanism). This document [I-D.ietf-sidr-rpki-rtr] for such a mechanism). This document
proposes a means by which a BGP speaker can make use of the processed 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 data in order to assign a "validation state" to each prefix in a
received BGP UPDATE message. received BGP UPDATE message.
Note that the complete path attestation against the AS_PATH attribute Note that the complete path attestation against the AS_PATH attribute
of a route is outside the scope of this document. of a route is outside the scope of this document.
Although RPKI provides the context for this draft, it is equally Although RPKI provides the context for this draft, it is equally
possible to use any other database which is able to map prefixes to possible to use any other database which is able to map prefixes to
their authorized origin ASes. Each distinct database will have its their authorized origin ASes. Each distinct database will have its
own particular operational and security characteristics; such own particular operational and security characteristics; such
characteristics are beyond the scope of this document. characteristics are beyond the scope of this document.
skipping to change at page 5, line 28 skipping to change at page 5, line 28
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
2. Prefix-to-AS Mapping Database 2. Prefix-to-AS Mapping Database
The BGP speaker loads validated objects from the cache into local The BGP speaker loads validated objects from the cache into local
storage. The objects loaded have the content (IP address, prefix storage. The objects loaded have the content (IP address, prefix
length, maximum length, origin AS number). We refer to such a length, maximum length, origin AS number). We refer to such a
locally stored object colloquially as a "ROA" in the discussion below locally stored object as a "Validated ROA Payload" or "VRP".
although we note that this is not a strictly accurate use of the
term.
We define several terms in addition to "ROA". Where these terms are We define several terms in addition to "VRP". Where these terms are
used, they are capitalized: used, they are capitalized:
o Prefix: (IP address, prefix length), interpreted as is customary o Prefix: (IP address, prefix length), interpreted as is customary
(see [RFC4632]). (see [RFC4632]).
o Route: Data derived from a received BGP UPDATE, as defined in o Route: Data derived from a received BGP UPDATE, as defined in
[RFC4271], Section 1.1. The Route includes one Prefix and an [RFC4271], Section 1.1. The Route includes one Prefix and an
AS_PATH; it may include other attributes to characterize the AS_PATH; it may include other attributes to characterize the
prefix. prefix.
o ROA Prefix: The Prefix from a ROA. o VRP Prefix: The Prefix from a VRP.
o ROA ASN: The origin AS number from a ROA. o VRP ASN: The origin AS number from a VRP.
o Route Prefix: The Prefix derived from a route. o Route Prefix: The Prefix derived from a route.
o Route Origin ASN: The origin AS number derived from a Route. The o 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 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_PATH attribute in the Route if that segment is of type
AS_SEQUENCE, or NONE if the final segment of the AS_PATH attribute AS_SEQUENCE, or the distinguished value "NONE" if the final
is of any type other than AS_SEQUENCE. No ROA can match an origin segment of the AS_PATH attribute is of any type other than
AS number of "NONE". No Route can match a ROA whose origin AS AS_SEQUENCE.
number is zero.
o Covered: A Route Prefix is said to be Covered by a ROA when the o Covered: A Route Prefix is said to be Covered by a VRP when the
ROA prefix length is less than or equal to the Route prefix length VRP prefix length is less than or equal to the Route prefix length
and the ROA prefix address matches the Route prefix address for and the VRP prefix address matches the Route prefix address for
all bits specified by the ROA prefix length. (This is simply a all bits specified by the VRP prefix length. (This is simply a
statement of the well-known concept of determining a prefix statement of the well-known concept of determining a prefix
match.) match.)
o Matched: A Route Prefix is said to be Matched by a ROA when the o Matched: A Route Prefix is said to be Matched by a VRP when the
Route Prefix is Covered by that ROA and in addition, the Route Route Prefix is Covered by that VRP and in addition, the Route
prefix length is less than or equal to the ROA maximum length and prefix length is less than or equal to the VRP maximum length and
the Route Origin ASN is equal to the ROA ASN, keeping in mind that the Route Origin ASN is equal to the VRP ASN.
a ROA ASN of zero can never be matched, nor can a route origin AS
number of "NONE".
Given these definitions, any given BGP Route will be found to have Given these definitions, any given BGP Route will be found to have
one of the following "validation states": one of the following "validation states":
o NotFound: No ROA Covers the Route Prefix. o NotFound: No VRP Covers the Route Prefix.
o Valid: At least one ROA Matches the Route Prefix. o Valid: At least one VRP Matches the Route Prefix.
o Invalid: At least one ROA Covers the Route Prefix, but no ROA o Invalid: At least one VRP Covers the Route Prefix, but no VRP
Matches it. Matches it.
When a BGP speaker receives an UPDATE from one of its EBGP peers, it We observe that no VRP can have the value "NONE" as its VRP ASN.
SHOULD perform a lookup as described above for each of the Routes in Thus a Route whose Origin ASN is "NONE" cannot be Matched by any VRP.
the UPDATE message. The "validation state" of the Route SHOULD be Similarly, no valid Route can have an Origin ASN of zero
set to reflect the result of the lookup. Note that the validation [I-D.ietf-idr-as0]. Thus no Route can be Matched by a VRP whose ASN
state of the Route does not determine whether the Route is stored in is zero.
the local BGP speaker's Adj-RIB-In. This procedure SHOULD NOT be
performed for Routes learned from peers of types other than EBGP. When a BGP speaker receives an UPDATE from a neighbor, it SHOULD
(Any of these MAY be overridden by configuration.) The suggested perform a lookup as described above for each of the Routes in the
implementation should consider the "validation state" as described in UPDATE message. The lookup SHOULD also be applied to routes which
the document as a local property or attribute of the Route. If are redistributed into BGP from another source, such as another
validation is not performed on a Route, the implementation SHOULD protocol or a locally defined static route. An implementation MAY
initialize the validation state of such a route to "Valid". provide configuration options to control which routes the lookup is
applied to. The "validation state" of the Route MUST be set to
reflect the result of the lookup. The implementation should consider
the "validation state" as described in the document as a local
property or attribute of the Route. If validation is not performed
on a Route, the implementation SHOULD initialize the "validation
state" of such a route to "NotFound".
Use of the validation state is discussed in Section 3 and Section 5. Use of the validation state is discussed in Section 3 and Section 5.
An implementation MUST NOT exclude a route from the Adj-RIB-In or
from consideration in the decision process as a side-effect of its
validation state, unless explicitly configured to do so.
We observe that a Route can be Matched or Covered by more than one 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 VRP. This procedure does not mandate an order in which VRPs must be
visited; however, the "validation state" output is fully determined. visited; however, the "validation state" output is fully determined.
2.1. Pseudo-Code 2.1. Pseudo-Code
The following pseudo-code illustrates the procedure above. In case The following pseudo-code illustrates the procedure above. In case
of ambiguity, the procedure above, rather than the pseudo-code, of ambiguity, the procedure above, rather than the pseudo-code,
should be taken as authoritative. should be taken as authoritative.
//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.
//
//Collectively, the prefix and origin_as correspond to the
//Route defined in the preceding section.
input = {prefix, origin_as};
//Initialize result to "NotFound" state
result = BGP_PFXV_STATE_NOT_FOUND; result = BGP_PFXV_STATE_NOT_FOUND;
//pfx_validate_table organizes all the ROA entries retrieved //Iterate through all the Covering entries in the local VRP
//from the RPKI cache based on the IP address and the prefix //database, pfx_validate_table.
//length field. There can be multiple such entries that match entry = next_lookup_result(pfx_validate_table, route_prefix);
//the input. Iterate through all of them.
entry = next_lookup_result(pfx_validate_table, input.prefix);
while (entry != NULL) { while (entry != NULL) {
prefix_exists = TRUE; prefix_exists = TRUE;
if (input.prefix.length <= entry->max_length) { if (route_prefix_length <= entry->max_length) {
if (input.origin_as != NONE if (route_origin_as != NONE
&& entry->origin_as != 0 && entry->origin_as != 0
&& input.origin_as == entry->origin_as) { && route_origin_as == entry->origin_as) {
result = BGP_PFXV_STATE_VALID; result = BGP_PFXV_STATE_VALID;
return (result); return (result);
} }
} }
entry = next_lookup_result(pfx_validate_table, input.prefix); entry = next_lookup_result(pfx_validate_table, input.prefix);
} }
//If pfx_validate_table contains one or more prefixes that //If one or more VRP entries Covered the route prefix, but
//match the input, but none of them resulted in a "valid" //no one Matched, return "Invalid" validation state.
//outcome since the origin_as did not match, return the
//result state as "invalid". Else the initialized state of
//"NotFound" applies to this validation operation.
if (prefix_exists == TRUE) { if (prefix_exists == TRUE) {
result = BGP_PFXV_STATE_INVALID; result = BGP_PFXV_STATE_INVALID;
} }
return (result); return (result);
3. Policy Control 3. Policy Control
An implementation MUST provide the ability to match and set the An implementation MUST provide the ability to match and set the
validation state of routes as part of its route policy filtering validation state of routes as part of its route policy filtering
function. Use of validation state in route policy is elaborated in function. Use of validation state in route policy is elaborated in
Section 5. For more details on operational policy considerations, Section 5. For more details on operational policy considerations,
see [I-D.ietf-sidr-origin-ops]. see [I-D.ietf-sidr-origin-ops].
skipping to change at page 9, line 13 skipping to change at page 8, line 49
propagated into IBGP) it could be necessary for routing correctness propagated into IBGP) it could be necessary for routing correctness
to propagate the validation state to the IBGP peer. This can be to propagate the validation state to the IBGP peer. This can be
accomplished on the sending side by setting a community or extended accomplished on the sending side by setting a community or extended
community based on the validation state, and on the receiving side by community based on the validation state, and on the receiving side by
matching the (extended) community and setting the validation state. matching the (extended) community and setting the validation state.
6. Acknowledgments 6. Acknowledgments
The authors wish to thank Rex Fernando, Hannes Gredler, Mouhcine The authors wish to thank Rex Fernando, Hannes Gredler, Mouhcine
Guennoun, Russ Housley, Junaid Israr, Miya Kohno, Shin Miyakawa, Taka Guennoun, Russ Housley, Junaid Israr, Miya Kohno, Shin Miyakawa, Taka
Mizuguchi, Hussein Mouftah, Keyur Patel, Tomoya Yoshida, and Kannan Mizuguchi, Hussein Mouftah, Keyur Patel, Tomoya Yoshida, Kannan
Varadhan. The authors are grateful for the feedback from the members Varadhan, and Wes George. The authors are grateful for the feedback
of the SIDR working group. from the members of the SIDR working group.
Junaid Israr's contribution to this specification was part of his PhD Junaid Israr's contribution to this specification was part of his PhD
research work and thesis at University of Ottawa. research work and thesis at University of Ottawa.
7. IANA Considerations 7. IANA Considerations
8. Security Considerations 8. Security Considerations
Although this specification discusses one portion of a system to Although this specification discusses one portion of a system to
validate BGP routes, it should be noted that it relies on a database validate BGP routes, it should be noted that it relies on a database
skipping to change at page 10, line 27 skipping to change at page 10, line 15
Plan", BCP 122, RFC 4632, August 2006. Plan", BCP 122, RFC 4632, August 2006.
[RFC4893] Vohra, Q. and E. Chen, "BGP Support for Four-octet AS [RFC4893] Vohra, Q. and E. Chen, "BGP Support for Four-octet AS
Number Space", RFC 4893, May 2007. Number Space", RFC 4893, May 2007.
[RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route [RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route
Origin Authorizations (ROAs)", RFC 6482, February 2012. Origin Authorizations (ROAs)", RFC 6482, February 2012.
9.2. Informational References 9.2. Informational References
[I-D.ietf-idr-as0]
Kumari, W., Bush, R., Schiller, H., and K. Patel,
"Codification of AS 0 processing.", draft-ietf-idr-as0-03
(work in progress), January 2012.
[I-D.ietf-sidr-origin-ops] [I-D.ietf-sidr-origin-ops]
Bush, R., "RPKI-Based Origin Validation Operation", Bush, R., "RPKI-Based Origin Validation Operation",
draft-ietf-sidr-origin-ops-15 (work in progress), draft-ietf-sidr-origin-ops-15 (work in progress),
March 2012. March 2012.
[I-D.ietf-sidr-rpki-rtr] [I-D.ietf-sidr-rpki-rtr]
Bush, R. and R. Austein, "The RPKI/Router Protocol", Bush, R. and R. Austein, "The RPKI/Router Protocol",
draft-ietf-sidr-rpki-rtr-26 (work in progress), draft-ietf-sidr-rpki-rtr-26 (work in progress),
February 2012. February 2012.
 End of changes. 29 change blocks. 
72 lines changed or deleted 66 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/