From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc4088.txt | 1011 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 1011 insertions(+) create mode 100644 doc/rfc/rfc4088.txt (limited to 'doc/rfc/rfc4088.txt') diff --git a/doc/rfc/rfc4088.txt b/doc/rfc/rfc4088.txt new file mode 100644 index 0000000..6a4964c --- /dev/null +++ b/doc/rfc/rfc4088.txt @@ -0,0 +1,1011 @@ + + + + + + +Network Working Group D. Black +Request for Comments: 4088 EMC Corporation +Category: Standards Track K. McCloghrie + Cisco Systems + J. Schoenwaelder + International University Bremen + June 2005 + + + Uniform Resource Identifier (URI) Scheme for the + Simple Network Management Protocol (SNMP) + +Status of This Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2005). + +Abstract + + The Simple Network Management Protocol (SNMP) and the Internet + Standard Management Framework are widely used for the management of + communication devices, creating a need 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), a uniform way to indicate how to + contact the device for management is needed. Uniform Resource + Identifiers (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. + + 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. + + + + + + + + + + +Black, et al. Standards Track [Page 1] + +RFC 4088 URI Scheme for SNMP June 2005 + + +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. Normative References.......................................... 14 + 9. Informative References........................................ 15 + 10. Acknowledgements............................................. 16 + Appendix A. Registration Template................................ 17 + +1. Introduction + + SNMP and the Internet-Standard Management Framework were originally + devised to manage IP devices via in-band means, in which 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 for + managing 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. + + For a detailed overview of the documents that describe the current + Internet-Standard Management Framework, please refer to Section 7 of + [RFC3410]. + + 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 [RFC2119]. + + + + + + +Black, et al. Standards Track [Page 2] + +RFC 4088 URI Scheme for SNMP June 2005 + + +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 the 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 it 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 ------------+ + + Additional configuration information (e.g., security secrets or keys) + may be provided via an interface other than that used for the URI. + For example, some types of security information, including secrets + + + +Black, et al. Standards Track [Page 3] + +RFC 4088 URI Scheme for SNMP June 2005 + + + and keys, should be pre-configured in or pre-authorized to the + manager rather than be provided by the client; see Section 6. + +3. Syntax of an SNMP URI + + An SNMP URI has the following ABNF [RFC2234] syntax, based on the + ABNF syntax rules for userinfo, host, port, and (path) segment in + [RFC3986] and the ABNF syntax rule for HEXDIG in [RFC2234]: + + 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 [RFC3986]. See [RFC3411] for the semantics of + securityName, contextEngineID, and contextName. + + The snmp-authority syntax matches the URI authority syntax in Section + 3.2 of [RFC3986], with the additional restriction that the userinfo + component of an authority (when present) 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 + [RFC3986]), 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 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 + + + +Black, et al. Standards Track [Page 4] + +RFC 4088 URI Scheme for SNMP June 2005 + + + 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 [RFC3986] 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 + [RFC3986] 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 [RFC3986]. These requirements + are a consequence of reusing the ABNF syntax rules for userinfo and + segment from [RFC3986]. + + 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 [RFC3986]) 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 [RFC1900] + 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, such as the + following: + + snmp://// + + This is allowed by [RFC3986] 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 [RFC3986]) because a "//" at the start of a relative reference + always introduces a URI authority component (host plus optional + userinfo and/or port; see [RFC3986]). Specifically, a relative + + + +Black, et al. Standards Track [Page 5] + +RFC 4088 URI Scheme for SNMP June 2005 + + + reference of the form // will not work, because the "//" will + cause to be parsed as a URI authority, resulting in a syntax + error when the parser fails to find a host in . 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., ..//). + 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 + [RFC1738] 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 SNMP proxy agents, + which are 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, et al. Standards Track [Page 6] + +RFC 4088 URI Scheme for SNMP June 2005 + + +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 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 as follows: + + (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 operation, + + + +Black, et al. Standards Track [Page 7] + +RFC 4088 URI Scheme for SNMP June 2005 + + + 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., ./) 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 an 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 [RFC3416]). + 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, et al. Standards Track [Page 8] + +RFC 4088 URI Scheme for SNMP June 2005 + + + (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 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, et al. Standards Track [Page 9] + +RFC 4088 URI Scheme for SNMP June 2005 + + +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., ./.* ) 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 + + + +Black, et al. Standards Track [Page 10] + +RFC 4088 URI Scheme for SNMP June 2005 + + + 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 + + + +Black, et al. Standards Track [Page 11] + +RFC 4088 URI Scheme for SNMP June 2005 + + + 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. + + + + + +Black, et al. Standards Track [Page 12] + +RFC 4088 URI Scheme for SNMP June 2005 + + + 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 + + + +Black, et al. Standards Track [Page 13] + +RFC 4088 URI Scheme for SNMP June 2005 + + + 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. + + + +Black, et al. Standards Track [Page 14] + +RFC 4088 URI Scheme for SNMP June 2005 + + + [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. + + + + + + + + + + + + +Black, et al. Standards Track [Page 15] + +RFC 4088 URI Scheme for SNMP June 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. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Black, et al. Standards Track [Page 16] + +RFC 4088 URI Scheme for SNMP June 2005 + + +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 + + + + + + + +Black, et al. Standards Track [Page 17] + +RFC 4088 URI Scheme for SNMP June 2005 + + +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. + + + + + + + +Black, et al. Standards Track [Page 18] + -- cgit v1.2.3