in Index   Prev   Next

RFC 7184

Definition of Managed Objects for the Optimized Link State Routing Protocol Version 2

Pages: 86
Proposed Standard
Part 4 of 4 – Pages 77 to 86
First   Prev   None

Top   ToC   RFC7184 - Page 77   prevText

8. Security Considerations

This MIB module defines objects for the configuration, monitoring, and notification of the Optimized Link State Routing Protocol version 2 (OLSRv2) [RFC7181]. OLSRv2 allows routers to acquire topological information of the routing domain by exchanging TC messages in order to calculate shortest paths to each destination router in the routing domain. There are a number of management objects defined in this MIB module with a MAX-ACCESS clause of read-write and/or read-create. Such objects may be considered sensitive or vulnerable in some network environments. The support for SET operations in a non-secure
Top   ToC   RFC7184 - Page 78
   environment without proper protection can have a negative effect on
   network operations.  These are the tables and objects and their

   o  olsrv2TcInterval, olsrv2TcMinInterval - these writable objects
      control the rate at which TC messages are sent.  If set at too
      high a rate, this could represent a form of a DoS attack by
      overloading interface resources.  If set too low, OLSRv2 may not
      converge fast enough to provide accurate routes to all
      destinations in the routing domain.

   o  olsrv2TcHopLimit - defines the hop limit for TC messages.  If set
      too low, messages will not be forwarded beyond the defined scope;
      thus, routers further away from the message originator will not be
      able to construct appropriate topology graphs.

   o  olsrv2OHoldTime, olsrv2THoldTime, olsrv2AHoldTime,
      olsrv2RxHoldTime, olsrv2PHoldTime, olsrv2FHoldTime - define hold
      times for tuples of different Information Bases of OLSRv2.  If set
      too low, information will expire quickly, and may this harm a
      correct operation of the routing protocol.

   o  olsrv2WillFlooding and olsrv2WillRouting - define the willingness
      of this router to become MPR.  If this is set to WILL_NEVER (0),
      the managed router will not forward any TC messages, nor accept a
      selection to become MPR by neighboring routers.  If set to
      WILL_ALWAYS (15), the router will be preferred by neighbors during
      MPR selection and may thus attract more traffic.

   o  olsrv2TpMaxJitter, olsrv2TtMaxJitter, olsrv2FMaxJitter - define
      jitter values for TC message transmission and forwarding.  If set
      too low, control traffic may get lost when collisions occur.

   o  olsrv2LinkMetricType - defines the type of the link metric that a
      router uses (e.g., ETX or hop count).  Whenever this value
      changes, all link metric information recorded by the router is
      invalid, causing a reset of information acquired from other
      routers in the MANET.  Moreover, if olsrv2LinkMetricType on a
      router is set to a value that is not known to other routers in the
      MANET, these routers will not be able to establish routes to that
      router or transiting that router.  Existing routes to the router
      with an olsrv2LinkMetricType unknown to other routers in the MANET
      will be removed.

   Some of the readable objects in this MIB module (i.e., objects with a
   MAX-ACCESS other than not-accessible) may be considered sensitive or
   vulnerable in some network environments.  It is thus important to
   control even GET and/or NOTIFY access to these objects and possibly
