draft-ietf-sidr-roa-validation-08.txt   draft-ietf-sidr-roa-validation-09.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: April 18, 2011 October 15, 2010 Expires: May 12, 2011 November 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-08.txt draft-ietf-sidr-roa-validation-09.txt
Abstract Abstract
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 to validate the origination of routes Public Key Infrastructure to validate the origination of routes
advertised in the Border Gateway Protocol. advertised in the Border Gateway Protocol.
Status of this Memo Status of this Memo
skipping to change at page 1, line 34 skipping to change at page 1, line 34
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 April 18, 2011. This Internet-Draft will expire on May 12, 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 4, line 4 skipping to change at page 4, line 4
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 defined as follows: If the final path A route's "origin AS" is defined as follows: If the final path
segment of the AS_PATH is of type AS_SEQUENCE, the "origin AS" is the segment of the AS_PATH is of type AS_SEQUENCE, the "origin AS" is the
first element of the sequence (i.e. the AS in the rightmost position first element of the sequence (i.e. the AS in the rightmost position
with respect to the position of octets in the protocol message). If with respect to the position of octets in the protocol message). If
the final path segment of the AS_PATH is of type AS_SET, indicating the final path segment of the AS_PATH is of type AS_SET, indicating
that the route is an aggregate, then the origin AS is taken as the AS that the route is an aggregate, then the origin AS is taken as the AS
component of the AGGREGATOR path attribute [RFC4271], if present. If component of the AGGREGATOR path attribute [RFC4271], if present.
the AGGREGATOR path attribute is missing, then the origin AS is the Otherwise the route's origin AS cannot be determined.
first AS element of the last path segment of type AS_SEQUENCE (i.e.
this would conventionally be the AS in the rightmost position of the
AS_SEQUENCE path segment immediately preceding the final AS_SET path
segment in the protocol message). 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].)
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 generic model of This approach to route origination validation uses a generic model of
"positive" attestation that has an associated inference that routes "positive" attestation that has an associated inference that routes
that cannot be validated within the RPKI framework would that cannot be validated within the RPKI framework would
conventionally be interpreted by a RP as "invalid". However, the conventionally be interpreted by an RP as "invalid". However, the
considerations of accommodating environments of partial adoption of considerations of accommodating environments of partial adoption of
the use of ROAs, where only a subset of validly advertised address the use of ROAs, where only a subset of validly advertised address
prefixes have associated published ROAs within the structure of the prefixes have associated published ROAs within the structure of the
RPKI, imply some modification to this model of positive attestation. RPKI, imply some modification to this model of positive attestation.
In the context of route validation it is assumed that once an address In the context of route validation it is assumed that once an address
prefix is described in a ROA, then this ROA specifically encompasses prefix is described in a ROA, then this ROA specifically encompasses
all address prefixes that are more specific than that described in all address prefixes that are more specific than that described in
the ROA. Thus, any route for a more specific address prefix than the ROA. Thus, any route for a more specific address prefix than
that described by any valid ROA that does not itself have a matching that described by any valid ROA that does not itself have a matching
valid ROA can be considered to be "invalid". However, routes objects valid ROA can be considered to be "invalid". However, routes objects
 End of changes. 5 change blocks. 
11 lines changed or deleted 6 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/