draft-ietf-sidr-pfx-validate-02.txt   draft-ietf-sidr-pfx-validate-03.txt 
Network Working Group P. Mohapatra, Ed. Network Working Group P. Mohapatra, Ed.
Internet-Draft Cisco Systems Internet-Draft Cisco Systems
Intended status: Standards Track J. Scudder, Ed. Intended status: Standards Track J. Scudder, Ed.
Expires: January 12, 2012 D. Ward, Ed. Expires: May 3, 2012 D. Ward, Ed.
Juniper Networks Juniper Networks
R. Bush, Ed. R. Bush, Ed.
Internet Initiative Japan, Inc. Internet Initiative Japan, Inc.
R. Austein, Ed. R. Austein, Ed.
Internet Systems Consortium Internet Systems Consortium
July 11, 2011 October 31, 2011
BGP Prefix Origin Validation BGP Prefix Origin Validation
draft-ietf-sidr-pfx-validate-02 draft-ietf-sidr-pfx-validate-03
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 43 skipping to change at page 1, line 43
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 January 12, 2012. This Internet-Draft will expire on May 3, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 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 10 skipping to change at page 3, line 10
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
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
3. Policy Control . . . . . . . . . . . . . . . . . . . . . . . . 7 2.1. Pseudo-Code . . . . . . . . . . . . . . . . . . . . . . . 6
4. Interaction with Local Cache . . . . . . . . . . . . . . . . . 7 3. Policy Control . . . . . . . . . . . . . . . . . . . . . . . . 9
5. Deployment Considerations . . . . . . . . . . . . . . . . . . 8 4. Interaction with Local Cache . . . . . . . . . . . . . . . . . 9
6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 8 5. Deployment Considerations . . . . . . . . . . . . . . . . . . 9
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 10
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
9. Security Considerations . . . . . . . . . . . . . . . . . . . 9 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 9. Security Considerations . . . . . . . . . . . . . . . . . . . 11
10.1. Normative References . . . . . . . . . . . . . . . . . . . 10 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
10.2. Informational References . . . . . . . . . . . . . . . . . 10 10.1. Normative References . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 10.2. Informational References . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
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
including prefix mis-announcing and monkey-in-the-middle attacks, one including prefix mis-announcing and monkey-in-the-middle attacks, one
of the security requirements is the ability to validate the of the security requirements is the ability to validate the
skipping to change at page 5, line 25 skipping to change at page 5, line 25
characteristics are beyond the scope of this document. characteristics are beyond the scope of this document.
1.1. Requirements Language 1.1. Requirements Language
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
In loading the validated objects from the local cache to the BGP The BGP speaker loads validated objects from the cache into local
speaker, the BGP speaker will store this data in the form of a storage. The objects loaded have the content (IP address, prefix
database that maintains the relationship between prefixes and the length, maximum length, origin AS number). We refer to such a
corresponding set of authorized origin ASes. The primary key for locally stored object colloquially as a "ROA" in the discussion below
this database is a prefix set represented as (IP prefix)/[min. although we note that this is not a strictly accurate use of the
length, max. length]. The value stored against each prefix set is term.
the set of AS numbers that is assigned or sub-allocated the
corresponding IP address block. An AS can originate more than one
prefix set. Thus, multiple prefix sets in the database can contain
the same origin AS(es).
Whenever UPDATEs are received from peers, a BGP speaker is expected We define several terms in addition to "ROA". Where these terms are
to perform a lookup in this database for each of the prefixes in the used, they are capitalized:
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" can yield
multiple matches.
The following are the different types of results expected from such a o Prefix: (IP address, prefix length), interpreted as is customary
lookup operation: (see [RFC4632]).
o If the "UPDATE prefix" finds no matching or covering prefixes in o Route: Data derived from a received BGP UPDATE, as defined in
the database (i.e. the "UPDATE prefix" is not a sub-block of any [RFC4271], Section 1.1. The Route includes one Prefix and an
of the database prefixes), the lookup result is returned as "not AS_PATH, among other things.
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 o ROA Prefix: The Prefix from a ROA.
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 o ROA ASN: The origin ASN from a ROA.
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 route, o Route Prefix: A Prefix derived from a route.
called the "validity state". It can assume the values "valid", "not
found", or "invalid".
Note that all the routes, regardless of their "validity state" will o Route Origin ASN: The origin AS number derived from a Route. The
be stored in the local BGP speaker's Adj-RIB-In. 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.
Following is a sample pseudo code for prefix validation function: o 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.)
o 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".
Given these definitions, any given BGP Route learned from an EBGP
peer will be found to have one of the following "validation states":
o Not found: No ROA Covers the Route Prefix.
o Valid: At least one ROA Matches the Route Prefix.
o Invalid: At least one ROA Covers the Route Prefix, but no ROA
Matches it.
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.)
Use of the validation state is discussed in Section 3 and Section 5.
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.
2.1. Pseudo-Code
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.
//Input are the variables derived from a BGP UPDATE message //Input are the variables derived from a BGP UPDATE message
//that need to be validated. //that need to be validated.
// //
//origin_as is the rightmost AS in the final AS_SEQUENCE of //The input prefix is comprised of prefix.address and
//the AS_PATH attribute in the UPDATE message. //prefix.length.
// //
//origin_as is NONE if the AS_PATH contains an AS_SET //origin_as is the rightmost AS in the final segment of the
//path segment type. //AS_PATH attribute in the UPDATE message if that segment is
input = {bgp_prefix, masklen, origin_as}; //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 //Initialize result to "not found" state
result = BGP_PFXV_STATE_NOT_FOUND; result = BGP_PFXV_STATE_NOT_FOUND;
//pfx_validate_table organizes all the ROA entries retrieved //pfx_validate_table organizes all the ROA entries retrieved
//from RPKI cache based on the IP address and the minLength //from the RPKI cache based on the IP address and the prefix
//field. There can be multiple such entries that match the //length field. There can be multiple such entries that match
//input. Iterate through all of them. //the input. Iterate through all of them.
entry = next_lookup_result(pfx_validate_table, entry = next_lookup_result(pfx_validate_table, input.prefix);
input.bgp_prefix, input.masklen);
while (entry != NULL) { while (entry != NULL) {
prefix_exists = TRUE; prefix_exists = TRUE;
//Each entry stores multiple records sorted by the ROA
//maxLength field. i.e. there can be multiple ROA records if (input.prefix.length <= entry->max_length) {
//with the same IPaddress and minLength fields, but different if (input.origin_as != NONE
//maxLength field. Iterate through all records of the entry && entry->origin_as != 0
//to check if there is one range that matches the input. && input.origin_as == entry->origin_as) {
record = next_in_entry_record_list(entry); result = BGP_PFXV_STATE_VALID;
while (record != NULL) { return (result);
if (input.masklen <= record->max_length) {
if (input.origin_as == record->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 //If pfx_validate_table contains one or more prefixes that
//match the input, but none of them resulted in a "valid" //match the input, but none of them resulted in a "valid"
//outcome since the origin_as did not match, return the //outcome since the origin_as did not match, return the
//result state as "invalid". Else the initialized state of //result state as "invalid". Else the initialized state of
//"not found" applies to this validation operation. //"not found" applies to this validation operation.
if (prefix_exists == TRUE) { if (prefix_exists == TRUE) {
result = BGP_PFXV_STATE_INVALID; result = BGP_PFXV_STATE_INVALID;
} }
skipping to change at page 9, line 29 skipping to change at page 10, line 46
Junaid Israr jisra052@uottawa.ca Junaid Israr jisra052@uottawa.ca
Mouhcine Guennoun mguennou@uottawa.ca Mouhcine Guennoun mguennou@uottawa.ca
Hussein Mouftah mouftah@site.uottawa.ca Hussein Mouftah mouftah@site.uottawa.ca
University of Ottawa School of Information Technology and University of Ottawa School of Information Technology and
Engineering(SITE) 800 King Edward Avenue, Ottawa, Ontario, Canada, Engineering(SITE) 800 King Edward Avenue, Ottawa, Ontario, Canada,
K1N 6N5 K1N 6N5
7. Acknowledgements 7. Acknowledgements
Junaid Israr's contribution to this specification is part of his PhD Junaid Israr's contribution to this specification is part of his PhD
research work and thesis at University of Ottawa, Canada. research work and thesis at University of Ottawa, Canada. Hannes
Gredler provided valuable feedback.
8. IANA Considerations 8. IANA Considerations
9. Security Considerations 9. 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
(RPKI or other) to provide validation information. As such, the (RPKI or other) to provide validation information. As such, the
security properties of that database must be considered in order to security properties of that database must be considered in order to
determine the security provided by the overall solution. If determine the security provided by the overall solution. If
skipping to change at page 10, line 12 skipping to change at page 11, line 31
order to defeat the protection provided by this system. This order to defeat the protection provided by this system. This
mechanism does not protect against "AS in the middle attacks" or mechanism does not protect against "AS in the middle attacks" or
provide any path validation. It only attempts to verify the origin. provide any path validation. It only attempts to verify the origin.
In general, this system should be thought of more as a protection In general, this system should be thought of more as a protection
against misconfiguration than as true "security" in the strong sense. against misconfiguration than as true "security" in the strong sense.
10. References 10. References
10.1. Normative References 10.1. Normative References
[I-D.ietf-sidr-arch]
Lepinski, M. and S. Kent, "An Infrastructure to Support
Secure Internet Routing", draft-ietf-sidr-arch-13 (work in
progress), May 2011.
[I-D.ietf-sidr-roa-format] [I-D.ietf-sidr-roa-format]
Lepinski, M., Kent, S., and D. Kong, "A Profile for Route Lepinski, M., Kent, S., and D. Kong, "A Profile for Route
Origin Authorizations (ROAs)", Origin Authorizations (ROAs)",
draft-ietf-sidr-roa-format-12 (work in progress), draft-ietf-sidr-roa-format-12 (work in progress),
May 2011. May 2011.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP [RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP
Addresses and AS Identifiers", RFC 3779, June 2004. Addresses and AS Identifiers", RFC 3779, June 2004.
[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
Protocol 4 (BGP-4)", RFC 4271, January 2006. Protocol 4 (BGP-4)", RFC 4271, January 2006.
[RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing
(CIDR): The Internet Address Assignment and Aggregation
Plan", BCP 122, RFC 4632, August 2006.
10.2. Informational References 10.2. Informational References
[I-D.ietf-sidr-arch]
Lepinski, M. and S. Kent, "An Infrastructure to Support
Secure Internet Routing", draft-ietf-sidr-arch-13 (work in
progress), May 2011.
[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-10 (work in progress), draft-ietf-sidr-origin-ops-12 (work in progress),
July 2011. October 2011.
[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-14 (work in progress), July 2011. draft-ietf-sidr-rpki-rtr-19 (work in progress),
October 2011.
Authors' Addresses Authors' Addresses
Pradosh Mohapatra (editor) Pradosh Mohapatra (editor)
Cisco Systems Cisco Systems
170 W. Tasman Drive 170 W. Tasman Drive
San Jose, CA 95134 San Jose, CA 95134
USA USA
Email: pmohapat@cisco.com Email: pmohapat@cisco.com
 End of changes. 25 change blocks. 
88 lines changed or deleted 120 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/