draft-ietf-sidr-roa-validation-05.txt   draft-ietf-sidr-roa-validation-06.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: September 4, 2010 March 3, 2010 Expires: November 9, 2010 May 8, 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-05.txt draft-ietf-sidr-roa-validation-06.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 in terms of the context of an application of the Resource Public Key
Infrastructure to validate the origination of routes advertised in Infrastructure to validate the origination of routes advertised in
the Border Gateway Protocol. the Border Gateway Protocol.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF). Note that other groups may also distribute
other groups may also distribute working documents as Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at This Internet-Draft will expire on November 9, 2010.
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 4, 2010.
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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the BSD License. described in the Simplified BSD License.
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 . . . . . . . . . . . . . . . 6
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
skipping to change at page 3, line 46 skipping to change at page 3, line 46
to the origination of routes, and the intended scope of the authority to the origination of routes, and the intended scope of the authority
that is conveyed in the ROA. that is conveyed in the ROA.
2. ROA Validation Outcomes for a Route 2. ROA Validation Outcomes for a Route
A "route" is unit of information that associates a set of A "route" is unit of information that associates a set of
destinations described by an IP address prefix with a set of destinations described by an IP address prefix with a set of
attributes of a path to those destinations, as defined in section 1.1 attributes of a path to those destinations, as defined in section 1.1
of [RFC4271]. of [RFC4271].
A route's "origin AS" is the final element of the route object's A route's "origin AS" is defined as follows: If the final path
AS_PATH attribute. If the final AS_PATH element is an AS Set, segment of the AS_PATH is of type AS_SEQUENCE, the "origin AS" is the
indicating that the route is an aggregate, then the origin AS is first element of the sequence (i.e. the AS in the rightmost position
taken as the AS component of the AGGREGATOR attribute [RFC4271]. In with respect to the position of octets in the protocol message). If
the case where there is an AS Set as the final AS_PATH element and no the final path segment of the AS_PATH is of type AS_SET, indicating
AGGREGATOR attribute is present then the origin AS is the AS that the route is an aggregate, then the origin AS is taken as the AS
immediately preceding the AS Set in the AS_PATH, and if there is no component of the AGGREGATOR attribute [RFC4271], if present.
such AS then the route's origin AS cannot be determined. Otherwise the route's origin AS cannot be determined.
In terms of validation of a route in the context of a routing In terms of validation of a route in the context of a routing
environment, the address prefix value and the origin AS are used in environment, the address prefix value and the origin AS are used in
the ROA validation operation. the ROA validation operation.
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].)
skipping to change at page 5, line 30 skipping to change at page 5, line 30
be "valid" if any ROA provides a "valid" outcome. It is considered be "valid" if any ROA provides a "valid" outcome. It is considered
to be "invalid" if one (or more) ROAs provide an "invalid" outcome to be "invalid" if one (or more) ROAs provide an "invalid" outcome
and no ROAs provide a "valid" outcome. It is considered to be and no ROAs provide a "valid" outcome. It is considered to be
"unknown" when no ROA produces either a "valid" or an "invalid" "unknown" when no ROA produces either a "valid" or an "invalid"
outcome. outcome.
Route validation is defined by the following procedure: Route validation 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. prefix in the route. This selection forms the set of
"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 validation
procedure stops with an outcome of "unknown". procedure stops with an outcome of "unknown".
3. If any of the selected ROAs has an asID value that matches the 3. If the route's origin AS can be determined and any of the set
origin AS in the route, and the route object's address prefix of candidate ROAs has an asID value that matches the origin AS
matches a ROAIPAddress in the ROA (where "match" is defined as in the route, and the route object's address prefix matches a
where the route object's address precisely matches the ROAIPAddress in the ROA (where "match" is defined as where the
ROAIPAddress, or where the ROAIPAddress includes a maxLength route object's address precisely matches the ROAIPAddress, or
element, and the route's address prefix is a more specific where the ROAIPAddress includes a maxLength element, and the
prefix of the ROAIPAddress, and the route's address prefix route's address prefix is a more specific prefix of the
length value is less than or equal to the ROAIPAddress ROAIPAddress, and the route's address prefix length value is
maxLength value) then the validation procedure stops with an less than or equal to the ROAIPAddress maxLength value) then
outcome of "valid". the validation procedure stops with an outcome of "valid".
4. Otherwise, the validation procedure stops with an outcome of 4. Othewise, the validation procedure stops 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.
skipping to change at page 7, line 4 skipping to change at page 7, line 4
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 never 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 use [sic] 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 is an attestation by the holder of a
prefix that the prefix described in the ROA, and any more specific prefix that the prefix described in the ROA, and any more specific
prefix, SHOULD NOT be used in a routing context. 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 AS 0 ROA has a lower
preference than any other ROA that has a routeable AS as its subject. preference than any other ROA that has a routeable AS as its subject.
This allows a prefix holder to use an AS 0 ROA to declare a default This allows a prefix holder to use an AS 0 ROA to declare a default
condition that any route that is equal to, or more specific than the condition that any route that is equal to, or more specific than the
prefix to be considered to be invalid, while also allowing other prefix to be considered to be invalid, while also allowing other
concurrently issued ROAs to describe valid origination authorizations concurrently issued ROAs to describe valid origination authorizations
for more specific prefixes. for more specific prefixes.
By convention, an AS 0 ROA SHOULD have a maxLength value of 32 for By convention, an AS 0 ROA SHOULD have a maxLength value of 32 for
IPv4 addresses and 128 for IPv6 addresses, although in terms of route IPv4 addresses and a maxlength value of 128 for IPv6 addresses,
validation the same outcome would be achieved with any valid although in terms of route validation the same outcome would be
maxLength value, or even if the maxLength element were to be omitted achieved with any valid maxLength value, or even if the maxLength
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 AS 0 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 can coexist with ROAs that have different requirement. An AS 0 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 of the AS 0
ROA does not alter the route validation outcome in any way. ROA does not alter the route validation outcome 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 prematurely invalidate a ROA by revoking the EE A ROA issuer may elect to prematurely invalidate a ROA by revoking
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 route objects that
have more specific prefixes with a prefix length greater than have more specific prefixes with a prefix length greater than
maxLength, and all originating AS's other than the AS listed in the maxLength, and all originating AS's other than the AS listed in the
collection of ROAs for this prefix. collection of 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
 End of changes. 15 change blocks. 
43 lines changed or deleted 38 lines changed or added

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