< draft-ietf-karp-ops-model-09.txt		draft-ietf-karp-ops-model-10.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: April 14, 2014 Huawei		Expires: July 13, 2014 Huawei
	October 11, 2013		January 9, 2014
	Operations Model for Router Keying		Operations Model for Router Keying
	draft-ietf-karp-ops-model-09.txt		draft-ietf-karp-ops-model-10.txt
	Abstract		Abstract
	The IETF is engaged in an effort to analyze security of routing		The IETF is engaged in an effort to analyze security of routing
	protocol authentication according to design guidelines discussed in		protocol authentication according to design guidelines discussed in
	RFC 6518. Developing an operational and management model for routing		RFC 6518. Developing an operational and management model for routing
	protocol security that works with all the routing protocols will be		protocol security that works with all the routing protocols will be
	critical to the deployability of these efforts. This document gives		critical to the deployability of these efforts. This document gives
	recommendations to operators and implementors regarding management		recommendations to operators and implementors regarding management
	and operation of router authentication. These recommendations will		and operation of router authentication. These recommendations will
	skipping to change at page 1, line 39 ¶		skipping to change at page 1, line 39 ¶
	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 14, 2014.		This Internet-Draft will expire on July 13, 2014.
	Copyright Notice		Copyright Notice
	Copyright (c) 2013 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
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	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
	skipping to change at page 2, line 25 ¶		skipping to change at page 2, line 25 ¶
	3.1. Integrity of the Key Table . . . . . . . . . . . . . . . . 6		3.1. Integrity of the Key Table . . . . . . . . . . . . . . . . 6
	3.2. Management of Key Table . . . . . . . . . . . . . . . . . 6		3.2. Management of Key Table . . . . . . . . . . . . . . . . . 6
	3.3. Interactions with Automated Key Management . . . . . . . . 7		3.3. Interactions with Automated Key Management . . . . . . . . 7
	3.4. Virtual Routing and Forwarding Instances (VRFs) . . . . . 7		3.4. Virtual Routing and Forwarding Instances (VRFs) . . . . . 7
	4. Credentials and Authorization . . . . . . . . . . . . . . . . 8		4. Credentials and Authorization . . . . . . . . . . . . . . . . 8
	4.1. Preshared Keys . . . . . . . . . . . . . . . . . . . . . . 9		4.1. Preshared Keys . . . . . . . . . . . . . . . . . . . . . . 9
	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 . . . . . . . . . . . . . . . 13
	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 . . . . . . . . . . . . . . . . . . . 20		8. Security Considerations . . . . . . . . . . . . . . . . . . . 20
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21		9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
	10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22		10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23		11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
	11.1. Normative References . . . . . . . . . . . . . . . . . . . 23		11.1. Normative References . . . . . . . . . . . . . . . . . . . 23
	skipping to change at page 6, line 31 ¶		skipping to change at page 6, line 31 ¶
	determination, the router MUST verify the internal consistency of		determination, the router MUST verify the internal consistency of
	entries added to the table. Routing protocols describe how their		entries added to the table. Routing protocols describe how their
	protocol interacts with the key table including what validation MUST		protocol interacts with the key table including what validation MUST
	be performed. At a minimum, the router MUST verify:		be performed. At a minimum, the router MUST verify:
	o The cryptographic algorithms are valid for the protocol.		o The cryptographic algorithms are valid for the protocol.
	o The key derivation function is valid for the protocol.		o The key derivation function is valid for the protocol.
	o The direction is valid for the protocol; for example protocols		o The direction is valid for the protocol; for example protocols
	that require the same session key be used in both directions MUST		that require the same session key be used in both directions
	have a direction of both.		REQUIRE have a direction of both be specified in the key table
			entry.
	o The peer specification is consistent with the protocol.		o The peer specification is consistent with the protocol.
	Other checks are possible. For example the router could verify that		Other checks are possible. For example the router could verify that
	if a key is associated with a peer, that peer is a configured peer		if a key is associated with a peer, that peer is a configured peer
	for the specified protocol. However, this may be undesirable. It		for the specified protocol. However, this may be undesirable. It
	may be desirable to load a key table when some peers have not yet		may be desirable to load a key table when some peers have not yet
	been configured. Also, it may be desirable to share portions of a		been configured. Also, it may be desirable to share portions of a
	key table across devices even when their current configuration does		key table across devices even when their current configuration does
	not require an adjacency with a particular peer in the interest of		not require an adjacency with a particular peer in the interest of
	uniform configuration or preparing for fail-over. For these reasons,		uniform configuration or preparing for fail-over. For these reasons,
	these additional checks are generally undesirable.		these additional checks are generally undesirable.
	3.2. Management of Key Table		3.2. Management of Key Table
	Several management operations will be quite common. For service		Several management interfaces will be quite common. For service
	provider deployments the configuration management system can simply		provider deployments the configuration management system can simply
	update the key table. However, for smaller deployments, efficient		update the key table. However, for smaller deployments, efficient
	management operations that do not require a configuration management		management interfaces that do not require a configuration management
	system are important. In these environments configuration interfaces		system are important. In these environments configuration interfaces
	(such as web interfaces and command-line interfaces) provided		(such as web interfaces and command-line interfaces) provided
	directly by the router will be important to easy management of the		directly by the router will be important to easy management of the
	router.		router.
	As part of adding a new key it is typically desirable to set an		As part of adding a new key it is typically desirable to set an
	expiration time for an old key. The management interface SHOULD		expiration time for an old key. The management interface SHOULD
	provide a mechanism to easily update the expiration time for a		provide a mechanism to easily update the expiration time for a
	current key used with a given peer or interface. Also when adding a		current key used with a given peer or interface. Also when adding a
	key it is desirable to push the key out to nodes that will need it,		key it is desirable to push the key out to nodes that will need it,
	allowing use for receiving packets then later enabling transmit.		allowing use for receiving packets then later enabling transmit.
	This can be accomplished automatically by providing a delay between		This can be accomplished automatically by providing a delay between
	when a key becomes valid for reception and transmission. However,		when a key becomes valid for reception and transmission. However,
	some environments may not be able to predict when all the necessary		some environments may not be able to predict when all the necessary
	changes will be made. In these cases having a mechanism to enable a		changes will be made. In these cases having a mechanism to enable a
	key for sending is desirable. Management interfaces SHOULD provide		key for sending is desirable. The management interface SHOULD
	an easy mechanism to update the direction of an existing key or to		provide an easy mechanism to update the direction of an existing key
	enable a disabled key.		or to enable a disabled key.
	Implementations SHOULD permit a configuration in which if no		Implementations SHOULD permit a configuration in which if no
	unexpired key is available, existing security associations continue		unexpired key is available, existing security associations continue
	using the expired key with which they were established.		using the expired key with which they were established.
	Implementations MUST support a configuration in which security		Implementations MUST support a configuration in which security
	associations fail if no un-expired key is available for them. See		associations fail if no un-expired key is available for them. See
	Section 6.2 for a discussion of reporting and managing security		Section 6.2 for a discussion of reporting and managing security
	faults including those related to key expiration.		faults including those related to key expiration.
	3.3. Interactions with Automated Key Management		3.3. Interactions with Automated Key Management
	skipping to change at page 12, line 44 ¶		skipping to change at page 12, line 44 ¶
	Assuming that self-signed certificates are used by routers that wish		Assuming that self-signed certificates are used by routers that wish
	to use public keys but that do not need a PKI, then PKI and the		to use public keys but that do not need a PKI, then PKI and the
	infrastructureless mode of public-key operation described in the		infrastructureless mode of public-key operation described in the
	previous section can work well together. One router could identify		previous section can work well together. One router could identify
	its peers based on names and use certificate validation. Another		its peers based on names and use certificate validation. Another
	router could use hashes of certificates. This could be very useful		router could use hashes of certificates. This could be very useful
	for border routers between two organizations. Smaller organizations		for border routers between two organizations. Smaller organizations
	could use public keys and larger organizations could use PKI.		could use public keys and larger organizations could use PKI.
			A PKI has significant operational concerns including certification
			practices, handling revocation and operational practices around
			certificate validation. The Routing PKI (RPKI) has addressed these
			concerns within the scope of BGP and validation of address ownership.
			Adapting these practices to routing protocol authentication is
			outside the scope of this document.
	4.4. The role of Central Servers		4.4. The role of Central Servers
	An area to explore is the role of central servers like RADIUS or		An area to explore is the role of central servers like RADIUS or
	directories. Routers need to securely operate in order to provide		directories. Routers need to securely operate in order to provide
	network routing services. Routers cannot generally contact a central		network routing services. Routers cannot generally contact a central
	server while establishing routing because the router might not have a		server while establishing routing because the router might not have a
	functioning route to the central service until after routing is		functioning route to the central service until after routing is
	established. As a result, a system where keys are pushed by a		established. As a result, a system where keys are pushed by a
	central management system is an undesirable result for router keying.		central management system is an undesirable result for router keying.
	However central servers may play a role in authorization and key		However central servers may play a role in authorization and key
	skipping to change at page 18, line 20 ¶		skipping to change at page 18, line 20 ¶
	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 cost of an update		the perceived risk of an attack is lower than the cost of an update
	combined with the potential cost of routing disruptions during the		combined with the potential cost of routing disruptions during the
	update. Even when a routing protocol has technical mechanisms that		update. Even when a routing protocol has technical mechanisms that
	permit an update with no disruption in service, there is still a		permit an update with no disruption in service, there is still a
	potential cost of service disruptions as operational procedures and		potential cost of service disruptions as operational procedures and
	practices need to correctly use the technical mechanisms.		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, upgrading to automated key
	First, code that supports automated key management needs to be loaded		management can be relatively easy. First, code that supports
	on both peers. Then the adjacency can be upgraded. The		automated key management needs to be loaded on both peers. Then the
	configuration can be updated to switch to automated key management		adjacency can be upgraded. The configuration can be updated to
	when the second router reboots. Alternatively, if the key management		switch to automated key management when the second router reboots.
	protocols involved can detect that both peers now support automated		Alternatively, if the key management protocols involved can detect
	key management, then a key can potentially be negotiated for an		that both peers now support automated key management, then a key can
	existing session.		potentially be negotiated for an existing session.
	The situation is more complex for organizations that have not		The situation is more complex for organizations that have not
	upgraded from TCP MD5 [RFC2385] to the TCP Authentication Option		upgraded from TCP MD5 [RFC2385] to the TCP Authentication Option
	[RFC5925]. Today, routers typically need to understand whether a		[RFC5925]. Today, routers typically need to understand whether a
	given peer supports TCP MD5 or TCP-AO before opening a TCP		given peer supports TCP MD5 or TCP-AO before opening a TCP
	connection. In addition, many implementations support grouping		connection. In addition, many implementations support grouping
	configuration of related peers including security configuration		configuration of related peers including security configuration
	together. Implementations make it challenging to move from TCP-MD5		together. Implementations make it challenging to move from TCP-MD5
	to TCP-AO before all peers in the group are ready. Operators		to TCP-AO before all peers in the group are ready. Operators
	perceive it as high risk to update the configuration of a large		perceive it as high risk to update the configuration of a large
	skipping to change at page 23, line 12 ¶		skipping to change at page 23, line 12 ¶
	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-08 (work in progress),		draft-ietf-karp-crypto-key-table-10 (work in progress),
	July 2013.		December 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),
	December 2011.		December 2011.
	[I-D.ietf-sidr-rtr-keying]		[I-D.ietf-sidr-rtr-keying]
	Turner, S., Patel, K., and R. Bush, "Router Keying for		Turner, S., Patel, K., and R. Bush, "Router Keying for
	BGPsec", draft-ietf-sidr-rtr-keying-03 (work in progress),		BGPsec", draft-ietf-sidr-rtr-keying-04 (work in progress),
	September 2013.		December 2013.
	[I-D.liu-ospfv3-automated-keying-req]		[I-D.liu-ospfv3-automated-keying-req]
	Liu, Y., "OSPFv3 Automated Group Keying Requirements",		Liu, Y., "OSPFv3 Automated Group Keying Requirements",
	draft-liu-ospfv3-automated-keying-req-01 (work in		draft-liu-ospfv3-automated-keying-req-01 (work in
	progress), July 2007.		progress), July 2007.
	[I-D.polk-saag-rtg-auth-keytable]		[I-D.polk-saag-rtg-auth-keytable]
	Polk, T. and R. Housley, "Routing Authentication Using A		Polk, T. and R. Housley, "Routing Authentication Using A
	Database of Long-Lived Cryptographic Keys",		Database of Long-Lived Cryptographic Keys",
	draft-polk-saag-rtg-auth-keytable-05 (work in progress),		draft-polk-saag-rtg-auth-keytable-05 (work in progress),
End of changes. 13 change blocks.
	25 lines changed or deleted		33 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/