< draft-ietf-ospf-ospfv3-auth-07.txt		draft-ietf-ospf-ospfv3-auth-08.txt >
	Network Working Group M. Gupta		Network Working Group M. Gupta
	Internet Draft Nokia		Internet Draft Tropos Networks
	Document: draft-ietf-ospf-ospfv3-auth-07.txt N. Melam		Document: draft-ietf-ospf-ospfv3-auth-08.txt N. Melam
	Expires: August 2005 Nokia		Expires: Aug 2006 Juniper Networks
	February 2005		February 2006
	Authentication/Confidentiality for OSPFv3		Authentication/Confidentiality for OSPFv3
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, each author represents that any		By submitting this Internet-Draft, each author represents that any
	applicable patent or other IPR claims of which he or she is aware		applicable patent or other IPR claims of which he or she is aware
	have been or will be disclosed, and any of which he or she becomes		have been or will be disclosed, and any of which he or she becomes
	aware will be disclosed, in accordance with Section 6 of RFC 3668.		aware will be disclosed, in accordance with Section 6 of BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	other groups may also distribute working documents as Internet-		other groups may also distribute working documents as Internet-
	Drafts.		Drafts.
	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."
	skipping to change at page 1, line 41 ¶		skipping to change at page 1, line 41 ¶
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	Abstract		Abstract
	This document describes means/mechanisms to provide		This document describes means/mechanisms to provide
	authentication/confidentiality to OSPFv3 using an IPv6 AH/ESP		authentication/confidentiality to OSPFv3 using an IPv6 AH/ESP
	Extension Header.		Extension Header.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society. (2004)		Copyright (C) The Internet Society (2006).
	Conventions used in this document		Conventions used in this document
	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 RFC-2119 [N7].		document are to be interpreted as described in RFC-2119 [N7].
	Table of Contents		Table of Contents
	1. Introduction...................................................2		1. Introduction...................................................2
	2. Transport Mode vs Tunnel Mode..................................2		2. Transport Mode vs Tunnel Mode..................................3
	3. Authentication.................................................3		3. Authentication.................................................3
	4. Confidentiality................................................3		4. Confidentiality................................................3
	5. Distinguishing OSPFv3 from OSPFv2..............................4		5. Distinguishing OSPFv3 from OSPFv2..............................4
	6. IPsec Requirements.............................................4		6. IPsec Requirements.............................................4
	7. Key Management.................................................5		7. Key Management.................................................5
	8. SA Granularity and Selectors...................................7		8. SA Granularity and Selectors...................................7
	9. Virtual Links..................................................7		9. Virtual Links..................................................7
	10. Rekeying......................................................8		10. Rekeying......................................................9
	10.1 Rekeying Procedure........................................8		10.1 Rekeying Procedure........................................9
	10.2 KeyRolloverInterval.......................................9		10.2 KeyRolloverInterval.......................................9
	10.3 Rekeying Interval.........................................9		10.3 Rekeying Interval........................................10
	11. IPsec rules..................................................10		11. IPsec Protection Barrier and SPD.............................10
	12. Entropy of manual keys.......................................11		12. Entropy of manual keys.......................................11
	13. Replay Protection............................................11		13. Replay Protection............................................12
	Security Considerations..........................................11		Security Considerations..........................................12
	Normative References.............................................12		IANA Considerations..............................................13
			Normative References.............................................13
	Informative References...........................................13		Informative References...........................................13
	Acknowledgments..................................................13		Acknowledgments..................................................14
	Authors' Addresses...............................................14		Authors' Addresses...............................................14
	1. Introduction		1. Introduction
	OSPF (Open Shortest Path First) Version 2 [N1] defines fields AuType		OSPF (Open Shortest Path First) Version 2 [N1] defines the fields
	and Authentication in its protocol header in order to provide		AuType and Authentication in its protocol header to provide security.
	security. In OSPF for IPv6 (OSPFv3) [N2], both of the authentication		In OSPF for IPv6 (OSPFv3) [N2], both of the authentication fields
	fields were removed from OSPF headers. OSPFv3 relies on the IPv6		were removed from OSPF headers. OSPFv3 relies on the IPv6
	Authentication Header (AH) and IPv6 Encapsulating Security Payload		Authentication Header (AH) and IPv6 Encapsulating Security Payload
	(ESP) to provide integrity, authentication and/or confidentiality.		(ESP) to provide integrity, authentication and/or confidentiality.
	This document describes how IPv6 AH/ESP extension headers can be used		This document describes how IPv6 AH/ESP extension headers can be used
	to provide authentication/confidentiality to OSPFv3.		to provide authentication/confidentiality to OSPFv3.
	It is assumed that the reader is familiar with OSPFv3 [N2], AH [N5],		It is assumed that the reader is familiar with OSPFv3 [N2], AH [N5],
	ESP [N4], the concept of security associations, tunnel and transport		ESP [N4], the concept of security associations, tunnel and transport
	mode of IPsec and the key management options available for AH and ESP		mode of IPsec and the key management options available for AH and ESP
	(manual keying [N3] and Internet Key Exchange (IKE)[I1]).		(manual keying [N3] and Internet Key Exchange (IKE)[I1]).
	2. Transport Mode vs Tunnel Mode		2. Transport Mode vs Tunnel Mode
	Transport mode Security Association (SA) is generally used between		The transport mode Security Association (SA) is generally used
	two hosts or routers/gateways when they are acting as hosts. SA must		between two hosts or routers/gateways when they are acting as hosts.
	be a tunnel mode SA if either end of the security association is a		The SA must be a tunnel mode SA if either end of the security
	router/gateway. Two hosts MAY establish a tunnel mode SA between		association is a router/gateway. Two hosts MAY establish a tunnel
	themselves. OSPFv3 packets are exchanged between the routers but as		mode SA between themselves. OSPFv3 packets are exchanged between
	the packets are destined to the routers, the routers act like hosts		routers. However, since the packets are locally delivered, the
	in this case. All implementations confirming to this specification		routers assume the role of hosts in the context of tunnel mode SA.
	MUST support Transport mode SA to provide required IPsec security to		All implementations confirming to this specification MUST support
	OSPFv3 packets. They MAY also support Tunnel mode SA to provide		Transport mode SA to provide required IPsec security to OSPFv3
	required IPsec security to OSPFv3 packets.		packets. They MAY also support Tunnel mode SA to provide required
			IPsec security to OSPFv3 packets.
	3. Authentication		3. Authentication
	Implementations conforming to this specification MUST support		Implementations conforming to this specification MUST support
	Authentication for OSPFv3.		Authentication for OSPFv3.
	In order to provide authentication to OSPFv3, ESP MUST be supported		In order to provide authentication to OSPFv3, implementations MUST
	and AH MAY be supported by the implementation.		support ESP and MAY support AH.
	If ESP in transport mode is used, it will provide authentication to		If ESP in transport mode is used, it will only provide authentication
	only OSPFv3 protocol headers but not to the IPv6 header, extension		to OSPFv3 protocol packet excluding the IPv6 header, extension
	headers and options.		headers and options.
	If AH in transport mode is used, it will provide authentication to		If AH in transport mode is used, it will provide authentication to
	OSPFv3 protocol headers, selected portions of IPv6 header, selected		OSPFv3 protocol packet, selected portions of IPv6 header, selected
	portions of extension headers and selected options.		portions of extension headers and selected options.
	When OSPFv3 authentication is enabled,		When OSPFv3 authentication is enabled,
	O OSPFv3 packets that are not protected with AH or ESP MUST be		O OSPFv3 packets that are not protected with AH or ESP MUST be
	silently discarded.		silently discarded.
	O OSPFv3 packets that fail the authentication checks MUST be		O OSPFv3 packets that fail the authentication checks MUST be
	silently discarded.		silently discarded.
	skipping to change at page 3, line 45 ¶		skipping to change at page 4, line 4 ¶
	silently discarded.		silently discarded.
	4. Confidentiality		4. Confidentiality
	Implementations conforming to this specification SHOULD support		Implementations conforming to this specification SHOULD support
	confidentiality for OSPFv3.		confidentiality for OSPFv3.
	If confidentiality is provided, ESP MUST be used.		If confidentiality is provided, ESP MUST be used.
	When OSPFv3 confidentiality is enabled,		When OSPFv3 confidentiality is enabled,
	O OSPFv3 packets that are not protected with ESP MUST be silently		O OSPFv3 packets that are not protected with ESP MUST be silently
	discarded.		discarded.
	O OSPFv3 packets that fail the confidentiality checks MUST be		O OSPFv3 packets that fail the confidentiality checks MUST be
	silently discarded.		silently discarded.
	5. Distinguishing OSPFv3 from OSPFv2		5. Distinguishing OSPFv3 from OSPFv2
	The IP/IPv6 Protocol Type for OSPFv2 and OSPFv3 is same (89) and		The IP/IPv6 Protocol Type for OSPFv2 and OSPFv3 is the same (89) and
	OSPF distinguishes them based on the OSPF header version number.		OSPF distinguishes them based on the OSPF header version number.
	However current IPsec standards do not allow using arbitrary protocol		However, current IPsec standards do not allow using arbitrary
	specific header fields as the selectors. Therefore, in order to		protocol specific header fields as the selectors. Therefore, the
	distinguish OSPFv3 packets from the OSPFv2 packets, OSPF version		OSPF version field in the OSPF header cannot be used in order to
	field in the OSPF header cannot be used. As OSPFv2 is only for IPv4		distinguish OSPFv3 packets from OSPFv2 packets. As OSPFv2 is only
	and OSPFv3 is only for IPv6, version field in IP header can be used		for IPv4 and OSPFv3 is only for IPv6, version field in IP header can
	to distinguish OSPFv3 packets from OSPFv2 packets.		be used to distinguish OSPFv3 packets from OSPFv2 packets.
	6. IPsec Requirements		6. IPsec Requirements
	In order to implement this specification, the following IPsec		In order to implement this specification, the following IPsec
	capabilities are required.		capabilities are required.
	Transport Mode		Transport Mode
	IPsec in transport mode MUST be supported. [N3]		IPsec in transport mode MUST be supported. [N3]
	Traffic Selectors		Multiple SPDs
	The implementation MUST be able to use interface index, source		The implementation MUST support multiple SPDs with a SPD selection
	address, destination address, protocol and direction for choosing		function that provides an ability to choose a specific SPD based
	the right security action.		on interface. [N3]
			Selectors
			The implementation MUST be able to use source address, destination
			address, protocol and direction as selectors in the SPD.
			Interface ID tagging
			The implementation MUST be able to tag the inbound packets with
			the ID of the interface (physical or virtual) via which it
			arrived. [N3]
	Manual key support		Manual key support
	Manually configured keys MUST be able to secure the specified		Manually configured keys MUST be able to secure the specified
	traffic. [N3]		traffic. [N3]
	Encryption and Authentication Algorithms		Encryption and Authentication Algorithms
	The implementation MUST NOT allow the user to choose stream		The implementation MUST NOT allow the user to choose stream
	ciphers as the encryption algorithm for securing OSPFv3 packets		ciphers as the encryption algorithm for securing OSPFv3 packets
	as the stream ciphers are not suitable for manual keys.		since the stream ciphers are not suitable for manual keys.
	Except when in conflict with the above statement, Keywords		Except when in conflict with the above statement, the Keywords
	"MUST", "MUST NOT", "REQUIRED", "SHOULD" and "SHOULD NOT" that		"MUST", "MUST NOT", "REQUIRED", "SHOULD" and "SHOULD NOT" that
	appear in the [N6] document for algorithms to be supported are to		appear in the [N6] document for algorithms to be supported are to
	be interpreted as described in [N7] for OSPFv3 support too.		be interpreted as described in [N7] for OSPFv3 support as well.
	Dynamic IPsec rule configuration		Dynamic IPsec rule configuration
	Routing module SHOULD be able to configure, modify and delete		The routing module SHOULD be able to configure, modify and delete
	IPsec rules on the fly. This is needed mainly for securing		IPsec rules on the fly. This is needed mainly for securing
	virtual links.		virtual links.
	Encapsulation of ESP packet		Encapsulation of ESP packet
	IP encapsulation of ESP packets MUST be supported. For		IP encapsulation of ESP packets MUST be supported. For
	simplicity, UDP encapsulation of ESP packets SHOULD NOT be used.		simplicity, UDP encapsulation of ESP packets SHOULD NOT be used.
	Different SAs for different DSCPs		Different SAs for different DSCPs
	As per [N3], IPsec implementation MUST support the establishment		As per [N3], the IPsec implementation MUST support the
	and maintenance of multiple SAs between given sender and receiver,		establishment and maintenance of multiple SAs with the same
	with the same selectors. This allows the implementation to put		selectors between a given sender and receiver. This allows the
	traffic of different classes, but with same selector values, on		implementation to associate different classes of traffic with same
	different SAs to support QoS appropriately.		selector values in support of QoS.
	7. Key Management		7. Key Management
	OSPFv3 exchanges both multicast and unicast packets. While running		OSPFv3 exchanges both multicast and unicast packets. While running
	OSPFv3 over a broadcast interface, the authentication/confidentiality		OSPFv3 over a broadcast interface, the authentication/confidentiality
	required is "one to many". Since IKE is based on the Diffie-Hellman		required is "one to many". Since IKE is based on the Diffie-Hellman
	key agreement protocol and works only for two communicating parties,		key agreement protocol and works only for two communicating parties,
	it is not possible to use IKE for providing the required "one to		it is not possible to use IKE for providing the required "one to
	many" authentication/confidentiality. This specification mandates		many" authentication/confidentiality. This specification mandates
	the usage of Manual Keying to work with the current IPsec		the usage of Manual Keying to work with the current IPsec
	implementations. Future specifications can explore the usage of		implementations. Future specifications can explore the usage of
	protocols like KINK/GSAKMP as and when they are widely available. In		protocols like KINK/GSAKMP when they are widely available. In manual
	manual keying SAs are statically installed on the routers and these		keying, SAs are statically installed on the routers and these static
	static SAs are used to authenticate/encrypt the packets.		SAs are used to authenticate/encrypt packets.
	The following discussion explains that it is not scalable and		The following discussion explains that it is not scalable and is
	practically infeasible to use different security associations for		practically infeasible to use different security associations for
	inbound and outbound traffic in order to provide the required "one to		inbound and outbound traffic to provide the required "one to many"
	many" security. Therefore, the implementations MUST use manually		security. Therefore, the implementations MUST use manually
	configured keys with same SA for inbound and outbound traffic (as		configured keys with the same SA parameters (SPI, keys etc.,) for
	shown in Figure 3).		both inbound and outbound SA (as shown in Figure 3).
	A |		A |
	SAa ------------>|		SAa ------------>|
	SAb <------------|		SAb <------------|
	|		|
	B |		B |
	SAb ------------>|		SAb ------------>|
	SAa <------------| Figure: 1		SAa <------------| Figure: 1
	|		|
	C |		C |
	SAa/SAb ------------>|		SAa/SAb ------------>|
	SAa/SAb <------------|		SAa/SAb <------------|
	|		|
	Broadcast		Broadcast
	Network		Network
	If we consider communication between A and B in Figure 1, everything		If we consider communication between A and B in Figure 1, everything
	seems to be fine. A uses security association SAa for outbound		seems to be fine. A uses security association SAa for outbound
	packets and B uses the same for inbound packets and vice versa. Now		packets and B uses the same for inbound packets and vice versa. Now
	if we include C in the group and C sends a packet out using SAa then		if we include C in the group and C sends a packet using SAa then only
	only A will be able to understand it or if C sends the packets out		A will be able to understand it. Similarly, if C sends a packet
	using SAb then only B will be able to understand it. Since the		using SAb then only B will be able to understand it. Since the
	packets are multicast packets and they are going to be processed by		packets are multicast and they are going to be processed by both A
	both A and B, there is no SA for C to use so that A and B both can		and B, there is no SA for C to use so that both A and B can
	understand it.		understand them.
	A |		A |
	SAa ------------>|		SAa ------------>|
	SAb <------------|		SAb <------------|
	SAc <------------|		SAc <------------|
	|		|
	B |		B |
	SAb ------------>|		SAb ------------>|
	SAa <------------| Figure: 2		SAa <------------| Figure: 2
	SAc <------------|		SAc <------------|
	|		|
	C |		C |
	SAc ------------>|		SAc ------------>|
	SAa <------------|		SAa <------------|
	SAb <------------|		SAb <------------|
	|		|
	Broadcast		Broadcast
	Network		Network
	The problem can be solved by configuring SAs for all the nodes on all		The problem can be solved by configuring SAs for all the nodes on
	the nodes as shown in Figure 2. So A, B and C will use SAa, SAb and		every other node as shown in Figure 2. So A, B and C will use SAa,
	SAc respectively for outbound traffic. Each node will lookup the SA		SAb and SAc respectively for outbound traffic. Each node will lookup
	to be used based on the source (A will use SAb and SAc for packets		the SA to be used based on the source (A will use SAb and SAc for
	received from B and C respectively). This solution is not scalable		packets received from B and C respectively). This solution is not
	and practically infeasible because every node will need to be		scalable and practically infeasible because a large number of SAs
	configured with a large number of SAs and addition of a node in the		will need to be configured on each node. Also, the addition of a
	network will cause addition of another SA on all the nodes.		node in the broadcast network will require the addition of another SA
			on every other node.
	A |		A |
	SAs ------------>|		SAo ------------>|
	SAs <------------|		SAi <------------|
	|		|
	B |		B |
	SAs ------------>|		SAo ------------>|
	SAs <------------| Figure: 3		SAi <------------| Figure: 3
	|		|
	C |		C |
	SAs ------------>|		SAo ------------>|
	SAs <------------|		SAi <------------|
	|		|
	Broadcast		Broadcast
	Network		Network
	The problem can also be solved by using the same SA for inbound and		The problem can be solved by using the same SA parameters (SPI, Keys
	outbound traffic as shown in Figure 3.		etc.,) for both inbound (SAi) and outbound (SAo) SAs as shown in
			Figure 3.
	8. SA Granularity and Selectors		8. SA Granularity and Selectors
	The user SHOULD be given a choice to share the same SA among multiple		The user SHOULD be given the choice of sharing the same SA among
	interfaces or using unique SA per interface.		multiple interfaces or using a unique SA per interface.
	OSPFv3 supports running multiple instances over one interface using		OSPFv3 supports running multiple instances over one interface using
	the "Instance Id" field contained in the OSPFv3 header. As IPsec		the "Instance Id" field contained in the OSPFv3 header. As IPsec
	does not support arbitrary fields in protocol header to be used as		does not support arbitrary fields in protocol header to be used as
	the selectors, it is not possible to use different SAs for different		the selectors, it is not possible to use different SAs for different
	instances of OSPFv3 running over the same interface. Therefore, all		OSPFv3 instances running over the same interface. Therefore, all
	the instances of OSPFv3 running over the same interface will have to		OSPFv3 instances running over the same interface will have to use the
	use the same SA. In OSPFv3 RFC terminology, SAs are per-link and not		same SA. In OSPFv3 RFC terminology, SAs are per-link and not per-
	per-interface.		interface.
	9. Virtual Links		9. Virtual Links
			A different SA than the SA of the underlying interface MUST be
			provided for virtual links. Packets sent on virtual links use
			unicast non-link local IPv6 addresses as the IPv6 source address
			while packets sent on other interfaces use multicast and unicast link
			local addresses. This difference in the IPv6 source address
			differentiates the packets sent on virtual links from other OSPFv3
			interface types.
	Different SA than the SA of underlying interface MUST be provided for		As the virtual link end point IPv6 addresses are not known, it is not
	virtual links. Packets sent out on virtual links use unicast non-		possible to install SPD/SAD entries at the time of configuration.
	link local IPv6 addresses as the IPv6 source address and all the		The virtual link end point IPv6 addresses are learned during the
	other packets use multicast and unicast link local addresses. This		routing table computation process. The packet exchange over the
	difference in the IPv6 source address is used in order to		virtual links starts only after the discovery of the end point IPv6
	differentiate the packets sent on interfaces and virtual links.		addresses. In order to protect these exchanges, the routing module
			must install the corresponding SPD/SAD entries before starting these
	As the end point IP addresses of the virtual links are not known at		exchanges. Note that manual SA parameters are preconfigured but not
	the time of configuration, the secure channel for these packets needs		installed in the SAD until the end point addresses are learned.
	to be set up dynamically. The end point IP addresses of virtual
	links are learned during the routing table build up process. The
	packet exchange over the virtual links starts only after the
	discovery of end point IP addresses. In order to provide security to
	these exchanges, the routing module should setup a secure IPsec
	channel dynamically once it acquires the required information.
	According to the OSPFv3 RFC [N2], the virtual neighbor's IP address		According to the OSPFv3 RFC [N2], the virtual neighbor's IP address
	is set to the first prefix with the "LA-bit" set from the list of		is set to the first prefix with the "LA-bit" set from the list of
	prefixes in intra-area-prefix-LSAs originated by the virtual		prefixes in intra-area-prefix-LSAs originated by the virtual
	neighbor. But when it comes to choosing the source address for the		neighbor. But when it comes to choosing the source address for the
	packets that are sent over the virtual link, the RFC simply suggests		packets that are sent over the virtual link, the RFC simply suggests
	using one of the router's own site-local or global IPv6 addresses.		using one of the router's own global IPv6 addresses. In order to
	In order to install the required security rules for virtual links,		install the required security rules for virtual links, the source
	the source address also needs to be predictable. So the routers that		address also needs to be predictable. Hence, routers that implement
	implement this specification MUST change the way the source and		this specification MUST change the way the source and destination
	destination addresses are chosen for the packets exchanged over		addresses are chosen for packets exchanged over virtual links when
	virtual links when the security is enabled on that virtual link.		IPsec is enabled.
	The first IPv6 address with the "LA-bit" set in the list of prefixes		The first IPv6 address with the "LA-bit" set in the list of prefixes
	advertised in intra-area-prefix-LSAs in the transit area MUST be used		advertised in intra-area-prefix-LSAs in the transit area MUST be used
	as the source address for packets exchanged over the virtual link.		as the source address for packets exchanged over the virtual link.
	When multiple intra-area-prefix-LSAs are originated they are		When multiple intra-area-prefix-LSAs are originated they are
	considered as being concatenated and are ordered by ascending Link		considered as being concatenated and are ordered by ascending Link
	State ID.		State ID.
	The first IPv6 address with the "LA-bit" set in the list of prefixes		The first IPv6 address with the "LA-bit" set in the list of prefixes
	received in intra-area-prefix-LSAs from the virtual neighbor in the		received in intra-area-prefix-LSAs from the virtual neighbor in the
	transit area MUST be used as the destination address for packets		transit area MUST be used as the destination address for packets
	exchanged over the virtual link. When multiple intra-area-prefix-		exchanged over the virtual link. When multiple intra-area-prefix-
	LSAs are received they are considered as being concatenated and are		LSAs are received they are considered as being concatenated and are
	ordered by ascending Link State ID.		ordered by ascending Link State ID.
	This makes both the source and destination addresses of the packets		This makes both the source and destination addresses of packets
	exchanged over the virtual link, predictable on both the routers for		exchanged over the virtual link predictable when IPsec is enabled.
	security purposes.
	10. Rekeying		10. Rekeying
	To maintain the security of a link, the authentication and encryption		To maintain the security of a link, the authentication and encryption
	key values SHOULD be changed from time to time.		key values SHOULD be changed from periodically.
	10.1 Rekeying Procedure		10.1 Rekeying Procedure
	The following three-step procedure SHOULD be provided to rekey the		The following three-step procedure SHOULD be provided to rekey the
	routers on a link without dropping OSPFv3 protocol packets or		routers on a link without dropping OSPFv3 protocol packets or
	disrupting the adjacency.		disrupting the adjacency.
	(1) For every router on the link, create an additional inbound SA for		(1) For every router on the link, create an additional inbound SA for
	the interface being rekeyed using a new SPI and the new key.		the interface being rekeyed using a new SPI and the new key.
	(2) For every router on the link, replace the original outbound SA		(2) For every router on the link, replace the original outbound SA
	with one using the new SPI and key values. The SA replacement		with one using the new SPI and key values. The SA replacement
	operation should be atomic with respect to sending OSPFv3 packets		operation should be atomic with respect to sending OSPFv3 packets
	on the link so that no OSPFv3 packets are sent without		on the link so that no OSPFv3 packets are sent without
	authentication/encryption.		authentication/encryption.
	(3) For every router on the link, remove the original inbound SA.		(3) For every router on the link, remove the original inbound SA.
	Note that all the routers on the link must complete step 1 before any		Note that all routers on the link must complete step 1 before any
	begin step 2. Likewise, all the routers on the link must complete		begin step 2. Likewise, all the routers on the link must complete
	step 2 before any begin step 3.		step 2 before any begin step 3.
	One way to control the progression from one step to the next is for		One way to control the progression from one step to the next is for
	each router to have a configurable time constant KeyRolloverInterval.		each router to have a configurable time constant KeyRolloverInterval.
	After the router begins step 1 on a given link, it waits for this		After the router begins step 1 on a given link, it waits for this
	interval and then moves to step 2. Likewise, after moving to step 2,		interval and then moves to step 2. Likewise, after moving to step 2,
	it waits for this interval and then moves to step 3.		it waits for this interval and then moves to step 3.
	In order to achieve smooth key transition, all the routers on a link		In order to achieve smooth key transition, all routers on a link
	should use the same value for KeyRolloverInterval, and should		should use the same value for KeyRolloverInterval and should initiate
	initiate the key rollover process within this time period.		the key rollover process within this time period.
	At the end of this procedure, all the routers will have a single		At the end of this procedure, all the routers on the link will have a
	inbound and outbound SA for OSPFv3 on the link with the new SPI and		single inbound and outbound SA for OSPFv3 with the new SPI and key
	key values.		values.
	10.2 KeyRolloverInterval		10.2 KeyRolloverInterval
	The configured value of KeyRolloverInterval should be long enough to		The configured value of KeyRolloverInterval should be long enough to
	allow the administrator to change keys on all the involved routers.		allow the administrator to change keys on all the OSPFv3 routers. As
	As this value can vary significantly depending upon the		this value can vary significantly depending upon the implementation
	implementation and the deployment, it is left to the administrator to		and the deployment, it is left to the administrator to choose the
	choose the appropriate value.		appropriate value.
	10.3 Rekeying Interval		10.3 Rekeying Interval
	This section analyzes the security provided by the manual keying and		This section analyzes the security provided by manual keying and
	recommends that the encryption and authentication keys SHOULD be		recommends that the encryption and authentication keys SHOULD be
	changed at least every 90 days.		changed at least every 90 days.
	The weakest security provided by the security mechanisms discussed in		The weakest security provided by the security mechanisms discussed in
	this specification is when NULL encryption (for ESP) or no encryption		this specification is when NULL encryption (for ESP) or no encryption
	(for AH) is used with the HMAC-MD5 authentication. Any other		(for AH) is used with the HMAC-MD5 authentication. Any other
	algorithm combinations will at least be as hard to break as the one		algorithm combinations will at least be as hard to break as the ones
	mentioned above as shown by the following examples:		mentioned above. This is shown by the following reasonable
			assumptions:
	O NULL Encryption and HMAC-SHA-1 Authentication will be more secure		O NULL Encryption and HMAC-SHA-1 Authentication will be more secure
	as HMAC-SHA-1 is considered to be more secure than HMAC-MD5		as HMAC-SHA-1 is considered to be more secure than HMAC-MD5.
	O NON-NULL Encryption and NULL Authentication is not applicable as		O NON-NULL Encryption and NULL Authentication is not applicable as
	this specification mandates the authentication when OSPFv3 security		this specification mandates authentication when OSPFv3 security is
	is enabled		enabled.
	O DES Encryption and HMAC-MD5 Authentication will be more secure		O DES Encryption and HMAC-MD5 Authentication will be more secure
	because of the additional security provided by DES		because of the additional security provided by DES.
	O Other encryption algorithms like 3DES, AES will be more secure than
	DES		O Other encryption algorithms like 3DES and AES will be more secure
			than DES.
	RFC 3562 [I4] analyzes the rekeying requirements for the TCP MD5		RFC 3562 [I4] analyzes the rekeying requirements for the TCP MD5
	signature option. The analysis provided in this RFC is also		signature option. The analysis provided in this RFC is also
	applicable to OSPFv3 security specification as the analysis is		applicable to this specification as the analysis is independent of
	independent of data patterns.		data patterns.
	11. IPsec rules
	The following set of transport mode rules can be installed in a
	typical IPsec implementation to provide the
	authentication/confidentiality to OSPFv3 packets.
	Outbound Rules for interface running OSPFv3 security:
	No. source destination protocol action		11. IPsec Protection Barrier and SPD
	1 fe80::/10 any OSPF apply
	Outbound Rules for virtual links running OSPFv3 security:		The IPsec protection barrier MUST BE around the OSPF protocol.
			Therefore, all the inbound and outbound OSPF traffic goes through
			IPsec processing.
	No. source destination protocol action		The SPD selection function MUST return a SPD with the following rule
	2 src/128 dst/128 OSPF apply		for all the interfaces that have OSPFv3
			authentication/confidentiality disabled.
	Inbound Rules for interface running OSPFv3 security:		No. source destination protocol action
			1 any any OSPF bypass
	No. source destination protocol action		The SPD selection function MUST return a SPD with the following rules
	3 fe80::/10 any ESP/OSPF or AH/OSPF apply		for all the interfaces that have OSPFv3
	4 fe80::/10 any OSPF drop		authentication/confidentiality enabled.
	Inbound Rules for virtual links running OSPFv3 security:		No. source destination protocol action
			2 fe80::/10 any OSPF protect
			3 fe80::/10 any ESP/OSPF or AH/OSPF protect
			4 src/128 dst/128 OSPF protect
			5 src/128 dst/128 ESP/OSPF or AH/OSPF protect
	No. source destination protocol action		For rules 2 and 4, action "protect" means encrypting/calculating ICV
	5 src/128 dst/128 ESP/OSPF or AH/OSPF apply		and adding an ESP or AH header. For rules 3 and 5, action "protect"
	6 src/128 dst/128 OSPF drop		means decrypting/authenticating the packets and stripping the ESP or
			AH header.
	For outbound rules, action "apply" means encrypting/calculating ICV		Rule 1 will bypass the OSPFv3 packets without any IPsec processing on
	and adding ESP or AH header. For inbound rules, action "apply" means		the interfaces that have OSPFv3 authentication/confidentiality
	decrypting/authenticating the packets and stripping ESP or AH header.		disabled.
	Rules 4 and 6 are to drop the insecure OSPFv3 packets without ESP/AH		Rules 2 and 4 will drop the inbound OSPFv3 packets that have not been
	headers.		secured with ESP/AH headers.
	ESP/OSPF or AH/OSPF in rules 3 and 5 mean that it is an OSPF packet		ESP/OSPF or AH/OSPF in rules 3 and 5 mean that it is an OSPF packet
	secured with ESP or AH.		secured with ESP or AH.
	Rules 1, 3 and 4 are meant to secure the unicast and multicast OSPF		Rules 2 and 3 are meant to secure the unicast and multicast OSPF
	packets that are not being exchanged over the virtual links. These		packets that are not being exchanged over the virtual links.
	rules MUST be installed only in the security policy database (SPD) of
	the interface running OSPFv3 security.
	Rules 2, 5 and 6 are meant to secure the packets being exchanged over		Rules 4 and 5 are meant to secure the packets being exchanged over
	virtual links. These rules are dynamically installed after learning		virtual links. These rules are installed after learning the virtual
	the end point IP addresses of a virtual link. These rules MUST be		link end point IPv6 addresses. These rules MUST be installed in the
	installed on at least the interfaces that are connected to the		SPD for the interfaces that are connected to the transit area for the
	transit area for the virtual link. These rules MAY alternatively be		virtual link. These rules MAY alternatively be installed on all the
	installed on all the interfaces. If these rules are not installed on		interfaces. If these rules are not installed on all the interfaces,
	all the interfaces, clear text or malicious OSPFv3 packets with same		clear text or malicious OSPFv3 packets with the same source and
	source and destination addresses as virtual link end point addresses		destination addresses as the virtual link end point IPv6 addresses
	will be delivered to OSPFv3. Though OSPFv3 drops these packets		will be delivered to OSPFv3. Though OSPFv3 drops these packets
	because they were not received on the right interface, OSPFv3		because they were not received on the right interface, OSPFv3
	receives some clear text or malicious packets even when the security		receives some clear text or malicious packets even when the security
	is on. Installing these rules on all the interfaces insures that		is enabled. Installing these rules on all the interfaces insures
	OSPFv3 does not receive these clear text or malicious packets when		that OSPFv3 does not receive these clear text or malicious packets
	security is turned on. On the other hand installing these rules on		when security is turned enabled. On the other hand, installing these
	all the interfaces increases the processing overhead on the		rules on all the interfaces increases the processing overhead on the
	interfaces where there is no IPsec processing otherwise. The		interfaces where there is no other IPsec processing. The decision of
	decision of installing these rules on all the interfaces or on just		installing these rules on all the interfaces or on just the
	the interfaces that are connected to the transit area is a private		interfaces that are connected to the transit area is a private
	decision and doesn't affect the interoperability in any way. So this		decision and doesn't affect the interoperability in any way. Hence
	decision is left to the implementers.		it is an implementation choice.
	12. Entropy of manual keys		12. Entropy of manual keys
	The implementations MUST allow the administrator to configure the		The implementations MUST allow the administrator to configure the
	cryptographic and authentication keys in hexadecimal format instead		cryptographic and authentication keys in hexadecimal format rather
	of restricting it a subset of ASCII characters (letters, numbers		than restricting it to a subset of ASCII characters (letters, numbers
	etc). Otherwise the entropy of the keys reduces significantly as		etc). A restricted character set will reduce key entropy
	discussed in [I2].		significantly as discussed in [I2].
	13. Replay Protection		13. Replay Protection
	As it is not possible as per the current standards to provide		Since it is not possible using the current standards to provide
	complete replay protection while using manual keying, the proposed		complete replay protection while using manual keying, the proposed
	solution will not provide protection against replay attacks.		solution will not provide protection against replay attacks.
	Detailed analysis of various vulnerabilities of the routing protocols		Detailed analysis of various vulnerabilities of the routing protocols
	and OSPF in particular is discussed in [I3] and [I2], but it can be		and OSPF in particular is discussed in [I3] and [I2]. The conclusion
	summarized that "Replay of OSPF packets can cause adjacencies to be		is that "Replay of OSPF packets can cause adjacencies to be
	disrupted, which can lead to DoS attack on the network. It can also		disrupted, which can lead to a DoS attack on the network. It can also
	cause database exchange process to occur continuously thus causing		cause database exchange process to occur continuously thus causing
	CPU overload as well as micro loops in the network".		CPU overload as well as micro loops in the network".
	Security Considerations		Security Considerations
	This memo discusses the use of IPsec AH and ESP headers in order to		This memo discusses the use of IPsec AH and ESP headers in order to
	provide security to OSPFv3 for IPv6. Hence security permeates		provide security to OSPFv3 for IPv6. Hence security permeates
	throughout this document.		throughout this document.
	OSPF Security Vulnerabilities Analysis [I2] identifies OSPF		OSPF Security Vulnerabilities Analysis [I2] identifies OSPF
	vulnerabilities in two scenarios - One with no authentication or		vulnerabilities in two scenarios - One with no authentication or
	simple password authentication and the other with cryptographic		simple password authentication and the other with cryptographic
	authentication. The solution described in this specification		authentication. The solution described in this specification
	provides security against all the vulnerabilities identified for		provides protection against all the vulnerabilities identified for
	scenario with cryptographic authentication with the following		scenarios with cryptographic authentication with the following
	exceptions:		exceptions:
	Limitations of manual key:		Limitations of manual key:
	This specification mandates the usage of manual keys. The following		This specification mandates the usage of manual keys. The following
	are the known limitations of the usage of manual keys.		are the known limitations of the usage of manual keys.
	O As the sequence numbers can not be negotiated, replay protection		O As the sequence numbers can not be negotiated, replay protection
	can not be provided. This leaves OSPF insecure against all the		can not be provided. This leaves OSPF insecure against all the
	attacks that can be performed by replaying OSPF packets.		attacks that can be performed by replaying OSPF packets.
	O Manual keys are usually long lived (changing them very often is		O Manual keys are usually long lived (changing them often is
	a tedious task). This gives an attacker enough time to discover		a tedious task). This gives an attacker enough time to discover
	the keys.		the keys.
	O As the administrator is manually configuring the keys, there is		O As the administrator is manually configuring the keys, there is
	a chance that the configured keys are weak (there are known weak		a chance that the configured keys are weak (there are known weak
	keys for DES/3DES at least).		keys for DES/3DES at least).
	Impersonating Attacks:		Impersonating Attacks:
	The usage of the same key on all the routers on the same link for
	securing OSPF leaves it insecure against impersonating attacks if one
	of the routers is compromised, malfunctioning or misconfigured.
	Detailed analysis of various vulnerabilities of the routing protocols		The usage of the same key on all the OSPF routers connected to a link
	is discussed in [I3].		leaves them all insecure against impersonating attacks if any one of
			the OSPF routers is compromised, malfunctioning or misconfigured.
			Detailed analysis of various vulnerabilities of routing protocols is
			discussed in [I3].
			IANA Considerations
			This document has no IANA considerations.
			This section should be removed by the RFC Editor to final
			publication.
	Normative References		Normative References
	N1. Moy, J., "OSPF version 2", RFC 2328, April 1998.		N1. Moy, J., "OSPF version 2", RFC 2328, April 1998.
	N2. Coltun, R., Ferguson, D. and J. Moy, "OSPF for IPv6", RFC 2740,		N2. Coltun, R., Ferguson, D. and J. Moy, "OSPF for IPv6", RFC 2740,
	December 1999.		December 1999.
	N3. Kent, S. and K. Seo, "Security Architecture for the Internet		N3. Kent, S. and K. Seo, "Security Architecture for the Internet
	Protocol", RFC XXXX, date [Note to RFC-Editor: Replace XXXX with		Protocol", RFC 4301, December 2005.
	the number of the RFC 2401 replacement].
	N4. Kent, S., "IP Encapsulating Security Payload (ESP)", RFC XXXY,		N4. Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303,
	date [Note to RFC-Editor: Replace XXXY with the number of the RFC		December 2005.
	2406 replacement].
	N5. Kent, S., "IP Authentication Header (AH)", RFC XXXZ, date [Note to		N5. Kent, S., "IP Authentication Header (AH)", RFC 4302, December
	RFC-Editor: Replace XXXZ with the number of the RFC 2402		2005.
	replacement].
	N6. Eastlake, D., "Cryptographic Algorithm Implementation Requirements		N6. Eastlake, D., "Cryptographic Algorithm Implementation Requirements
	For ESP And AH", RFC XXYY, date [Note to RFC-Editor: Replace XXYY		For ESP And AH", RFC 4305, December 2005.
	with the number of the RFC that the draft draft-ietf-ipsec-esp-ah-
	algorithms-02.txt gets].
	N7. Bradner, S., "Key words for use in RFCs to Indicate Requirement		N7. Bradner, S., "Key words for use in RFCs to Indicate Requirement
	Level", BCP 14, RFC 2119, March 1997.		Level", BCP 14, RFC 2119, March 1997.
	N8. Frankel, S., Glenn, R. and S. Kelly, "The AES-CBC Cipher Algorithm		N8. Frankel, S., Glenn, R. and S. Kelly, "The AES-CBC Cipher Algorithm
	and Its Use with IPsec", RFC 3602, September 2003.		and Its Use with IPsec", RFC 3602, September 2003.
	N9. Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within ESP and		N9. Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within ESP and
	AH", RFC 2404, November 1998.		AH", RFC 2404, November 1998.
	Informative References		Informative References
	I1. Kaufman, C., "The Internet Key Exchange (IKEv2) Protocol", RFC		I1. Kaufman, C., "The Internet Key Exchange (IKEv2) Protocol", RFC
	XXZZ, date [Note to RFC-Editor: Replace XXZZ with the number of the		4306, December 2005.
	RFC 2409 replacement].
	I2. Jones, E. and O. Moigne, "OSPF Security Vulnerabilities Analysis",		I2. Jones, E. and O. Moigne, "OSPF Security Vulnerabilities Analysis",
	draft-ietf-rpsec-ospf-vuln-01.txt, work in progress.		draft-ietf-rpsec-ospf-vuln-01.txt, work in progress.
	I3. Barbir, A., Murphy, S. and Y. Yang, "Generic Threats to Routing		I3. Barbir, A., Murphy, S. and Y. Yang, "Generic Threats to Routing
	Protocols", draft-ietf-rpsec-routing-threats-07.txt, work in		Protocols", draft-ietf-rpsec-routing-threats-07.txt, work in
	progress.		progress.
	I4. Leech, M., "Key Management Considerations for the TCP MD5		I4. Leech, M., "Key Management Considerations for the TCP MD5
	Signature Option", RFC 3562, July 2003.		Signature Option", RFC 3562, July 2003.
	Acknowledgments		Acknowledgments
	Authors would like to extend sincere thanks to Marc Solsona, Janne		Authors would like to extend sincere thanks to Marc Solsona, Janne
	Peltonen, John Cruz, Dhaval Shah, Abhay Roy, Paul Wells and Vishwas		Peltonen, John Cruz, Dhaval Shah, Abhay Roy, Paul Wells, Vishwas
	Manral for providing useful information and critiques in order to		Manral and Sam Hartman for providing useful information and critiques
	write this memo.		in order to write this memo. Authors would like to extend special
			thanks to Acee Lindem for lots of editorial changes.
	We would also like to thank IPsec and OSPF WG people to provide		We would also like to thank IPsec and OSPF WG people to provide
	valuable review comments.		valuable review comments.
	Authors' Addresses		Authors' Addresses
	Mukesh Gupta		Mukesh Gupta
	Nokia		Tropos Networks
	313 Fairchild Drive		555 Del Rey Ave
	Mountain View, CA 94043		Sunnyvale, CA 94085
	Phone: 650-625-2264		Phone: 408-331-6889
	Email: Mukesh.Gupta@nokia.com		Email: mukesh.gupta@tropos.com
	Nagavenkata Suresh Melam		Nagavenkata Suresh Melam
	Nokia		Juniper Networks
	313 Fairchild Drive		1194 N. Mathilda Ave
	Mountain View, CA 94043		Sunnyvale, CA 94089
	Phone: 650-625-2949		Phone: 408-505-4392
	Email: Nagavenkata.Melam@nokia.com		Email: nmelam@juniper.net
	Full copyright statement		Full copyright statement
	Copyright (C) The Internet Society (2004). This document is subject		This document is subject to the rights, licenses and restrictions
	to the rights, licenses and restrictions contained in BCP 78 and		contained in BCP 78, and except as set forth therein, the authors
	except as set forth therein, the authors retain all their rights.		retain all their rights.
	This document and the information contained herein are provided on an		This document and the information contained herein are provided on an
	"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS		"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
	OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET		OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
	ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,		ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
	INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE		INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
	INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED		INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
	WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.		WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
	Intellectual Property		Intellectual Property
End of changes. 80 change blocks.
	231 lines changed or deleted		244 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/