draft-ietf-sidr-pfx-validate-03.txt   draft-ietf-sidr-pfx-validate-04.txt 
Network Working Group P. Mohapatra, Ed. Network Working Group P. Mohapatra
Internet-Draft Cisco Systems Internet-Draft Cisco Systems
Intended status: Standards Track J. Scudder, Ed. Intended status: Standards Track J. Scudder
Expires: May 3, 2012 D. Ward, Ed. Expires: September 13, 2012 Juniper Networks
Juniper Networks D. Ward
R. Bush, Ed. Cisco Systems
R. Bush
Internet Initiative Japan, Inc. Internet Initiative Japan, Inc.
R. Austein, Ed. R. Austein
Internet Systems Consortium Dragon Research Labs
October 31, 2011 March 12, 2012
BGP Prefix Origin Validation BGP Prefix Origin Validation
draft-ietf-sidr-pfx-validate-03 draft-ietf-sidr-pfx-validate-04
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 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 May 3, 2012. This Internet-Draft will expire on September 13, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 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
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
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
2.1. Pseudo-Code . . . . . . . . . . . . . . . . . . . . . . . 6 2.1. Pseudo-Code . . . . . . . . . . . . . . . . . . . . . . . 7
3. Policy Control . . . . . . . . . . . . . . . . . . . . . . . . 9 3. Policy Control . . . . . . . . . . . . . . . . . . . . . . . . 8
4. Interaction with Local Cache . . . . . . . . . . . . . . . . . 9 4. Interaction with Local Cache . . . . . . . . . . . . . . . . . 8
5. Deployment Considerations . . . . . . . . . . . . . . . . . . 9 5. Deployment Considerations . . . . . . . . . . . . . . . . . . 8
6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 10 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9
9. Security Considerations . . . . . . . . . . . . . . . . . . . 11 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 9.1. Normative References . . . . . . . . . . . . . . . . . . . 10
10.1. Normative References . . . . . . . . . . . . . . . . . . . 11 9.2. Informational References . . . . . . . . . . . . . . . . . 10
10.2. Informational References . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
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
origination AS of BGP routes. More specifically, one needs to origination AS of BGP routes. More specifically, one needs to
validate that the AS number claiming to originate an address prefix 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 (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 authorized by the prefix holder to do so. This document describes a
simple validation mechanism to partially satisfy this requirement. simple validation mechanism to partially satisfy this requirement.
The Resource Public Key Infrastructure (RPKI) describes an approach The Resource Public Key Infrastructure (RPKI) describes an approach
to build a formally verifyable database of IP addresses and AS to build a formally verifiable database of IP addresses and AS
numbers as resources. The overall architecture of RPKI as defined in numbers as resources. The overall architecture of RPKI as defined in
[I-D.ietf-sidr-arch] consists of three main components: [RFC6480] consists of three main components:
o A public key infrastructure (PKI) with the necessary certificate o A public key infrastructure (PKI) with the necessary certificate
objects, objects,
o Digitally signed routing objects, o Digitally signed routing objects,
o A distributed repository system to hold the objects that would o A distributed repository system to hold the objects that would
also support periodic retrieval. also support periodic retrieval.
The RPKI system is based on resource certificates that define The RPKI system is based on resource certificates that define
extensions to X.509 to represent IP addresses and AS identifiers extensions to X.509 to represent IP addresses and AS identifiers
[RFC3779], thus the name RPKI. Route Origin Authorizations (ROA) [RFC3779], thus the name RPKI. Route Origin Authorizations (ROA)
[I-D.ietf-sidr-roa-format] are separate digitally signed objects that [RFC6482] are separate digitally signed objects that define
define associations between ASes and IP address blocks. Finally the associations between ASes and IP address blocks. Finally the
repository system is operated in a distributed fashion through the repository system is operated in a distributed fashion through the
IANA, RIR hierarchy, and ISPs. IANA, RIR hierarchy, and ISPs.
In order to benefit from the RPKI system, it is envisioned that In order to benefit from the RPKI system, it is envisioned that
relying parties either at AS or organization level obtain a local relying parties either at AS or organization level obtain a local
copy of the signed object collection, verify the signatures, and copy of the signed object collection, verify the signatures, and
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.
skipping to change at page 5, line 40 skipping to change at page 5, line 40
term. term.
We define several terms in addition to "ROA". Where these terms are We define several terms in addition to "ROA". 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, among other things. AS_PATH; it may include other attributes to characterize the
prefix.
o ROA Prefix: The Prefix from a ROA. o ROA Prefix: The Prefix from a ROA.
o ROA ASN: The origin ASN from a ROA. o ROA ASN: The origin AS number from a ROA.
o Route Prefix: A 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 NONE if the final segment of the AS_PATH attribute
is of any type other than AS_SEQUENCE. No ROA can match an origin 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 AS number of "NONE". No Route can match a ROA whose origin AS
number is zero. 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 ROA when the
skipping to change at page 6, line 23 skipping to change at page 6, line 24
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 ROA when the
Route Prefix is Covered by that ROA and in addition, the Route 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 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 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 a ROA ASN of zero can never be matched, nor can a route origin AS
number of "NONE". number of "NONE".
Given these definitions, any given BGP Route learned from an EBGP Given these definitions, any given BGP Route will be found to have
peer will be found to have one of the following "validation states": one of the following "validation states":
o Not found: No ROA Covers the Route Prefix. o NotFound: No ROA Covers the Route Prefix.
o Valid: At least one ROA Matches 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 o Invalid: At least one ROA Covers the Route Prefix, but no ROA
Matches it. Matches it.
When a BGP speaker receives an UPDATE from one of its EBGP peers, 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 SHOULD perform a lookup as described above for each of the Routes in
the UPDATE message. The "validation state" of the Route SHOULD be the UPDATE message. The "validation state" of the Route SHOULD be
set to reflect the result of the lookup. Note that the validation 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 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 the local BGP speaker's Adj-RIB-In. This procedure SHOULD NOT be
performed for Routes learned from peers of types other than EBGP. performed for Routes learned from peers of types other than EBGP.
(Any of these MAY be overridden by configuration.) (Any of these MAY be overridden by configuration.) The suggested
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 "Valid".
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.
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 ROA. This procedure does not mandate an order in which ROAs 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 //Input are the variables derived from a BGP UPDATE message
//that need to be validated. //that need to be validated.
// //
//The input prefix is comprised of prefix.address and //The input prefix is comprised of prefix.address and
//prefix.length. //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 //Collectively, the prefix and origin_as correspond to the
//Route defined in the preceding section. //Route defined in the preceding section.
input = {prefix, origin_as}; input = {prefix, origin_as};
//Initialize result to "not found" state //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 //pfx_validate_table organizes all the ROA entries retrieved
//from the RPKI cache based on the IP address and the prefix //from the RPKI cache based on the IP address and the prefix
//length field. There can be multiple such entries that match //length field. There can be multiple such entries that match
//the input. Iterate through all of them. //the input. Iterate through all of them.
entry = next_lookup_result(pfx_validate_table, input.prefix); 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 (input.prefix.length <= entry->max_length) {
if (input.origin_as != NONE if (input.origin_as != NONE
&& entry->origin_as != 0 && entry->origin_as != 0
&& input.origin_as == entry->origin_as) { && input.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 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. //"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 14
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].
An implementation MUST support Four-Octet AS Numbers, [RFC4893].
4. 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 more RPKI caches,
that store a database of RPKI signed objects. The protocol each of which stores a local copy of the global RPKI database. The
mechanisms used to fetch the data and store them locally at the BGP protocol mechanisms used to gather and validate these data and
speaker is beyond the scope of this document (please refer present them to BGP speakers are described in
[I-D.ietf-sidr-rpki-rtr]). Irrespective of the protocol, the prefix [I-D.ietf-sidr-rpki-rtr].
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.
In the event that connectivity to the cache is lost, the router The prefix-to-AS mappings used by the BGP speaker are expected to be
should make a reasonable effort to fetch a new validation database updated over time. When a mapping is added or deleted, the
(either from the same, or a different cache), and SHOULD wait until implementation MUST re-validate any affected prefixes. An "affected
the new validation database has been fetched before purging the prefix" is any prefix that was matched by a deleted or updated
previous one. A configurable timer MUST be provided to bound the mapping, or could be matched by an added mapping.
length of time the router will wait before purging the previous
validation database.
5. Deployment Considerations 5. Deployment Considerations
Once a route is received from an EBGP peer it is categorized Once a Route is selected for validation, it is categorized according
according the procedure given in Section 2. Subsequently, routing the procedure given in Section 2. Subsequently, routing policy as
policy as discussed in Section 3 can be used to take action based on discussed in Section 3 can be used to take action based on the
the validation state. 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. Considering adjusting the value of such attributes as LOCAL_PREF. Considering
invalid routes for BGP decision process is a pure local policy matter invalid routes for BGP decision process is a pure local policy matter
and should be done with utmost care. 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.
6. Contributors 6. Acknowledgments
Rex Fernando rex@cisco.com
Keyur Patel keyupate@cisco.com
Cisco Systems
Miya Kohno mkohno@juniper.net
Juniper Networks
Shin Miyakawa miyakawa@nttv6.jp
Taka Mizuguchi
Tomoya Yoshida
NTT Communications
Russ Housley housley@vigilsec.com
Vigil Security
Junaid Israr jisra052@uottawa.ca
Mouhcine Guennoun mguennou@uottawa.ca
Hussein Mouftah mouftah@site.uottawa.ca
University of Ottawa School of Information Technology and
Engineering(SITE) 800 King Edward Avenue, Ottawa, Ontario, Canada,
K1N 6N5
7. Acknowledgements The authors wish to thank Rex Fernando, Hannes Gredler, Mouhcine
Guennoun, Russ Housley, Junaid Israr, Miya Kohno, Shin Miyakawa, Taka
Mizuguchi, Hussein Mouftah, Keyur Patel, Tomoya Yoshida, and Kannan
Varadhan. The authors are grateful for the feedback from the members
of the SIDR working group.
Junaid Israr's contribution to this specification is part of his PhD Junaid Israr's contribution to this specification was part of his PhD
research work and thesis at University of Ottawa, Canada. Hannes research work and thesis at University of Ottawa.
Gredler provided valuable feedback.
8. IANA Considerations 7. IANA Considerations
9. 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
(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 or remove one or more
into the validation database which lead a good route to be declared records in the validation database, it could lead an otherwise valid
invalid. In addition, this system is only able to provide limited route to be marked as invalid.
protection against a determined attacker -- the attacker need only
prepend the "valid" source AS to a forged BGP route announcement in In addition, this system is only able to provide limited protection
order to defeat the protection provided by this system. This against a determined attacker -- the attacker need only prepend the
mechanism does not protect against "AS in the middle attacks" or "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. 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 9. References
9.1. Normative References
10.1. Normative References
[I-D.ietf-sidr-roa-format]
Lepinski, M., Kent, S., and D. Kong, "A Profile for Route
Origin Authorizations (ROAs)",
draft-ietf-sidr-roa-format-12 (work in progress),
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 [RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing
(CIDR): The Internet Address Assignment and Aggregation (CIDR): The Internet Address Assignment and Aggregation
Plan", BCP 122, RFC 4632, August 2006. Plan", BCP 122, RFC 4632, August 2006.
10.2. Informational References [RFC4893] Vohra, Q. and E. Chen, "BGP Support for Four-octet AS
Number Space", RFC 4893, May 2007.
[I-D.ietf-sidr-arch] [RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route
Lepinski, M. and S. Kent, "An Infrastructure to Support Origin Authorizations (ROAs)", RFC 6482, February 2012.
Secure Internet Routing", draft-ietf-sidr-arch-13 (work in
progress), May 2011. 9.2. Informational References
[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-12 (work in progress), draft-ietf-sidr-origin-ops-15 (work in progress),
October 2011. 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-19 (work in progress), draft-ietf-sidr-rpki-rtr-26 (work in progress),
October 2011. February 2012.
[RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support
Secure Internet Routing", RFC 6480, February 2012.
Authors' Addresses Authors' Addresses
Pradosh Mohapatra (editor) Pradosh Mohapatra
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
John Scudder
John Scudder (editor)
Juniper Networks Juniper Networks
1194 N. Mathilda Ave 1194 N. Mathilda Ave
Sunnyvale, CA 94089 Sunnyvale, CA 94089
USA USA
Email: jgs@juniper.net Email: jgs@juniper.net
David Ward (editor) David Ward
Juniper Networks Cisco Systems
1194 N. Mathilda Ave 170 W. Tasman Drive
Sunnyvale, CA 94089 San Jose, CA 95134
USA USA
Email: dward@juniper.net Email: dward@cisco.com
Randy Bush (editor)
Randy Bush
Internet Initiative Japan, Inc. Internet Initiative Japan, Inc.
5147 Crystral Springs 5147 Crystal Springs
Bainbridge Island, Washington 98110 Bainbridge Island, Washington 98110
USA USA
Email: randy@psg.com Email: randy@psg.com
Rob Austein (editor) Rob Austein
Internet Systems Consortium Dragon Research Labs
950 Charter Street
Redwood City, CA 94063
USA
Email: sra@isc.org Email: sra@hactrn.net
 End of changes. 46 change blocks. 
150 lines changed or deleted 114 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/