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/