RFC 7184
Definition of Managed Objects for the Optimized Link State Routing Protocol Version 2
Pages: 86
Proposed Standard
Proposed Standard
Part 4 of 4 – Pages 77 to 86
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
environment without proper protection can have a negative effect on
network operations. These are the tables and objects and their
sensitivity/vulnerability:
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
to even encrypt the values of these objects when sending them over
the network via SNMP. These are the tables and objects and their
sensitivity/vulnerability:
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
nhdpNibNeighborSetTable.
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.
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.
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 <http://www.iana.org/assignments/manet-parameters>. 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.
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.
[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.
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 <http://www.iana.org/assignments/manet-parameters>. 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: iana@iana.org" 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
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'):
http://www.iana.org/assignments/manet-parameters/
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
IANA.)
Requests for new values should be made to IANA via
email (iana@iana.org)."
SYNTAX INTEGER {
unknown(0) -- Link metric meaning assigned
-- by administrative action
-- 1-223 Unassigned
-- 224-255 Reserved for
-- Experimental Use
}
END
Authors' Addresses
Ulrich Herberg Fujitsu Laboratories of America 1240 East Arques Avenue Sunnyvale, CA 94085 USA EMail: ulrich@herberg.name URI: http://www.herberg.name/ Robert G. Cole US Army CERDEC 6010 Frankford Road, Bldg 6010 Aberdeen Proving Ground, Maryland 21005 USA Phone: +1 443 395 8744 EMail: robert.g.cole@us.army.mil URI: http://www.cs.jhu.edu/~rgcole/ Thomas Heide Clausen LIX, Ecole Polytechnique Palaiseau Cedex 91128 France Phone: +33 6 6058 9349 EMail: T.Clausen@computer.org URI: http://www.ThomasClausen.org/