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/