draft-ietf-sidr-roa-validation-06.txt | draft-ietf-sidr-roa-validation-07.txt | |||
---|---|---|---|---|
Secure Inter-Domain Routing (SIDR) G. Huston | Secure Inter-Domain Routing (SIDR) G. Huston | |||
Internet-Draft G. Michaelson | Internet-Draft G. Michaelson | |||
Intended status: Informational APNIC | Intended status: Informational APNIC | |||
Expires: November 9, 2010 May 8, 2010 | Expires: April 13, 2011 October 10, 2010 | |||
Validation of Route Origination using the Resource Certificate PKI and | Validation of Route Origination using the Resource Certificate PKI and | |||
ROAs | ROAs | |||
draft-ietf-sidr-roa-validation-06.txt | draft-ietf-sidr-roa-validation-07.txt | |||
Abstract | Abstract | |||
This document defines the semantics of a Route Origin Authorization | This document defines the semantics of a Route Origin Authorization | |||
in terms of the context of an application of the Resource Public Key | (ROA) in terms of the context of an application of the Resource | |||
Infrastructure to validate the origination of routes advertised in | Public Key Infrastructure to validate the origination of routes | |||
the Border Gateway Protocol. | advertised in the Border Gateway Protocol. | |||
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 9, 2010. | This Internet-Draft will expire on April 13, 2011. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2010 IETF Trust and the persons identified as the | Copyright (c) 2010 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 2, line 10 | skipping to change at page 2, line 10 | |||
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 Simplified BSD License. | described in the Simplified BSD License. | |||
Table of Contents | Table of Contents | |||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
2. ROA Validation Outcomes for a Route . . . . . . . . . . . . . . 3 | 2. ROA Validation Outcomes for a Route . . . . . . . . . . . . . . 3 | |||
3. Applying Validation Outcomes to Route Selection . . . . . . . . 6 | 3. Applying Validation Outcomes to Route Selection . . . . . . . . 6 | |||
4. Disavowal of Routing Origination . . . . . . . . . . . . . . . 6 | 4. Disavowal of Routing Origination . . . . . . . . . . . . . . . 7 | |||
5. Route Validation Lifetime . . . . . . . . . . . . . . . . . . . 7 | 5. Route Validation Lifetime . . . . . . . . . . . . . . . . . . . 7 | |||
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 | 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 | |||
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 | 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 | |||
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 | 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 | |||
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 | 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 | |||
9.1. Normative References . . . . . . . . . . . . . . . . . . . 8 | 9.1. Normative References . . . . . . . . . . . . . . . . . . . 9 | |||
9.2. Informative References . . . . . . . . . . . . . . . . . . 9 | 9.2. Informative References . . . . . . . . . . . . . . . . . . 9 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 | |||
1. Introduction | 1. Introduction | |||
This document defines the semantics of a Route Origin Authorization | This document defines the semantics of a Route Origin Authorization | |||
(ROA) in terms of the context of an application of the Resource | (ROA) in terms of the context of an application of the Resource | |||
Public Key Infrastructure (RPKI) [I-D.ietf-sidr-arch] to validate the | Public Key Infrastructure (RPKI) [I-D.ietf-sidr-arch] to validate the | |||
origination of routes advertised in the Border Gateway Protocol (BGP) | origination of routes advertised in the Border Gateway Protocol (BGP) | |||
[RFC4271]. | [RFC4271]. | |||
skipping to change at page 4, line 20 | skipping to change at page 4, line 20 | |||
It is assumed here that a Relying Party (RP) has access to a local | It is assumed here that a Relying Party (RP) has access to a local | |||
cache of the complete set of valid ROAs when performing validation of | cache of the complete set of valid ROAs when performing validation of | |||
a route. (Valid ROAs are defined as ROAs that are determined to be | a route. (Valid ROAs are defined as ROAs that are determined to be | |||
syntactically correct and are signed using a signature that can be | syntactically correct and are signed using a signature that can be | |||
verified using the RPKI, as described in [I-D.ietf-sidr-roa-format].) | verified using the RPKI, as described in [I-D.ietf-sidr-roa-format].) | |||
The RP needs to match a route to one or more candidate valid ROAs in | The RP needs to match a route to one or more candidate valid ROAs in | |||
order to determine a validation outcome, which, in turn, can be used | order to determine a validation outcome, which, in turn, can be used | |||
to determine the appropriate local actions to perform on the route. | to determine the appropriate local actions to perform on the route. | |||
This approach to route origination validation uses a model of | This approach to route origination validation uses a generic model of | |||
"positive" attestations, with an associated inference that route that | "positive" attestation that has an associated inference that routes | |||
cannot be validated within the RPKI framework would conventionally be | that cannot be validated within the RPKI framework would | |||
interpreted by a RP as "invalid". However, the considerations of | conventionally be interpreted by a RP as "invalid". However, the | |||
accommodating environments of partial adoption of the use of ROAs, | considerations of accommodating environments of partial adoption of | |||
where only a subset of validly advertised address prefixes have | the use of ROAs, where only a subset of validly advertised address | |||
associated published ROAs within the structure of the RPKI, imply | prefixes have associated published ROAs within the structure of the | |||
some modification to this model of positive attestation. In the | RPKI, imply some modification to this model of positive attestation. | |||
context of route validation it is assumed that once an address prefix | In the context of route validation it is assumed that once an address | |||
is described in a ROA, then this ROA specifically encompasses all | prefix is described in a ROA, then this ROA specifically encompasses | |||
address prefixes that are more specific than that described in the | all address prefixes that are more specific than that described in | |||
ROA. Thus, any route for more specific address prefix than that | the ROA. Thus, any route for a more specific address prefix than | |||
described by any valid ROA that does not itself have a matching valid | that described by any valid ROA that does not itself have a matching | |||
ROA is considered to be "invalid". However, routes objects for | valid ROA can be considered to be "invalid". However, routes objects | |||
address prefixes that are not fully described by any single ROA, | for address prefixes that are not fully described by any single ROA, | |||
i.e., those route objects whose address prefixes may be an aggregate | i.e., those route objects whose address prefixes may be an aggregate | |||
of address prefixes described in a valid ROA, or have address | of address prefixes described in a valid ROA, or have address | |||
prefixes where there is no intersection with any ROA, and are not | prefixes where there is no intersection with any ROA, and are not | |||
matched by any ROA and are not a more specific of any ROA, cannot be | matched by any ROA and are not a more specific of any ROA, cannot be | |||
reliably classified as "invalid" in a partial deployment scenario. | reliably classified as "invalid" in a partial deployment scenario. | |||
Such routes have a validation outcome of "unknown". | Such routes have a validation outcome of "unknown". | |||
The validation condition of a route with a prefix and an origin AS | An abstract attribute of a route can be determined as the outcome of | |||
when using single ROA for validation is summarized in the following | this validation procedure, namely a "validity state" | |||
table: | [I-D.ietf-sidr-pfx-validate]. The "validity state" of a route, with | |||
a prefix and an origin AS as defined above, when using single ROA for | ||||
determining this validity state is summarized in the following table: | ||||
Prefix matching non-matching | Route matching non-matching | |||
AS AS | Prefix AS-> AS AS | |||
+---------+-------------+ | V +---------+---------+ | |||
Covering | unknown | unknown | | Non- | unknown | unknown | | |||
Aggregate | | | | Intersecting | | | | |||
+---------+-------------+ | +---------+---------+ | |||
match ROA | valid | invalid | | Covering | unknown | unknown | | |||
prefix | | | | Aggregate | | | | |||
+---------+-------------+ | +---------+---------+ | |||
More | invalid | invalid | | match ROA | valid | invalid | | |||
Specific | | | | prefix | | | | |||
than ROA | | | | +---------+---------+ | |||
+---------+-------------+ | More | | | | |||
Specific | invalid | invalid | | ||||
than ROA | | | | ||||
+---------+---------+ | ||||
In an environment of a collection of ROAs, a route is considered to | Route's Validity State | |||
be "valid" if any ROA provides a "valid" outcome. It is considered | ||||
to be "invalid" if one (or more) ROAs provide an "invalid" outcome | In an environment of a collection of valid ROAs, a route's validity | |||
and no ROAs provide a "valid" outcome. It is considered to be | state is considered to be "valid" if any ROA provides a "valid" | |||
"unknown" when no ROA produces either a "valid" or an "invalid" | outcome. It's validity state is considered to be "invalid" if one | |||
(or more) ROAs provide an "invalid" outcome and no ROAs provide a | ||||
"valid" outcome. Its validity state is considered to be "unknown" | ||||
(or, synonymously, "not found" [I-D.ietf-sidr-pfx-validate] when no | ||||
valid ROA can produce either a "valid" or an "invalid" validity state | ||||
outcome. | outcome. | |||
Route validation is defined by the following procedure: | A route validity state is defined by the following procedure: | |||
1. Select all valid ROAs that include a ROAIPAddress value that | 1. Select all valid ROAs that include a ROAIPAddress value that | |||
either matches, or is a covering aggregate of, the address | either matches, or is a covering aggregate of, the address | |||
prefix in the route. This selection forms the set of | prefix in the route. This selection forms the set of | |||
"candidate ROAs." | "candidate ROAs." | |||
2. If the set of candidate ROAs is empty, then the validation | 2. If the set of candidate ROAs is empty, then the procedure | |||
procedure stops with an outcome of "unknown". | stops with an outcome of "unknown" (or, synonymously, "not | |||
found", as used in [I-D.ietf-sidr-pfx-validate]). | ||||
3. If the route's origin AS can be determined and any of the set | 3. If the route's origin AS can be determined and any of the set | |||
of candidate ROAs has an asID value that matches the origin AS | of candidate ROAs has an asID value that matches the origin AS | |||
in the route, and the route object's address prefix matches a | in the route, and the route's address prefix matches a | |||
ROAIPAddress in the ROA (where "match" is defined as where the | ROAIPAddress in the ROA (where "match" is defined as where the | |||
route object's address precisely matches the ROAIPAddress, or | route's address precisely matches the ROAIPAddress, or where | |||
where the ROAIPAddress includes a maxLength element, and the | the ROAIPAddress includes a maxLength element, and the route's | |||
route's address prefix is a more specific prefix of the | address prefix is a more specific prefix of the ROAIPAddress, | |||
ROAIPAddress, and the route's address prefix length value is | and the route's address prefix length value is less than or | |||
less than or equal to the ROAIPAddress maxLength value) then | equal to the ROAIPAddress maxLength value) then the procedure | |||
the validation procedure stops with an outcome of "valid". | halts with an outcome of "valid". | |||
4. Othewise, the validation procedure stops with an outcome of | 4. Otherwise, the procedure halts with an outcome of "invalid". | |||
"invalid". | ||||
3. Applying Validation Outcomes to Route Selection | 3. Applying Validation Outcomes to Route Selection | |||
Within the framework of the abstract model of the operation of inter- | Within the framework of the abstract model of the operation of inter- | |||
domain routing using BGP [RFC4271], a received prefix announcement | domain routing using BGP [RFC4271], a received prefix announcement | |||
from a routing peer is compared to all announcements for this prefix | from a routing peer is compared to all announcements for this prefix | |||
received from other routing peers and a route selection procedure is | received from other routing peers and a route selection procedure is | |||
used to select the "best" route from this candidate set. | used to select the "best" route from this candidate set. | |||
The route validation outcome, described in Section 2, of "unknown", | The route's validity state, described in Section 2, of "valid", | |||
"valid" or "invalid" may be used as part of the determination of the | "invalid" or "unknown" may be used as part of the determination of | |||
local degree of preference, in which case the local order of | the local degree of preference, in which case the local order of | |||
preference is as follows: | preference is as follows: | |||
"valid" is to be preferred over | "valid" is to be preferred over | |||
"unknown", which itself is to be preferred over | "unknown", which is to be preferred over | |||
"invalid". | "invalid". | |||
It is a matter of local routing policy as to the actions to be | It is a matter of local routing policy as to the actions to be | |||
undertaken by a routing entity in processing routes with "unknown" | undertaken by a routing entity in processing those routes with | |||
validation outcomes. Due to considerations of partial use of ROAs in | "unknown" validity states. Due to considerations of partial use of | |||
heterogeneous environments, such as in the public Internet, it is | ROAs in heterogeneous environments, such as in the public Internet, | |||
advised that local policy settings should not result in "unknown" | it is advised that local policy settings should not result in | |||
validation outcomes being considered as sufficient grounds to reject | "unknown" validity state outcomes being considered as sufficient | |||
a route outright from further consideration as a local "best" route. | grounds to reject a route outright from further consideration as a | |||
local "best" route. | ||||
It is a matter of local routing policy as to whether "invalid" routes | It is a matter of local routing policy as to whether routes with an | |||
are considered to be ineligible for further consideration in a route | "invalid" validity state are considered to be ineligible for further | |||
selection process. A possible consideration here is one of potential | consideration in a route selection process. A possible consideration | |||
circularity of dependence. If the authoritative publication point of | here is one of potential circularity of dependence: If the | |||
the repository of ROAs, or that of any certificate used in relation | authoritative publication point of the repository of ROAs, or that of | |||
to an address prefix, is located at an address that lies within the | any certificate used in relation to an address prefix, is located at | |||
address prefix described in a ROA, then the repository can only be | an address that lies within the address prefix described in a ROA, | |||
accessed by the RP once a route for the prefix has been accepted by | then the repository can only be accessed by the RP once a route for | |||
the RP's local routing domain. It is also noted that the propagation | the prefix has been accepted by the RP's local routing domain. It is | |||
time of RPKI objects may be different to the propagation time of | also noted that the propagation time of RPKI objects may be different | |||
routes, and that routes may be learned by an RP's routing system | to the propagation time of routes, and that routes may be learned by | |||
before the RP's local RPKI repository cache picks up the associated | an RP's routing system before the RP's local RPKI repository cache | |||
ROAs and recognises them as valid within the RPKI. | picks up the associated ROAs and recognises them as having a validity | |||
state of "valid" within the RPKI. | ||||
4. Disavowal of Routing Origination | 4. Disavowal of Routing Origination | |||
A ROA is a positive attestation that a prefix holder has authorized | A ROA is a positive attestation that a prefix holder has authorized | |||
an AS to originate a route for this prefix into the inter-domain | an AS to originate a route for this prefix into the inter-domain | |||
routing system. It is possible for a prefix holder to construct an | routing system. It is possible for a prefix holder to construct an | |||
authorization where no valid AS has been granted any such authority | authorization where no valid AS has been granted any such authority | |||
to originate a route for an address prefix. This is achieved by | to originate a route for an address prefix. This is achieved by | |||
using a ROA where the ROA's subject AS is one that must never be used | using a ROA where the ROA's subject AS is one that must not be used | |||
in any routing context. Specifically, AS 0 is reserved by the IANA | in any routing context. Specifically, AS 0 is reserved by the IANA | |||
such that it may be used to identify non-routed networks | such that it may be used to identify non-routed networks | |||
[IANA.AS-Registry]. | [IANA.AS-Registry]. | |||
A ROA with a subject of AS 0 is an attestation by the holder of a | A ROA with a subject of AS 0 (AS0-ROA) is an attestation by the | |||
prefix that the prefix described in the ROA, and any more specific | holder of a prefix that the prefix described in the ROA, and any more | |||
prefix, SHOULD NOT be used in a routing context. | specific prefix, should not be used in a routing context. | |||
The route validation procedure, described in Section 2, will provide | The route validation procedure, described in Section 2, will provide | |||
a "valid" outcome if any ROA matches the address prefix and origin | a "valid" outcome if any ROA matches the address prefix and origin | |||
AS, even if other valid ROAs would provide an "invalid" validation | AS, even if other valid ROAs would provide an "invalid" validation | |||
outcome if used in isolation. Consequently, an AS 0 ROA has a lower | outcome if used in isolation. Consequently, an AS0-ROA has a lower | |||
preference than any other ROA that has a routeable AS as its subject. | relative preference than any other ROA that has a routable AS as its | |||
This allows a prefix holder to use an AS 0 ROA to declare a default | subject. This allows a prefix holder to use an AS0-ROA to declare a | |||
condition that any route that is equal to, or more specific than the | default condition that any route that is equal to, or more specific | |||
prefix to be considered to be invalid, while also allowing other | than the prefix to be considered to be invalid, while also allowing | |||
concurrently issued ROAs to describe valid origination authorizations | other concurrently issued ROAs to describe valid origination | |||
for more specific prefixes. | authorizations for more specific prefixes. | |||
By convention, an AS 0 ROA SHOULD have a maxLength value of 32 for | By convention, an AS0-ROA should have a maxLength value of 32 for | |||
IPv4 addresses and a maxlength value of 128 for IPv6 addresses, | IPv4 addresses and a maxlength value of 128 for IPv6 addresses, | |||
although in terms of route validation the same outcome would be | although in terms of route validation the same outcome would be | |||
achieved with any valid maxLength value, or even if the maxLength | achieved with any valid maxLength value, or even if the maxLength | |||
element were to be omitted from the ROA. | element were to be omitted from the ROA. | |||
Also by convention, an AS 0 ROA SHOULD be the only ROA issued for a | Also by convention, an AS0-ROA should be the only ROA issued for a | |||
given address prefix, although again this is not a strict | given address prefix, although again this is not a strict | |||
requirement. An AS 0 ROA MAY coexist with ROAs that have different | requirement. An AS0-ROA MAY coexist with ROAs that have different | |||
subject AS values, although in such cases the presence of the AS 0 | subject AS values, although in such cases the presence or otherwise | |||
ROA does not alter the route validation outcome in any way. | of the AS0-ROA does not alter the route's validity state in any way. | |||
5. Route Validation Lifetime | 5. Route Validation Lifetime | |||
The "lifetime" of a validation outcome refers to the time period | The "lifetime" of a validation outcome refers to the time period | |||
during which the original validation outcome can be still applied. | during which the original validation outcome can be still applied. | |||
The implicit assumption here is that when the validation lifetime | The implicit assumption here is that when the validation lifetime | |||
expires the routing object SHOULD be re-tested for validity. | expires the routing object should be re-tested for validity. | |||
The validation lifetime for a ROA is controlled by the Valid times | The validation lifetime for a ROA is controlled by the Valid times | |||
specified in the End Entity (EE) Certificate used to sign the ROA, | specified in the End Entity (EE) Certificate used to sign the ROA, | |||
and the valid times of those certificates in the certification path | and the valid times of those certificates in the certification path | |||
used to validate the EE Certificate. A ROA validation "expires" at | used to validate the EE Certificate. A ROA validation "expires" at | |||
the Validity To field of the signing EE certificate, or at such a | the Validity To field of the signing EE certificate, or at such a | |||
time when there is no certification path that can validate the ROA. | time when there is no certification path that can validate the ROA. | |||
A ROA issuer may elect to prematurely invalidate a ROA by revoking | A ROA issuer may elect to prematurely invalidate a ROA by revoking | |||
the EE certificate that was used to sign the ROA. | the EE certificate that was used to sign the ROA. | |||
6. Security Considerations | 6. Security Considerations | |||
ROA issuers should be aware of the validation implication in issuing | ROA issuers should be aware of the validation implication in issuing | |||
a ROA, in that a ROA implicitly invalidates all route objects that | a ROA, in that a ROA implicitly invalidates all routes that have more | |||
have more specific prefixes with a prefix length greater than | specific prefixes with a prefix length greater than maxLength, and | |||
maxLength, and all originating AS's other than the AS listed in the | all originating AS's other than the AS listed in the collection of | |||
collection of ROAs for this prefix. | ROAs for this prefix. | |||
A conservative operational practice would be to ensure the issuing of | A conservative operational practice would be to ensure the issuing of | |||
ROAs for all more specific prefixes with distinct origination AS's | ROAs for all more specific prefixes with distinct origination AS's | |||
prior to the issuing of ROAs for larger encompassing address blocks, | prior to the issuing of ROAs for larger encompassing address blocks, | |||
in order to avoid inadvertent invalidation of valid routes during ROA | in order to avoid inadvertent invalidation of valid routes during ROA | |||
generation. | generation. | |||
ROA issuers should also be aware that if they generate a ROA for one | ROA issuers should also be aware that if they generate a ROA for one | |||
origin AS, then if the address prefix holder authorises multiple AS's | origin AS, then if the address prefix holder authorises multiple AS's | |||
to originate routes for a given address prefix, then is necessary for | to originate routes for a given address prefix, then is necessary for | |||
skipping to change at page 8, line 37 | skipping to change at page 8, line 44 | |||
8. Acknowledgements | 8. Acknowledgements | |||
The authors would like to acknowledge the helpful contributions of | The authors would like to acknowledge the helpful contributions of | |||
John Scudder and Stephen Kent in preparing this document, and also | John Scudder and Stephen Kent in preparing this document, and also | |||
the contributions of many members of the SIDR Working Group in | the contributions of many members of the SIDR Working Group in | |||
response to presentations of this material in SIDR WG sessions. The | response to presentations of this material in SIDR WG sessions. The | |||
authors also acknowledge prior work undertaken by Tony Bates, Randy | authors also acknowledge prior work undertaken by Tony Bates, Randy | |||
Bush, Tony Li, and Yakov Rekhter as the validation outcomes described | Bush, Tony Li, and Yakov Rekhter as the validation outcomes described | |||
here reflect the authentication outcomes and semantics of origin AS | here reflect the authentication outcomes and semantics of origin AS | |||
verification described in [exI-D.bates]. | verification described in [exI-D.bates]. A number of validation | |||
concepts relating to a route's "validity state" presented in | ||||
[I-D.ietf-sidr-pfx-validate], edited by Pradosh Mohapatra et al, have | ||||
be used in this document. | ||||
9. References | 9. References | |||
9.1. Normative References | 9.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 (work in | Secure Internet Routing", draft-ietf-sidr-arch (work in | |||
progress), October 2009. | progress), October 2009. | |||
skipping to change at page 9, line 21 | skipping to change at page 9, line 33 | |||
[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. | |||
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., | [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., | |||
Housley, R., and W. Polk, "Internet X.509 Public Key | Housley, R., and W. Polk, "Internet X.509 Public Key | |||
Infrastructure Certificate and Certificate Revocation List | Infrastructure Certificate and Certificate Revocation List | |||
(CRL) Profile", RFC 5280, May 2008. | (CRL) Profile", RFC 5280, May 2008. | |||
9.2. Informative References | 9.2. Informative References | |||
[I-D.ietf-sidr-pfx-validate] | ||||
Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R. | ||||
Austein, "BGP Prefix Origin Validation", | ||||
draft-ietf-sidr-pfx-validate-00 (work in progress), | ||||
July 2010. | ||||
[IANA.AS-Registry] | [IANA.AS-Registry] | |||
IANA, "IANA Autonomous System Number Registry", | IANA, "IANA Autonomous System Number Registry", | |||
March 2010. | March 2010. | |||
[exI-D.bates] | [exI-D.bates] | |||
Bates, T., Bush, R., Li, T., and Y. Rekhter, "DNS-based | Bates, T., Bush, R., Li, T., and Y. Rekhter, "DNS-based | |||
NLRI origin AS verification in BGP", | NLRI origin AS verification in BGP", | |||
draft-bates-bgp4-nlri-orig-verif-00.txt (work in | draft-bates-bgp4-nlri-orig-verif-00.txt (work in | |||
progress), January 1998. | progress), January 1998. | |||
End of changes. 29 change blocks. | ||||
102 lines changed or deleted | 122 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/ |