Top   ToC   RFC7184 - Page 79
   to even encrypt the values of these objects when sending them over
   the network via SNMP.  These are the tables and objects and their

   o  olsrv2TibRouterTopologySetTable - The contains information on the
      topology of the MANET, specifically the IP address of the routers
      in the MANET (as identified by
      olsrv2TibRouterTopologySetFromOrigIpAddr and
      olsrv2TibRouterTopologySetToOrigIpAddr objects).  This information
      provides an adversary broad information on the members of the
      MANET, located within this single table.  This information can be
      used to expedite attacks on the other members of the MANET without
      having to go through a laborious discovery process on their own.

   Some of the Tables in this MIB module AUGMENT Tables defined in NHDP-
   MIB [RFC6779].  Hence, care must be taken in configuring access
   control here in order make sure that the permitted permissions
   granted for the AUGMENTing Tables here are consistent with the access
   controls permitted within the NHDP-MIB.  The below list identifies
   the AUGMENTing Tables and their NHDP-MIB counterparts.  It is
   RECOMMENDED that access control policies for these Table pairs are
   consistently set.

   o  The olsrv2InterfaceTable AUGMENTs the nhdpInterfaceTable.

   o  The olsrv2IibLinkSetTable AUGMENTs the nhdpIibLinkSetTable.

   o  The olsrv2Iib2HopSetTable AUGMENTs the nhdpIib2HopSetTable.

   o  The olsrv2NibNeighborSetTable AUGMENTs the

   o  The olsrv2InterfacePerfTable AUGMENTs the nhdpInterfacePerfTable.

   MANET technology is often deployed to support communications of
   emergency services or military tactical applications.  In these
   applications, it is imperative to maintain the proper operation of
   the communications network and to protect sensitive information
   related to its operation.  Therefore, when implementing these
   capabilities, the full use of SNMPv3 cryptographic mechanisms for
   authentication and privacy is RECOMMENDED.

   SNMP versions prior to SNMPv3 did not include adequate security.
   Even if the network itself is secure (for example by using IPsec),
   there is no control as to who on the secure network is allowed to
   access and GET/SET (read/change/create/delete) the objects in this
   MIB module.
Top   ToC   RFC7184 - Page 80
   Implementations SHOULD provide the security features described by the
   SNMPv3 framework (see [RFC3410]), and implementations claiming
   compliance to the SNMPv3 standard MUST include full support for
   authentication and privacy via the User-based Security Model (USM)
   [RFC3414] with the AES cipher algorithm [RFC3826].  Implementations
   MAY also provide support for the Transport Security Model (TSM)
   [RFC5591] in combination with a secure transport such as SSH
   [RFC5592] or TLS/DTLS [RFC6353].

   Further, deployment of SNMP versions prior to SNMPv3 is NOT
   RECOMMENDED.  Instead, it is RECOMMENDED to deploy SNMPv3 and to
   enable cryptographic security.  It is then a customer/operator
   responsibility to ensure that the SNMP entity giving access to an
   instance of this MIB module is properly configured to give access to
   the objects only to those principals (users) that have legitimate
   rights to indeed GET or SET (change/create/delete) them.

9. Applicability Statement

This document describes objects for configuring parameters of the Optimized Link State Routing Protocol version 2 (OLSRv2) [RFC7181] process on a router. This MIB module, denoted OLSRv2-MIB, also reports state, performance information, and notifications. The OLSRv2 protocol relies upon information gathered via the Neighborhood Discovery Protocol [RFC6130] in order to perform its operations. NHDP is managed via the NHDP-MIB [RFC6779]. MANET deployments can greatly differ in aspects of dynamics of the topology, capacity, and loss rates of underlying channels, traffic flow directions, memory and CPU capacity of routers, etc. SNMP, and therefore this MIB module, are only applicable for a subset of MANET deployments, in particular deployments: o In which routers have enough memory and CPU resources to run SNMP and expose the MIB module. o Where a Network Management System (NMS) is defined to which notifications are generated and from which routers can be managed. o Where this NMS is reachable from routers in the MANET most of the time (as notifications to the NMS and management information from the NMS to the router will be lost when connectivity is temporarily lost). This requires that the topology of the MANET is only moderately dynamic. o Where the underlying wireless channel supports enough bandwidth to run SNMP, and where loss rates of the channel are not exhaustive.
Top   ToC   RFC7184 - Page 81
   Certain MANET deployments such as community networks with non-mobile
   routers, dynamic topology because of changing link quality, and a
   predefined gateway (that could also serve as NMS), are examples of
   networks applicable for this MIB module.  Other, more constrained
   deployments of MANETs may not be able to run SNMP and require
   different management protocols.

   Some level of configuration, i.e., read-write objects, is desirable
   for OLSRv2 deployments.  Topology-related configuration, such as the
   ability to enable OLSRv2 on new interfaces or initially configure
   OLSRv2 on a router's interfaces through the
   olsrv2InterfaceAdminStatus object, is critical to initial system
   startup.  The OLSRv2 protocol allows for some level of performance
   tuning through various protocol parameters, and this MIB module
   allows for configuration of those protocol parameters through read-
   write objects such as the olsrv2TcHopLimit or the olsrv2FMaxJitter.
   Other read-write objects allow for the control of Notification
   behavior through this MIB module, e.g., the
   olsrv2RoutingSetRecalculationCountThreshold object.  A fuller
   discussion of MANET network management applicability is to be
   provided elsewhere: [MGMT-SNAP] provides a snapshot of OLSRv2-routed
   MANET management as currently deployed, while [MANET-MGMT] is
   intended to provide specific guidelines on MANET network management
   considering the various MIB modules that have been written.

