URI Scheme for SNMP August 2003 Network Working Group D.Black Internet Draft EMC Corporation Document: draft-black-snmp-uri-00.txt K. McCloghrie Expires: February 2004 Cisco Systems August 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. 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]. Black Expires - February 2004 [Page 1] URI Scheme for SNMP August 2003 Table of Contents 1. Introduction...................................................2 2. Syntax of an SNMP URI..........................................2 3. Semantics and Operations.......................................3 4. Examples.......................................................3 5. Security Considerations........................................4 6. IANA Considerations............................................5 7. Normative References...........................................5 8. Informative References.........................................5 9. Acknowledgments................................................6 10. Author's Addresses............................................6 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. 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 a URI scheme to permit SNMP to be designated as the management protocol by such a URL. 2. Syntax of an SNMP URI An SNMP URI has the following ABNF [RFC 2234] syntax: snmp_URI = "snmp:" "//" [ user "@" ] host [ ":" port ] user = // userName as specified by [RFC 3414] host = // as specified by [RFC 2396] and [RFC 2732] port = // as specified by [RFC 2396] If the user is empty or not given, the recipient of this URI is expected to already know what 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. 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 Black Expires - February 2004 [Page 2] URI Scheme for SNMP August 2003 be avoided; otherwise IP addresses should not be used (see [RFC 1900] for further explanation). Although SNMP can be encapsulated over transports other than UDP, the SNMP URI scheme designates SNMP over UDP [RFC 3417]. There is existing usage of the "snmp:" prefix as designating SNMP over UDP that would break if a syntax like that for the BEEP URI schemes (e.g., "xmlrpc.beep" [RFC 3529]) were required; URI schemes for other transport encapsulations of SNMP may wish to adopt an approach of prefixing "snmp" with the underlying protocol and a period (e.g., "tcp.snmp:" for the experimental use of SNMP over TCP [RFC 3430]). Also, "snmp:" is specified in the SNMP URI scheme rather than "snmpv3:" for backwards compatibility with existing usage as well as for forwards compatibility with any possible future successor to SNMPv3. 3. Semantics and Operations An SNMP 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 a location designated by an SNMP URI is to use an SNMP Manager to access the SNMP Agent at that location. Further designation of the specific management object or objects to be accessed is not supported by the SNMP URI scheme because existing SNMP techniques are more than adequate to determine what SNMP management objects of interest to an SNMP Manager are exported by an SNMP Agent. An SNMP URI designates use of SNMPv3 over UDP 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]. 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. Black Expires - February 2004 [Page 3] URI Scheme for SNMP August 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 - February 2004 [Page 4] URI Scheme for SNMP August 2003 6. IANA Considerations The IANA is asked to register the URL registration template found in Appendix A in accordance with [RFC 2717]. 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. 8. Informative References [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. Black Expires - February 2004 [Page 5] URI Scheme for SNMP August 2003 [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. 9. Acknowledgments Significant portions of this text were adapted from Eliot Lear's TFTP URI scheme specification. 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 Appendix A. Registration Template 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: None Security considerations: Section 5 Relevant publications: See [RFC 3410] Contact: David L. Black, Section 10 Author/Change Controller: IESG Black Expires - February 2004 [Page 6]