draft-ietf-sidr-pfx-validate-06.txt   draft-ietf-sidr-pfx-validate-07.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: November 23, 2012 Juniper Networks Expires: December 01, 2012 Juniper Networks
D. Ward D. Ward
Cisco Systems Cisco Systems
R. Bush R. Bush
Internet Initiative Japan, Inc. Internet Initiative Japan
R. Austein R. Austein
Dragon Research Labs Dragon Research Labs
May 22, 2012 June 2012
BGP Prefix Origin Validation BGP Prefix Origin Validation
draft-ietf-sidr-pfx-validate-06 draft-ietf-sidr-pfx-validate-07
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
mechanism to partially satisfy this requirement. mechanism to partially satisfy this requirement.
Status of this Memo Status of This Memo
This Internet-Draft is submitted 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). 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 November 23, 2012. This Internet-Draft will expire on December 01, 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/
(http://trustee.ietf.org/license-info) in effect on the date of license-info) in effect on the date of publication of this document.
publication of this document. Please review these documents Please review these documents carefully, as they describe your rights
carefully, as they describe your rights and restrictions with respect and restrictions with respect to this document. Code Components
to this document. Code Components extracted from this document must extracted from this document must include Simplified BSD License text
include Simplified BSD License text as described in Section 4.e of as described in Section 4.e of the Trust Legal Provisions and are
the Trust Legal Provisions and are provided without warranty as provided without warranty as described in the Simplified 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 . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Prefix-to-AS Mapping Database . . . . . . . . . . . . . . . . 5 2. Prefix-to-AS Mapping Database . . . . . . . . . . . . . . . . 4
2.1. Pseudo-Code . . . . . . . . . . . . . . . . . . . . . . . 7 2.1. Pseudo-Code . . . . . . . . . . . . . . . . . . . . . . . 5
3. Policy Control . . . . . . . . . . . . . . . . . . . . . . . . 8 3. Policy Control . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Interaction with Local Cache . . . . . . . . . . . . . . . . . 8 4. Interaction with Local Cache . . . . . . . . . . . . . . . . . 6
5. Deployment Considerations . . . . . . . . . . . . . . . . . . 8 5. Deployment Considerations . . . . . . . . . . . . . . . . . . 7
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 8. Security Considerations . . . . . . . . . . . . . . . . . . . 7
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
9.1. Normative References . . . . . . . . . . . . . . . . . . . 10 9.1. Normative References . . . . . . . . . . . . . . . . . . . 8
9.2. Informational References . . . . . . . . . . . . . . . . . 10 9.2. Informational References . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9
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 4, line 51 skipping to change at page 3, line 36
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.
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-
[I-D.ietf-sidr-rpki-rtr] for such a mechanism). This document sidr-rpki-rtr] for such a mechanism). This document proposes a means
proposes a means by which a BGP speaker can make use of the processed by which a BGP speaker can make use of the processed data in order to
data in order to assign a "validation state" to each prefix in a assign a "validation state" to each prefix in a received BGP UPDATE
received BGP UPDATE message. 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.
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
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
locally stored object as a "Validated ROA Payload" or "VRP". stored object as a "Validated ROA Payload" or "VRP".
We define several terms in addition to "VRP". 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 VRP Prefix: The Prefix from a VRP. o VRP Prefix: The Prefix from a VRP.
o VRP ASN: The origin AS number from a VRP. 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 as o Route Origin ASN: The origin AS number derived from a Route as
skipping to change at page 6, line 19 skipping to change at page 4, line 47
AS_CONFED_SEQUENCE or AS_CONFED_SET or if the AS_PATH is empty, AS_CONFED_SEQUENCE or AS_CONFED_SET or if the AS_PATH is empty,
or or
* the distinguished value "NONE" if the final segment of the * the distinguished value "NONE" if the final segment of the
AS_PATH attribute is of any other type. AS_PATH attribute is of any other type.
o Covered: A Route Prefix is said to be Covered by a VRP when the o Covered: A Route Prefix is said to be Covered by a VRP when the
VRP prefix length is less than or equal to the Route prefix VRP prefix length is less than or equal to the Route prefix
length, and the VRP prefix address and the Route prefix address length, and the VRP prefix address and the Route prefix address
are identical for all bits specified by the VRP prefix are identical for all bits specified by the VRP prefix
length.(I.e. the Route prefix is either identical to the VRP length.(I.e. the Route prefix is either identical to the VRP
prefix or a more specific of the VRP prefix.) prefix or a more specific of the VRP prefix.)
o Matched: A Route Prefix is said to be Matched by a VRP when the o Matched: A Route Prefix is said to be Matched by a VRP when the
Route Prefix is Covered by that VRP 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 VRP maximum length and prefix length is less than or equal to the VRP maximum length and
the Route Origin ASN is equal to the VRP ASN. the Route Origin ASN is equal to the VRP ASN.
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 VRP Covers the Route Prefix. o NotFound: No VRP Covers the Route Prefix.
o Valid: At least one VRP Matches the Route Prefix. o Valid: At least one VRP Matches the Route Prefix.
o Invalid: At least one VRP Covers the Route Prefix, but no VRP o Invalid: At least one VRP Covers the Route Prefix, but no VRP
Matches it. Matches it.
We observe that no VRP can have the value "NONE" as its VRP ASN. We observe that no VRP can have the value "NONE" as its VRP ASN. Thus
Thus a Route whose Origin ASN is "NONE" cannot be Matched by any VRP. a Route whose Origin ASN is "NONE" cannot be Matched by any VRP.
Similarly, no valid Route can have an Origin ASN of zero Similarly, no valid Route can have an Origin ASN of zero [I-D.ietf-
[I-D.ietf-idr-as0]. Thus no Route can be Matched by a VRP whose ASN idr-as0]. Thus no Route can be Matched by a VRP whose ASN is zero.
is zero.
When a BGP speaker receives an UPDATE from a neighbor, it SHOULD When a BGP speaker receives an UPDATE from a neighbor, it SHOULD
perform a lookup as described above for each of the Routes in the perform a lookup as described above for each of the Routes in the
UPDATE message. The lookup SHOULD also be applied to routes which UPDATE message. The lookup SHOULD also be applied to routes which
are redistributed into BGP from another source, such as another are redistributed into BGP from another source, such as another
protocol or a locally defined static route. An implementation MAY protocol or a locally defined static route. An implementation MAY
provide configuration options to control which routes the lookup is provide configuration options to control which routes the lookup is
applied to. The "validation state" of the Route MUST be set to applied to. The "validation state" of the Route MUST be set to
reflect the result of the lookup. The implementation should consider reflect the result of the lookup. The implementation should consider
the "validation state" as described in the document as a local the "validation state" as described in the document as a local
property or attribute of the Route. If validation is not performed property or attribute of the Route. If validation is not performed
on a Route, the implementation SHOULD initialize the "validation on a Route, the implementation SHOULD initialize the "validation
state" of such a route to "NotFound". 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 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 from consideration in the decision process as a side-effect of its
validation state, unless explicitly configured to do so. 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
VRP. This procedure does not mandate an order in which VRPs 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.
result = BGP_PFXV_STATE_NOT_FOUND; result = BGP_PFXV_STATE_NOT_FOUND;
//Iterate through all the Covering entries in the local VRP //Iterate through all the Covering entries in the local VRP
//database, pfx_validate_table. //database, pfx_validate_table.
entry = next_lookup_result(pfx_validate_table, route_prefix); entry = next_lookup_result(pfx_validate_table, route_prefix);
while (entry != NULL) { while (entry != NULL) {
prefix_exists = TRUE; prefix_exists = TRUE;
if (route_prefix_length <= entry->max_length) { if (route_prefix_length <= entry->max_length) {
if (route_origin_as != NONE if (route_origin_as != NONE
&& entry->origin_as != 0 && entry->origin_as != 0
&& route_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 one or more VRP entries Covered the route prefix, but //If one or more VRP entries Covered the route prefix, but
//no one Matched, return "Invalid" validation state. //no one Matched, return "Invalid" validation state.
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
see [I-D.ietf-sidr-origin-ops]. [I-D.ietf-sidr-origin-ops].
An implementation MUST support Four-Octet AS Numbers, [RFC4893]. An implementation MUST also 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 more RPKI caches, document is expected to communicate with one or more RPKI caches,
each of which stores a local copy of the global RPKI database. The each of which stores a local copy of the global RPKI database. The
protocol mechanisms used to gather and validate these data and protocol mechanisms used to gather and validate these data and
present them to BGP speakers are described in present them to BGP speakers are described in [I-D.ietf-sidr-rpki-
[I-D.ietf-sidr-rpki-rtr]. rtr].
The prefix-to-AS mappings used by the BGP speaker are expected to be The prefix-to-AS mappings used by the BGP speaker are expected to be
updated over time. When a mapping is added or deleted, the updated over time. When a mapping is added or deleted, the
implementation MUST re-validate any affected prefixes. An "affected implementation MUST re-validate any affected prefixes and run the BGP
prefix" is any prefix that was matched by a deleted or updated decision process if needed. An "affected prefix" is any prefix that
mapping, or could be matched by an added mapping. was matched by a deleted or updated mapping, or could be matched by
an added mapping.
5. Deployment Considerations 5. Deployment Considerations
Once a Route is selected for validation, it is categorized according Once a Route is selected for validation, it is categorized according
the procedure given in Section 2. Subsequently, routing policy as the procedure given in Section 2. Subsequently, routing policy as
discussed in Section 3 can be used to take action based on the discussed in Section 3 can be used to take action based on 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.
skipping to change at page 10, line 4 skipping to change at page 8, line 26
against a determined attacker -- the attacker need only prepend the against a determined attacker -- the attacker need only prepend the
"valid" source AS to a forged BGP route announcement in order to "valid" source AS to a forged BGP route announcement in order to
defeat the protection provided by this system. defeat the protection provided by this system.
This mechanism does not protect against "AS in the middle attacks" or 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.
9. References 9. References
9.1. Normative References 9.1. Normative References
[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.
[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] [I-D.ietf-idr-as0]
Kumari, W., Bush, R., Schiller, H., and K. Patel, Kumari, W., Bush, R., Schiller, H. and K. Patel,
"Codification of AS 0 processing.", draft-ietf-idr-as0-04 "Codification of AS 0 processing.", Internet-Draft draft-
(work in progress), May 2012. ietf-idr-as0-05, May 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), Internet-Draft draft-ietf-sidr-origin-ops-16, May 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), Internet-Draft draft-ietf-sidr-rpki-rtr-26, February 2012.
February 2012.
[RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support
Secure Internet Routing", RFC 6480, February 2012. Secure Internet Routing", RFC 6480, February 2012.
Authors' Addresses Authors' Addresses
Pradosh Mohapatra 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
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 David Ward
Cisco Systems Cisco Systems
170 W. Tasman Drive 170 W. Tasman Drive
San Jose, CA 95134 San Jose, CA 95134
USA USA
Email: dward@cisco.com Email: dward@cisco.com
Randy Bush Randy Bush
Internet Initiative Japan, Inc. Internet Initiative Japan
5147 Crystal Springs 5147 Crystal Springs
Bainbridge Island, Washington 98110 Bainbridge Island, Washington 98110
USA USA
Email: randy@psg.com Email: randy@psg.com
Rob Austein Rob Austein
Dragon Research Labs Dragon Research Labs
Email: sra@hactrn.net Email: sra@hactrn.net
 End of changes. 38 change blocks. 
90 lines changed or deleted 88 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/