< draft-ietf-ospf-security-extension-manual-keying-07.txt		draft-ietf-ospf-security-extension-manual-keying-08.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: October 10, 2014 Painless Security		Expires: November 20, 2014 Painless Security
	D. Zhang		D. Zhang
	Huawei Technologies co., LTD.		Huawei Technologies co., LTD.
	A. Lindem		A. Lindem
	Ericsson		Ericsson
	April 8, 2014		May 19, 2014
	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-07		draft-ietf-ospf-security-extension-manual-keying-08
	Abstract		Abstract
	The current OSPFv2 cryptographic authentication mechanism as defined		The current OSPFv2 cryptographic authentication mechanism as defined
	in RFC 2328 and RFC 5709 is vulnerable to both inter-session and		in RFC 2328 and RFC 5709 is vulnerable to both inter-session and
	intra-session replay attacks when using manual keying. Additionally,		intra-session replay attacks when using manual keying. Additionally,
	the existing cryptographic authentication mechanism does not cover		the existing cryptographic authentication mechanism does not cover
	the IP header. This omission can be exploited to carry out various		the IP header. This omission can be exploited to carry out various
	types of attacks.		types of attacks.
	skipping to change at page 1, line 47 ¶		skipping to change at page 1, line 47 ¶
	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 October 10, 2014.		This Internet-Draft will expire on November 20, 2014.
	Copyright Notice		Copyright Notice
	Copyright (c) 2014 IETF Trust and the persons identified as the		Copyright (c) 2014 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	skipping to change at page 2, line 34 ¶		skipping to change at page 2, line 34 ¶
	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 . . . 8		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 . . . . . . . . . . . . . . . . . . . . 9		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 . . . . . . . . . . . . . . . . . . . . . 11		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 . . . . . . . . . . . . . . . . . . 12
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
	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 attempts to replay stale packets can be thwarted. The		so that attempts to replay stale packets can be thwarted. The
	sequence number values are maintained as a part of neighbor adjacency		sequence number values are maintained as a part of neighbor adjacency
	state. Therefore, if an adjacency is taken down, the associated		state. Therefore, if an adjacency is taken down, the associated
	sequence numbers get reinitialized and neighbor adjacency formation		sequence numbers get reinitialized and neighbor adjacency formation
	skipping to change at page 4, line 13 ¶		skipping to change at page 4, line 13 ¶
	"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].
	When used in lowercase, these words convey their typical use in		When used in lowercase, these words convey their typical use in
	common language, and are not to be interpreted as described in		common language, and are not to be interpreted as described in
	RFC2119 [RFC2119].		RFC2119 [RFC2119].
	1.2. Acknowledgments		1.2. Acknowledgments
	Thanks to Ran Atkinson for help in the analysis of RFC 6506 errata		Thanks to Ran Atkinson for help in the analysis of RFC 6506 errata
	leading to clarifications in this document.		leading to clarifications in this document. Thanks to Gabi Nakibly
			for pointing out the possible attack on p2p links.
	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
	skipping to change at page 11, line 14 ¶		skipping to change at page 11, line 14 ¶
	formation packet exchange. Without adjacency formation, the replay		formation packet exchange. Without adjacency formation, the replay
	of OSPFv2 hello packets alone for an OSPFv2 router that has been		of OSPFv2 hello packets alone for an OSPFv2 router that has been
	taken out of service should not result in any serious attack as the		taken out of service should not result in any serious attack as the
	only consequence is superfluous processing. Of course, this attack		only consequence is superfluous processing. Of course, this attack
	could also be thwarted by 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 an OSPFv2 protocol packet.		in the IP header of an OSPFv2 protocol packet.
			Using a single crypto sequence number can leave the router vulnerable
			to a replay attack where it uses the same source IP address on two
			different point-to-point unnumbered links. In such environments
			where an attacker can actively tap the point-to-point links, its
			recommended that the user employes different keys on each of those
			unnumbered IP interfaces.
	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
	Authentication for Routing Protocols (KARP) Parameters":		Authentication for Routing Protocols (KARP) Parameters":
End of changes. 7 change blocks.
	7 lines changed or deleted		15 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/