draft-ietf-manet-olsrv2-dat-metric-08.txt   draft-ietf-manet-olsrv2-dat-metric-09.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: May 7, 2016 INRIA Expires: May 16, 2016 INRIA
November 4, 2015 November 13, 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-08 draft-ietf-manet-olsrv2-dat-metric-09
Abstract Abstract
This document specifies an directional airtime link metric for usage This document specifies an directional airtime link metric for usage
in OLSRv2. 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 1, line 32 skipping to change at page 1, line 32
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 May 7, 2016. This Internet-Draft will expire on May 16, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 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 26 skipping to change at page 2, line 26
8.1. Initial Values . . . . . . . . . . . . . . . . . . . . . 9 8.1. Initial Values . . . . . . . . . . . . . . . . . . . . . 9
9. Packets and Messages . . . . . . . . . . . . . . . . . . . . 10 9. Packets and Messages . . . . . . . . . . . . . . . . . . . . 10
9.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 10 9.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 10
9.2. Requirements for using DAT metric in OLSRv2 9.2. Requirements for using DAT metric in OLSRv2
implementations . . . . . . . . . . . . . . . . . . . . . 10 implementations . . . . . . . . . . . . . . . . . . . . . 10
9.3. Link Loss Data Gathering . . . . . . . . . . . . . . . . 11 9.3. Link Loss Data Gathering . . . . . . . . . . . . . . . . 11
9.4. HELLO Message Processing . . . . . . . . . . . . . . . . 11 9.4. HELLO Message Processing . . . . . . . . . . . . . . . . 11
10. Timer Event Handling . . . . . . . . . . . . . . . . . . . . 12 10. Timer Event Handling . . . . . . . . . . . . . . . . . . . . 12
10.1. Packet Timeout Processing . . . . . . . . . . . . . . . 12 10.1. Packet Timeout Processing . . . . . . . . . . . . . . . 12
10.2. Metric Update . . . . . . . . . . . . . . . . . . . . . 12 10.2. Metric Update . . . . . . . . . . . . . . . . . . . . . 12
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 11. Security Considerations . . . . . . . . . . . . . . . . . . . 13
12. Security Considerations . . . . . . . . . . . . . . . . . . . 13 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 13.1. Normative References . . . . . . . . . . . . . . . . . . 14
14.1. Normative References . . . . . . . . . . . . . . . . . . 14 13.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 . . . . . . . . . . . . . . . . . 18 Appendix E. Example DAT values . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
1. Introduction 1. Introduction
One of the major shortcomings of OLSR [RFC3626] is the lack of a One of the major shortcomings of OLSR [RFC3626] is the lack of a
skipping to change at page 13, line 41 skipping to change at page 13, line 41
7. add(L_DAT_total, 0) 7. add(L_DAT_total, 0)
8. remove(L_DAT_received) 8. remove(L_DAT_received)
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 C Appendix D for an example. function. See Appendix C Appendix D for an example.
11. IANA Considerations 11. Security Considerations
This document contains no actions for IANA.
12. 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. By
artificially increasing or decreasing the L_in_metric values it artificially increasing or decreasing the L_in_metric values it
advertises, a rogue router may thus attract or repulse data traffic. advertises, a rogue router may thus attract or repulse data traffic.
A rogue router may then potentially degrade data throughput by not A rogue router may then potentially degrade data throughput by not
forwarding data as it should or redirecting traffic into routing forwarding data as it should or redirecting traffic into routing
loops or bad links. loops or bad links.
An attacker might also inject packets with incorrect packet level An attacker might also inject packets with incorrect packet level
sequence numbers, pretending to be somebody else. This attack can be sequence numbers, pretending to be somebody else. This attack can be
prevented by the true originator of the RFC5444 packets by adding a prevented by the true originator of the RFC5444 packets by adding a
[RFC7182] ICV Packet TLV and TIMESTAMP Packet TLV to each packet. [RFC7182] ICV Packet TLV and TIMESTAMP Packet TLV to each packet.
This allows the receiver to drop all incoming packets which have a This allows the receiver to drop all incoming packets which have a
forged packet source, both packets generated by the attacker or forged packet source, both packets generated by the attacker or
skipping to change at page 14, line 20 skipping to change at page 14, line 16
sequence numbers, pretending to be somebody else. This attack can be sequence numbers, pretending to be somebody else. This attack can be
prevented by the true originator of the RFC5444 packets by adding a prevented by the true originator of the RFC5444 packets by adding a
[RFC7182] ICV Packet TLV and TIMESTAMP Packet TLV to each packet. [RFC7182] ICV Packet TLV and TIMESTAMP Packet TLV to each packet.
This allows the receiver to drop all incoming packets which have a This allows the receiver to drop all incoming packets which have a
forged packet source, both packets generated by the attacker or forged packet source, both packets generated by the attacker or
replayed packets. The signature scheme described in [RFC7183] does replayed packets. The signature scheme described in [RFC7183] does
not protect the additional sequence number of the DAT metric because not protect the additional sequence number of the DAT metric because
it does only sign the RFC5444 messages, not the RFC5444 packet it does only sign the RFC5444 messages, not the RFC5444 packet
header. header.
13. Acknowledgements 12. 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.
This effort/activity is supported by the European Community Framework This effort/activity is supported by the European Community Framework
Program 7 within the Future Internet Research and Experimentation Program 7 within the Future Internet Research and Experimentation
Initiative (FIRE), Community Networks Testbed for the Future Internet Initiative (FIRE), Community Networks Testbed for the Future Internet
([CONFINE]), contract FP7-288535. ([CONFINE]), contract FP7-288535.
The authors would like to gratefully acknowledge the following people The authors would like to gratefully acknowledge the following people
for intense technical discussions, early reviews and comments on the for intense technical discussions, early reviews and comments on the
specification and its components (listed alphabetically): Teco Boot specification and its components (listed alphabetically): Teco Boot
(Infinity Networks), Juliusz Chroboczek (PPS, University of Paris 7), (Infinity Networks), Juliusz Chroboczek (PPS, University of Paris 7),
Thomas Clausen, Christopher Dearlove (BAE Systems Advanced Technology Thomas Clausen, Christopher Dearlove (BAE Systems Advanced Technology
Centre), Ulrich Herberg (Fujitsu Laboratories of America), Markus Centre), Ulrich Herberg (Fujitsu Laboratories of America), Markus
Kittenberger (Funkfeuer Vienna), Joseph Macker (Naval Research Kittenberger (Funkfeuer Vienna), Joseph Macker (Naval Research
Laboratory), Fabian Nack and Stan Ratliff (Cisco Systems). Laboratory), Fabian Nack and Stan Ratliff (Cisco Systems).
14. References 13. References
14.1. Normative References 13.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, BCP 14, March 1997. Requirement Levels", RFC 2119, BCP 14, March 1997.
[RFC5444] Clausen, T., Dearlove, C., Dean, J., and C. Adjih, [RFC5444] Clausen, T., Dearlove, C., Dean, J., and C. Adjih,
"Generalized Mobile Ad Hoc Network (MANET) Packet/Message "Generalized Mobile Ad Hoc Network (MANET) Packet/Message
Format", RFC 5444, February 2009. Format", RFC 5444, February 2009.
[RFC5497] Clausen, T. and C. Dearlove, "Representing Multi-Value [RFC5497] Clausen, T. and C. Dearlove, "Representing Multi-Value
Time in Mobile Ad Hoc Networks (MANETs)", RFC 5497, March Time in Mobile Ad Hoc Networks (MANETs)", RFC 5497, March
2009. 2009.
[RFC6130] Clausen, T., Dearlove, C., and J. Dean, "Mobile Ad Hoc [RFC6130] Clausen, T., Dearlove, C., and J. Dean, "Mobile Ad Hoc
Network (MANET) Neighborhood Discovery Protocol (NHDP)", Network (MANET) Neighborhood Discovery Protocol (NHDP)",
RFC 6130, April 2011. RFC 6130, April 2011.
[RFC7181] Clausen, T., Jacquet, P., and C. Dearlove, "The Optimized [RFC7181] Clausen, T., Jacquet, P., and C. Dearlove, "The Optimized
Link State Routing Protocol version 2", RFC 7181, April Link State Routing Protocol version 2", RFC 7181, April
2014. 2014.
14.2. Informative References 13.2. Informative References
[RFC3626] Clausen, T. and P. Jacquet, "Optimized Link State Routing [RFC3626] Clausen, T. and P. Jacquet, "Optimized Link State Routing
Protocol", RFC 3626, October 2003. Protocol", RFC 3626, October 2003.
[RFC7182] Ulrich, U., Clausen, T., and C. Dearlove, "Integrity Check [RFC7182] Ulrich, U., Clausen, T., and C. Dearlove, "Integrity Check
Value and Timestamp TLV Definitions for Mobile Ad Hoc Value and Timestamp TLV Definitions for Mobile Ad Hoc
Networks (MANETs)", RFC 7182, April 2014. Networks (MANETs)", RFC 7182, April 2014.
[RFC7183] Ulrich, U., Dearlove, C., and T. Clausen, "Integrity [RFC7183] Ulrich, U., Dearlove, C., and T. Clausen, "Integrity
Protection for the Neighborhood Discovery Protocol (NHDP) Protection for the Neighborhood Discovery Protocol (NHDP)
 End of changes. 10 change blocks. 
20 lines changed or deleted 14 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/