10. IANA Considerations

IANA now maintains the IANAolsrv2LinkMetricType-MIB and keeps it synchronized with the "LINK_METRIC Address Block TLV Type Extensions" registry at <>. The MIB modules in this document use the following IANA-assigned OBJECT IDENTIFIER values recorded in the SMI Numbers registry: Descriptor OBJECT IDENTIFIER value ---------- ----------------------- OLSRv2-MIB { mib-2 219 } IANA-OLSRv2-LINK-METRIC-TYPE-MIB { mib-2 221 }

11. Acknowledgements

The authors would like to thank Randy Presuhn, Benoit Claise, Adrian Farrel, as well as the entire MANET WG for reviews of this document. This MIB document uses the template authored by D. Harrington, which is based on contributions from the MIB Doctors, especially Juergen Schoenwaelder, Dave Perkins, C.M. Heard, and Randy Presuhn.
Top   ToC   RFC7184 - Page 82

12. References

12.1. Normative References

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", RFC 2863, June 2000. [RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", STD 62, RFC 3414, December 2002. [RFC3418] Presuhn, R., "Management Information Base (MIB) for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3418, December 2002. [RFC3826] Blumenthal, U., Maino, F., and K. McCloghrie, "The Advanced Encryption Standard (AES) Cipher Algorithm in the SNMP User-based Security Model", RFC 3826, June 2004. [RFC4001] Daniele, M., Haberman, B., Routhier, S., and J. Schoenwaelder, "Textual Conventions for Internet Network Addresses", RFC 4001, February 2005. [RFC5591] Harrington, D. and W. Hardaker, "Transport Security Model for the Simple Network Management Protocol (SNMP)", RFC 5591, June 2009. [RFC5592] Harrington, D., Salowey, J., and W. Hardaker, "Secure Shell Transport Model for the Simple Network Management Protocol (SNMP)", RFC 5592, June 2009.
Top   ToC   RFC7184 - Page 83
   [RFC6130]    Clausen, T., Dearlove, C., and J. Dean, "Mobile Ad Hoc
                Network (MANET) Neighborhood Discovery Protocol (NHDP)",
                RFC 6130, April 2011.

   [RFC6353]    Hardaker, W., "Transport Layer Security (TLS) Transport
                Model for the Simple Network Management Protocol
                (SNMP)", RFC 6353, July 2011.

   [RFC6779]    Herberg, U., Cole, R., and I. Chakeres, "Definition of
                Managed Objects for the Neighborhood Discovery
                Protocol", RFC 6779, October 2012.

   [RFC7181]    Clausen, T., Dearlove, C., Jacquet, P., and U. Herberg,
                "The Optimized Link State Routing Protocol Version 2",
                RFC 7181, April 2014.

12.2. Informative References

