remote lookup operation.
The operational state of a remote lookup operation
can be determined by examination of its
lookupCtlOperStatus object."
REFERENCE
"See definition of RowStatus in RFC 2579,
’Textual Conventions for SMIv2.’"
::= { lookupCtlEntry 8 }
-- Lookup Results Table
lookupResultsTable OBJECT-TYPE
SYNTAX SEQUENCE OF LookupResultsEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Defines the Lookup Results Table for providing
the capability of determining the results of a
operation at a remote host.
One or more entries are added to the
lookupResultsTable when a lookup operation,
as reflected by an lookupCtlEntry, is completed
successfully. All entries related to a
successful lookup operation MUST be added
to the lookupResultsTable at the same time
that the associating lookupCtlOperStatus
object is transitioned to completed(2).
The number of entries added depends on the
results determined for a particular lookup
operation. All entries associated with an
lookupCtlEntry are removed when the
lookupCtlEntry is deleted.
A remote host can be multi-homed and have more than one IP
address associated with it (returned by lookup function),
or it can have more than one symbolic name (returned
by lookup function).
A function such as, for example, getnameinfo() or
gethostbyaddr() is called with a host address as its
parameter and is used primarily to determine a symbolic
name to associate with the host address. Entries in the
lookupResultsTable MUST be made for each host name
returned. If the function identifies an ’official host
name,’ then this symbolic name MUST be assigned a
lookupResultsIndex of 1.
A function such as, for example, getaddrinfo() or
gethostbyname() is called with a symbolic host name and is
used primarily to retrieve a host address. The entries
MUST be stored in the order that they are retrieved from
the lookup function. lookupResultsIndex 1 MUST be
assigned to the first entry."
::= { lookupObjects 4 }
lookupResultsEntry OBJECT-TYPE
SYNTAX LookupResultsEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Defines an entry in the lookupResultsTable. The
first two index elements identify the
lookupCtlEntry that a lookupResultsEntry belongs
to. The third index element selects a single
lookup operation result."
INDEX {
lookupCtlOwnerIndex,
lookupCtlOperationName,
lookupResultsIndex
}
::= { lookupResultsTable 1 }
LookupResultsEntry ::=
SEQUENCE {
lookupResultsIndex Unsigned32,
lookupResultsAddressType InetAddressType,
lookupResultsAddress InetAddress
}
lookupResultsIndex OBJECT-TYPE
SYNTAX Unsigned32 (1..’ffffffff’h)
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Entries in the lookupResultsTable are created when
the result of a lookup operation is determined.
Entries MUST be stored in the lookupResultsTable in
the order that they are retrieved. Values assigned
to lookupResultsIndex MUST start at 1 and increase
consecutively."
::= { lookupResultsEntry 1 }
lookupResultsAddressType OBJECT-TYPE
SYNTAX InetAddressType
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Indicates the type of result of a remote lookup
operation. A value of unknown(0) implies either that
the operation hasn’t been started or that
it has failed."
::= { lookupResultsEntry 2 }
lookupResultsAddress OBJECT-TYPE
SYNTAX InetAddress
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Reflects a result for a remote lookup operation
as per the value of lookupResultsAddressType.
The address type (InetAddressType) that relates to
this object is specified by the corresponding value
of lookupResultsAddress."
::= { lookupResultsEntry 3 }
-- Conformance information
-- Compliance statements
lookupCompliances OBJECT IDENTIFIER ::= { lookupConformance 1 }
lookupGroups OBJECT IDENTIFIER ::= { lookupConformance 2 }
-- Compliance statements
lookupCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"The compliance statement for SNMP entities that
fully implement the DISMAN-NSLOOKUP-MIB."
MODULE -- this module
MANDATORY-GROUPS { lookupGroup }
OBJECT lookupMaxConcurrentRequests
MIN-ACCESS read-only
DESCRIPTION
"The agent is not required to support set
operations to this object."
OBJECT lookupPurgeTime
MIN-ACCESS read-only
DESCRIPTION
"The agent is not required to support a set
operation to this object."
::= { lookupCompliances 1 }
lookupMinimumCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"The minimum compliance statement for SNMP entities
that implement the minimal subset of the
DISMAN-NSLOOKUP-MIB. Implementors might choose this
subset for small devices with limited resources."
MODULE -- this module
MANDATORY-GROUPS { lookupGroup }
OBJECT lookupMaxConcurrentRequests
MIN-ACCESS read-only
DESCRIPTION
"The agent is not required to support set
operations to this object."
OBJECT lookupPurgeTime
MIN-ACCESS read-only
DESCRIPTION
"The agent is not required to support a set
operation to this object."
OBJECT lookupCtlRowStatus
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required. If write access is
not supported, then at least one entry in the
lookupCtlTable MUST be established already when the SNMP
agent starts offering access to the NSLOOKUP-MIB module.
If, in such a case, only a single entry is offered, then
it is RECOMMENDED that this entry use strings with a
length of 0 for both of its two index objects."
::= { lookupCompliances 2 }
-- MIB groupings
lookupGroup OBJECT-GROUP
OBJECTS {
lookupMaxConcurrentRequests,
lookupPurgeTime,
lookupCtlOperStatus,
lookupCtlTargetAddressType,
lookupCtlTargetAddress,
lookupCtlTime,
lookupCtlRc,
lookupCtlRowStatus,
lookupResultsAddressType,
lookupResultsAddress
}
STATUS current
DESCRIPTION
"The group of objects that constitute the remote
Lookup operation."
::= { lookupGroups 1 }
END
5. Security Considerations
There are a number of management objects defined in the three MIB
modules 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 pingMaxConcurrentRequests
o traceRouteMaxConcurrentRequests
o lookupMaxConcurrentRequests
The MIB modules limit their maximum numbers of concurrent requests
by the values of these objects. Unauthorized access to them may
lead to an overload of the managed node and to a disruption of
other functions of the managed node.
o pingCtlTable
o traceRouteCtlTable
o lookupCtlTable
All objects in entries of these tables (except index objects) have
a MAX-ACCESS clause of read-create. Unauthorized access to these
objects can disturb the measurements controlled by the tables.
Also, the functions offered by the MIB modules can be misused for
illegal data retrieval and for attacking other systems by floods
of ping probes, traceroute probes or lookup requests,
respectively.
In general, all three, the ping, traceroute, and lookup functions,
when used excessively are considered a form of system attack. In the
case of ping, sending a system request too often can negatively
effect its performance and attempting to connect to what is supposed
to be an unused port can be very unpredictable. Excessive use of the
traceroute capability can, like ping, negatively affect system
performance. The same applies to excessive use of the lookup
service, particularly if the lookup cannot be resolved locally. In
insecure environments, it is RECOMMENDED that the MIBs defined within
this memo not be supported.
o lookupPurgeTime
Unauthorized access to this object can lead to the deletion of
results of lookup operations before they are read by a management
system, if the object is set to 0 or small values close to 0. If
the object is set to very high values, unauthorized access can
lead to a high consumption of resources for storing lookup
results.
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. However, the only information that can be
disclosed without encryption is the configuration and results of
measurements that are performed by implementations of the MIB
modules.
To facilitate the provisioning of access control by a security
administrator using the View-Based Access Control Model (VACM),
defined in RFC 3415 [RFC3415], for tables in which multiple users may
need to create or modify entries independently, the initial index is
used as an "owner index." Such an initial index has a syntax of
SnmpAdminString and can thus be trivially mapped to a securityName or
groupName defined in VACM, in accordance with a security policy.
All entries in related tables belonging to a particular user will
have the same value for this initial index. For a given user’s
entries in a particular table, the object identifiers for the
information in these entries will have the same subidentifiers
(except for the "column" subidentifier) up to the end of the encoded
owner index. To configure VACM to permit access to this portion of
the table, one would create vacmViewTreeFamilyTable entries with the
value of vacmViewTreeFamilySubtree including the owner index portion,
and vacmViewTreeFamilyMask ’wildcarding’ the column subidentifier.
More elaborate configurations are possible. The VACM access control
mechanism described above provides control.
SNMP versions prior to SNMPv3 did not include adequate security.
Even if the network itself is secure (for example by using IPSec),
even then, 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.
It is RECOMMENDED that implementers consider the security features as
provided by the SNMPv3 framework (see [RFC3410], section 8),
including full support for the SNMPv3 cryptographic mechanisms (for
authentication and privacy).
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.
6. Acknowledgements
This document is a product of the DISMAN Working Group. Thanks to
Eduardo Cardona for suggesting the minimum compliance statements and
to Juergen Schoenwaelder for the very detailed and constructive MIB
review.
7. References
7.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., Perkins, D., Schoenwaelder, J., Case, J.,
Rose, M., and S. Waldbusser, "Structure of Management
Information Version 2 (SMIv2)", STD 58, RFC 2578, April
1999.
[RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
Rose, M., and S. Waldbusser, "Textual Conventions for
SMIv2", STD 58, RFC 2579, April 1999.
[RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
Rose, M., and S. Waldbusser, "Conformance Statements for
SMIv2", STD 58, RFC 2580, April 1999.
[RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group
MIB", RFC 2863, June 2000.
[RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An
Architecture for Describing Simple Network Management
Protocol (SNMP) Management Frameworks", STD 62, RFC 3411,
December 2002.
[RFC4001] Daniele, M., Haberman, B., Routhier, S., and J.
Schoenwaelder, "Textual Conventions for Internet Network
Addresses", RFC 4001, February 2005.
7.2. Informative References
[RFC792] Postel, J., "Internet Control Message Protocol", STD 5,
RFC 792, September 1981.
[RFC862] Postel, J., "Echo Protocol", STD 20, RFC 862, May 1983.
[RFC1812] Baker, F., "Requirements for IP Version 4 Routers", RFC
1812, June 1995.
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,
"Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers", RFC 2474, December
1998.
[RFC3260] Grossman, D., "New Terminology and Clarifications for
Diffserv", RFC 3260, April 2002.
[RFC3410] Case, J., Mundy, R., Partain, D. and B. Stewart,
"Introduction and Applicability Statements for Internet-
Standard Management Framework", RFC 3410, December 2002.
[RFC3415] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based
Access Control Model (VACM) for the Simple Network
Management Protocol (SNMP)", STD 62, RFC 3415, December
2002.
Authors’ Addresses
Juergen Quittek
NEC Europe Ltd.
Network Laboratories
Kurfuersten-Anlage 36
69115 Heidelberg
Germany
Phone: +49 6221 4342-115
EMail: quittek@netlab.nec.de
Kenneth D. White
Dept. BRQA/Bldg. 501/G114
IBM Corporation
P.O.Box 12195
3039 Cornwallis
Research Triangle Park, NC 27709, USA
EMail: wkenneth@us.ibm.com
Full Copyright Statement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).