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/rfc5343.txt | 507 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 507 insertions(+) create mode 100644 doc/rfc/rfc5343.txt (limited to 'doc/rfc/rfc5343.txt') diff --git a/doc/rfc/rfc5343.txt b/doc/rfc/rfc5343.txt new file mode 100644 index 0000000..4cda944 --- /dev/null +++ b/doc/rfc/rfc5343.txt @@ -0,0 +1,507 @@ + + + + + + +Network Working Group J. Schoenwaelder +Request for Comments: 5343 Jacobs University Bremen +Updates: 3411 September 2008 +Category: Standards Track + + + Simple Network Management Protocol (SNMP) Context EngineID Discovery + +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. + +Abstract + + The Simple Network Management Protocol (SNMP) version three (SNMPv3) + requires that an application know the identifier (snmpEngineID) of + the remote SNMP protocol engine in order to retrieve or manipulate + objects maintained on the remote SNMP entity. + + This document introduces a well-known localEngineID and a discovery + mechanism that can be used to learn the snmpEngineID of a remote SNMP + protocol engine. The proposed mechanism is independent of the + features provided by SNMP security models and may also be used by + other protocol interfaces providing access to managed objects. + + This document updates RFC 3411. + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 + 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 2 + 3. Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 3.1. Local EngineID . . . . . . . . . . . . . . . . . . . . . . 4 + 3.2. EngineID Discovery . . . . . . . . . . . . . . . . . . . . 4 + 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 + 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 + 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 7 + 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 + 7.1. Normative References . . . . . . . . . . . . . . . . . . . 7 + 7.2. Informative References . . . . . . . . . . . . . . . . . . 7 + + + + + + + +Schoenwaelder Standards Track [Page 1] + +RFC 5343 SNMP Context EngineID Discovery September 2008 + + +1. Introduction + + To retrieve or manipulate management information using the third + version of the Simple Network Management Protocol (SNMPv3) [RFC3410], + it is necessary to know the identifier of the remote SNMP protocol + engine, the so-called snmpEngineID [RFC3411]. While an appropriate + snmpEngineID can in principle be configured on each management + application for each SNMP agent, it is often desirable to discover + the snmpEngineID automatically. + + This document introduces a discovery mechanism that can be used to + learn the snmpEngineID of a remote SNMP protocol engine. The + proposed mechanism is independent of the features provided by SNMP + security models. The mechanism has been designed to coexist with + discovery mechanisms that may exist in SNMP security models, such as + the authoritative engine identifier discovery of the User-based + Security Model (USM) of SNMP [RFC3414]. + + This document updates RFC 3411 [RFC3411] by clarifying the IANA rules + for the maintenance of the SnmpEngineID format registry. + + 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 [RFC2119]. + +2. Background + + Within an administrative domain, an SNMP engine is uniquely + identified by an snmpEngineID value [RFC3411]. An SNMP entity, which + consists of an SNMP engine and several SNMP applications, may provide + access to multiple contexts. + + An SNMP context is a collection of management information accessible + by an SNMP entity. An item of management information may exist in + more than one context and an SNMP entity potentially has access to + many contexts [RFC3411]. A context is identified by the snmpEngineID + value of the entity hosting the management information (also called a + contextEngineID) and a context name that identifies the specific + context (also called a contextName). + + To identify an individual item of management information within an + administrative domain, a four tuple is used consisting of + + 1. a contextEngineID, + + 2. a contextName, + + + + + +Schoenwaelder Standards Track [Page 2] + +RFC 5343 SNMP Context EngineID Discovery September 2008 + + + 3. an object type, and + + 4. its instance identification. + + The last two elements are encoded in an object identifier (OID) + value. The contextName is a character string (following the + SnmpAdminString textual convention of the SNMP-FRAMEWORK-MIB + [RFC3411]) while the contextEngineID is an octet string constructed + according to the rules defined as part of the SnmpEngineID textual + convention of the SNMP-FRAMEWORK-MIB [RFC3411]. + + The SNMP protocol operations and the protocol data units (PDUs) + operate on OIDs and thus deal with object types and instances + [RFC3416]. The SNMP architecture [RFC3411] introduces the concept of + a scopedPDU as a data structure containing a contextEngineID, a + contextName, and a PDU. The SNMP version 3 (SNMPv3) message format + uses ScopedPDUs to exchange management information [RFC3412]. + + Within the SNMP framework, contextEngineIDs serve as end-to-end + identifiers. This becomes important in situations where SNMP proxies + are deployed to translate between protocol versions or to cross + middleboxes such as network address translators. In addition, + snmpEngineIDs separate the identification of an SNMP engine from the + transport addresses used to communicate with an SNMP engine. This + property can be used to correlate management information easily, even + in situations where multiple different transports were used to + retrieve the information or where transport addresses can change + dynamically. + + To retrieve data from an SNMPv3 agent, it is necessary to know the + appropriate contextEngineID. The User-based Security Model (USM) of + SNMPv3 provides a mechanism to discover the snmpEngineID of the + remote SNMP engine, since this is needed for security processing + reasons. The discovered snmpEngineID can subsequently be used as a + contextEngineID in a ScopedPDU to access management information local + to the remote SNMP engine. Other security models, such as the + Transport Security Model (TSM) [TSM], lack such a procedure and may + use the discovery mechanism defined in this memo. + +3. Procedure + + The proposed discovery mechanism consists of two parts, namely (i) + the definition of a special well-known snmpEngineID value, called the + localEngineID, which always refers to a local default context, and + (ii) the definition of a procedure to acquire the snmpEngineID scalar + of the SNMP-FRAMEWORK-MIB [RFC3411] using the special well-known + local localEngineID value. + + + + +Schoenwaelder Standards Track [Page 3] + +RFC 5343 SNMP Context EngineID Discovery September 2008 + + +3.1. Local EngineID + + An SNMP command responder implementing this specification MUST + register their pduTypes using the localEngineID snmpEngineID value + (defined below) by invoking the registerContextEngineID() Abstract + Service Interface (ASI) defined in RFC 3412 [RFC3412]. This + registration is done in addition to the normal registration under the + SNMP engine's snmpEngineID. This is consistent with the SNMPv3 + specifications since they explicitly allow registration of multiple + engineIDs and multiple pduTypes [RFC3412]. + + The SnmpEngineID textual convention [RFC3411] defines that an + snmpEngineID value MUST be between 5 and 32 octets long. This + specification proposes to use the variable length format 3) of the + SnmpEngineID textual convention and to allocate the reserved, unused + format value 6, using the enterprise ID 0 for the localEngineID. An + ASN.1 definition for localEngineID would look like this: + + localEngineID OCTET STRING ::= '8000000006'H + + The localEngineID value always provides access to the default context + of an SNMP engine. Note that the localEngineID value is intended to + be used as a special value for the contextEngineID field in the + ScopedPDU. It MUST NOT be used as a value to identify an SNMP + engine; that is, this value MUST NOT be used in the snmpEngineID.0 + scalar [RFC3418] or in the msgAuthoritativeEngineID field in the + securityParameters of the User-based Security Model (USM) [RFC3414]. + +3.2. EngineID Discovery + + Discovery of the snmpEngineID is done by sending a Read Class + protocol operation (see Section 2.8 of [RFC3411]) to retrieve the + snmpEngineID scalar using the localEngineID defined above as a + contextEngineID value. Implementations SHOULD only perform this + discovery step when it is needed. In particular, if security models + are used that already discover the remote snmpEngineID (such as USM), + then no further discovery is necessary. The same is true in + situations where the application already knows a suitable + snmpEngineID value. + + The procedure to discover the snmpEngineID of a remote SNMP engine + can be described as follows: + + 1. Check whether a suitable contextEngineID value is already known. + If yes, use the provided contextEngineID value and stop the + discovery procedure. + + + + + +Schoenwaelder Standards Track [Page 4] + +RFC 5343 SNMP Context EngineID Discovery September 2008 + + + 2. Check whether the selected security model supports discovery of + the remote snmpEngineID (e.g., USM with its discovery mechanism). + If yes, let the security model perform the discovery. If the + remote snmpEngineID value has been successfully determined, + assign it to the contextEngineID and stop the discovery + procedure. + + 3. Send a Read Class operation to the remote SNMP engine using the + localEngineID value as the contextEngineID in order to retrieve + the scalar snmpEngineID.0 of the SNMP-FRAMEWORK-MIB [RFC3411]. + If successful, set the contextEngineID to the retrieved value and + stop the discovery procedure. + + 4. Return an error indication that a suitable contextEngineID could + not be discovered. + + The procedure outlined above is an example and can be modified to + retrieve more variables in step 3, such as the sysObjectID.0 scalar + or the snmpSetSerialNo.0 scalar of the SNMPv2-MIB [RFC3418]. + +4. IANA Considerations + + RFC 3411 requested that IANA create a registry for SnmpEngineID + formats. However, RFC 3411 did not ask IANA to record the initial + assignments made by RFC 3411 nor did RFC 3411 spell out the precise + allocation rules. To address this issue, the following rules are + hereby established. + + IANA maintains a registry for SnmpEngineID formats. The first four + octets of an SnmpEngineID carry an enterprise number, while the fifth + octet in a variable length SnmpEngineID value, called the format + octet, indicates how the following octets are formed. The following + format values were allocated in [RFC3411]: + + Format Description References + ------- ----------- ---------- + 0 reserved, unused [RFC3411] + 1 IPv4 address [RFC3411] + 2 IPv6 address [RFC3411] + 3 MAC address [RFC3411] + 4 administratively assigned text [RFC3411] + 5 administratively assigned octets [RFC3411] + 6-127 reserved, unused [RFC3411] + 128-255 enterprise specific [RFC3411] + + IANA can assign new format values out of the originally assigned and + reserved number space 1-127. For new assignments in this number + + + + +Schoenwaelder Standards Track [Page 5] + +RFC 5343 SNMP Context EngineID Discovery September 2008 + + + space, a specification is required as per [RFC5226]. The number + space 128-255 is enterprise specific and is not controlled by IANA. + + Per this document, IANA has made the following assignment: + + Format Description References + ------- ----------- ---------- + 6 local engine [RFC5343] + +5. Security Considerations + + SNMP version 3 (SNMPv3) provides cryptographic security to protect + devices from unauthorized access. This specification recommends use + of the security services provided by SNMPv3. In particular, it is + RECOMMENDED to protect the discovery exchange. + + An snmpEngineID can contain information such as a device's MAC + address, IPv4 address, IPv6 address, or administratively assigned + text. An attacker located behind a router / firewall / network + address translator may not be able to obtain this information + directly, and he therefore might discover snmpEngineID values in + order to obtain this kind of device information. + + In many environments, making snmpEngineID values accessible via a + security level of noAuthNoPriv will benefit legitimate tools that try + to algorithmically determine some basic information about a device. + For this reason, the default View-based Access Control Model (VACM) + configuration in Appendix A of RFC 3415 [RFC3415] gives noAuthNoPriv + read access to the snmpEngineID. Furthermore, the USM discovery + mechanism defined in RFC 3414 [RFC3414] uses unprotected messages and + reveals snmpEngineID values. + + In highly secure environments, snmpEngineID values can be protected + by using the discovery mechanism described in this document together + with a security model that does not exchange cleartext SNMP messages, + such as the Transport Security Model (TSM) [TSM]. + + The isAccessAllowed() abstract service primitive of the SNMP access + control subsystem does not take the contextEngineID into account when + checking access rights [RFC3411]. As a consequence, it is not + possible to define a special view for context engineID discovery. A + request with a localEngineID is thus treated like a request with the + correct snmpEngineID by the access control subsystem. This is inline + with the SNMPv3 design where the authenticated identity is the + securityName (together with the securityModel and securityLevel + information), and transport addresses or knowledge of contextEngineID + values do not impact the access-control decision. + + + + +Schoenwaelder Standards Track [Page 6] + +RFC 5343 SNMP Context EngineID Discovery September 2008 + + +6. Acknowledgments + + Dave Perkins suggested the introduction of a "local" contextEngineID + during the interim meeting of the ISMS (Integrated Security Model for + SNMP) working group in Boston, 2006. Joe Fernandez, David + Harrington, Dan Romascanu, and Bert Wijnen provided helpful review + and feedback, which helped to improve this document. + +7. References + +7.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [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. + + [RFC3412] Case, J., Harrington, D., Presuhn, R., and B. Wijnen, + "Message Processing and Dispatching for the Simple Network + Management Protocol (SNMP)", STD 62, RFC 3412, + December 2002. + + [RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model + (USM) for version 3 of the Simple Network Management + Protocol (SNMPv3)", STD 62, RFC 3414, December 2002. + + [RFC3416] Presuhn, R., "Version 2 of the Protocol Operations for the + Simple Network Management Protocol (SNMP)", STD 62, + RFC 3416, December 2002. + + [RFC3418] Presuhn, R., "Management Information Base (MIB) for the + Simple Network Management Protocol (SNMP)", STD 62, + RFC 3418, December 2002. + + [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an + IANA Considerations Section in RFCs", BCP 26, RFC 5226, + May 2008. + +7.2. Informative References + + [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, + "Introduction and Applicability Statements for Internet- + Standard Management Framework", RFC 3410, December 2002. + + + + + +Schoenwaelder Standards Track [Page 7] + +RFC 5343 SNMP Context EngineID Discovery September 2008 + + + [RFC3415] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based + Access Control Model (VACM) for the Simple Network + Management Protocol (SNMP)", STD 62, RFC 3415, + December 2002. + + [TSM] Harrington, D., "Transport Security Model for SNMP", Work + in Progress, July 2008. + +Author's Address + + Juergen Schoenwaelder + Jacobs University Bremen + Campus Ring 1 + 28725 Bremen + Germany + + Phone: +49 421 200-3587 + EMail: j.schoenwaelder@jacobs-university.de + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Schoenwaelder Standards Track [Page 8] + +RFC 5343 SNMP Context EngineID Discovery September 2008 + + +Full Copyright Statement + + Copyright (C) The IETF Trust (2008). + + 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, THE IETF TRUST 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. + + + + + + + + + + + + +Schoenwaelder Standards Track [Page 9] + -- cgit v1.2.3