[MANET-MGMT] Nguyen, J., Cole, R., Herberg, U., Yi, J., and J. Dean, "Network Management of Mobile Ad hoc Networks (MANET): Architecture, Use Cases, and Applicability", Work in Progress, February 2013. [MGMT-SNAP] Clausen, T. and U. Herberg, "Snapshot of OLSRv2-Routed MANET Management", Work in Progress, February 2014. [REPORT-MIB] Cole, R., Macker, J., and A. Bierman, "Definition of Managed Objects for Performance Reporting", Work in Progress, November 2012. [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet- Standard Management Framework", RFC 3410, December 2002.
Top   ToC   RFC7184 - Page 84

Appendix A. IANAolsrv2LinkMetricType-MIB

This document has set up the IANAolsrv2LinkMetricType-MIB module. IANA now maintains the IANAolsrv2LinkMetricType-MIB and keeps it synchronized with the "LINK_METRIC Address Block TLV Type Extensions" registry at <>. The IANA site is the definitive source for this MIB should there be any discrepancies (e.g., future updates to the MIB). IANA-OLSRv2-LINK-METRIC-TYPE-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, mib-2 FROM SNMPv2-SMI TEXTUAL-CONVENTION FROM SNMPv2-TC; ianaolsrv2LinkMetricType MODULE-IDENTITY LAST-UPDATED "201404090000Z" -- 09 April 2014 ORGANIZATION "IANA" CONTACT-INFO "Internet Assigned Numbers Authority Postal: ICANN 12025 Waterfront Drive, Suite 300 Los Angeles, CA 90094-2536 Tel: +1 310 301 5800 E-Mail:" DESCRIPTION "This MIB module defines the IANAolsrv2LinkMetricType Textual Convention, and thus the enumerated values of the olsrv2LinkMetricType object defined in the OLSRv2-MIB." REVISION "201404090000Z" -- 09 April 2014 DESCRIPTION "Initial version of this MIB as published in RFC 7184." ::= { mib-2 221 } IANAolsrv2LinkMetricTypeTC ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "This data type is used as the syntax of the olsrv2LinkMetricType object in the definition of the OLSRv2-MIB module. The olsrv2LinkMetricType corresponds to
Top   ToC   RFC7184 - Page 85
          LINK_METRIC_TYPE of OLSRv2 (RFC 7181).
          OLSRv2 uses bidirectional additive link metrics
          to determine shortest distance routes (i.e.,
          routes with smallest total of link metric values).

          OLSRv2 has established a registry for the LINK_METRIC_TYPEs
          (denoted 'LINK_METRIC Address Block TLV Type Extensions'):

          This is done in Section 24.5 in OLSRv2 (RFC 7181).
          The LINK_METRIC_TYPE (which has as corresponding
          object in the MIB module olsrv2LinkMetricType)
          corresponds to the type extension of
          the LINK_METRIC TLV that is set up in the
          'LINK_METRIC Address Block TLV Type Extensions' registry.
          Whenever new link metric types are added to that registry,
          IANA MUST update this textual convention accordingly.

          The definition of this textual convention with the
          addition of newly assigned values is published
          periodically by the IANA, in either the Assigned
          Numbers RFC, or some derivative of it specific to
          Internet Network Management number assignments.  (The
          latest arrangements can be obtained by contacting the

          Requests for new values should be made to IANA via
          email ("
                 unknown(0)     -- Link metric meaning assigned
                                --       by administrative action
                                -- 1-223 Unassigned
                                -- 224-255 Reserved for
                                --       Experimental Use

Top   ToC   RFC7184 - Page 86

Authors' Addresses

Ulrich Herberg Fujitsu Laboratories of America 1240 East Arques Avenue Sunnyvale, CA 94085 USA EMail: URI: Robert G. Cole US Army CERDEC 6010 Frankford Road, Bldg 6010 Aberdeen Proving Ground, Maryland 21005 USA Phone: +1 443 395 8744 EMail: URI: Thomas Heide Clausen LIX, Ecole Polytechnique Palaiseau Cedex 91128 France Phone: +33 6 6058 9349 EMail: URI: