draft-ietf-manet-olsrv2-dat-metric-11.txt		draft-ietf-manet-olsrv2-dat-metric-12.txt
	MANET H. Rogge		MANET H. Rogge
	Internet-Draft Fraunhofer FKIE		Internet-Draft Fraunhofer FKIE
	Intended status: Experimental E. Baccelli		Intended status: Experimental E. Baccelli
	Expires: June 17, 2016 INRIA		Expires: June 17, 2016 INRIA
	December 15, 2015		December 15, 2015
	Packet Sequence Number based directional airtime metric for OLSRv2		Packet Sequence Number based directional airtime metric for OLSRv2
	draft-ietf-manet-olsrv2-dat-metric-11		draft-ietf-manet-olsrv2-dat-metric-12
	Abstract		Abstract
	This document specifies an Directional Airtime (DAT) link metric for		This document specifies an Directional Airtime (DAT) link metric for
	usage in OLSRv2.		usage in OLSRv2.
	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.
	skipping to change at page 2, line 37		skipping to change at page 2, line 37
	12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14		12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
	13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14		13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14
	14. References . . . . . . . . . . . . . . . . . . . . . . . . . 15		14. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
	14.1. Normative References . . . . . . . . . . . . . . . . . . 15		14.1. Normative References . . . . . . . . . . . . . . . . . . 15
	14.2. Informative References . . . . . . . . . . . . . . . . . 15		14.2. Informative References . . . . . . . . . . . . . . . . . 15
	Appendix A. Future work . . . . . . . . . . . . . . . . . . . . 16		Appendix A. Future work . . . . . . . . . . . . . . . . . . . . 16
	Appendix B. OLSR.org metric history . . . . . . . . . . . . . . 17		Appendix B. OLSR.org metric history . . . . . . . . . . . . . . 17
	Appendix C. Linkspeed stabilization . . . . . . . . . . . . . . 18		Appendix C. Linkspeed stabilization . . . . . . . . . . . . . . 18
	Appendix D. Packet loss hysteresis . . . . . . . . . . . . . . . 18		Appendix D. Packet loss hysteresis . . . . . . . . . . . . . . . 18
	Appendix E. Example DAT values . . . . . . . . . . . . . . . . . 19		Appendix E. Example DAT values . . . . . . . . . . . . . . . . . 19
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
	1. Introduction		1. Introduction
	One of the major shortcomings of Optimized Link State Routing (OLSR)		One of the major shortcomings of Optimized Link State Routing (OLSR)
	[RFC3626] is the lack of a granular link cost metric between OLSR		[RFC3626] is the lack of a granular link cost metric between OLSR
	routers. Operational experience with OLSR networks gathered since		routers. Operational experience with OLSR networks gathered since
	its publication has revealed that wireless networks links can have		its publication has revealed that wireless networks links can have
	highly variable and heterogeneous properties. This makes a hopcount		highly variable and heterogeneous properties. This makes a hopcount
	metric insufficient for effective OLSR routing.		metric insufficient for effective OLSR routing.
	skipping to change at page 14, line 4		skipping to change at page 14, line 5
	9. add(L_DAT_received, 0)		9. add(L_DAT_received, 0)
	The calculated L_in_metric value should be stabilized by a hysteresis		The calculated L_in_metric value should be stabilized by a hysteresis
	function. See Appendix D for an example.		function. See Appendix D for an example.
	11. Security Considerations		11. Security Considerations
	Artificial manipulation of metrics values can drastically alter		Artificial manipulation of metrics values can drastically alter
	network performance. In particular, advertising a higher L_in_metric		network performance. In particular, advertising a higher L_in_metric
	value may decrease the amount of incoming traffic, while advertising		value may decrease the amount of incoming traffic, while advertising
	lower L_in_metric may increase the amount of incoming traffic. By		lower L_in_metric may increase the amount of incoming traffic.
	artificially increasing or decreasing the L_in_metric values it
	advertises, a rogue router may thus attract or repulse data traffic.
	A rogue router may then potentially degrade data throughput by not
	forwarding data as it should or redirecting traffic into routing
	loops or bad links. It might also attract traffic for "Man in the
	Middle" attacks or traffic analysis.
	An attacker might also inject packets with incorrect packet level
	sequence numbers, pretending to be somebody else. This attack can be
	prevented by the true originator of the RFC5444 packets by adding a
	[RFC7182] ICV Packet TLV and TIMESTAMP Packet TLV to each packet.
	This allows the receiver to drop all incoming packets which have a
	forged packet source, both packets generated by the attacker or
	replayed packets. The security mechanism described in [RFC7183] does
	not protect the sequence number used by the DAT metric because it
	does only sign the RFC5444 messages, not the RFC5444 packet header
	(which contains the RFC5444 packet sequence number).
	Protection mechanisms against "Man in the Middle" attacks are		For example, by thus artificially attracting mesh routes and then
			dropping the incoming traffic, an attacker may achieve a Denial of
			Service (DoS) against other mesh nodes. Similarly, an attacker may
			achieve Man in the Middle (MITM) attacks or traffic analysis by
			concentrating traffic being router over a node the attacker controls
			(and end-to-end encryption is not used or somehow broken).
			Protection mechanisms against such MITM or DoS attacks are
	nevertheless out of scope of this document.		nevertheless out of scope of this document.
			Security threats also include potential attacks on the integrity of
			the control traffic passively monitored by DAT to measure link
			quality. For example, an attacker might inject packets pretending to
			be somebody else, and using incorrect sequence numbers. This attack
			can be prevented by the true originator of the RFC5444 packets by
			adding a [RFC7182] ICV Packet TLV and TIMESTAMP Packet TLV to each
			packet. This allows the receiver to drop all incoming packets which
			have a forged packet source, both packets generated by the attacker
			or replayed packets. However, the security mechanism described in
			[RFC7183] does not protect the sequence number used by the DAT metric
			because it does only sign the RFC5444 messages, not the RFC5444
			packet header (which contains the RFC5444 packet sequence number).
	12. IANA Considerations		12. IANA Considerations
	This document has no actions for IANA.		This document has no actions for IANA.
	13. Acknowledgements		13. Acknowledgements
	The authors would like to acknowledge the network administrators from		The authors would like to acknowledge the network administrators from
	Freifunk Berlin [FREIFUNK] and Funkfeuer Vienna [FUNKFEUER] for		Freifunk Berlin [FREIFUNK] and Funkfeuer Vienna [FUNKFEUER] for
	endless hours of testing and suggestions to improve the quality of		endless hours of testing and suggestions to improve the quality of
	the original ETX metric for the OLSR.org routing daemon.		the original ETX metric for the OLSR.org routing daemon.
End of changes. 5 change blocks.
	21 lines changed or deleted		23 lines changed or added
This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/