draft-ietf-sidr-rpki-rtr-rfc6810-bis-00.txt		draft-ietf-sidr-rpki-rtr-rfc6810-bis-01.txt
	Network Working Group R. Bush		Network Working Group R. Bush
	Internet-Draft Internet Initiative Japan		Internet-Draft Internet Initiative Japan
	Intended status: Standards Track R. Austein		Intended status: Standards Track R. Austein
	Expires: September 12, 2014 Dragon Research Labs		Expires: October 6, 2014 Dragon Research Labs
	March 11, 2014		April 4, 2014
	The Resource Public Key Infrastructure (RPKI) to Router Protocol		The Resource Public Key Infrastructure (RPKI) to Router Protocol
	draft-ietf-sidr-rpki-rtr-rfc6810-bis-00		draft-ietf-sidr-rpki-rtr-rfc6810-bis-01
	Abstract		Abstract
	In order to verifiably validate the origin Autonomous Systems of BGP		In order to verifiably validate the origin Autonomous Systems of BGP
	announcements, routers need a simple but reliable mechanism to		announcements, routers need a simple but reliable mechanism to
	receive Resource Public Key Infrastructure (RFC 6480) prefix origin		receive Resource Public Key Infrastructure (RFC 6480) prefix origin
	data from a trusted cache. This document describes a protocol to		data from a trusted cache. This document describes a protocol to
	deliver validated prefix origin data to routers.		deliver validated prefix origin data to routers.
	Status of This Memo		Status of This Memo
	skipping to change at page 1, line 35		skipping to change at page 1, line 35
	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 12, 2014.		This Internet-Draft will expire on October 6, 2014.
	Copyright Notice		Copyright Notice
	Copyright (c) 2014 IETF Trust and the persons identified as the		Copyright (c) 2014 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 7, line 24		skipping to change at page 7, line 24
	header which end with the length field.		header which end with the length field.
	Flags: The lowest order bit of the Flags field is 1 for an		Flags: The lowest order bit of the Flags field is 1 for an
	announcement and 0 for a withdrawal. For a Prefix PDU (IPv4 or		announcement and 0 for a withdrawal. For a Prefix PDU (IPv4 or
	IPv6), the flag indicates whether this PDU announces a new right		IPv6), the flag indicates whether this PDU announces a new right
	to announce the prefix or withdraws a previously announced right;		to announce the prefix or withdraws a previously announced right;
	a withdraw effectively deletes one previously announced Prefix PDU		a withdraw effectively deletes one previously announced Prefix PDU
	with the exact same Prefix, Length, Max-Len, and Autonomous System		with the exact same Prefix, Length, Max-Len, and Autonomous System
	Number (ASN). Similarly, for a Router Key PDU, the flag indicates		Number (ASN). Similarly, for a Router Key PDU, the flag indicates
	whether this PDU announces a new Router Key or deletes one		whether this PDU announces a new Router Key or deletes one
	previously announced Router Key PDU with the exact same AS		previously announced Router Key PDU with the exact same AS Number,
	Numbers, subjectKeyIdentifier, and subjectPublicKeyInfo.		subjectKeyIdentifier, and subjectPublicKeyInfo.
	Prefix Length: An 8-bit unsigned integer denoting the shortest		Prefix Length: An 8-bit unsigned integer denoting the shortest
	prefix allowed for the prefix.		prefix allowed for the prefix.
	Max Length: An 8-bit unsigned integer denoting the longest prefix		Max Length: An 8-bit unsigned integer denoting the longest prefix
	allowed by the prefix. This MUST NOT be less than the Prefix		allowed by the prefix. This MUST NOT be less than the Prefix
	Length element.		Length element.
	Prefix: The IPv4 or IPv6 prefix of the ROA.		Prefix: The IPv4 or IPv6 prefix of the ROA.
	skipping to change at page 13, line 21		skipping to change at page 13, line 21
	| |		| |
	| Length=8 |		| Length=8 |
	| |		| |
	`-------------------------------------------'		`-------------------------------------------'
	5.10. Router Key		5.10. Router Key
	0 8 16 24 31		0 8 16 24 31
	.-------------------------------------------.		.-------------------------------------------.
	| Protocol | PDU | | |		| Protocol | PDU | | |
	| Version | Type | Flags | AS Count |		| Version | Type | Flags | zero |
	| 1 | 9 | | |		| 1 | 9 | | |
	+-------------------------------------------+		+-------------------------------------------+
	| |		| |
	| Length |		| Length |
	| |		| |
	+-------------------------------------------+		+-------------------------------------------+
	| |		| |
	| Subject Key Identifier |		| Subject Key Identifier |
	| 20 octets |		| 20 octets |
	| |		| |
	+-------------------------------------------+		+-------------------------------------------+
	| |		| |
	| AS Numbers |		| AS Number |
	| |		| |
	+-------------------------------------------+		+-------------------------------------------+
	| |		| |
	| Subject Public Key Info |		| Subject Public Key Info |
	| |		| |
	`-------------------------------------------'		`-------------------------------------------'
	In addition to the normal boilerplate fields of an RPKI-Router PDU,		In addition to the normal boilerplate fields of an RPKI-Router PDU,
	the Router Key PDU has the following fields.		the Router Key PDU has the following fields.
	Subject Key Identifier is the 20-octet subjectKeyIdentifier (SKI)		Subject Key Identifier is the 20-octet subjectKeyIdentifier (SKI)
	value for the Router Key, as described in [RFC6487].		value for the Router Key, as described in [RFC6487].
	AS Numbers contains one or more Autonomous System Numbers. The		AS Number one Autonomous System Number.
	number of ASNs is specified in the AS Count field. To simplify
	comparision, the ASNs within this field MUST be sorted into
	increasing numerical order considered as unsigned big-endian
	32-bit integers.
	Subject Public Key Info is the Router Key's subjectPublicKeyInfo as		Subject Public Key Info is the Router Key's subjectPublicKeyInfo as
	described in [I-D.ietf-sidr-bgpsec-algs]. This is the full ASN.1		described in [I-D.ietf-sidr-bgpsec-algs]. This is the full ASN.1
	DER encoding of the subjectPublicKeyInfo, including the ASN.1 tag		DER encoding of the subjectPublicKeyInfo, including the ASN.1 tag
	and length values of the subjectPublicKeyInfo SEQUENCE.		and length values of the subjectPublicKeyInfo SEQUENCE.
			The cache server MUST ensure that it has told the router client to
			have one and only one Router Key PDU for a unique {SKI, ASN, Subject
			Public Key} at any one point in time. Should the router client
			receive a Router Key PDU with a {SKI, ASN, Subject Public Key}
			identical to one it already has active, it SHOULD raise a Duplicate
			Announcement Received error.
			Note that a particular ASN may appear in multiple Router Key PDUs
			with different Subject Public Key values, while a particular Subject
			Public Key value may appear in multiple Router Key PDUs with
			different ASNs. In the interest of keeping the announcement and
			withdrawal semantics as simple as possible for the router, this
			protocol makes no attempt to compress either of these cases.
			Also note that it is possible, albeit very unlikely, for multiple
			distinct Subject Public Key values to hash to the same SKI. For this
			reason, implementations MUST compare Subject Public Key values as
			well as SKIs when detecting duplicate PDUs.
	5.11. Error Report		5.11. Error Report
	This PDU is used by either party to report an error to the other.		This PDU is used by either party to report an error to the other.
	Error reports are only sent as responses to other PDUs.		Error reports are only sent as responses to other PDUs.
	The Error Code is described in Section 12.		The Error Code is described in Section 12.
	If the error is generic (e.g., "Internal Error") and not associated		If the error is generic (e.g., "Internal Error") and not associated
	with the PDU to which it is responding, the Erroneous PDU field MUST		with the PDU to which it is responding, the Erroneous PDU field MUST
	skipping to change at page 25, line 49		skipping to change at page 25, line 49
	3: Invalid Request (fatal): The cache server believes the client's		3: Invalid Request (fatal): The cache server believes the client's
	request to be invalid.		request to be invalid.
	4: Unsupported Protocol Version (fatal): The Protocol Version is not		4: Unsupported Protocol Version (fatal): The Protocol Version is not
	known by the receiver of the PDU.		known by the receiver of the PDU.
	5: Unsupported PDU Type (fatal): The PDU Type is not known by the		5: Unsupported PDU Type (fatal): The PDU Type is not known by the
	receiver of the PDU.		receiver of the PDU.
	6: Withdrawal of Unknown Record (fatal): The received PDU has Flag=0		6: Withdrawal of Unknown Record (fatal): The received PDU has Flag=0
	but a record for the {Prefix, Len, Max-Len, ASN} tuple does not		but a matching record ({Prefix, Len, Max-Len, ASN} tuple for an
	exist in the receiver's database.		IPvX PDU, {SKI, ASN, Subject Public Key} tuple for a Router Key
			PDU) does not exist in the receiver's database.
	7: Duplicate Announcement Received (fatal): The received PDU has an		7: Duplicate Announcement Received (fatal): The received PDU has
	identical {Prefix, Len, Max-Len, ASN} tuple as a PDU which is		Flag=1 but a matching record ({Prefix, Len, Max-Len, ASN} tuple
	still active in the router.		for an IPvX PDU, {SKI, ASN, Subject Public Key} tuple for a Router
			Key PDU) is already active in the router.
	13. Security Considerations		13. Security Considerations
	As this document describes a security protocol, many aspects of		As this document describes a security protocol, many aspects of
	security interest are described in the relevant sections. This		security interest are described in the relevant sections. This
	section points out issues which may not be obvious in other sections.		section points out issues which may not be obvious in other sections.
	Cache Validation: In order for a collection of caches as described		Cache Validation: In order for a collection of caches as described
	in Section 11 to guarantee a consistent view, they need to be		in Section 11 to guarantee a consistent view, they need to be
	given consistent trust anchors to use in their internal validation		given consistent trust anchors to use in their internal validation
	skipping to change at page 28, line 23		skipping to change at page 28, line 25
	5 Unsupported PDU Type		5 Unsupported PDU Type
	6 Withdrawal of Unknown Record		6 Withdrawal of Unknown Record
	7 Duplicate Announcement Received		7 Duplicate Announcement Received
	255 Reserved		255 Reserved
	IANA has added an SSH Connection Protocol Subsystem Name, as defined		IANA has added an SSH Connection Protocol Subsystem Name, as defined
	in [RFC4250], of "rpki-rtr".		in [RFC4250], of "rpki-rtr".
	15. Acknowledgments		15. Acknowledgments
	The authors wish to thank Steve Bellovin, Rex Fernando, Paul Hoffman,		The authors wish to thank Steve Bellovin, Tim Bruijnzeels, Rex
	Russ Housley, Pradosh Mohapatra, Keyur Patel, Sandy Murphy, Robert		Fernando, Paul Hoffman, Russ Housley, Pradosh Mohapatra, Keyur Patel,
	Raszuk, John Scudder, Ruediger Volk, and David Ward. Particular		David Mandelberg, Sandy Murphy, Robert Raszuk, John Scudder, Ruediger
	thanks go to Hannes Gredler for showing us the dangers of unnecessary		Volk, Matthias Waehlisch, and David Ward. Particular thanks go to
	fields.		Hannes Gredler for showing us the dangers of unnecessary fields.
	16. References		16. References
	16.1. Normative References		16.1. Normative References
	[I-D.ietf-sidr-bgpsec-algs]		[I-D.ietf-sidr-bgpsec-algs]
	Turner, S., "BGP Algorithms, Key Formats, & Signature		Turner, S., "BGP Algorithms, Key Formats, & Signature
	Formats", draft-ietf-sidr-bgpsec-algs-05 (work in		Formats", draft-ietf-sidr-bgpsec-algs-06 (work in
	progress), September 2013.		progress), March 2014.
	[RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982,		[RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982,
	August 1996.		August 1996.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", RFC 2119, BCP 14, March 1997.		Requirement Levels", RFC 2119, BCP 14, March 1997.
	[RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5		[RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5
	Signature Option", RFC 2385, August 1998.		Signature Option", RFC 2385, August 1998.
End of changes. 12 change blocks.
	25 lines changed or deleted		42 lines changed or added
This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/