< draft-ietf-karp-ops-model-07.txt		draft-ietf-karp-ops-model-08.txt >
	Network Working Group S. Hartman		Network Working Group S. Hartman
	Internet-Draft Painless Security		Internet-Draft Painless Security
	Intended status: Informational D. Zhang		Intended status: Informational D. Zhang
	Expires: January 6, 2014 Huawei		Expires: March 3, 2014 Huawei
	July 5, 2013		August 30, 2013
	Operations Model for Router Keying		Operations Model for Router Keying
	draft-ietf-karp-ops-model-07.txt		draft-ietf-karp-ops-model-08.txt
	Abstract		Abstract
	Developing an operational and management model for routing protocol		Developing an operational and management model for routing protocol
	security that works with all the routing protocols will be critical		security that works with all the routing protocols will be critical
	to the success of routing protocol security efforts. This document		to the success of routing protocol security efforts. This document
	discusses issues and begins to consider development of these models.		discusses issues and begins to consider development of these models.
	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 January 6, 2014.		This Internet-Draft will expire on March 3, 2014.
	Copyright Notice		Copyright Notice
	Copyright (c) 2013 IETF Trust and the persons identified as the		Copyright (c) 2013 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 26 ¶		skipping to change at page 2, line 26 ¶
	4.1.1. Sharing Keys and Zones of Trust . . . . . . . . . . . 10		4.1.1. Sharing Keys and Zones of Trust . . . . . . . . . . . 10
	4.1.2. Key Separation and Protocol Design . . . . . . . . . . 11		4.1.2. Key Separation and Protocol Design . . . . . . . . . . 11
	4.2. Asymmetric Keys . . . . . . . . . . . . . . . . . . . . . 11		4.2. Asymmetric Keys . . . . . . . . . . . . . . . . . . . . . 11
	4.3. Public Key Infrastructure . . . . . . . . . . . . . . . . 12		4.3. Public Key Infrastructure . . . . . . . . . . . . . . . . 12
	4.4. The role of Central Servers . . . . . . . . . . . . . . . 12		4.4. The role of Central Servers . . . . . . . . . . . . . . . 12
	5. Grouping Peers Together . . . . . . . . . . . . . . . . . . . 14		5. Grouping Peers Together . . . . . . . . . . . . . . . . . . . 14
	6. Administrator Involvement . . . . . . . . . . . . . . . . . . 16		6. Administrator Involvement . . . . . . . . . . . . . . . . . . 16
	6.1. Enrollment . . . . . . . . . . . . . . . . . . . . . . . . 16		6.1. Enrollment . . . . . . . . . . . . . . . . . . . . . . . . 16
	6.2. Handling Faults . . . . . . . . . . . . . . . . . . . . . 16		6.2. Handling Faults . . . . . . . . . . . . . . . . . . . . . 16
	7. Upgrade Considerations . . . . . . . . . . . . . . . . . . . . 18		7. Upgrade Considerations . . . . . . . . . . . . . . . . . . . . 18
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 19		8. Security Considerations . . . . . . . . . . . . . . . . . . . 20
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20		9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
	10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21		10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22		11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
	11.1. Normative References . . . . . . . . . . . . . . . . . . . 22		11.1. Normative References . . . . . . . . . . . . . . . . . . . 23
	11.2. Informative References . . . . . . . . . . . . . . . . . . 22		11.2. Informative References . . . . . . . . . . . . . . . . . . 23
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25
	1. Introduction		1. Introduction
	The KARP working group is designing improvements to the cryptographic		The KARP working group is designing improvements to the cryptographic
	authentication of IETF routing protocols. These improvements include		authentication of IETF routing protocols. These improvements include
	improvements to how integrity functions are handled within each		improvements to how integrity functions are handled within each
	protocol as well as designing an automated key management solution.		protocol as well as designing an automated key management solution.
	This document discusses issues to consider when thinking about the		This document discusses issues to consider when thinking about the
	operational and management model for KARP. Each implementation will		operational and management model for KARP. Each implementation will
	skipping to change at page 4, line 5 ¶		skipping to change at page 3, line 27 ¶
	architects and protocol designers to understand what management		architects and protocol designers to understand what management
	capabilities they can depend on in heterogeneous environments.		capabilities they can depend on in heterogeneous environments.
	Similarly, designing and deploying the protocol will be easier with		Similarly, designing and deploying the protocol will be easier with
	thought paid to a common operational model. This will also help with		thought paid to a common operational model. This will also help with
	the design of NetConf schemas or MIBs later.		the design of NetConf schemas or MIBs later.
	This document also gives recommendations for how management and		This document also gives recommendations for how management and
	operational issues can be approached as protocols are revised and as		operational issues can be approached as protocols are revised and as
	support is added for the key table [I-D.ietf-karp-crypto-key-table]		support is added for the key table [I-D.ietf-karp-crypto-key-table]
			Routing security faces interesting challenges not present with some
			other security domains. routers need to function in order to
			establish network connectivity. As a result, centralized services
			cannot typically be used for authentication or other security tasks;
			see Section 4.4. In addition, routers' roles affect how new routers
			are installed and how problems are handleded; see Section 6.
	2. Requirements notation		2. Requirements notation
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in [RFC2119].		document are to be interpreted as described in [RFC2119].
	3. Breakdown of KARP configuration		3. Breakdown of KARP configuration
	There are multiple ways of structuring configuration information.		There are multiple ways of structuring configuration information.
	One factor to consider is the scope of the configuration information.		One factor to consider is the scope of the configuration information.
	skipping to change at page 18, line 13 ¶		skipping to change at page 18, line 13 ¶
	service.		service.
	7. Upgrade Considerations		7. Upgrade Considerations
	It needs to be possible to deploy automated key management in an		It needs to be possible to deploy automated key management in an
	organization without either having to disable existing security or		organization without either having to disable existing security or
	disrupting routing. As a result, it needs to be possible to perform		disrupting routing. As a result, it needs to be possible to perform
	a phased upgrade from manual keying to automated key management.		a phased upgrade from manual keying to automated key management.
	This upgrade procedure needs to be easy and have a very low risk of		This upgrade procedure needs to be easy and have a very low risk of
	disrupting routing. Today, many operators do not update keys because		disrupting routing. Today, many operators do not update keys because
	the perceived risk of an attack is lower than the complexity of and		the perceived risk of an attack is lower than the cost of an update
	update and risk of routing disruptions.		combined with the potential cost of routing disruptions during the
			update. Even when a routing protocol has technical mechanisms that
			permit an update with no disruption in service, there is still a
			potential cost of service disruptions as operational procedures and
			practices need to correctly use the technical mechanisms.
	For peer-to-peer protocols such as BGP, this can be relatively easy.		For peer-to-peer protocols such as BGP, this can be relatively easy.
	First, code that supports automated key management needs to be loaded		First, code that supports automated key management needs to be loaded
	on both peers. Then the adjacency can be upgraded. The		on both peers. Then the adjacency can be upgraded. The
	configuration can be updated to switch to automated key management		configuration can be updated to switch to automated key management
	when the second router reboots. Alternatively, if the key management		when the second router reboots. Alternatively, if the key management
	protocols involved can detect that both peers now support automated		protocols involved can detect that both peers now support automated
	key management, then a key can potentially be negotiated for an		key management, then a key can potentially be negotiated for an
	existing session.		existing session.
	skipping to change at page 20, line 5 ¶		skipping to change at page 20, line 11 ¶
	removed will generate a new fresh key. Group key management		removed will generate a new fresh key. Group key management
	protocols are RECOMMENDED to support an option to export existing		protocols are RECOMMENDED to support an option to export existing
	manual keys during initial deployment of automated key management.		manual keys during initial deployment of automated key management.
	8. Security Considerations		8. Security Considerations
	This document does not define a protocol. It does discuss the		This document does not define a protocol. It does discuss the
	operational and management implications of several security		operational and management implications of several security
	technologies.		technologies.
			Close synchronization of time can impact the security of routing
			protocols in a number of ways. Time is used to control when keys MAY
			begin being used and when they MUST NOT be used any longer as
			described in [I-D.ietf-karp-crypto-key-table]. Routers need to have
			tight enough time synchronization that receivers permit a key to be
			utilized for validation prior to the first use of that key for
			generation of integrity-protected messages or availability will be
			impacted. If time synchronization is too loose, then a key can be
			used beyond its intended lifetime. The Network Time Protocol (NTP)
			can be used to provide time synchronization. For some protocols,
			time synchronization is also important for replay detection.
	9. IANA Considerations		9. IANA Considerations
	This document has no actions for IANA.		This document has no actions for IANA.
	10. Acknowledgments		10. Acknowledgments
	Funding for Sam Hartman's work on this memo is provided by Huawei.		Funding for Sam Hartman's work on this memo is provided by Huawei.
	The authors would like to thank Bill Atwood , Randy Bush, Wes George,		The authors would like to thank Bill Atwood , Randy Bush, Wes George,
	Gregory Lebovitz, and Russ White for valuable reviews.		Gregory Lebovitz, and Russ White for valuable reviews.
	11. References		11. References
	11.1. Normative References		11.1. Normative References
	[I-D.ietf-karp-crypto-key-table]		[I-D.ietf-karp-crypto-key-table]
	Housley, R., Polk, T., Hartman, S., and D. Zhang,		Housley, R., Polk, T., Hartman, S., and D. Zhang,
	"Database of Long-Lived Symmetric Cryptographic Keys",		"Database of Long-Lived Symmetric Cryptographic Keys",
	draft-ietf-karp-crypto-key-table-07 (work in progress),		draft-ietf-karp-crypto-key-table-08 (work in progress),
	March 2013.		July 2013.
	[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, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	11.2. Informative References		11.2. Informative References
	[I-D.ietf-karp-design-guide]		[I-D.ietf-karp-design-guide]
	Lebovitz, G. and M. Bhatia, "Keying and Authentication for		Lebovitz, G. and M. Bhatia, "Keying and Authentication for
	Routing Protocols (KARP) Design Guidelines",		Routing Protocols (KARP) Design Guidelines",
	draft-ietf-karp-design-guide-10 (work in progress),		draft-ietf-karp-design-guide-10 (work in progress),
End of changes. 8 change blocks.
	15 lines changed or deleted		38 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/