< draft-ietf-sidr-rpsl-sig-10.txt		draft-ietf-sidr-rpsl-sig-11.txt >
	SIDR R. Kisteleki		SIDR R. Kisteleki
	Internet-Draft RIPE NCC		Internet-Draft RIPE NCC
	Updates: 2622, 4012 (if approved) B. Haberman		Updates: 2622, 4012 (if approved) B. Haberman
	Intended status: Standards Track JHU APL		Intended status: Standards Track JHU APL
	Expires: September 11, 2016 March 10, 2016		Expires: November 17, 2016 May 16, 2016
	Securing RPSL Objects with RPKI Signatures		Securing RPSL Objects with RPKI Signatures
	draft-ietf-sidr-rpsl-sig-10.txt		draft-ietf-sidr-rpsl-sig-11.txt
	Abstract		Abstract
	This document describes a method to allow parties to electronically		This document describes a method to allow parties to electronically
	sign Routing Policy Specification Language objects and validate such		sign Routing Policy Specification Language objects and validate such
	electronic signatures. This allows relying parties to detect		electronic signatures. This allows relying parties to detect
	accidental or malicious modifications on such objects. It also		accidental or malicious modifications on such objects. It also
	allows parties who run Internet Routing Registries or similar		allows parties who run Internet Routing Registries or similar
	databases, but do not yet have Routing Policy System Security-based		databases, but do not yet have Routing Policy System Security-based
	authentication of the maintainers of certain objects, to verify that		authentication of the maintainers of certain objects, to verify that
	skipping to change at page 1, line 41 ¶		skipping to change at page 1, line 41 ¶
	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 September 11, 2016.		This Internet-Draft will expire on November 17, 2016.
	Copyright Notice		Copyright Notice
	Copyright (c) 2016 IETF Trust and the persons identified as the		Copyright (c) 2016 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 17 ¶		skipping to change at page 2, line 17 ¶
	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 . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Signature Syntax and Semantics . . . . . . . . . . . . . . . 3		2. Signature Syntax and Semantics . . . . . . . . . . . . . . . 3
	2.1. General Attributes, Meta Information . . . . . . . . . . 3		2.1. General Attributes, Meta Information . . . . . . . . . . 3
	2.2. Signed Attributes . . . . . . . . . . . . . . . . . . . . 5		2.2. Signed Attributes . . . . . . . . . . . . . . . . . . . . 4
	2.3. Storage of the Signature Data . . . . . . . . . . . . . . 5		2.3. Storage of the Signature Data . . . . . . . . . . . . . . 5
	2.4. Number Resource Coverage . . . . . . . . . . . . . . . . 5		2.4. Number Resource Coverage . . . . . . . . . . . . . . . . 5
	2.5. Validity Time of the Signature . . . . . . . . . . . . . 6		2.5. Validity Time of the Signature . . . . . . . . . . . . . 6
	3. Signature Creation and Validation Steps . . . . . . . . . . . 6		3. Signature Creation and Validation Steps . . . . . . . . . . . 6
	3.1. Canonicalization . . . . . . . . . . . . . . . . . . . . 6		3.1. Canonicalization . . . . . . . . . . . . . . . . . . . . 6
	3.2. Signature Creation . . . . . . . . . . . . . . . . . . . 8		3.2. Signature Creation . . . . . . . . . . . . . . . . . . . 8
	3.3. Signature Validation . . . . . . . . . . . . . . . . . . 9		3.3. Signature Validation . . . . . . . . . . . . . . . . . . 9
	4. Signed Object Types, Set of Signed Attributes . . . . . . . . 10		4. Signed Object Types, Set of Signed Attributes . . . . . . . . 10
	5. Keys and Certificates used for Signature and Verification . . 12		5. Keys and Certificates used for Signature and Verification . . 12
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 12		6. Security Considerations . . . . . . . . . . . . . . . . . . . 12
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
	8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13		8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13
	9. Normative References . . . . . . . . . . . . . . . . . . . . 13		9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
			9.1. Normative References . . . . . . . . . . . . . . . . . . 13
			9.2. Informative References . . . . . . . . . . . . . . . . . 14
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
	1. Introduction		1. Introduction
	Objects stored in resource databases, like the RIPE DB, are generally		Objects stored in resource databases, like the RIPE DB, are generally
	protected by an authentication mechanism: anyone creating or		protected by an authentication mechanism: anyone creating or
	modifying an object in the database has to have proper authorization		modifying an object in the database has to have proper authorization
	to do so, and therefore has to go through an authentication procedure		to do so, and therefore has to go through an authentication procedure
	(provide a password, certificate, e-mail signature, etc.) However,		(provide a password, certificate, e-mail signature, etc.) However,
	for objects transferred between resource databases, the		for objects transferred between resource databases, the
	authentication is not guaranteed. This means when downloading a		authentication is not guaranteed. This means that when a Routing
	Routing Policy Specification Language (RPSL) object stored in this		Policy Specification Language (RPSL) object is downloaded from a
	database, one can reasonably safely claim that the object is		database, the consumer can reasonably claim that the object is
	authentic, but for an imported object one cannot. Also, once such an		authentic if it was locally created, but cannot make the same claim
			for an object imported from a different database. Also, once such an
	object is downloaded from the database, it becomes a simple (but		object is downloaded from the database, it becomes a simple (but
	still structured) text file with no integrity protection. More		still structured) text file with no integrity protection. More
	importantly, the authentication and integrity guarantees associated		importantly, the authentication and integrity guarantees associated
	with these objects do not always ensure that the entity that		with these objects do not always ensure that the entity that
	generated them is authorized to make the assertions implied by the		generated them is authorized to make the assertions implied by the
	data contained in the objects.		data contained in the objects.
	A potential use for resource certificates [RFC6487] is to use them to		A potential use for resource certificates [RFC6487] is to use them to
	secure such (both imported and downloaded) database objects, by		secure such (both imported and downloaded) database objects, by
	applying a digital signature over the object contents. A maintainer		applying a digital signature over the object contents in lieu of
			methods such as Routing Policy System Security [RFC2725]. The signer
	of such signed database objects MUST possess a relevant resource		of such signed database objects MUST possess a relevant resource
	certificate, which shows him/her as the legitimate holder of an		certificate, which shows him/her as the legitimate holder of an
	Internet number resource. This mechanism allows the users of such		Internet number resource. This mechanism allows the users of such
	database objects to verify that the contents are in fact produced by		database objects to verify that the contents are in fact produced by
	the legitimate holder(s) of the Internet resources mentioned in those		the legitimate holder(s) of the Internet resources mentioned in those
	objects. It also allows the signatures to cover whole RPSL objects,		objects. It also allows the signatures to cover whole RPSL objects,
	or just selected attributes of them. In other words, a digital		or just selected attributes of them. In other words, a digital
	signature created using the private key associated with a resource		signature created using the private key associated with a resource
	certificate can offer object security in addition to the channel		certificate can offer object security in addition to the channel
	security already present in most of such databases. Object security		security already present in most of such databases. Object security
	skipping to change at page 3, line 45 ¶		skipping to change at page 3, line 48 ¶
	2.1. General Attributes, Meta Information		2.1. General Attributes, Meta Information
	The digital signature associated with an RPSL object is itself a new		The digital signature associated with an RPSL object is itself a new
	attribute named "signature". It consists of mandatory and optional		attribute named "signature". It consists of mandatory and optional
	fields. These fields are structured in a sequence of name and value		fields. These fields are structured in a sequence of name and value
	pairs, separated by a semicolon ";" and a white space. Collectively		pairs, separated by a semicolon ";" and a white space. Collectively
	these fields make up the value for the new "signature" attribute.		these fields make up the value for the new "signature" attribute.
	The "name" part of such a component is always a single ASCII		The "name" part of such a component is always a single ASCII
	character that serves as an identifier; the value is an ASCII string		character that serves as an identifier; the value is an ASCII string
	the contents of which depend on the field type. Mandatory fields		the contents of which depend on the field type. Mandatory fields
	must appear exactly once, whereas optional fields MUST appear at most		MUST appear exactly once, whereas optional fields MUST appear at most
	once.		once.
	Mandatory fields of the "signature" attribute:		Mandatory fields of the "signature" attribute:
	o Version of the signature (field "v"). This field MUST be set to		o Version of the signature (field "v"). This field MUST be set to
	"rpkiv1". The signature format described in this document applies		"rpkiv1" and MAY be the first field of the signature attribute to
	when the version field is set to "rpkiv1". All the rest of the		simplify the parsing of the attributes' fields. The signature
	signature attributes are defined by the value of version field.		format described in this document applies when the version field
			is set to "rpkiv1". All the rest of the signature attributes are
			defined by the value of version field.
	o Reference to the certificate corresponding to the private key used		o Reference to the certificate corresponding to the private key used
	to sign this object (field "c"). The value of this field MUST be		to sign this object (field "c"). The value of this field MUST be
	a URL of type "rsync" or "http(s)" that points to a specific		a URL of type "rsync" or "http(s)" that points to a specific
	resource certificate in an RPKI repository [RFC6481]. Any non		resource certificate in an RPKI repository [RFC6481]. Any non
	URL-safe characters (including semicolon ";" and plus "+") must be		URL-safe characters (including semicolon ";" and plus "+") must be
	URL encoded.		URL encoded.
	o Signature method (field "m"): what hash and signature algorithms		o Signature method (field "m"): what hash and signature algorithms
	were used to create the signature. The allowed algorithms which		were used to create the signature. This specification follows th
	can be used for the signature are specified in Section 5 of RFC		algorithms defined in RFC 6485 [RFC6485]. The algorithms are
	4055 [RFC4055]. More specifically, this version of RPSL		referenced witin the signature attribute by the ASCII names of the
	signatures supports the following hash algorithms:		algorithms.
	* sha224WithRSAEncryption
	* sha256WithRSAEncryption
	* sha384WithRSAEncryption
	* sha512WithRSAEncryption
	The algorithms are referenced witin the signature attribute by the
	ASCII names of the algorithms.
	o Time of signing (field "t"). The format of the value of this		o Time of signing (field "t"). The format of the value of this
	field MUST be in the Internet Date/Time format [RFC3339]. All		field MUST be in the Internet Date/Time format [RFC3339]. All
	times MUST be converted to Universal Coordinated Time (UTC)		times MUST be converted to Universal Coordinated Time (UTC)
	o The signed attributes (field "a"). This is a list of attribute		o The signed attributes (field "a"). This is a list of attribute
	names, separated by an ASCII "+" character (if more than one		names, separated by an ASCII "+" character (if more than one
	attribute is enumerated). The list must include any attribute at		attribute is enumerated). The list must include any attribute at
	most once.		most once.
	skipping to change at page 5, line 49 ¶		skipping to change at page 5, line 42 ¶
	attribute2: value2		attribute2: value2
	attribute3: value3		attribute3: value3
	...		...
	signature: v=rpkiv1; c=rsync://.....; m=sha256WithRSAEncryption;		signature: v=rpkiv1; c=rsync://.....; m=sha256WithRSAEncryption;
	t=2014-12-31T23:59:60Z;		t=2014-12-31T23:59:60Z;
	a=attribute1+attribute2+attribute3+...;		a=attribute1+attribute2+attribute3+...;
	b=<base64 data>		b=<base64 data>
	2.4. Number Resource Coverage		2.4. Number Resource Coverage
	Even if the signature(s) over the object are valid according to the		Even if the signature over the object is valid according to the
	signature validation rules, they may not be relevant to the object;		signature validation rules, they may not be relevant to the object;
	they also need to cover the relevant Internet number resources		they also need to cover the relevant Internet number resources
	mentioned in the object.		mentioned in the object.
	Therefore the Internet number resources present in [RFC3779]		Therefore the Internet number resources present in [RFC3779]
	extensions of the certificate referred to in the "c" field of the		extensions of the certificate referred to in the "c" field of the
	signature MUST cover the resources in the primary key of the object		signature MUST cover the resources in the primary key of the object
	(e.g., value of the "aut-num:" attribute of an aut-num object, value		(e.g., value of the "aut-num:" attribute of an aut-num object, value
	of the "inetnum:" attribute of an inetnum object, values of "route:"		of the "inetnum:" attribute of an inetnum object, values of "route:"
	and "origin:" attributes of a route object, etc.).		and "origin:" attributes of a route object, etc.).
	skipping to change at page 8, line 8 ¶		skipping to change at page 7, line 34 ¶
	* IPv4 addresses MUST be represented as the ipv4-address type		* IPv4 addresses MUST be represented as the ipv4-address type
	defined by RPSL [RFC2622]		defined by RPSL [RFC2622]
	* All IP prefixes (IPv4 and IPv6) MUST be represented in CIDR		* All IP prefixes (IPv4 and IPv6) MUST be represented in CIDR
	notation [RFC4632].		notation [RFC4632].
	5. All ranges, lists, or sets of numerical fields are represented		5. All ranges, lists, or sets of numerical fields are represented
	using the appropriate RPSL attribute and each numerical element		using the appropriate RPSL attribute and each numerical element
	contained within those attributes MUST conform to the		contained within those attributes MUST conform to the
	canonicalization rules in this document.		canonicalization rules in this document. The ordering of values
			within such fields MUST be maintained during database transfers.
	6. The name of each attribute MUST be converted into lower case, and		6. The name of each attribute MUST be converted into lower case, and
	MUST be kept as part of the attribute line.		MUST be kept as part of the attribute line.
	7. Tab characters ("\t") MUST be converted to spaces.		7. Tab characters ("\t") MUST be converted to spaces.
	8. Multiple whitespaces MUST be collapsed into a single space (" ")		8. Multiple whitespaces MUST be collapsed into a single space (" ")
	character.		character.
	9. All line endings MUST be converted to a singe new line ("\n")		9. All line endings MUST be converted to a singe new line ("\n")
	skipping to change at page 10, line 31 ¶		skipping to change at page 10, line 24 ¶
	since these usually make sense only within the context of such a		since these usually make sense only within the context of such a
	database, whereas the scope of the signatures is only one specific		database, whereas the scope of the signatures is only one specific
	object. Since the attributes in the referred object (such as mnt-by,		object. Since the attributes in the referred object (such as mnt-by,
	admin-c, tech-c, ...) can change without any modifications to the		admin-c, tech-c, ...) can change without any modifications to the
	signed object, signing such attributes could lead to false sense of		signed object, signing such attributes could lead to false sense of
	security in terms of the contents of the signed data; therefore		security in terms of the contents of the signed data; therefore
	including such attributes should only be done in order to provide		including such attributes should only be done in order to provide
	full integrity protection of the object itself.		full integrity protection of the object itself.
	The newly constructed "signature" attribute is always included in the		The newly constructed "signature" attribute is always included in the
	list.		list. The signature under construction MUST NOT include signature
			attributes that are already present in the object.
	as-block:		as-block:
	* as-block		* as-block
	* org
	* signature		* signature
	aut-num:		aut-num:
	* aut-num		* aut-num
	* as-name		* as-name
	* member-of		* member-of
	skipping to change at page 11, line 4 ¶		skipping to change at page 10, line 44 ¶
	* aut-num		* aut-num
	* as-name		* as-name
	* member-of		* member-of
	* import		* import
	* mp-import		* mp-import
	* export		* export
	* mp-export		* mp-export
	* default		* default
	* mp-default		* mp-default
	* signature		* signature
	inet[6]num:		inet[6]num:
	* inet[6]num		* inet[6]num
	* netname		* netname
	* country		* country
	* org
	* status		* status
	* signature		* signature
	route[6]:		route[6]:
	* route[6]		* route[6]
	* origin		* origin
	* holes		* holes
	* org
	* member-of		* member-of
	* signature		* signature
			It should be noted that the approach defined in this document has a
			limitation in signing route[6] objects. This document only supports
			a single signature per object. This means that it is not possible to
			properly sign route[6] objects where one resource holder possesses
			the ASN and another resource holder possesses the referenced prefix.
			A future version of this specification may rsolve this limitation.
	For each signature, the RFC3779 extension appearing in the		For each signature, the RFC3779 extension appearing in the
	certificate used to verify the signature MUST include a resource		certificate used to verify the signature MUST include a resource
	entry that is equivalent to, or covers ("less specific" than) the		entry that is equivalent to, or covers ("less specific" than) the
	following resources mentioned in the object the signature is attached		following resources mentioned in the object the signature is attached
	to:		to:
	o For the as-block object type: the resource in the "as-block"		o For the as-block object type: the resource in the "as-block"
	attribute.		attribute.
	o For the aut-num object type: the resource in the "aut-num"		o For the aut-num object type: the resource in the "aut-num"
	skipping to change at page 12, line 24 ¶		skipping to change at page 12, line 21 ¶
	5. Keys and Certificates used for Signature and Verification		5. Keys and Certificates used for Signature and Verification
	The certificate that is referred to in the signature (in the "c"		The certificate that is referred to in the signature (in the "c"
	field):		field):
	o MUST be an end-entity (ie. non-CA) certificate		o MUST be an end-entity (ie. non-CA) certificate
	o MUST conform to the X.509 PKIX Resource Certificate profile		o MUST conform to the X.509 PKIX Resource Certificate profile
	[RFC6487]		[RFC6487]
	o MUST have an [RFC3779] extension that covers the Internet number		o MUST have an RFC 3779 extension that covers the Internet number
	resource included in a signed attribute.		resource included in a signed attribute [RFC3779]
	o SHOULD NOT be used to verify more than one signed object (ie.		o SHOULD NOT be used to sign more than one signed object (ie. should
	should be a "single-use" EE certificate, as defined in [RFC6487]).		be a "single-use" EE certificate, as defined in [RFC6487]).
			The certificate generated will omit the Subject Information Access
			(SIA) extension mandated by RFC 6487 as that extension requires an
			rsync URI for the accessLocation form and RPSL currently does not
			support database access via rsync.
	6. Security Considerations		6. Security Considerations
	RPSL objects stored in the IRR databases are public, and as such		RPSL objects stored in the IRR databases are public, and as such
	there is no need for confidentiality. Each signed RPSL object can		there is no need for confidentiality. Each signed RPSL object can
	have its integrity and authenticity verified using the supplied		have its integrity and authenticity verified using the supplied
	digital signature and the referenced certificate.		digital signature and the referenced certificate.
	Since the RPSL signature approach leverages X.509 extensions, the		Since the RPSL signature approach leverages X.509 extensions, the
	security considerations in [RFC3779] apply here as well.		security considerations in [RFC3779] apply here as well.
			Additionally, implementers MUST follow the certificate validation
			steps described in RFC 6487.
	The maintainer of an object has the ability to include attributes in		The maintainer of an object has the ability to include attributes in
	the signature that are not included in the resource certificate used		the signature that are not included in the resource certificate used
	to create the signature. Potentially, a maintainer may include		to create the signature. Potentially, a maintainer may include
	attributes that reference resources the maintainer is not authorized		attributes that reference resources the maintainer is not authorized
	to use.		to use.
	7. IANA Considerations		7. IANA Considerations
	[Note to IANA, to be removed prior to publication: there are no IANA		[Note to IANA, to be removed prior to publication: there are no IANA
	considerations stated in this version of the document.]		considerations stated in this version of the document.]
	8. Acknowledgements		8. Acknowledgements
	The authors would like to acknowledge the valued contributions from		The authors would like to acknowledge the valued contributions from
	Jos Boumans, Steve Kent, Sean Turner, Geoff Huston, and Stephen		Jos Boumans, Tom Harrison, Steve Kent, Sandra Murphy, Magnus Nystrom,
	Farrell in preparation of this document.		Alvaro Retana, Sean Turner, Geoff Huston, and Stephen Farrell in
			preparation of this document.
	9. Normative References		9. 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,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<http://www.rfc-editor.org/info/rfc2119>.		<http://www.rfc-editor.org/info/rfc2119>.
	[RFC2622] Alaettinoglu, C., Villamizar, C., Gerich, E., Kessens, D.,		[RFC2622] Alaettinoglu, C., Villamizar, C., Gerich, E., Kessens, D.,
	Meyer, D., Bates, T., Karrenberg, D., and M. Terpstra,		Meyer, D., Bates, T., Karrenberg, D., and M. Terpstra,
	"Routing Policy Specification Language (RPSL)", RFC 2622,		"Routing Policy Specification Language (RPSL)", RFC 2622,
	DOI 10.17487/RFC2622, June 1999,		DOI 10.17487/RFC2622, June 1999,
	skipping to change at page 13, line 38 ¶		skipping to change at page 13, line 46 ¶
	[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,		Addresses and AS Identifiers", RFC 3779,
	DOI 10.17487/RFC3779, June 2004,		DOI 10.17487/RFC3779, June 2004,
	<http://www.rfc-editor.org/info/rfc3779>.		<http://www.rfc-editor.org/info/rfc3779>.
	[RFC4012] Blunk, L., Damas, J., Parent, F., and A. Robachevsky,		[RFC4012] Blunk, L., Damas, J., Parent, F., and A. Robachevsky,
	"Routing Policy Specification Language next generation		"Routing Policy Specification Language next generation
	(RPSLng)", RFC 4012, DOI 10.17487/RFC4012, March 2005,		(RPSLng)", RFC 4012, DOI 10.17487/RFC4012, March 2005,
	<http://www.rfc-editor.org/info/rfc4012>.		<http://www.rfc-editor.org/info/rfc4012>.
	[RFC4055] Schaad, J., Kaliski, B., and R. Housley, "Additional
	Algorithms and Identifiers for RSA Cryptography for use in
	the Internet X.509 Public Key Infrastructure Certificate
	and Certificate Revocation List (CRL) Profile", RFC 4055,
	DOI 10.17487/RFC4055, June 2005,
	<http://www.rfc-editor.org/info/rfc4055>.
	[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, DOI 10.17487/RFC4632, August		Plan", BCP 122, RFC 4632, DOI 10.17487/RFC4632, August
	2006, <http://www.rfc-editor.org/info/rfc4632>.		2006, <http://www.rfc-editor.org/info/rfc4632>.
	[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data		[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
	Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,		Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
	<http://www.rfc-editor.org/info/rfc4648>.		<http://www.rfc-editor.org/info/rfc4648>.
	[RFC5396] Huston, G. and G. Michaelson, "Textual Representation of		[RFC5396] Huston, G. and G. Michaelson, "Textual Representation of
	Autonomous System (AS) Numbers", RFC 5396,		Autonomous System (AS) Numbers", RFC 5396,
	DOI 10.17487/RFC5396, December 2008,		DOI 10.17487/RFC5396, December 2008,
	<http://www.rfc-editor.org/info/rfc5396>.		<http://www.rfc-editor.org/info/rfc5396>.
	[RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6		[RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6
	Address Text Representation", RFC 5952,		Address Text Representation", RFC 5952,
	DOI 10.17487/RFC5952, August 2010,		DOI 10.17487/RFC5952, August 2010,
	<http://www.rfc-editor.org/info/rfc5952>.		<http://www.rfc-editor.org/info/rfc5952>.
	[RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed.,
	"DomainKeys Identified Mail (DKIM) Signatures", STD 76,
	RFC 6376, DOI 10.17487/RFC6376, September 2011,
	<http://www.rfc-editor.org/info/rfc6376>.
	[RFC6481] Huston, G., Loomans, R., and G. Michaelson, "A Profile for		[RFC6481] Huston, G., Loomans, R., and G. Michaelson, "A Profile for
	Resource Certificate Repository Structure", RFC 6481,		Resource Certificate Repository Structure", RFC 6481,
	DOI 10.17487/RFC6481, February 2012,		DOI 10.17487/RFC6481, February 2012,
	<http://www.rfc-editor.org/info/rfc6481>.		<http://www.rfc-editor.org/info/rfc6481>.
			[RFC6485] Huston, G., "The Profile for Algorithms and Key Sizes for
			Use in the Resource Public Key Infrastructure (RPKI)",
			RFC 6485, DOI 10.17487/RFC6485, February 2012,
			<http://www.rfc-editor.org/info/rfc6485>.
	[RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for		[RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for
	X.509 PKIX Resource Certificates", RFC 6487,		X.509 PKIX Resource Certificates", RFC 6487,
	DOI 10.17487/RFC6487, February 2012,		DOI 10.17487/RFC6487, February 2012,
	<http://www.rfc-editor.org/info/rfc6487>.		<http://www.rfc-editor.org/info/rfc6487>.
			9.2. Informative References
			[RFC2725] Villamizar, C., Alaettinoglu, C., Meyer, D., and S.
			Murphy, "Routing Policy System Security", RFC 2725,
			DOI 10.17487/RFC2725, December 1999,
			<http://www.rfc-editor.org/info/rfc2725>.
			[RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed.,
			"DomainKeys Identified Mail (DKIM) Signatures", STD 76,
			RFC 6376, DOI 10.17487/RFC6376, September 2011,
			<http://www.rfc-editor.org/info/rfc6376>.
	Authors' Addresses		Authors' Addresses
	Robert Kisteleki		Robert Kisteleki
	Email: robert@ripe.net		Email: robert@ripe.net
	URI: http://www.ripe.net		URI: http://www.ripe.net
	Brian Haberman		Brian Haberman
	Johns Hopkins University Applied Physics Lab		Johns Hopkins University Applied Physics Lab
	Email: brian@innovationslab.net		Email: brian@innovationslab.net
End of changes. 30 change blocks.
	60 lines changed or deleted		72 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/