URI Scheme for SNMP October 2003
Network Working Group D.Black
Internet Draft EMC Corporation
Document: draft-black-snmp-uri-01.txt K. McCloghrie
Expires: April 2004 Cisco Systems
October 2003
URI Scheme for SNMP
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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. 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. URLs fit this need well, as they allow a single text
string to indicate a management point of contact for a wide
variety of IP-based protocols. This document defines a simple URI
scheme so that SNMP can be designated as the protocol used for
management.
NOTE: This draft has a several significant OPEN ISSUES and is
definitely a work in progress. In particular, the syntax for SNMP
object URIs is not stable.
Black Expires - April 2004 [Page 1]
URI Scheme for SNMP October 2003
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. Syntax of an SNMP URI..........................................3
3. Semantics and Operations.......................................5
3.1 SNMP Service URIs..........................................5
3.2 SNMP Object URIs and Interoperability Considerations.......5
4. Examples.......................................................6
5. Security Considerations........................................7
6. IANA Considerations............................................8
7. Normative References...........................................8
8. Informative References.........................................8
9. Acknowledgments................................................9
10. Author's Addresses............................................9
1. Introduction
NOTE: This draft has a number of OPEN ISSUES and is very much a
work in progress.
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. URLs 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 text string URL that indicates how the device is
managed. This document specifies URI schemes to permit SNMP to be
designated as the management protocol by such a URL. The schemes
contain OPTIONAL extensions that allow a URI to refer to specific
information within an SNMP MIB.
Black Expires - April 2004 [Page 2]
URI Scheme for SNMP October 2003
2. Syntax of an SNMP URI
An SNMP URI has the following ABNF [RFC 2234] syntax:
snmp_URI = [ "udp." ] "snmp:" "//"
[ user "@" ] host [ ":" port ]
[ "/" [ engine ] [ ";" context ] "?" oid ]
user = // userName as specified by [RFC 3414]
host = // as specified by [RFC 2396] and [RFC 2732]
port = // as specified by [RFC 2396]
engine = "0x" hex [ (hex)*]
// contextEngineID as specified by [RFC 3411]
hex = // Hex digit, as specified by [RFC 2396]
context = // contextName as specified by [RFC 3411]
oid = // as specified by [RFC 3061]
OPEN ISSUE: Textual representation of "engine". The represented
SNMP contextEngineID is a variable-format binary element whose
preferred textual representation is format-dependent, but not
required. See the definition of SnmpEngineID on pp.41-43 of [RFC
3411]. The above hex representation works in all cases, but is
not particularly human-friendly.
Here's an initial attempt at a more human-friendly definition of
"engine", whose major benefit is representing the possible formats
in clause 3 on p.43 of RFC 3411 (this definition would replace the
above definition of "engine"):
engine = ("-" "0x" hex [ (hex)* ] ) |
("2" "0x" enterprise-id hex-string-16 ) |
("3" "0x" enterprise-id "-"
(("v4:" IPv4-address) |
("v6:" IPv6-address) |
("mac:" "0x" MAC-address) |
("txt:" text-string) |
("hex:" "0x" hex [ (hex)* ])))
"-" indicates that no RFC 3411 recommended format was used. "2"
indicates the clause 2 format in [RFC 3411] (SNMPv2 or prior)
where the first bit of the engineID is '0', "3" indicates the
clause 3 format in [RFC 3411] (SNMPv3) where the first bit of the
engineID is '1'. enterprise-id is an 8 character hex string; the
first hex character MUST NOT be 8 or greater, as the first bit of
the first octet is specified by the preceding "2" or "3". hex-
string-16 is a 16 character hex string. IPv4-address and IPv6-
address are represented in the usual fashion (OPEN ISSUE: RFC
reference for these formats). MAC-address is an IEEE MAC address
represented as a 12 character fixed length hex string (48 bits).
The text-string for the "txt:" case MUST NOT exceed 27 characters
Black Expires - April 2004 [Page 3]
URI Scheme for SNMP October 2003
(and has the UTF-8 issue in the next paragraph). The hex string
in the final case MUST NOT exceed 54 hex characters. Also, the
"0x" prefix on all hex values may or may not be a good idea.
OPEN ISSUE: SNMP allows the use of any UTF-8 character in userName
and contextName strings; see the SnmpAdminString definition on
pp.47-48 of RFC 3411. In addition to escaping the obvious
reserved characters (as specified in RFC 2396, Sections 2.2 and
2.4), something needs to be said about UTF-8 characters in URIs,
as RFC 2396 is written in terms of US-ASCII. There should be a
generic URI solution to UTF-8 support ... or this draft could just
specify US-ASCII only awaiting the real solution.
This specification defines two similar URI schemes; "udp.snmp:"
specifies use of SNMP over UDP [RFC 3417] and a transport-
independent "snmp:" scheme that accommodates 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. Other documents
may define URI schemes that designate specific transports by
adding the appropriate prefix (e.g., "tcp.snmp:" is appropriate
for SNMP over TCP [RFC 3430]). SNMP versions (e.g., v3) have been
omitted from these URI schemes for forwards compatibility with any
possible future successor to SNMPv3.
OPEN ISSUE: Use of other transports may have interoperability
consequences; is saying "specify the transport if there is any
doubt" sufficient?
An SNMP URI that does not include a "/" and any elements following
it is called an SNMP service URI because it designates a
communication endpoint for access to SNMP service. An SNMP URI
that includes a "/" and the elements following it is called an
SNMP object URI. If the user is empty or not given, the user of
this URI is expected to already know what SNMP userName to use if
required. In contrast to protocols such as FTP, SNMPv3 does not
use passwords, so there is no support for passwords in the SNMP
URI syntax. If the port is empty or not given, UDP port 161 is
assumed.
In an SNMP object URI: (1) If the engine is empty or not given,
the URI is only valid if there is at most one SNMP engine
supported by the SNMP agent at the specified host and port. (2) If
the context is empty or not given, the empty string ("") SHOULD be
used as it is the default SNMP context. (3) The oid is REQUIRED,
and it must be a complete OID. (OPEN ISSUE: OID sentence needs
some wordsmithing - check RFC 3061 - also point out what the first
few components will generally have to be.)
Black Expires - April 2004 [Page 4]
URI Scheme for SNMP October 2003
WARNING: The syntax in this draft for SNMP object URIs is not
stable and should not be relied upon.
The encoding rules specified in [RFC 2396] and [RFC 2732] apply to
SNMP URIs and no additional rules are specified here. Host names
are generally short enough to avoid implementation string length
limits (e.g., that may occur at 255 characters). 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).
OPEN ISSUE: foregoing is for service URIs, needs to be extended to
cover object URIs once engine and UTF-8 encoding issues are
resolved.
3. Semantics and Operations
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 to access a location designated by an SNMP URI in
accordance with [RFC 3584] where usage of such older versions is
unavoidable. For a detailed overview of the documents that
describe the current Internet-Standard Management Framework,
please refer to section 7 of [RFC 3410].
3.1 SNMP Service URIs
An SNMP service URI does not designate a data object, but rather
an interactive service; the telnet URI scheme [RFC 1738] is
another example where a service is designated by URIs. The
expected means of accessing information designated by an SNMP
service URI is to use an SNMP Manager to access the SNMP Agent at
the host (and port) specified by the URI. There are no
significant interoperability considerations for SNMP Service URIs.
3.2 SNMP Object URIs and Interoperability Considerations
An SNMP object URI contains an OID, and its expected means of
access is to use an SNMP Manager to issue an SNMP GET operation.
When the OID refers to a MIB element, the SNMP GET will return
useful information. On the other hand when the OID specifies a
subtree (e.g., a MIB table or an entire MIB), an SNMP GET will
return "noSuchInstance". In practice, an SNMP Manager or
Application can use knowledge of the MIB involved to determine
what the OID designates and how to access the information, but
this knowledge cannot reasonably be encoded into an SNMP object
URI. Therefore an SNMP Manager or Application SHOULD NOT issue
SNMP operations for an unrecognized OID; instead, the SNMP Manager
Black Expires - April 2004 [Page 5]
URI Scheme for SNMP October 2003
or Application SHOULD first determine whether it has knowledge of
the MIB that is specified by or contains the OID and then proceed
to access management information in an appropriate fashion based
on that knowledge. There may be security consequences as a result
of disregarding the "SHOULD" and "SHOULD NOT" requirements in this
paragraph.
Similar concerns apply when the engine is omitted from an SNMP
object URI. It is only safe to omit the engine when the SNMP
agent at the specified host and port supports at most one SNMP
engine; in this case the SNMP object URI specifies use of the one
engine instance (and an error will result if there is no engine
instance). Otherwise, an SNMP object URI without an engine
component is ambiguous and SHOULD NOT be used. In addition an
SNMP manager or application using an SNMP object URI that omitted
the engine SHOULD check for the existence of multiple engines at
the accessed Agent and SHOULD NOT proceed with SNMP operations
based on the URI if more than one engine exists. In contrast,
when the context is omitted, the default SNMP context, namely the
empty string ("") SHOULD be used. There may be interoperability
consequences (different information accessed by different users of
the same URI) as a result of disregarding the "SHOULD" and "SHOULD
NOT" requirements in this paragraph.
OPEN ISSUE: Allow engine and context wildcarding so an object URI
can specify all or a collection of instances of an object at an
Agent? This has some similarity to the ability of an LDAP URI to
specify a query, but could easily get out-of-hand. It might be
better not to do this until someone needs it, but reserving the
wildcarding syntax would be a good thing to do now?.
4. Examples
snmp://snmp.example.com
This example designates the SNMP Agent at UDP port 161 of host
snmp.example.com .
snmp://tester5@snmp.example.com:8161
This example designates the SNMP Agent at UDP port 8161 of host
snmp.example.com and indicates that the SNMP userName "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 an SNMP agent.
OPEN ISSUE: Need an example or two of SNMP object URIs.
Black Expires - April 2004 [Page 6]
URI Scheme for SNMP October 2003
5. 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 even read access to that
information and possibly even to encrypt it 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.
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. The 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 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. The individual MIB module
specifications, and especially their security considerations,
should be consulted for further information.
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 MIB modules. It is RECOMMENDED that implementers
consider the security features as provided by the SNMPv3 framework
(see [RFC 3410], 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.
Black Expires - April 2004 [Page 7]
URI Scheme for SNMP October 2003
OPEN ISSUE: Security concerns when SNMP Manager or Application
does not have MIB knowledge for MIB that contains the OID. Needs
text added here.
6. IANA Considerations
The IANA is asked to register the URL registration template found
in Appendix A in accordance with [RFC 2717].
The IANA is asked to reserve the "tcp.snmp" URI scheme prefix for
possible future specification of an SNMP over TCP URI scheme.
7. Normative References
[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 2396] Uniform Resource Identifiers (URI): Generic Syntax.
T. Berners-Lee, R. Fielding, L. Masinter. RFC 2396.
August 1998.
[RFC 2732] Format for Literal IPv6 Addresses in URL's. R. Hinden,
B. Carpenter, L. Masinter. RFC 2732. December 1999.
[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.
OPEN ISSUE: Not all referenced RFCs are here. They will be.
8. Informative References
Black Expires - April 2004 [Page 8]
URI Scheme for SNMP October 2003
[RFC 1738] Uniform Resource Locators (URL). T. Berners-Lee,
L. Masinter, M. McCahill. RFC 1738. December 1994.
[RFC 1900] Renumbering Needs Work. B. Carpenter, Y. Rekhter.
RFC 1900. February 1996.
[RFC 2026] The Internet Standards Process -- Revision 3.
S. Bradner. RFC 2026, BCP 9. October 1996.
[RFC 2717] Registration Procedures for URL Scheme Names. R. Petke,
I. King. RFC 2717. November 1999.
[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 3529] Using Extensible Markup Language-Remote Procedure
Calling (XML-RPC) in Blocks Extensible Exchange
Protocol (BEEP). W. Harold. RFC 3529. April 2003.
OPEN ISSUE: Not all referenced RFCs are here. They will be.
9. Acknowledgments
Significant portions of this text were adapted from Eliot Lear's
TFTP URI scheme specification (RFC 3617). The security
considerations text was adapted from the widely used security
considerations "boilerplate" for MIB modules.
10. Author's Addresses
David L. Black Keith McCloghrie
EMC Corporation Cisco Systems, Inc.
176 South Street 170 West Tasman Drive
Hopkinton, MA 01748 San Jose, CA USA 95134
Phone: +1 (508) 293-7953 Phone: +1 (408) 526-5260
Email: black_david@emc.com Email: kzm@cisco.com
Black Expires - April 2004 [Page 9]
URI Scheme for SNMP October 2003
Appendix A. Registration Template
OPEN ISSUE: Needs to be updated to register "snmp" and "udp.snmp".
OPEN ISSUE: Transport interoperability concerns.
URL scheme name: snmp
URL scheme syntax: Section 2
Character encoding considerations: Section 2
Intended usage: Section 1
Applications and/or protocols which use this scheme: SNMP, all
versions, see [RFC 3410] and [RFC 3584]
Interoperability considerations: Section 3.2
Security considerations: Section 5
Relevant publications: See [RFC 3410]
Contact: David L. Black, Section 10
Author/Change Controller: IESG
Black Expires - April 2004 [Page 10]
