< draft-ietf-ospf-security-extension-manual-keying-05.txt		draft-ietf-ospf-security-extension-manual-keying-06.txt >
	OSPF Working Group M. Bhatia		OSPF Working Group M. Bhatia
	Internet-Draft Alcatel-Lucent		Internet-Draft Alcatel-Lucent
	Intended status: Standards Track S. Hartman		Intended status: Standards Track S. Hartman
	Expires: November 28, 2013 Painless Security		Expires: May 29, 2014 Painless Security
	D. Zhang		D. Zhang
	Huawei Technologies co., LTD.		Huawei Technologies co., LTD.
	A. Lindem		A. Lindem
	Ericsson		Ericsson
	May 27, 2013		November 25, 2013
	Security Extension for OSPFv2 when using Manual Key Management		Security Extension for OSPFv2 when using Manual Key Management
	draft-ietf-ospf-security-extension-manual-keying-05		draft-ietf-ospf-security-extension-manual-keying-06
	Abstract		Abstract
	The current OSPFv2 cryptographic authentication mechanism as defined		The current OSPFv2 cryptographic authentication mechanism as defined
	in the OSPF standards is vulnerable to both inter-session and intra-		in RFC 2328 and RFC 5709 is vulnerable to both inter-session and
	session replay attacks when its uses manual keying. Additionally,		intra-session replay attacks when using manual keying. Additionally,
	the existing cryptographic authentication schemes do not cover the IP		the existing cryptographic authentication schemes do not cover the IP
	header. This omission can be exploited to carry out various types of		header. This omission can be exploited to carry out various types of
	attacks.		attacks.
	This draft proposes changes to the authentication sequence number		This draft proposes changes to the authentication sequence number
	mechanism that will protect OSPFv2 from both inter-session and intra-		mechanism that will protect OSPFv2 from both inter-session and intra-
	session replay attacks when its using manual keys for securing its		session replay attacks when using manual keys for securing OSPFv2
	protocol packets. Additionally, we also describe some changes in the		protocol packets. Additionally, we also describe some changes in the
	cryptographic hash computation so that we eliminate most attacks that		cryptographic hash computation so that we eliminate most attacks that
	result because OSPFv2 does not protect the IP header.		result from OSPFv2 not protecting the IP header.
	Status of this Memo		Status of this Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	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 November 28, 2013.		This Internet-Draft will expire on May 29, 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
	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
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	1.1. Requirements Section . . . . . . . . . . . . . . . . . . . 4		1.1. Requirements Section . . . . . . . . . . . . . . . . . . . 3
	1.2. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 4		1.2. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 4
	2. Replay Protection using Extended Sequence Numbers . . . . . . 4		2. Replay Protection using Extended Sequence Numbers . . . . . . 4
	3. OSPF Packet Extensions . . . . . . . . . . . . . . . . . . . . 5		3. OSPF Packet Extensions . . . . . . . . . . . . . . . . . . . . 5
	4. OSPF Packet Key Selection . . . . . . . . . . . . . . . . . . 6		4. OSPF Packet Key Selection . . . . . . . . . . . . . . . . . . 6
	4.1. Key Selection for Unicast OSPF Packet Transmission . . . . 7		4.1. Key Selection for Unicast OSPF Packet Transmission . . . . 7
	4.2. Key Selection for Multicast OSPF Packet Transmission . . . 7		4.2. Key Selection for Multicast OSPF Packet Transmission . . . 8
	4.3. Key Selection for OSPF Packet Reception . . . . . . . . . 8		4.3. Key Selection for OSPF Packet Reception . . . . . . . . . 8
	5. Securing the IP header . . . . . . . . . . . . . . . . . . . . 8		5. Securing the IP header . . . . . . . . . . . . . . . . . . . . 9
	6. Mitigating Cross-Protocol Attacks . . . . . . . . . . . . . . 9		6. Mitigating Cross-Protocol Attacks . . . . . . . . . . . . . . 9
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 10		7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11		9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
	9.1. Normative References . . . . . . . . . . . . . . . . . . . 11		9.1. Normative References . . . . . . . . . . . . . . . . . . . 11
	9.2. Informative References . . . . . . . . . . . . . . . . . . 11		9.2. Informative References . . . . . . . . . . . . . . . . . . 11
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
	1. Introduction		1. Introduction
	The OSPFv2 cryptographic authentication mechanism as described in		The OSPFv2 cryptographic authentication mechanism as described in
	[RFC2328] uses per-packet sequence numbers to provide protection		[RFC2328] uses per-packet sequence numbers to provide protection
	against replay attacks. The sequence numbers increase monotonically		against replay attacks. The sequence numbers increase monotonically
	so that the attempts to replay the stale packets can be thwarted.		so that attempts to replay the stale packets can be thwarted. The
	The sequence number values are maintained as a part of adjacency		sequence number values are maintained as a part of adjacency states.
	states. Therefore, if an adjacency is broken down, the associated		Therefore, if an adjacency is taken down, the associated sequence
	sequence numbers get reinitialized and the neighbors start all over		numbers get reinitialized and the neighbors start all over again.
	again. Additionally, the cryptographic authentication mechanism does		Additionally, the cryptographic authentication mechanism does not
	not specify how to deal with the rollover of a sequence number when		specify how to deal with the rollover of a sequence number when its
	its value would wrap. These omissions can be taken advantage of by		value wraps. These omissions can be taken advantage of by attackers
	attackers to implement various replay attacks ([RFC6039]). In order		to implement various replay attacks ([RFC6039]). In order to address
	to address these issues, we propose extensions to the authentication		these issues, we propose extensions to the authentication sequence
	sequence number mechanism. Compared with the cryptographic		number mechanism.
	authentication mechanism proposed in [RFC5709], the solution proposed
	does not impose any more security presumption.
	The cryptographic authentication as described in [RFC2328] and later		The cryptographic authentication as described in [RFC2328] and later
	updated in [RFC5709] does not include the IP header. This also can		updated in [RFC5709] does not include the IP header. This also can
	be exploited to launch several attacks as the source address in the		be exploited to launch several attacks as the source address in the
	IP header is no longer protected. The OSPF specification, for		IP header is no longer protected. The OSPF specification, for
	broadcast and NBMA (Non-Broadcast Multi-Access Networks), requires		broadcast and NBMA (Non-Broadcast Multi-Access Networks), requires
	the implementations to look at the source address in the IP header to		implementations to look at the source address in the IP header to
	determine the neighbor from witch the packet was received. Changing		determine the neighbor from which the packet was received. Changing
	the IP source address of a packet which can confuse the receiver and		the IP source address of a packet that confuses the receiver and can
	can be exploited to produce a number of denial of service attacks		be exploited to produce a number of denial of service attacks
	[RFC6039]. If the packet is interpreted as coming from a different		[RFC6039]. If the packet is interpreted as coming from a different
	neighbor, the sequence number received from the neighbor may be		neighbor, the sequence number received from the neighbor may be
	updated. This may disrupt communication with the legitimate		updated. This may disrupt communication with the legitimate
	neighbor. Hello packets may be reflected to cause a neighbor to		neighbor. Hello packets may be reflected to cause a neighbor to
	appear to have one-way communication. Old Database descriptions may		appear to have one-way communication. Additionally, Database
	be reflected in cases where the per-packet sequence numbers are		Description packets may be reflected in cases where the per-packet
	sufficiently divergent in order to disrupt an adjacency [RFC6863].		sequence numbers are sufficiently divergent in order to disrupt an
	This is referred to as the IP layer issue in [RFC6862].		adjacency [RFC6863]. This is referred to as the IP layer issue in
			[RFC6862].
	[RFC2328] states that implementations MUST offer keyed MD5		[RFC2328] states that implementations MUST offer keyed MD5
	authentication. It is likely that this will be deprecated in favor		authentication. It is likely that this will be deprecated in favor
	of the stronger algorithms described in [RFC5709] in future		of the stronger algorithms described in [RFC5709] and required in
	deployments [RFC6094].		[RFC6094].
	This draft proposes a few simple changes to the cryptographic		This draft proposes a few simple changes to the cryptographic
	authentication mechanism, as currently described in [RFC5709], to		authentication mechanism, as currently described in [RFC5709], to
	prevent such IP layer attacks.		prevent such IP layer attacks.
	1.1. Requirements Section		1.1. Requirements Section
	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 [RFC2119].		document are to be interpreted as described in RFC2119 [RFC2119].
	skipping to change at page 4, line 30 ¶		skipping to change at page 4, line 25 ¶
	2. Replay Protection using Extended Sequence Numbers		2. Replay Protection using Extended Sequence Numbers
	In order to provide replay protection against both inter-session and		In order to provide replay protection against both inter-session and
	intra-session replay attacks, the OSPFv2 sequence number is expanded		intra-session replay attacks, the OSPFv2 sequence number is expanded
	to 64-bits with the least significant 32-bit value containing a		to 64-bits with the least significant 32-bit value containing a
	strictly increasing sequence number and the most significant 32-bit		strictly increasing sequence number and the most significant 32-bit
	value containing the boot count. OSPFv2 implementations are required		value containing the boot count. OSPFv2 implementations are required
	to retain the boot count in non-volatile storage for the deployment		to retain the boot count in non-volatile storage for the deployment
	life the OSPF router. The requirement to preserve the boot count is		life the OSPF router. The requirement to preserve the boot count is
	also placed on SNMP agents by the SNMPv3 security architecture (refer		also placed on SNMP agents by the SNMPv3 security architecture (refer
	to snmpEngineBoots in [RFC4222].		to snmpEngineBoots in [RFC4222]).
	Since there is no room in the OSPFv2 packet for a 64-bit sequence		Since there is no room in the OSPFv2 packet for a 64-bit sequence
	number, it will occupy the 8 octets following the OSPFv2 packet and		number, it will occupy the 8 octets following the OSPFv2 packet and
	MUST be included when calculating the OSPFv2 packet digest. These		MUST be included when calculating the OSPFv2 packet digest. These
	additional 8 bytes are not included in the OSPFv2 packet header		additional 8 bytes are not included in the OSPFv2 packet header
	length but are included in the OSPFv2 header Authentication Data		length but are included in the OSPFv2 header Authentication Data
	length and the IPv4 packet header length.		length and the IPv4 packet header length.
	The lower order 32-bit sequence number MUST be incremented for every		The lower order 32-bit sequence number MUST be incremented for every
	OSPF packet sent by the OSPF router. Upon reception, the sequence		OSPF packet sent by the OSPF router. Upon reception, the sequence
	number MUST be greater than the sequence number in the last OSPF		number MUST be greater than the sequence number in the last OSPF
	packet of that type accepted from the sending OSPF neighbor.		packet of that type accepted from the sending OSPF neighbor.
	Otherwise, the OSPF packet is considered a replayed packet and		Otherwise, the OSPF packet is considered a replayed packet and
	dropped. OSPF packets of different types may arrive out of order if		dropped. OSPF packets of different types may arrive out of order if
	they are priorized as recommended in [RFC3414].		they are prioritized as recommended in [RFC3414].
	OSPF routers implementing this specification MUST use available		OSPF routers implementing this specification MUST use available
	mechanisms to preserve the sequence number's strictly increasing		mechanisms to preserve the sequence number's strictly increasing
	property for the deployed life of the OSPFv3 router (including cold		property for the deployed life of the OSPFv3 router (including cold
	restarts). This is achieved by maintaining a boot count in non-		restarts). This is achieved by maintaining a boot count in non-
	volatile storage and incrementing it each time the OSPF router loses		volatile storage and incrementing it each time the OSPF router loses
	its prior sequence number state. The SNMPv3 snmpEngineBoots variable		its prior sequence number state. The SNMPv3 snmpEngineBoots variable
	[RFC4222] MAY be used for this purpose. However, maintaining a		[RFC4222] MAY be used for this purpose. However, maintaining a
	separate boot count solely for OSPF sequence numbers has the		separate boot count solely for OSPF sequence numbers has the
	advantage of decoupling SNMP reinitialization and OSPF		advantage of decoupling SNMP reinitialization and OSPF
	skipping to change at page 6, line 35 ¶		skipping to change at page 6, line 35 ¶
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Sequence Number (Boot Count) |		| Sequence Number (Boot Count) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Sequence Number (Strictly Increasing Packet Counter) |		| Sequence Number (Strictly Increasing Packet Counter) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	~ Authentication Data ~		~ Authentication Data ~
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 7 - Extended Sequence Number Packet Extensions		Figure 1 - Extended Sequence Number Packet Extensions
	4. OSPF Packet Key Selection		4. OSPF Packet Key Selection
	This section describes how the proposed security solution selects		This section describes how the proposed security solution selects
	long-lived keys from key tables. [I-D.ietf-karp-crypto-key-table].		long-lived keys from key tables. [I-D.ietf-karp-crypto-key-table].
	Generally, a key used for OSPFv2 packet authentication should satisfy		Generally, a key used for OSPFv2 packet authentication should satisfy
	the following requirements:		the following requirements:
	o For packet transmission, the key validity interval as defined by		o For packet transmission, the key validity interval as defined by
	SendLifeTimeStart and SendLifeTimeEnd must include the current		SendLifetimeStart and SendLifetimeEnd must include the current
	time.		time.
	o For packet reception, the key validity interval as defined by		o For packet reception, the key validity interval as defined by
	AcceptLifeTimeStart and AcceptLifeTimeEnd must include the current		AcceptLifetimeStart and AcceptLifetimeEnd must include the current
	time.		time.
	o The key can be used for the desired security algorithm.		o The key must be valid for the desired security algorithm.
	In the remainder of this section, additional requirements for keys		In the remainder of this section, additional requirements for keys
	are enumerated for different scenarios.		are enumerated for different scenarios.
	4.1. Key Selection for Unicast OSPF Packet Transmission		4.1. Key Selection for Unicast OSPF Packet Transmission
	Assume that a router R1 tries to send a unicast OSPF packet from its		Assume that a router R1 tries to send a unicast OSPF packet from its
	interface I1 to the interface R2 of a remote router R2 using security		interface I1 to the interface R2 of a remote router R2 using security
	protocol P via interface I at time T. First, consider the		protocol P via interface I at time T. First, consider the
	circumstances where R1 and R2 are not connected with a virtual link.		circumstances where R1 and R2 are not connected with a virtual link.
	R1 then needs to select a long long-lived symmetric key from its key		R1 then needs to select a long long-lived symmetric key from its key
	table. Because the key should be shared by the by both R1 and R2 to		table. Because the key should be shared by the by both R1 and R2 to
	protect the communication between I1 and I2, the key should satisfy		protect the communication between I1 and I2, the key should satisfy
	the following requirements:		the following requirements:
	o The Peers field is unused. OSPF authentiction is interface based.		o The Peers field is unused. OSPF authentication is interface
			based.
	o The Interfaces field includes the local IP address of the		o The Interfaces field includes the local IP address of the
	interface for nummbered interfaces or the MIB-II [RFC1213],		interface for numbered interfaces or the MIB-II [RFC1213], ifIndex
	ifIndex for unnumbered interfaces.		for unnumbered interfaces.
	o The Direction field is either "out" or "both".		o The Direction field is either "out" or "both".
			o If multiple keys match the Interface, the key with the most recent
			SendLifetimeStart time will be selected. This will facilitate
			graceful key rollover.
			o The Key ID field in the OSPFv2 header (refer to figure 1) will be
			set to the selected key's LocalKeyName.
	When R1 and R2 are connected to a virtual link, the interfaces field		When R1 and R2 are connected to a virtual link, the interfaces field
	must identify the virtual endpoint rather than the virtual link.		must identify the virtual endpoint rather than the virtual link.
	Since there may be virtual links to the same router, the transit area		Since there may be virtual links to the same router, the transit area
	ID must be part of the identifier. Hence, the key should satisfy the		ID must be part of the identifier. Hence, the key should satisfy the
	following requirements:		following requirements:
	o The Peers field is unused. OSPF authentiction is interface based.		o The Peers field is unused. OSPF authentication is interface
			based.
	o The Interfaces field includes both the virtual endpoint's OSPF		o The Interfaces field includes both the virtual endpoint's OSPF
	router ID and the the transit area ID for the virtual link.		router ID and the transit area ID for the virtual link.
	o The Direction field is either "out" or "both".		o The Direction field is either "out" or "both".
			o If multiple keys match the Interface, the key with the most recent
			SendLifetimeStart time will be selected. This will facilitate
			graceful key rollover.
			o The Key ID field in the OSPFv2 header (refer to figure 1) will be
			set to the selected key's LocalKeyName.
	4.2. Key Selection for Multicast OSPF Packet Transmission		4.2. Key Selection for Multicast OSPF Packet Transmission
	If a router R1 sends an OSPF packet from its interface I1 to a		If a router R1 sends an OSPF packet from its interface I1 to a
	multicast address (e.g., AllSPFRouters, AllDRouters), it needs to		multicast address (e.g., AllSPFRouters, AllDRouters), it needs to
	select a key according to the following requirements:		select a key according to the following requirements:
	o The Peers field is unused. OSPF authentication is interface		o The Peers field is unused. OSPF authentication is interface
	based.		based.
	o The Interfaces field includes the local IP address of the		o The Interfaces field includes the local IP address of the
	interface for nummbered interfaces or the MIB-II [RFC1213],		interface for numbered interfaces or the MIB-II [RFC1213], ifIndex
	ifIndex for unnumbered interfaces.		for unnumbered interfaces.
	o The Direction field is either "out" or "both".		o The Direction field is either "out" or "both".
			o If multiple keys match the Interface, the key with the most recent
			SendLifetimeStart time will be selected. This will facilitate
			graceful key rollover.
			o The Key ID field in the OSPFv2 header (refer to figure 1) will be
			set to the selected key's LocalKeyName.
	4.3. Key Selection for OSPF Packet Reception		4.3. Key Selection for OSPF Packet Reception
	When Cryptographic Authentication is used, the ID of the		When Cryptographic Authentication is used, the ID of the
	authentication key is included in the authentication field of the		authentication key is included in the authentication field of the
	OSPF packet header. Using this key ID, it is relatively easy for a		OSPF packet header. Using this key ID, it is relatively easy for a
	receiver to locate the key. The simple requirements are:		receiver to locate the key. The simple requirements are:
	o The interface on which the key was received is associated with the		o The interface on which the key was received is associated with the
	key's interface.		key's interface.
	o The PeerKeyName field includes the key ID obtained from the		o The Key ID obtained from the OSPFv2 packet header corresponds to
	authentication field. Since OSPF keys are symmetric, the		the neighbor's PeerKeyName. Since OSPFv2 keys are symmetric, the
	LocalKeyName and PeerKeyName for OSPF keys will be identical.		LocalKeyName and PeerKeyName for OSPFv2 keys will be identical.
			Hence, the Key ID will be used to select the correct local key.
	o The Direction field is either "in" or "both".		o The Direction field is either "in" or "both".
	5. Securing the IP header		5. Securing the IP header
	This document updates the definition of Apad which is currently a		This document updates the definition of Apad which is currently a
	constant defined in [RFC5709] to the source address from the IP		constant defined in [RFC5709] to the source address from the IP
	header of the OSPFv2 protocol packet. The overall cryptographic		header of the OSPFv2 protocol packet. The overall cryptographic
	authentication process defined in [RFC5709] remains unchanged. To		authentication process defined in [RFC5709] remains unchanged. To
	reduce the potential for confusion, this section minimizes the		reduce the potential for confusion, this section minimizes the
	skipping to change at page 9, line 10 ¶		skipping to change at page 9, line 38 ¶
	change of IP source address in a replayed packet can be detected.		change of IP source address in a replayed packet can be detected.
	At the receiving end, implementations MUST initialize Apad as the		At the receiving end, implementations MUST initialize Apad as the
	source address from IP Header of the incoming OSPFv2 packet, repeated		source address from IP Header of the incoming OSPFv2 packet, repeated
	L/4 times, instead of the constant that's currently defined in		L/4 times, instead of the constant that's currently defined in
	[RFC5709]. Besides changing the value of Apad, this document does		[RFC5709]. Besides changing the value of Apad, this document does
	not introduce any other changes to the authentication mechanism		not introduce any other changes to the authentication mechanism
	described in [RFC5709]. This would prevent all attacks where a rogue		described in [RFC5709]. This would prevent all attacks where a rogue
	OSPF router changes the IP source address of an OSPFv2 packet and		OSPF router changes the IP source address of an OSPFv2 packet and
	replays it on the same multi-access interface or another interface		replays it on the same multi-access interface or another interface
	since the IP source address is now protected and such changes would		since the IP source address is now protected and modification would
	cause the authentication check to fail and the replayed packet to be		result in the OSPFv2 packet being dropped due to an authentication
	rejected.		failure.
	6. Mitigating Cross-Protocol Attacks		6. Mitigating Cross-Protocol Attacks
	In order to prevent cross protocol replay attacks for protocols		In order to prevent cross protocol replay attacks for protocols
	sharing common keys, the two octet OSPFv2 Cryptographic Protocol ID		sharing common keys, the two octet OSPFv2 Cryptographic Protocol ID
	is appended to the authentication key prior to use. Refer to IANA		is appended to the authentication key prior to use. Refer to IANA
	Considerations (Section 8).		Considerations (Section 8).
	[RFC5709], Section 3.3 describes the mechanism to prepare the key		[RFC5709], Section 3.3 describes the mechanism to prepare the key
	used in the hash computation. This document updates the sub section		used in the hash computation. This document updates the sub section
	skipping to change at page 9, line 47 ¶		skipping to change at page 10, line 27 ¶
	Protocol-Specific Authentication Key (Ks) is less than L octets long,		Protocol-Specific Authentication Key (Ks) is less than L octets long,
	then Ko is set to the Protocol-Specific Authentication Key (Ks) with		then Ko is set to the Protocol-Specific Authentication Key (Ks) with
	zeros appended to the end of the Protocol-Specific Authentication Key		zeros appended to the end of the Protocol-Specific Authentication Key
	(Ks) such that Ko is L octets long.		(Ks) such that Ko is L octets long.
	Once the cryptographic key (Ko) used with the hash algorithm is		Once the cryptographic key (Ko) used with the hash algorithm is
	derived the rest of the authentication mechanism described in		derived the rest of the authentication mechanism described in
	[RFC5709] remains unchanged other than one detail that was		[RFC5709] remains unchanged other than one detail that was
	unspecified. When XORing Ko and Ipad of Opad, Ko MUST be padded with		unspecified. When XORing Ko and Ipad of Opad, Ko MUST be padded with
	zeros to the length of Ipad or Opad. It is expected that RFC 5709		zeros to the length of Ipad or Opad. It is expected that RFC 5709
	[RFC5709] implementation perform this padding implicitly.		[RFC5709] implementations perform this padding implicitly.
	7. Security Considerations		7. Security Considerations
	This document attempts to fix the manual key management procedure		This document rectifies the manual key management procedure that
	that currently exists within OSPFv2, as part of the Phase 1 of the		currently exists within OSPFv2, as part of the Phase 1 of the KARP
	KARP Working Group. Therefore, only the OSPFv2 manual key management		Working Group. Therefore, only the OSPFv2 manual key management
	mechanism is considered. Any solution that takes advantage of the		mechanism is considered. Any solution that takes advantage of the
	automatic key management mechanism is beyond the scope of this		automatic key management mechanism is beyond the scope of this
	document.		document.
	The proposed sequence number extension offers most of the benefits of		The proposed sequence number extension offers most of the benefits of
	of more complicated mechanisms involving challenges. There are,		more complicated mechanisms involving challenges. There are,
	however, a couple drawbacks to this approach. First, it requires the		however, a couple drawbacks to this approach. First, it requires the
	OSPF implementation to be able to save its boot count in non-volatile		OSPF implementation to be able to save its boot count in non-volatile
	storage. If the non-volatile storage is ever repaired or upgraded		storage. If the non-volatile storage is ever repaired or upgraded
	such that the contents are lost or the OSPFv2 router is replaced with		such that the contents are lost or the OSPFv2 router is replaced, the
	a model, the keys MUST be changed to prevent replay attacks.		keys MUST be changed to prevent replay attacks.
	Second, if a router is taken out of service completely (either		Second, if a router is taken out of service completely (either
	intentionally or due to a persistent failure), the potential exists		intentionally or due to a persistent failure), the potential exists
	for reestablishment of an OSPFv2 adjacency by replaying the entire		for reestablishment of an OSPFv2 adjacency by replaying the entire
	OSPFv2 session establishment. This scenario is however, extremely		OSPFv2 session establishment. This scenario is however, extremely
	unlikely, since it would imply an identical OSPFv2 adjacency		unlikely, since it would imply an identical OSPFv2 adjacency
	formation packet exchange. The replay of OSPFv2 hello packets alone		formation packet exchange. Without adjacency formation, the replay
	for an OSPFv2 router that has been taken out of service should not		of OSPFv2 hello packets alone for an OSPFv2 router that has been
	result in any serious attack as the only consequence is superfluous		taken out of service should not result in any serious attack as the
	processing. Of course, this attack could also be thwarted by		only consequence is superfluous processing. Of course, this attack
	changing the relevant manual keys.		could also be thwarted by changing the relevant manual keys.
	This document also provides a solution to prevent certain denial of		This document also provides a solution to prevent certain denial of
	service attacks that can be launched by changing the source address		service attacks that can be launched by changing the source address
	in the IP header of the OSPFv2 protocol packet.		in the IP header of an OSPFv2 protocol packet.
	8. IANA Considerations		8. IANA Considerations
	This document requests a new code point from the "OSPF Shortest Path		This document requests a new code point from the "OSPF Shortest Path
	First (OSPF) Authentication Codes" registry:		First (OSPF) Authentication Codes" registry:
	o 3 - Cryptographic Authentication with Extended Sequence Numbers.		o 3 - Cryptographic Authentication with Extended Sequence Numbers.
	This document also requests a new code point from the "Authentication		This document also requests a new code point from the "Authentication
	Cryptographic Protocol ID" registry defined under "Keying and		Cryptographic Protocol ID" registry defined under "Keying and
	skipping to change at page 13, line 7 ¶		skipping to change at page 13, line 32 ¶
	Beijing,		Beijing,
	China		China
	Phone:		Phone:
	Fax:		Fax:
	Email: zhangdacheng@huawei.com		Email: zhangdacheng@huawei.com
	URI:		URI:
	Acee Lindem		Acee Lindem
	Ericsson		Ericsson
	102 Carric Bend Court		301 Midenhall Way
	Cary, NC 27519		Cary, NC 27513
	USA		USA
	Phone:		Phone:
	Email: acee.lindem@ericsson.com		Email: acee.lindem@ericsson.com
End of changes. 38 change blocks.
	68 lines changed or deleted		91 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/