Uniform Resource Identifier (URI) Scheme for the Simple Network Management Protocol (SNMP)
draft-black-snmp-uri-09
The information below is for an old version of the document that is already published as an RFC.
| Document | Type |
This is an older version of an Internet-Draft that was ultimately published as RFC 4088.
|
|
|---|---|---|---|
| Authors | Jürgen Schönwälder , David L. Black , Keith McCloghrie | ||
| Last updated | 2018-12-20 (Latest revision 2004-12-02) | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Intended RFC status | Proposed Standard | ||
| Formats | |||
| Stream | WG state | (None) | |
| Document shepherd | (None) | ||
| IESG | IESG state | Became RFC 4088 (Proposed Standard) | |
| Action Holders |
(None)
|
||
| Consensus boilerplate | Unknown | ||
| Telechat date | (None) | ||
| Responsible AD | Bert Wijnen | ||
| Send notices to | <j.schoenwaelder@iu-bremen.de>, <Black_David@emc.com>, <hardie@qualcomm.com> |
draft-black-snmp-uri-09
URI Scheme for SNMP December 2004
Network Working Group D. Black
Internet Draft EMC Corporation
Document: draft-black-snmp-uri-09.txt K. McCloghrie
Expires: May 2005 Cisco Systems
J. Schoenwaelder
International University Bremen
December 2004
Uniform Resource Identifier (URI) Scheme for the
Simple Network Management Protocol (SNMP)
Status of this Memo
By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been
disclosed, or will be disclosed, and any of which I become aware
will be disclosed, in accordance with RFC 3668.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-Drafts
as reference material or to cite them other than as "work in
progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
SNMP and the Internet Standard Management Framework are widely
used for management of communication devices, creating needs to
specify SNMP access (including access to SNMP MIB object
instances) from non-SNMP management environments. For example,
when out-of-band IP management is used via a separate management
interface (e.g., for a device that does not support in-band IP
access) there is a need for a uniform way to indicate how to
contact the device for management. URIs fit this need well, as
they allow a single text string to indicate a management access
communication endpoint for a wide variety of IP-based protocols.
Black Expires - May 2005 [Page 1]
URI Scheme for SNMP December 2004
This document defines a URI scheme so that SNMP can be designated
as the protocol used for management. The scheme also allows a URI
to designate one or more MIB object instances.
Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL"
in this document are to be interpreted as described in [RFC 2119].
Table of Contents
1. Introduction...................................................2
2. Usage..........................................................3
3. Syntax of an SNMP URI..........................................4
3.1 Relative Reference Considerations..........................5
4. Semantics and Operations.......................................6
4.1 SNMP Service URIs..........................................6
4.2 SNMP Object URIs...........................................7
4.2.1 SNMP Object URI Data Access..........................8
4.3 OID Groups in SNMP URIs...................................10
4.4 Interoperability Considerations...........................10
5. Examples......................................................11
6. Security Considerations.......................................12
6.1 SNMP URI to SNMP Gateway Security Considerations..........13
7. IANA Considerations...........................................14
8. Change History (to be deleted prior to RFC publication).......14
9. Normative References..........................................15
10. Informative References.......................................15
11. Acknowledgments..............................................16
12. Copyright Notice and Disclaimers.............................16
13. Author's Addresses...........................................17
1. Introduction
SNMP and the Internet-Standard Management Framework were
originally devised to manage IP devices via in-band means where
management access is primarily via the same interface(s) used to
send and receive IP traffic. SNMP's wide adoption has resulted in
its use to manage communication devices that do not support in-
band IP access (e.g., Fibre Channel devices); a separate out-of-
band IP interface is often used for management. URIs provide a
convenient way to locate that interface and specify the protocol
to be used for management; one possible scenario is for an in-band
query to return a URI that indicates how the device is managed.
This document specifies a URI scheme to permit SNMP (including a
specific SNMP context) to be designated as the management protocol
by such a URI. This scheme also allows a URI to refer to specific
object instances within an SNMP MIB.
Black Expires - May 2005 [Page 2]
URI Scheme for SNMP December 2004
For a detailed overview of the documents that describe the current
Internet-Standard Management Framework, please refer to section 7
of [RFC 3410].
2. Usage
There are two major classes of SNMP URI usage, configuration and
gateways between SNMP and other protocols that use SNMP URIs.
An SNMP URI used for configuration indicates the location of
management information as part of configuration of an application
containing an SNMP manager. The URI can be obtained from a
configuration file or may be provided by a managed device (see
Section 1 for an example). Management information is exchanged
between the SNMP manager and agent, but does not flow beyond the
manager, as shown in the following diagram:
*********** SNMP-Request *********
* *================>* *
URI ---------->* Manager * * Agent *
* *<================* *
*********** SNMP-Response *********
^
|
Other Config Info ------------+
Additional configuration information (e.g., a security secret or
key) may be provided via an interface other than that used for the
URI. For example, when a managed device provides an SNMP URI in
an unprotected fashion, that device should not provide a secret or
key required to use the URI. The secret or key should instead be
pre-configured in or pre-authorized to the manager; see Section 6.
For gateway usage, clients employ SNMP URIs to request management
information via an SNMP URI to SNMP gateway (also called an SNMP
gateway in this document). The SNMP manager within the SNMP
gateway accesses the management information and returns it to the
requesting client, as shown in the following diagram:
SNMP gateway
********** URI *********** SNMP-Request *********
* *===========>* *================>* *
* Client * * Manager * * Agent *
* *<===========* *<================* *
********** Info *********** SNMP-Response *********
^
|
Other Config Info ------------+
Black Expires - May 2005 [Page 3]
URI Scheme for SNMP December 2004
Additional configuration information (e.g., security secret(s) or
key(s)) may be provided via an interface other than that used for
the URI. For example, some types of security information,
including secrets and keys, should be pre-configured in or pre-
authorized to the manager rather than being provided by the
client; see Section 6.
3. Syntax of an SNMP URI
An SNMP URI has the following ABNF [RFC 2234] syntax, based on the
ABNF syntax rules for userinfo, host, port, and (path) segment in
[rfc2396bis] and the ABNF syntax rule for HEXDIG in [RFC 2234]:
snmp-uri = "snmp://" snmp-authority [ context [ oids ]]
snmp-authority = [ securityName "@" ] host [ ":" port ]
securityName = userinfo ; SNMP securityName
context = "/" contextName [ ";" contextEngineID ]
contextName = segment ; SNMP contextName
contextEngineID = 1*(HEXDIG HEXDIG) ; SNMP contextEngineID
oids = "/" ( oid / oid-group ) [ suffix ]
oid-group = "(" oid *( "," oid ) ")"
oid = < as specified by [RFC 3061] >
suffix = "+" / ".*"
The userinfo and (path) segment ABNF rules are reused for syntax
only. In contrast, host and port have both the syntax and
semantics specified in [rfc2396bis]. See [RFC 3411] for the
semantics of securityName, contextEngineID, and contextName.
The snmp-authority syntax matches the URI authority syntax in
section 3.2 of [rfc2396bis] with the additional restriction that
(when present) the userinfo component of an authority MUST be an
SNMP securityName. If the securityName is empty or not given, the
entity making use of an SNMP URI is expected to know what SNMP
securityName to use if one is required. Inclusion of
authentication information (e.g., passwords) in URIs has been
deprecated (see Section 3.2.1 of [rfc2396bis]), so any secret or
key required for SNMP access must be provided via other means that
may be out-of-band with respect to communication of the URI. If
the port is empty or not given, port 161 is assumed.
If the contextName is empty or not given, the zero-length string
("") is assumed, as it is the default SNMP context. An SNMP
contextEngineID is a variable-format binary element that is
usually discovered by an SNMP manager. An SNMP URI encodes a
contextEngineID as hexadecimal digits corresponding to a sequence
Black Expires - May 2005 [Page 4]
URI Scheme for SNMP December 2004
of bytes. If the contextEngineID is empty or not given, the
context engine is to be discovered by querying the SNMP agent at
the specified host and port; see Section 4.1 below. The
contextEngineID component of the URI SHOULD be present if more
than one context engine at the designated host and port supports
the designated context.
An SNMP URI that designates the default SNMP context ("") MAY end
with the "/" character that introduces the contextName component.
An SNMP URI MUST NOT end with the "/" character that introduces an
oid or oid-group component, as the empty string is not a valid OID
for SNMP.
The encoding rules specified in [rfc2396bis] MUST be used for SNMP
URIs, including the use of percent encoding ("%" followed by two
hex digits) as needed to represent characters defined as reserved
in [rfc2396bis] and any characters not allowed in a URI. SNMP
permits any UTF-8 character to be used in a securityName or
contextName; all multi-byte UTF-8 characters in an SNMP URI MUST
be percent encoded as specified in Sections 2.1 and 2.5 of
[rfc2396bis]. These requirements are a consequence of reusing the
ABNF syntax rules for userinfo and segment from [rfc2396bis].
SNMP URIs will generally be short enough to avoid implementation
string length limits (e.g., that may occur at 255 characters).
Such limits may be a concern for large OID groups; relative
references to URIs (see Section 4.2 of [rfc2396bis]) may provide
an alternative in some circumstances.
Use of IP addresses in SNMP URIs is acceptable in situations where
dependence on availability of DNS service is undesirable or must
be avoided; otherwise IP addresses should not be used (see [RFC
1900] for further explanation).
3.1 Relative Reference Considerations
Use of the SNMP default context (zero-length string) within an
SNMP URI can result in a second instance of "//" in the URI, e.g.:
snmp://<host>//<oid>
This is allowed by [rfc2396bis] syntax; if a URI parser does not
handle the second "//" correctly, the parser is broken and needs
to be fixed. This example is important because use of the SNMP
default context in SNMP URIs is expected to be common.
On the other hand, the second occurrence of "//" in an absolute
SNMP URI affects usage of relative references to that URI (see
Section 4.2 of [rfc2396bis]) because a "//" at the start of a
Black Expires - May 2005 [Page 5]
URI Scheme for SNMP December 2004
relative reference always introduces a URI authority component
(host plus optional userinfo and/or port, see [rfc2396bis]).
Specifically, a relative reference of the form //<oid2> will not
work because the "//" will cause <oid2> to be parsed as a URI
authority, resulting in a syntax error when the parser fails to
find a host in <oid2> . To avoid this problem, relative
references that start with "//" but do not contain a URI authority
component MUST NOT be used. Functionality equivalent to any such
forbidden relative reference can be obtained by prefixing "." or
".." to the forbidden relative reference (e.g., ..//<oid2>). The
prefix to use depends on the base URI.
4. Semantics and Operations
An SNMP URI that does not include any OIDs is called an SNMP
service URI because it designates a communication endpoint for
access to SNMP management service. An SNMP URI that includes one
or more OIDs is called an SNMP object URI because it designates
one or more object instances in an SNMP MIB. The expected means
of using an SNMP URI is to employ an SNMP manager to access the
SNMP context designated by the URI via the SNMP agent at the host
and port designated by the URI.
4.1 SNMP Service URIs
An SNMP service URI does not designate a data object, but rather
an SNMP context to be accessed by a service; the telnet URI scheme
[RFC 1738] is another example of URIs that designate service
access. If the contextName in the URI is empty or not given,
"" (the zero-length string) is assumed as it is the default SNMP
context.
If a contextEngineID is given in an SNMP service URI, the context
engine that it designates is to be used. If the contextEngineID
is empty or not given in the URI, the context engine is to be
discovered; the context engine to be used is the one that supports
the context designated by the URI. The contextEngineID component
of the URI SHOULD be present if more than one context engine at
the designated host and port supports the designated context.
Many common uses of SNMP URIs are expected to omit (i.e., default)
the contextEngineID because they do not involve accessing SNMP
proxy agents, the most common reason for multiple SNMP context
engines to exist at a single host and port. Specifically, when an
SNMP agent is local to the network interface that it manages, the
agent will usually have only one context engine, in which case it
is safe to omit the contextEngineID component of an SNMP URI. In
addition, many SNMP agents that are local to a network interface
support only the default SNMP context (zero-length string).
Black Expires - May 2005 [Page 6]
URI Scheme for SNMP December 2004
4.2 SNMP Object URIs
An SNMP object URI contains one or more OIDs. The URI is used by
first separating the OID or OID group (including its preceding
slash plus any parentheses and/or suffix), and then processing the
resulting SNMP service URI as specified in Section 4.1 (above) to
determine the SNMP context to be accessed. The OID or OID group
is then used to generate SNMP operations directed to that SNMP
context.
The semantics of an SNMP object URI depend on whether the OID or
OID group has a suffix and what that suffix is. There are three
possible formats; in each case, the MIB object instances are
designated within the SNMP context specified by the service URI
portion of the SNMP object URI. The semantics of an SNMP object
URI that contains a single OID are:
(1) An OID without a suffix designates the MIB object
instance named by the OID.
(2) An OID with a "+" suffix designates the lexically next
MIB object instance following the OID.
(3) An OID with a ".*" suffix designates the set of MIB
object instances for which the OID is a strict lexical prefix;
this does not include the MIB object instance named by the OID.
An OID group in an SNMP URI consists of a set of OIDs in
parentheses. In each case, the OID group semantics are the
extension of the single OID semantics to each OID in the group
(e.g., a URI with a "+" suffix designates the set of MIB object
instances consisting of the lexically next instance for each OID
in the OID group).
When there is a choice among URI formats to designate the same MIB
object instance or instances, the above list is in order of
preference (no suffix is most preferable) as it runs from most
precise to least precise. This is because an OID without a suffix
precisely designates an object instance, whereas a "+" suffix
designates the next object instance, which may change, and the
".*" suffix could designate multiple object instances. Multiple
syntactically distinct SNMP URIs SHOULD NOT be used to designate
the same MIB object instance or set of instances as this may cause
unexpected results in URI-based systems that use string comparison
to test URIs for equality.
SNMP object URIs designate the data to be accessed, as opposed to
the specific SNMP operations to be used for access; Section 4.2.1
provides examples of how SNMP operations can be used to access
data for SNMP object URIs. Nonetheless, any applicable SNMP
Black Expires - May 2005 [Page 7]
URI Scheme for SNMP December 2004
operation, including GetBulk, MAY be used to access data for all
or part of one or more SNMP object URIs (e.g., via use of multiple
variable bindings in a single operation); it is not necessary to
use the specific operations described in Section 4.2.1 as long as
the results (returned variable bindings or error) could have been
obtained by following Section 4.2.1's descriptions. The use of
relative references that do not change the contextName (i.e.,
./<oid>) should be viewed as a hint that optimization of SNMP
access across multiple SNMP URIs may be possible.
An SNMP object URI MAY also be used to specify a MIB object
instance or instances to be written; this causes generation of an
SNMP Set operation instead of a Get. The "+" and ".*" suffixes
MUST NOT be used in this case; any attempt to do so is an error
that MUST NOT generate any SNMP Set operations. Values to be
written to the MIB object instance or instances are not specified
within an SNMP object URI.
SNMP object URIs designate data in SNMP MIBs, and hence do not
provide the means to generate all possible SNMP protocol
operations. For example, data access for an SNMP object URI
cannot directly generate either Snmpv2-Trap or InformRequest
notifications, although side effects of data access could cause
such notifications (depending on the MIB). In addition, whether
and how GetBulk is used for a SNMP object URI with a ".*" suffix
is implementation-specific.
4.2.1 SNMP Object URI Data Access
Data access based on an SNMP object URI returns an SNMP variable
binding for each MIB object instance designated by the URI or an
SNMP error if the operation fails. An SNMP variable binding binds
a variable name (OID) to a value or an SNMP exception (see [RFC
3416]). The SNMP operation or operations needed to access data
designated by an SNMP object URI depend on the OID or OID group
suffix or absence thereof. The following descriptions are not the
only method of performing data access for an SNMP object URI; any
suitable SNMP operations may be used as long as the results
(returned variable bindings or error) are functionally equivalent.
(1) For an OID or OID group without a suffix, an SNMP Get
operation is generated using each OID as a variable binding
name. If an SNMP error occurs, that error is the result
of URI data access, otherwise the returned variable binding or
bindings are the result of URI data access. Note that any
returned variable binding may contain an SNMP "noSuchObject"
or "noSuchInstance" exception.
Black Expires - May 2005 [Page 8]
URI Scheme for SNMP December 2004
(2) For an OID or OID group with a "+" suffix, an SNMP GetNext
operation is generated using each OID as a variable binding
name. If an SNMP error occurs, that error is the result
of URI data access, otherwise the returned variable binding
or bindings are the result of URI data access. Note that any
returned variable binding may contain an SNMP "endOfMibView"
exception.
(3) For an OID or OID group with a ".*" suffix, an SNMP GetNext
operation is initially generated using each OID as a variable
binding name. If the result is an SNMP error, that error is
the result of URI data access. If all returned variable
bindings contain either a) an OID for which the corresponding
URI OID is not a lexical prefix or b) an SNMP "endOfMibView"
exception, then the returned variable bindings are the
result of URI data access.
Otherwise the results of the GetNext operation are saved, and
another SNMP GetNext operation is generated using the newly
returned OIDs as variable binding names. This is repeated
(save the results and generate a GetNext with newly returned
OIDs as variable binding names) until all of the returned
variable bindings from a GetNext contain either a) an OID for
which the corresponding URI OID is not a lexical prefix or b)
an SNMP "endOfMibView" exception. The results from all of
the GetNext operations are combined to become the overall
result of URI data access; this may include variable bindings
whose OID is not a lexical extension of the corresponding URI
OID. If the OID subtrees (set of OIDs for which a specific URI
OID is a lexical prefix) are not the same size for all OIDs in
the OID group, the largest subtree determines when this
iteration ends. SNMP GetBulk operations MAY be used to
optimize this iterated access.
Whenever a returned variable binding contains an OID for which
the corresponding URI OID is not a lexical prefix or an SNMP
"endOfMibView" exception, iteration of that element of the
OID group MAY cease, reducing the number of variable bindings
used in subsequent GetNext operations. In this case the
results of URI data access for the SNMP URI will not consist
entirely of OID-group-sized sets of variable bindings. Even if
this does not occur, the last variable binding returned for
each member of the OID group will generally contain an SNMP
"endOfMibView" exception or an OID for which the corresponding
URI OID is not a lexical prefix.
Black Expires - May 2005 [Page 9]
URI Scheme for SNMP December 2004
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 or otherwise desirable.
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 [RFC 3291] where 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 incorrectly
interpreted.
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 backwards compatibility with existing usage, but
other transports MAY be used. If more than one transport can be
used (e.g., SNMP over TCP [RFC 3430] 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 [RFC 3430]).
An SNMP URI designates use of SNMPv3 as specified by [RFC 3416],
[RFC 3417], and related documents, but older versions of SNMP MAY
be used in accordance with [RFC 3584] where 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 [RFC
3584]. 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
Black Expires - May 2005 [Page 10]
URI Scheme for SNMP December 2004
SHOULD be omitted. Note that some community names contain
reserved characters (e.g., "@") that require percent encoding when
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 for use of a non-standard port is testing of 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 [RFC 3411].
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.
Black Expires - May 2005 [Page 11]
URI Scheme for SNMP December 2004
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 when sending it 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 [RFC 3411]). 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 MUST 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-authorized for use by the
manager. If an SNMP URI contains a securityName that the SNMP
manager is not authorized 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
Black Expires - May 2005 [Page 12]
URI Scheme for SNMP December 2004
allowed to access and GET/SET (read/change/create/delete) the
objects in MIB modules. It is RECOMMENDED that implementers
consider the security features as provided by the SNMPv3 framework
(see [RFC 3410], 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 [RFC
3411] 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
Black Expires - May 2005 [Page 13]
URI Scheme for SNMP December 2004
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
sending them 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 is asked to register the URL registration template found
in Appendix A in accordance with [RFC 2717].
8. Change History (to be deleted prior to RFC publication)
-03: Update to reference rfc2396bis draft instead of RFC 2396.
Context and engine syntax changed to comply with rfc2396bis
authority component restrictions. Minor text editing.
-04: Remove "0x" engine prefix. Add discussion of relative
URI impacts of embedded //. Add OID groups to support
MIB object instances that need to be accessed together.
Always discard SNMP "no data" response exceptions. More edits.
-05: Spell out acronyms in title. Correct wording to refer to
SNMP exceptions. More editing.
-06: Change syntax component names to match SNMP terminology
(e.g., contextName, contextEngineID). Back out -04 change to
discard SNMP "no data" exceptions. Loosen requirements on
group iteration. Drop "engine=" to simplify syntax.
Rewrite ABNF for clarity and correctness. More editing.
-07: Yet more editing. Move data access details into a
separate subsection, and make it clear that functional
equivalence to their results is all that is required. Use
example.com consistently in all examples.
Black Expires - May 2005 [Page 14]
URI Scheme for SNMP December 2004
-08: Remove discussion of SNMP security models. Add warning
about avoiding disclosure of a community name when it's a
secret. Change "relative URI" to "relative reference" to match
final version of rfc2396bis.
-09: Expand security considerations section to cover SNMP URI
to SNMP gateways. Add usage section to help explain this.
9. Normative References
[rfc2396bis] Uniform Resource Identifiers (URI): Generic Syntax.
T. Berners-Lee, R. Fielding, L. Masinter.
Internet-Draft draft-fielding-uri-rfc2396bis-07.txt .
Work in Progress. September 2004.
[RFC 2119] Key words for use in RFCs to Indicate Requirement
Levels. S. Bradner. RFC 2119, BCP 14. March 1997.
[RFC 2234] Augmented BNF for Syntax Specifications: ABNF.
D. Crocker, Ed., P. Overell. RFC 2234. November 1997.
[RFC 3061] A URN Namespace of Object Identifiers. M. Mealling.
February 2001.
[RFC 3411] An Architecture for Describing Simple Network
Management Protocol (SNMP) Management Frameworks.
D. Harrington, R. Presuhn, B. Wijnen. December 2002.
[RFC 3414] User-based Security Model (USM) for version 3 of the
Simple Network Management Protocol (SNMPv3).
U. Blumenthal, B. Wijnen. RFC 3414. December 2002.
[RFC 3416] Version 2 of the Protocol Operations for the Simple
Network Management Protocol (SNMP). R. Presuhn, Ed.
RFC 3416. December 2002.
[RFC 3417] Transport Mappings for the Simple Network Management
Protocol (SNMP). R. Presuhn, Ed. RFC 3417.
December 2002.
[RFC 3584] Coexistence between Version 1, Version 2, and Version 3
of the Internet-standard Network Management Framework.
R. Frye, D. Levi, S. Routhier, B. Wijnen. RFC 3584.
August 2003.
10. Informative References
[RFC 1738] Uniform Resource Locators (URL). T. Berners-Lee,
L. Masinter, M. McCahill. RFC 1738. December 1994.
Black Expires - May 2005 [Page 15]
URI Scheme for SNMP December 2004
[RFC 1900] Renumbering Needs Work. B. Carpenter, Y. Rekhter.
RFC 1900. February 1996.
[RFC 2717] Registration Procedures for URL Scheme Names. R. Petke,
I. King. RFC 2717. November 1999.
[RFC 3291] Textual Conventions for Internet Network Addresses.
M. Daniele, B. Haberman, S. Routhier,
J. Schoenwaelder. RFC 3291. May 2002.
[RFC 3410] Introduction and Applicability Statements for Internet-
Standard Management Framework. J. Case, R. Mundy,
D. Partain, B. Stewart. RFC 3410. December 2002.
[RFC 3430] Simple Network Management Protocol Over Transmission
Control Protocol Transport Mapping. J. Schoenwaelder.
December 2002.
[RFC 3617] Uniform Resource Identifier (URI) Scheme and
Applicability Statement for the Trivial File Transfer
Protocol (TFTP). E. Lear. October 2003.
11. Acknowledgments
Portions of this document were adapted from Eliot Lear's TFTP URI
scheme specification [RFC 3617]. 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 draft
have resulted in significant improvements and are gratefully
acknowledged.
12. Copyright Notice and Disclaimers
Copyright (C) The Internet Society (2004). 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."
Black Expires - May 2005 [Page 16]
URI Scheme for SNMP December 2004
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."
13. Author's 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
Black Expires - May 2005 [Page 17]
URI Scheme for SNMP December 2004
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 [RFC 3410] and [RFC 3584]. Also SNMP over TCP,
see [RFC 3430].
Interoperability considerations: Section 4.4
Security considerations: Section 6
Relevant publications: See [RFC 3410] for list. Also [RFC 3430]
and [RFC 3584].
Contact: David L. Black, Section 13
Author/Change Controller: IESG
Black Expires - May 2005 [Page 18]