< draft-herberg-manet-nhdp-olsrv2-sec-01.txt		draft-herberg-manet-nhdp-olsrv2-sec-02.txt >
	Mobile Ad hoc Networking (MANET) U. Herberg		Mobile Ad hoc Networking (MANET) U. Herberg
	Internet-Draft Fujitsu Laboratories of America		Internet-Draft Fujitsu Laboratories of America
	Updates: RFC6130 C. Dearlove		Updates: RFC6130 C. Dearlove
	(if approved) BAE Systems ATC		(if approved) BAE Systems ATC
	Intended status: Standards Track T. Clausen		Intended status: Standards Track T. Clausen
	Expires: August 29, 2013 LIX, Ecole Polytechnique		Expires: September 19, 2013 LIX, Ecole Polytechnique
	February 25, 2013		March 18, 2013
	Integrity Protection for Control Messages in NHDP and OLSRv2		Integrity Protection for Control Messages in NHDP and OLSRv2
	draft-herberg-manet-nhdp-olsrv2-sec-01		draft-herberg-manet-nhdp-olsrv2-sec-02
	Abstract		Abstract
	This document specifies integrity and replay protection for required		This document specifies integrity and replay protection for required
	implementation in the MANET Neighborhood Discovery Protocol (NHDP)		implementation in the MANET Neighborhood Discovery Protocol (NHDP)
	and the Optimized Link State Routing Protocol version 2 (OLSRv2).		and the Optimized Link State Routing Protocol version 2 (OLSRv2).
	This document specifies how an included integrity check value (ICV)		This document specifies how an included integrity check value (ICV)
	and a timestamp TLV, defined in RFC6622bis, are used by NHDP and		and a timestamp TLV, defined in RFC6622bis, are used by NHDP and
	OLSRv2 for countering a number of security threats. The ICV TLV uses		OLSRv2 for countering a number of security threats. The ICV TLV uses
	a SHA-256 based HMAC and a single shared secret key. The timestamp		a SHA-256 based HMAC and a single shared secret key. The timestamp
	TLV is based on POSIX time, assuming router synchronization. The		TLV is based on POSIX time, and assumes that the clocks in all
	mechanism in this specification can also be used for other MANET		routers in the network can be synchronized with sufficient precision.
			The mechanism in this specification can also be used for other MANET
	protocols using RFC5444.		protocols using RFC5444.
	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 August 29, 2013.		This Internet-Draft will expire on September 19, 2013.
	Copyright Notice		Copyright Notice
	Copyright (c) 2013 IETF Trust and the persons identified as the		Copyright (c) 2013 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 2, line 22 ¶		skipping to change at page 2, line 24 ¶
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
	3. Applicability Statement . . . . . . . . . . . . . . . . . . . 4		3. Applicability Statement . . . . . . . . . . . . . . . . . . . 4
	4. Protocol Overview and Functioning . . . . . . . . . . . . . . 6		4. Protocol Overview and Functioning . . . . . . . . . . . . . . 6
	5. Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . 7		5. Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . 7
	6. Message Generation and Processing . . . . . . . . . . . . . . 8		6. Message Generation and Processing . . . . . . . . . . . . . . 8
	6.1. Message Content . . . . . . . . . . . . . . . . . . . . . 8		6.1. Message Content . . . . . . . . . . . . . . . . . . . . . 8
	6.2. Message Generation . . . . . . . . . . . . . . . . . . . . 8		6.2. Message Generation . . . . . . . . . . . . . . . . . . . . 9
	6.3. Message Processing . . . . . . . . . . . . . . . . . . . . 9		6.3. Message Processing . . . . . . . . . . . . . . . . . . . . 9
	6.3.1. Invalidating a Message Based on Timestamp . . . . . . 10		6.3.1. Invalidating a Message Based on Timestamp . . . . . . 10
	6.3.2. Invalidating a Message Based on Integrity Check . . . 10		6.3.2. Invalidating a Message Based on Integrity Check . . . 10
	7. Provisioning of Routers . . . . . . . . . . . . . . . . . . . 11		7. Provisioning of Routers . . . . . . . . . . . . . . . . . . . 11
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
	9. Security Considerations . . . . . . . . . . . . . . . . . . . 11		9. Security Considerations . . . . . . . . . . . . . . . . . . . 11
	9.1. Alleviated Attacks . . . . . . . . . . . . . . . . . . . . 11		9.1. Alleviated Attacks . . . . . . . . . . . . . . . . . . . . 11
	9.1.1. Identity Spoofing . . . . . . . . . . . . . . . . . . 11		9.1.1. Identity Spoofing . . . . . . . . . . . . . . . . . . 11
	9.1.2. Link Spoofing . . . . . . . . . . . . . . . . . . . . 11		9.1.2. Link Spoofing . . . . . . . . . . . . . . . . . . . . 11
	9.1.3. Replay Attack . . . . . . . . . . . . . . . . . . . . 11		9.1.3. Replay Attack . . . . . . . . . . . . . . . . . . . . 12
	9.2. Limitations . . . . . . . . . . . . . . . . . . . . . . . 12		9.2. Limitations . . . . . . . . . . . . . . . . . . . . . . . 12
	10. Normative References . . . . . . . . . . . . . . . . . . . . . 12		10. Normative References . . . . . . . . . . . . . . . . . . . . . 12
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
	1. Introduction		1. Introduction
	This specification defines a framework of security mechanisms that		This specification defines a framework of security mechanisms that
	must be included in conforming implementations of the Neighborhood		must be included in conforming implementations of the Neighborhood
	Discovery Protocol (NHDP) [RFC6130] and the Optimized Link State		Discovery Protocol (NHDP) [RFC6130] and the Optimized Link State
	Routing Protocol version 2 (OLSRv2) [OLSRv2] for Mobile Ad hoc		Routing Protocol version 2 (OLSRv2) [OLSRv2] for Mobile Ad hoc
	NETworks (MANETs). A deployment of these protocols may choose to		NETworks (MANETs). A deployment of these protocols may choose to
	employ alternative(s) to these mechanisms, in particular it may		employ alternative(s) to these mechanisms, in particular it may
	choose to protect packets rather than messages, it may choose to use		choose to protect packets rather than messages, it may choose to use
	skipping to change at page 5, line 36 ¶		skipping to change at page 5, line 36 ¶
	including the IP datagram source address). Deployments of		including the IP datagram source address). Deployments of
	[RFC6130] and [OLSRv2] using this framework should use the HMAC/		[RFC6130] and [OLSRv2] using this framework should use the HMAC/
	SHA-256 ICV TLV, but may use different algorithms if more		SHA-256 ICV TLV, but may use different algorithms if more
	appropriate in a deployment. An implementation may also use more		appropriate in a deployment. An implementation may also use more
	than one ICV TLV in a message as long as they each use a different		than one ICV TLV in a message as long as they each use a different
	algorithm to calculate the ICV.		algorithm to calculate the ICV.
	o Specifies the implementation of a TIMESTAMP TLV, defined in		o Specifies the implementation of a TIMESTAMP TLV, defined in
	[RFC6622bis], to provide message replay protection. Deployments		[RFC6622bis], to provide message replay protection. Deployments
	of [RFC6130] and [OLSRv2] using this framework SHOULD use a POSIX		of [RFC6130] and [OLSRv2] using this framework SHOULD use a POSIX
	time based timestamp, if all routers can be sufficiently		time based timestamp, if the clocks in all routers in the network
	synchronized.		can be synchronized with sufficient precision.
	o Assumes that a router that is able to generate correct integrity		o Assumes that a router that is able to generate correct integrity
	check values is considered trusted.		check values is considered trusted.
	This framework does not:		This framework does not:
	o Specify how to distribute cryptographic material (shared secret		o Specify how to distribute cryptographic material (shared secret
	key).		key).
	o Specify how to detect compromised routers with valid keys.		o Specify how to detect compromised routers with valid keys.
	skipping to change at page 6, line 23 ¶		skipping to change at page 6, line 23 ¶
	[OLSRv2] may use more than one ICV TLV in a message, even with the		[OLSRv2] may use more than one ICV TLV in a message, even with the
	same type extension, but these ICV TLVs MUST each use a different		same type extension, but these ICV TLVs MUST each use a different
	algorithm to calculate the ICV, e.g., with different hash and/or		algorithm to calculate the ICV, e.g., with different hash and/or
	cryptographic functions when using type extension 1 or 2. An		cryptographic functions when using type extension 1 or 2. An
	implementation of [RFC6130] and [OLSRv2] must at least be able to		implementation of [RFC6130] and [OLSRv2] must at least be able to
	generate an ICV TLV using HMAC/SHA-256 and a single secret key		generate an ICV TLV using HMAC/SHA-256 and a single secret key
	shared by all routers.		shared by all routers.
	o Generation of TIMESTAMP TLVs (as defined in [RFC6622bis]) for		o Generation of TIMESTAMP TLVs (as defined in [RFC6622bis]) for
	inclusion in an outgoing message. An implementation of [RFC6130]		inclusion in an outgoing message. An implementation of [RFC6130]
	and [OLSRv2] that is able to synchronize routers, must at least be		and [OLSRv2], that is able to synchronize the clocks in all
			routers in the network with sufficient precision, must at least be
	able to generate a TIMESTAMP TLV using POSIX time.		able to generate a TIMESTAMP TLV using POSIX time.
	o Verification of ICV TLVs contained in a message, in order to		o Verification of ICV TLVs contained in a message, in order to
	determine if this message MUST be rejected as "badly formed and		determine if this message MUST be rejected as "badly formed and
	therefore invalid for processing" [RFC6130] [OLSRv2]. An		therefore invalid for processing" [RFC6130] [OLSRv2]. An
	implementation of [RFC6130] and [OLSRv2] must at least be able to		implementation of [RFC6130] and [OLSRv2] must at least be able to
	verify an ICV TLV using HMAC/SHA-256 and a single secret key		verify an ICV TLV using HMAC/SHA-256 and a single secret key
	shared by all routers.		shared by all routers.
	o Verification of a TIMESTAMP TLV (as defined in [RFC6622bis])		o Verification of a TIMESTAMP TLV (as defined in [RFC6622bis])
	contained in a message, in order to determine if this message MUST		contained in a message, in order to determine if this message MUST
	be rejected as "badly formed and therefore invalid for processing"		be rejected as "badly formed and therefore invalid for processing"
	[RFC6130] [OLSRv2]. An implementation of [RFC6130] and [OLSRv2]		[RFC6130] [OLSRv2]. An implementation of [RFC6130] and [OLSRv2]
	that is able to synchronize routers, must at least be able to		that is able to synchronize the clocks in all routers in the
	verify a TIMESTAMP TLV using POSIX time.		network with sufficient precision, must at least be able to verify
			a TIMESTAMP TLV using POSIX time.
	ICV Packet TLVs (as defined in [RFC6622bis]) may be used by a		ICV Packet TLVs (as defined in [RFC6622bis]) may be used by a
	deployment of the multiplexing process defined in [RFC5444], either		deployment of the multiplexing process defined in [RFC5444], either
	as well as, or instead of, the protection of the NHDP and OLSRv2		as well as, or instead of, the protection of the NHDP and OLSRv2
	messages. (Note that in the case of NHDP, the packet protection is		messages. (Note that in the case of NHDP, the packet protection is
	equally good, and also protects the packet header. In the case of		equally good, and also protects the packet header. In the case of
	OLSRv2, the packet protection has different properties than the		OLSRv2, the packet protection has different properties than the
	message protection, especially for some forms of ICV. When packets		message protection, especially for some forms of ICV. When packets
	contain more than one message, the packet protection has lower		contain more than one message, the packet protection has lower
	overheads in space and computation time.)		overheads in space and computation time.)
	skipping to change at page 7, line 45 ¶		skipping to change at page 7, line 46 ¶
	The following constraints apply to these parameters:		The following constraints apply to these parameters:
	o MAX_HELLO_TIMESTAMP_DIFF > 0		o MAX_HELLO_TIMESTAMP_DIFF > 0
	o MAX_HELLO_TIMESTAMP_DIFF < REFRESH_INTERVAL		o MAX_HELLO_TIMESTAMP_DIFF < REFRESH_INTERVAL
	o MAX_TC_TIMESTAMP_DIFF > 0		o MAX_TC_TIMESTAMP_DIFF > 0
	o MAX_TC_TIMESTAMP_DIFF < T_HOLD_TIME		o MAX_TC_TIMESTAMP_DIFF < T_HOLD_TIME
	The second and fourth of those constraints assume ideal		The second and fourth of those constraints assume ideal time
	synchronization. These bounds MAY be relaxed to allow for expected		synchronization of the clocks in all routers in the network. These
	timing differences between routers (between neighboring routers for		bounds MAY be relaxed to allow for expected timing differences
			between routers (between neighboring routers for
	MAX_HELLO_TIMESTAMP_DIFF). However it should also be noted that, in		MAX_HELLO_TIMESTAMP_DIFF). However it should also be noted that, in
	the ideal case, the parameters SHOULD be significantly less than		the ideal case, the parameters SHOULD be significantly less than
	those bounds.		those bounds.
	6. Message Generation and Processing		6. Message Generation and Processing
	This section specifies how messages are generated and processed by		This section specifies how messages are generated and processed by
	[RFC6130] and [OLSRv2] when using this framework.		[RFC6130] and [OLSRv2] when using this framework.
	6.1. Message Content		6.1. Message Content
	skipping to change at page 12, line 46 ¶		skipping to change at page 13, line 11 ¶
	February 2009.		February 2009.
	[RFC6130] Clausen, T., Dean, J., and C. Dearlove, "Mobile Ad Hoc		[RFC6130] Clausen, T., Dean, J., and C. Dearlove, "Mobile Ad Hoc
	Network (MANET) Neighborhood Discovery Protocol (NHDP)",		Network (MANET) Neighborhood Discovery Protocol (NHDP)",
	RFC 6130, April 2011.		RFC 6130, April 2011.
	[RFC6622bis]		[RFC6622bis]
	Herberg, U., Clausen, T., and C. Dearlove, "Integrity		Herberg, U., Clausen, T., and C. Dearlove, "Integrity
	Check Value and Timestamp TLV Definitions for Mobile Ad		Check Value and Timestamp TLV Definitions for Mobile Ad
	Hoc Networks (MANETs)", Internet		Hoc Networks (MANETs)", Internet
	Draft draft-herberg-manet-rfc6622-bis-00, February 2013.		Draft draft-herberg-manet-rfc6622-bis-02, March 2013.
	Authors' Addresses		Authors' Addresses
	Ulrich Herberg		Ulrich Herberg
	Fujitsu Laboratories of America		Fujitsu Laboratories of America
	1240 E. Arques Ave.		1240 E. Arques Ave.
	Sunnyvale, CA, 94085,		Sunnyvale, CA, 94085,
	USA		USA
	Email: ulrich@herberg.name		Email: ulrich@herberg.name
End of changes. 12 change blocks.
	18 lines changed or deleted		22 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/