4.3. OID Groups in SNMP URIs
Parenthesized OID groups in SNMP URIs are intended to support MIB
object instances for which access via a single SNMP operation is
required to ensure consistent results. Therefore, the OIDs within an
OID group in an SNMP URI SHOULD be accessed by a single SNMP
operation containing a variable binding corresponding to each OID in
the group. A specific example involves the InetAddress and
InetAddressType textual conventions defined in [RFC4001], for which
the format of an InetAddress instance is specified by an associated
InetAddressType instance. If two such associated instances are read
via separate SNMP operations, the resulting values could be
inconsistent (e.g., due to an intervening Set), causing the
InetAddress value to be interpreted incorrectly.
This single operation requirement ("SHOULD") also applies to each OID
group resulting from iterated access for an SNMP URI with a ".*"
suffix. When members of an SNMP URI OID group differ in the number
of OIDs for which each is a lexical prefix, this iteration may
overrun by returning numerous variable bindings for which the
corresponding OID in the OID group is not a lexical prefix. Such
overrun can be avoided by using relative references within the same
context (i.e., ./<oid>.* ) when it is not important to access
multiple MIB object instances in a single SNMP operation.
4.4. Interoperability Considerations
This document defines a transport-independent "snmp" scheme that is
intended to accommodate SNMP transports other than UDP. UDP is the
default transport for access to information specified by an SNMP URI
for backward compatibility with existing usage, but other transports
MAY be used. If more than one transport can be used (e.g., SNMP over
TCP [RFC3430] in addition to SNMP over UDP), the information or SNMP
service access designated by an SNMP URI SHOULD NOT depend on which
transport is used (for SNMP over TCP, this is implied by Section 2 of
[RFC3430]).
An SNMP URI designates use of SNMPv3 as specified by [RFC3416],
[RFC3417], and related documents, but older versions of SNMP MAY be
used in accordance with [RFC3584] when usage of such older versions
is unavoidable. For SNMPv1 and SNMPv2c, the securityName,
contextName, and contextEngineID elements of an SNMP URI are mapped
to/from the community name, as described in [RFC3584]. When the
community name is kept secret as a weak form of authentication, this
mapping should be configured so that these three elements do not
reveal information about the community name. If this is not done,
then any SNMP URI component that would disclose significant
information about a secret community name SHOULD be omitted. Note
that some community names contain reserved characters (e.g., "@")
that require percent encoding when they are used in an SNMP URI.
SNMP versions (e.g., v3) have been omitted from the SNMP URI scheme
to permit use of older versions of SNMP, as well as any possible
future successor to SNMPv3.
5. Examples
snmp://example.com
This example designates the default SNMP context at the SNMP agent at
port 161 of host example.com .
snmp://tester5@example.com:8161
This example designates the default SNMP context at the SNMP agent at
port 8161 of host example.com and indicates that the SNMP
securityName "tester5" is to be used to access that agent. A
possible reason to use a non-standard port is for testing a new
version of SNMP agent code.
snmp://example.com/bridge1
This example designates the "bridge1" SNMP context at example.com.
Because the contextEngineID component of the URI is omitted, there
SHOULD be at most one SNMP context engine at example.com that
supports the "bridge1" context.
snmp://example.com/bridge1;800002b804616263
This example designates the "bridge1" context at snmp.example.com via
the SNMP context engine 800002b804616263 (string representation of a
hexadecimal value). This avoids ambiguity if any other context
engine supports a "bridge1" context. The above two examples are
based on the figure in Section 3.3 of [RFC3411].
snmp://example.com//1.3.6.1.2.1.1.3.0
snmp://example.com//1.3.6.1.2.1.1.3+
snmp://example.com//1.3.6.1.2.1.1.3.*
These three examples all designate the sysUpTime.0 object instance in
the SNMPv2-MIB or RFC1213-MIB for the default SNMP context ("") at
example.com as sysUpTime.0 is:
a) designated directly by OID 1.3.6.1.2.1.1.3.0,
b) the lexically next MIB object instance after the OID
1.3.6.1.2.1.1.3, and
c) the only MIB object instance whose OID has 1.3.6.1.2.1.1.3 as a
lexical prefix.
These three examples are provided for illustrative purposes only, as
multiple syntactically distinct URIs SHOULD NOT be used to designate
the same MIB object instance, in order to avoid unexpected results in
URI-based systems that use string comparison to test URIs for
equality.
snmp://example.com/bridge1/1.3.6.1.2.1.2.2.1.8.*
This example designates the ifOperStatus column of the IF-MIB in the
bridge1 SNMP context at example.com.
snmp://example.com//(1.3.6.1.2.1.2.2.1.7,1.3.6.1.2.1.2.2.1.8).*
This example designates all (ifAdminStatus, ifOperStatus) pairs in
the IF-MIB in the default SNMP context at example.com.
6. Security Considerations
An intended use of this URI scheme is designation of the location of
management access to communication devices. Such location
information may be considered sensitive in some environments, making
it important to control access to this information and possibly even
to encrypt it when it is sent over the network. All uses of this URI
scheme should provide security mechanisms appropriate to the
environments in which such uses are likely to be deployed.
The SNMP architecture includes control of access to management
information (see Section 4.3 of [RFC3411]). An SNMP URI does not
contain sufficient security information to obtain access in all
situations, as the SNMP URI syntax is incapable of encoding SNMP
securityModels, SNMP securityLevels, and credential or keying
information for SNMP securityNames. Other means are necessary to
provide such information; one possibility is out-of-band pre-
configuration of the SNMP manager, as shown in the diagrams in
Section 2.
By itself, the presence of a securityName in an SNMP URI does not
authorize use of that securityName to access management information.
Instead, the SNMP manager SHOULD match the securityName in the URI to
an SNMP securityName and associated security information that have
been pre-configured for use by the manager. If an SNMP URI contains
a securityName that the SNMP manager is not provisioned to use, SNMP
operations for that URI SHOULD NOT be generated.
SNMP versions prior to SNMPv3 did not include adequate security.
Even if the network itself is secure (for example, via use of IPsec),
there is no control over who on the secure network is allowed to
access and GET/SET (read/change/create/delete) the objects in MIB
modules. It is RECOMMENDED that implementers consider the security
features provided by the SNMPv3 framework (see [RFC3410], Section 8,
for an overview), including full support for SNMPv3 cryptographic
mechanisms (for authentication and privacy). This is of additional
importance for MIB elements considered sensitive or vulnerable
because GETs have side effects.
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 a MIB
module instance is properly configured to give access to the objects
only to those principals (users) that have legitimate rights to
indeed GET or SET (read/change/create/delete) them.
6.1. SNMP URI to SNMP Gateway Security Considerations
Additional security considerations apply to SNMP gateways that
generate SNMP operations for SNMP URIs and return the results to
clients (see Section 2) because management information is
communicated beyond the SNMP framework. In general, an SNMP gateway
should have some knowledge of the structure and function of the
management information that it accesses via SNMP. Among other
benefits, this allows an SNMP gateway to avoid SNMP access control
failures because the gateway can reject an SNMP URI that will cause
such failures before generating any SNMP operations.
SNMP gateways SHOULD impose authorization or access-control checks on
all clients. If an SNMP gateway does not impose authorization or
access controls, the gateway MUST NOT automatically obtain or use
SNMP authentication material for arbitrary securityNames, as doing so
would defeat SNMP’s access controls. Instead, all SNMP gateways
SHOULD authenticate each client and check the client’s authorization
to use a securityName in an SNMP URI before using the securityName on
behalf of that client.
An SNMP gateway is also responsible for ensuring that all of its
communication is appropriately secured. Specifically, an SNMP
gateway SHOULD ensure that communication of management information
with any client is protected to at least the SNMP securityLevel used
for the corresponding SNMP access (see Section 3.4.3 of [RFC3411] for
more information on securityLevel). If the client provides SNMP
security information, the SNMP gateway SHOULD authenticate the client
and SHOULD ensure that an authenticated cryptographic integrity check
is used for that communication to prevent modification of the
security information. In addition, if a client provides any key or
secret, the SNMP gateway SHOULD ensure that encryption is used in
addition to the integrity check for that communication to prevent
disclosure of keys or secrets.
There are management objects defined in SNMP MIBs whose MAX-ACCESS is
read-write and/or read-create. Such objects may be considered
sensitive or vulnerable in some network environments. SNMP gateway
support for SNMP SET operations in a non-secure environment without
proper protection can have a negative effect on network operations.
The individual MIB module specifications, and especially their
security considerations, should be consulted for further information.
Some readable objects in some MIB modules (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 access to these objects via an SNMP gateway and
possibly to even encrypt the values of these objects when they are
sent over the network. The individual MIB module specifications, and
especially their security considerations, should be consulted for
further information. This consideration also applies to objects for
which read operations have side effects.
7. IANA Considerations
The IANA has registered the URL registration template found in
Appendix A in accordance with [RFC2717].
8. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
[RFC3061] Mealling, M., "A URN Namespace of Object Identifiers", RFC
3061, February 2001.
[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.
[RFC3416] Presuhn, R., "Version 2 of the Protocol Operations for the
Simple Network Management Protocol (SNMP)", STD 62, RFC
3416, December 2002.
[RFC3417] Presuhn, R., "Transport Mappings for the Simple Network
Management Protocol (SNMP)", STD 62, RFC 3417, December
2002.
[RFC3584] Frye, R., Levi, D., Routhier, S., and B. Wijnen,
"Coexistence between Version 1, Version 2, and Version 3 of
the Internet-standard Network Management Framework", BCP
74, RFC 3584, August 2003.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, RFC
3986, January 2005.
9. Informative References
[RFC1738] Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform
Resource Locators (URL)", RFC 1738, December 1994.
[RFC1900] Carpenter, B. and Y. Rekhter, "Renumbering Needs Work", RFC
1900, February 1996.
[RFC2717] Petke, R. and I. King, "Registration Procedures for URL
Scheme Names", BCP 35, RFC 2717, November 1999.
[RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart,
"Introduction and Applicability Statements for Internet-
Standard Management Framework", RFC 3410, December 2002.
[RFC3430] Schoenwaelder, J., "Simple Network Management Protocol Over
Transmission Control Protocol Transport Mapping", RFC 3430,
December 2002.
[RFC3617] Lear, E., "Uniform Resource Identifier (URI) Scheme and
Applicability Statement for the Trivial File Transfer
Protocol (TFTP)", RFC 3617, October 2003.
[RFC4001] Daniele, M., Haberman, B., Routhier, S., and J.
Schoenwaelder, "Textual Conventions for Internet Network
Addresses", RFC 4001, February 2005.
10. Acknowledgements
Portions of this document were adapted from Eliot Lear’s TFTP URI
scheme specification [RFC3617]. Portions of the security
considerations were adapted from the widely used security
considerations "boilerplate" for MIB modules. Comments from Ted
Hardie, Michael Mealing, Larry Masinter, Frank Strauss, Bert Wijnen,
Steve Bellovin, the mreview@ops.ietf.org mailing list and the
uri@w3c.org mailing list on earlier versions of this document have
resulted in significant improvements and are gratefully acknowledged.
Appendix A. Registration Template
URL scheme name: snmp
URL scheme syntax: Section 3
Character encoding considerations: Section 3
Intended usage: Sections 1 and 2
Applications and/or protocols which use this scheme: SNMP, all
versions, see [RFC3410] and [RFC3584]. Also SNMP over TCP,
see [RFC3430].
Interoperability considerations: Section 4.4
Security considerations: Section 6
Relevant publications: See [RFC3410] for list. Also [RFC3430]
and [RFC3584].
Contact: David L. Black, see below
Author/Change Controller: IESG
Authors’ Addresses
David L. Black
EMC Corporation
176 South Street
Hopkinton, MA 01748
Phone: +1 (508) 293-7953
EMail: black_david@emc.com
Keith McCloghrie
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA USA 95134
Phone: +1 (408) 526-5260
EMail: kzm@cisco.com
Juergen Schoenwaelder
International University Bremen
P.O. Box 750 561
28725 Bremen
Germany
Phone: +49 421 200 3587
EMail: j.schoenwaelder@iu-bremen.de
Full Copyright Statement
Copyright (C) The Internet Society (2005).
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 currently provided by the
Internet Society.