tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 7184


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

Part 4 of 4, p. 77 to 86
Prev RFC Part


prevText      Top      Up      ToC       Page 77 
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

   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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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

   [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      Up      ToC       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      Up      ToC       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).


       MODULE-IDENTITY, mib-2
                 FROM SNMPv2-SMI
                 FROM SNMPv2-TC;

   ianaolsrv2LinkMetricType MODULE-IDENTITY
       LAST-UPDATED "201404090000Z"  -- 09 April 2014
       CONTACT-INFO "Internet Assigned Numbers Authority

                     Postal: ICANN
                             12025 Waterfront Drive, Suite 300
                             Los Angeles, CA 90094-2536

                     Tel:    +1 310 301 5800
       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
         "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      Up      ToC       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      Up      ToC       Page 86 
Authors' Addresses

   Ulrich Herberg
   Fujitsu Laboratories of America
   1240 East Arques Avenue
   Sunnyvale, CA  94085


   Robert G. Cole
   6010 Frankford Road, Bldg 6010
   Aberdeen Proving Ground, Maryland  21005

   Phone: +1 443 395 8744

   Thomas Heide Clausen
   LIX, Ecole Polytechnique
   Palaiseau Cedex  91128

   Phone: +33 6 6058 9349