draft-ietf-sidr-pfx-validate-00.txt   draft-ietf-sidr-pfx-validate-01.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 29, 2011 D. Ward, Ed. Expires: August 11, 2011 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 28, 2010 February 7, 2011
BGP Prefix Origin Validation BGP Prefix Origin Validation
draft-ietf-sidr-pfx-validate-00 draft-ietf-sidr-pfx-validate-01
Abstract Abstract
A BGP route associates an address prefix with a set of autonomous To help reduce well-known threats against BGP including prefix mis-
systems (AS) that identify the interdomain path the prefix has announcing and monkey-in-the-middle attacks, one of the security
traversed in the form of BGP announcements. This set is represented requirements is the ability to validate the origination AS of BGP
as the AS_PATH attribute in BGP and starts with the AS that routes. More specifically, one needs to validate that the AS number
originated the prefix. To help reduce well-known threats against BGP claiming to originate an address prefix (as derived from the AS_PATH
including prefix mis-announcing and monkey-in-the-middle attacks, one attribute of the BGP route) is in fact authorized by the prefix
of the security requirements is the ability to validate the holder to do so. This document describes a simple validation
origination AS of BGP routes. More specifically, one needs to mechanism to partially satisfy this requirement.
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.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF). Note that other groups may also distribute
other groups may also distribute working documents as Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts. 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."
The list of current Internet-Drafts can be accessed at This Internet-Draft will expire on August 11, 2011.
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 29, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the BSD License. described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this 10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process. modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
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 3. Policy Control . . . . . . . . . . . . . . . . . . . . . . . . 7
4. Route Aggregation . . . . . . . . . . . . . . . . . . . . . . 7 4. Interaction with Local Cache . . . . . . . . . . . . . . . . . 7
5. Interaction with Local Cache . . . . . . . . . . . . . . . . . 8 5. Deployment Considerations . . . . . . . . . . . . . . . . . . 8
6. Deployment Considerations . . . . . . . . . . . . . . . . . . 8 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 8
7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 9 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 9. Security Considerations . . . . . . . . . . . . . . . . . . . 9
10. Security Considerations . . . . . . . . . . . . . . . . . . . 9 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 10.1. Normative References . . . . . . . . . . . . . . . . . . . 10
11.1. Normative References . . . . . . . . . . . . . . . . . . . 10 10.2. Informational References . . . . . . . . . . . . . . . . . 10
11.2. Informative 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
including prefix mis-announcing and monkey-in-the-middle attacks, one including prefix mis-announcing and monkey-in-the-middle attacks, one
skipping to change at page 5, line 32 skipping to change at page 5, line 32
2. Prefix-to-AS Mapping Database 2. Prefix-to-AS Mapping Database
In loading the validated objects from the local cache to the BGP 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 speaker, the BGP speaker will store this data in the form of a
database that maintains the relationship between prefixes and the database that maintains the relationship between prefixes and the
corresponding set of authorized origin ASes. The primary key for corresponding set of authorized origin ASes. The primary key for
this database is a prefix set represented as (IP prefix)/[min. this database is a prefix set represented as (IP prefix)/[min.
length, max. length]. The value stored against each prefix set is length, max. length]. The value stored against each prefix set is
the set of AS numbers that is assigned or sub-allocated the the set of AS numbers that is assigned or sub-allocated the
corresponding IP address block. An AS may originate more than one corresponding IP address block. An AS can originate more than one
prefix set. Thus, multiple prefix sets in the database may contain prefix set. Thus, multiple prefix sets in the database may contain
the same origin AS(es). the same origin AS(es).
Whenever UPDATEs are received from peers, a BGP speaker is expected 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 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 message. To aid with better description, we define terms
"UPDATE prefix" and "UPDATE origin AS number" to denote the values "UPDATE prefix" and "UPDATE origin AS number" to denote the values
derived from the received UPDATE message, and "database prefix set" derived from the received UPDATE message, and "database prefix set"
and "database origin AS number set" to mean the values derived from and "database origin AS number set" to mean the values derived from
the database lookup. Note that in the presence of overlapping the database lookup. Note that in the presence of overlapping
skipping to change at page 6, line 31 skipping to change at page 6, line 31
called the "validity state". It can assume the values "valid", "not called the "validity state". It can assume the values "valid", "not
found", or "invalid". found", or "invalid".
Note that all the routes, regardless of their "validity state" will Note that all the routes, regardless of their "validity state" will
be stored in the local BGP speaker's Adj-RIB-In. be stored in the local BGP speaker's Adj-RIB-In.
Following is a sample pseudo code for prefix validation function: Following is a sample pseudo code for prefix validation function:
//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 //origin_as is the rightmost AS in the final AS_SEQUENCE of
//the AS_PATH attribute in the UPDATE message. //the AS_PATH attribute in the UPDATE message.
// //
//If the UPDATE message carries [AS4_]AGGREGATOR attribute, //origin_as is NONE if the AS_PATH contains an AS_SET
//origin_as is derived from the AS field of that attribute. //path segment type.
//
//origin_as is NONE if the AS_PATH begins with a non-trivial
//AS_SET and has no [AS4_]AGGREGATOR attribute.
input = {bgp_prefix, masklen, origin_as}; input = {bgp_prefix, masklen, 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 RPKI cache based on the IP address and the minLength
//field. There can be multiple such entries that match the //field. There can be multiple such entries that match the
//input. Iterate through all of them. //input. Iterate through all of them.
entry = next_lookup_result(pfx_validate_table, entry = next_lookup_result(pfx_validate_table,
skipping to change at page 7, line 40 skipping to change at page 7, line 36
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 6. Section 5.
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 4. Interaction with Local Cache
Each BGP speaker supporting prefix validation as described in this Each BGP speaker supporting prefix validation as described in this
document is expected to communicate with one or multiple local caches document is expected to communicate with one or multiple local caches
that store a database of RPKI signed objects. The protocol that store a database of RPKI signed objects. The protocol
mechanisms used to fetch the data and store them locally at the BGP mechanisms used to fetch the data and store them locally at the BGP
speaker is beyond the scope of this document (please refer speaker is beyond the scope of this document (please refer
[I-D.ymbk-rpki-rtr-protocol]). Irrespective of the protocol, the [I-D.ymbk-rpki-rtr-protocol]). Irrespective of the protocol, the
prefix validation algorithm as outlined in this document is expected prefix validation algorithm as outlined in this document is expected
to function correctly in the event of failures and other timing to function correctly in the event of failures and other timing
conditions that may result in an empty and/or partial prefix-to-AS conditions that may result in an empty and/or partial prefix-to-AS
skipping to change at page 8, line 35 skipping to change at page 8, line 23
subsequent incremental updates of the validation database. subsequent incremental updates of the validation database.
In the event that connectivity to the cache is lost, the router In the event that connectivity to the cache is lost, the router
should make a reasonable effort to fetch a new validation database should make a reasonable effort to fetch a new validation database
(either from the same, or a different cache), and SHOULD wait until (either from the same, or a different cache), and SHOULD wait until
the new validation database has been fetched before purging the the new validation database has been fetched before purging the
previous one. A configurable timer MUST be provided to bound the previous one. A configurable timer MUST be provided to bound the
length of time the router will wait before purging the previous length of time the router will wait before purging the previous
validation database. validation database.
6. Deployment Considerations 5. Deployment Considerations
Once a route is received from an EBGP peer it is categorized Once a route is received from an EBGP peer it is categorized
according the procedure given in Section 2. Subsequently, routing according the procedure given in Section 2. Subsequently, routing
policy as discussed in Section 3 can be used to take action based on policy as discussed in Section 3 can be used to take action based on
the validation state. the validation state.
Policies which could be implemented include filtering routes based on Policies which could be implemented include filtering routes based on
validation state (for example, rejecting all "invalid" routes) or validation state (for example, rejecting all "invalid" routes) or
adjusting a route's degree of preference in the selection algorithm adjusting a route's degree of preference in the selection algorithm
based on its validation state. The latter could be accomplished by based on its validation state. The latter could be accomplished by
adjusting the value of such attributes as LOCAL_PREF. 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.
In some cases (particularly when the selection algorithm is In some cases (particularly when the selection algorithm is
influenced by the adjustment of a route property that is not influenced by the adjustment of a route property that is not
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.
7. Contributors 6. Contributors
Rex Fernando rex@cisco.com Rex Fernando rex@cisco.com
Keyur Patel keyupate@cisco.com Keyur Patel keyupate@cisco.com
Cisco Systems Cisco Systems
Miya Kohno mkohno@juniper.net Miya Kohno mkohno@juniper.net
Juniper Networks Juniper Networks
Shin Miyakawa miyakawa@nttv6.jp Shin Miyakawa miyakawa@nttv6.jp
Taka Mizuguchi Taka Mizuguchi
Tomoya Yoshida Tomoya Yoshida
skipping to change at page 9, line 32 skipping to change at page 9, line 26
Russ Housley housley@vigilsec.com Russ Housley housley@vigilsec.com
Vigil Security Vigil Security
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
8. 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.
9. IANA Considerations 8. IANA Considerations
10. 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
"invalid" routes are blocked as this specification suggests, the "invalid" routes are blocked as this specification suggests, the
overall system provides a possible denial-of-service vector, for overall system provides a possible denial-of-service vector, for
example if an attacker is able to inject one or more spoofed records 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 into the validation database which lead a good route to be declared
invalid. In addition, this system is only able to provide limited invalid. In addition, this system is only able to provide limited
protection against a determined attacker -- the attacker need only protection against a determined attacker -- the attacker need only
prepend the "valid" source AS to a forged BGP route announcement in prepend the "valid" source AS to a forged BGP route announcement in
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.
11. References 10. References
11.1. Normative References 10.1. Normative References
[I-D.ietf-sidr-arch] [I-D.ietf-sidr-arch]
Lepinski, M. and S. Kent, "An Infrastructure to Support Lepinski, M. and S. Kent, "An Infrastructure to Support
Secure Internet Routing", draft-ietf-sidr-arch-09 (work in Secure Internet Routing", draft-ietf-sidr-arch-09 (work in
progress), October 2009. progress), October 2009.
[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-06 (work in progress), draft-ietf-sidr-roa-format-06 (work in progress),
skipping to change at page 10, line 39 skipping to change at page 10, line 32
[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.
11.2. Informative References 10.2. Informational References
[I-D.ymbk-rpki-rtr-protocol] [I-D.ymbk-rpki-rtr-protocol]
Bush, R. and R. Austein, "The RPKI/Router Protocol", Bush, R. and R. Austein, "The RPKI/Router Protocol",
draft-ymbk-rpki-rtr-protocol-05 (work in progress), draft-ymbk-rpki-rtr-protocol-05 (work in progress),
February 2010. February 2010.
Authors' Addresses Authors' Addresses
Pradosh Mohapatra (editor) Pradosh Mohapatra (editor)
Cisco Systems Cisco Systems
 End of changes. 24 change blocks. 
62 lines changed or deleted 44 lines changed or added

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