idnits 2.17.1 draft-schoenw-snmp-discover-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 337. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 348. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 355. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 361. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 14, 2007) is 6221 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFCXXXX' is mentioned on line 242, but not defined ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) == Outdated reference: A later version (-14) exists of draft-ietf-isms-transport-security-model-03 Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Schoenwaelder 3 Internet-Draft Jacobs University Bremen 4 Intended status: Informational April 14, 2007 5 Expires: October 16, 2007 7 Simple Network Management Protocol (SNMP) EngineID Discovery 8 draft-schoenw-snmp-discover-02.txt 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on October 16, 2007. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2007). 39 Abstract 41 The third version of the Simple Network Management Protocol (SNMP) 42 assumes that a manager knows the identifier of a remote SNMP protocol 43 engine (the so called snmpEngineID) in order to retrieve or 44 manipulate objects maintained locally on the remote engine. This 45 document introduces a well-known localEngineID and a discovery 46 mechanism which can be used to learn the engine identifier of a 47 remote SNMP protocol engine. The proposed mechanism is independent 48 of the features provided by SNMP security models and may also be used 49 by other protocol interfaces providing access to managed objects. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 3. Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 3.1. Local EngineID . . . . . . . . . . . . . . . . . . . . . . 4 57 3.2. EngineID Discovery . . . . . . . . . . . . . . . . . . . . 5 58 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 59 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 60 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 7 61 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 62 7.1. Normative References . . . . . . . . . . . . . . . . . . . 7 63 7.2. Informative References . . . . . . . . . . . . . . . . . . 8 64 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8 65 Intellectual Property and Copyright Statements . . . . . . . . . . 9 67 1. Introduction 69 To retrieve or manipulate management information using the third 70 version of the Simple Network Management Protocol (SNMPv3) [RFC3410], 71 it is necessary to know the identifier of the remote SNMP protocol 72 engine, the so called snmpEngineID [RFC3411]. While an appropriate 73 engine identifier can in principle be provided by an operator, it is 74 often desirable to discover the engine identifier automatically. 76 This document introduces a discovery mechanism which can be used to 77 learn the engine identifier of a remote SNMP protocol engine. The 78 proposed mechanism is independent of the features provided by SNMP 79 security models and may be used also by other protocol interfaces to 80 discover the engine identifier. The mechanism has been designed to 81 co-exists with discovery mechanisms, which may exist in security 82 models, such as the authoritative engine identifier discovery of the 83 User-based Security Model (USM) of SNMP [RFC3414]. 85 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 86 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 87 document are to be interpreted as described in RFC 2119 [RFC2119]. 89 2. Background 91 Within an administrative domain, an SNMP engine is uniquely 92 identified by an snmpEngineID value [RFC3411]. An SNMP entity, which 93 consists of an SNMP engine and several SNMP applications, may provide 94 access to multiple contexts. 96 An SNMP context is a collection of management information accessible 97 by an SNMP entity. An item of management information may exist in 98 more than one context and an SNMP entity potentially has access to 99 many contexts [RFC3411]. A context is identified by the snmpEngineID 100 value of the entity hosting the management information (called a 101 contextEngineID) and a context name which identifies the specific 102 context (called a contextName). 104 To identify an individual item of management information within an 105 administrative domain, a four tuple is used consisting of 107 1. a contextEngineID, 108 2. a contextName, 109 3. an object type, and 110 4. its instance identification. 112 The last two elements are encoded in an object identifier (OID) 113 value. The contextName is a string while the contextEngineID is a 114 binary value constructed according to the rules defined as part of 115 the SnmpEngineID textual convention of the SNMP-FRAMEWORK-MIB 116 [RFC3411]. 118 The SNMP protocol operations and the protocol data units (PDUs) 119 operate on OIDs and thus deal with object types and instances 120 [RFC3416]. The SNMP architecture [RFC3411] introduces the concept of 121 a scopedPDU as a data structure containing a contextEngineID, a 122 contextName, and a PDU. The SNMP version 3 (SNMPv3) message format 123 uses ScopedPDUs to exchange management information [RFC3412]. 125 Within the SNMP framework, contextEngineIDs serve as end-to-end 126 identifiers. This becomes important in situations where SNMP proxies 127 are deployed to translate between protocol versions or to cross 128 middleboxes such as network address translators. In addition, 129 snmpEngineIDs separate the identification of an SNMP engine from the 130 transport endpoints used to communicate with an SNMP engine. This 131 property allows to correlate management information easily even in 132 situations where multiple different transports were used to retrieve 133 the information or where transport endpoints can change dynamically. 135 To retrieve data from an SNMPv3 agent, it is necessary to know the 136 appropriate contextEngineID. The User-based Security Model (USM) of 137 SNMPv3 provides a mechanism to discover the snmpEngineID of the 138 remote SNMP engine since this is needed for security processing 139 reasons. The discovered snmpEngineID can subsequently be used as a 140 contextEngineID in a ScopedPDU to access management information local 141 to the remote SNMP engine. Other security models, such as the 142 Transport Security Model (TSM) [I-D.TSM], lack such a procedure and 143 may use the discovery mechanism defined in this memo. 145 3. Procedure 147 The proposed discovery mechanism consists of two parts, namely (i) 148 the definition of a special well-known snmpEngineID value, called the 149 localEngineID, which always refers to a local context, and (ii) the 150 definition of a procedure to acquire the snmpEngineID scalar of the 151 SNMP-FRAMEWORK-MIB [RFC3411] using the special well-known local 152 localEngineID value. 154 3.1. Local EngineID 156 SNMP command responder implementing this specification MUST register 157 their main local context using the localEngineID snmpEngineID value 158 (defined below) using the registerContextEngineID() Abstract Service 159 Interface (ASI) defined in RFC 3412 [RFC3412]. This registration is 160 done in addition to the normal registration under the SNMP engine's 161 snmpEngineID. This is consistent with the SNMPv3 specifications 162 since they explicitly allow to register management information in 163 multiple contexts [RFC3412]. 165 The SnmpEngineID textual convention defines that an snmpEngineID 166 value MUST be between 5 and 12 octets long. This specification 167 proposes to use the variable length format 3) and to allocate the 168 reserved, unused format value 6 using the enterprise ID 0 for the 169 localEngineID. An ASN.1 definition for localEngineID would look like 170 this: 172 localEngineID OCTET STRING ::= '8000000006'H 174 The localEngineID value always provides access to the main local 175 context of an SNMP engine. 177 3.2. EngineID Discovery 179 Discovery of the snmpEngineID is simply done by sending a Read Class 180 protocol operation (see section 2.8 of [RFC3411] to retrieve the 181 snmpEngineID scalar using the localEngineID defined above as a 182 contextEngineID value. Implementations SHOULD only perform this 183 discovery step when it is needed. In particular, if security models 184 are used that already discover the remote snmpEngineID (such as USM), 185 then no further discovery is necessary. The same is true in 186 situations where the application already supplies a suitable 187 snmpEngineID value (e.g., in proxy situations). 189 The procedure to discover the snmpEngineID of a remote SNMP engine 190 can be described as follows: 192 1) Check whether the application provided a contextEngineID value to 193 be used. If yes, use the provided contextEngineID value and stop the 194 discovery procedure. 196 2) Check whether the selected security model supports discovery of 197 the remote snmpEngineID (e.g., USM with its discovery mechanism). If 198 yes, let the security model perform the discovery. If the remote 199 snmpEngineID value has been successfully determined, assign it to the 200 contextEngineID and stop the discovery procedure. 202 3) Send a Read Class operation to the remote SNMP engine using the 203 localEngineID value as the contextEngineID in order to retrieve the 204 scalar snmpEngineID.0 of the SNMP-FRAMEWORK-MIB [RFC3411]. If 205 successful, set the contextEngineID to the retrieved value and stop 206 the discovery procedure. 208 4) Return an error indication that a suitable contextEngineID could 209 not be discovered. 211 The procedure outlined above is exemplary and can be modified to 212 retrieve more variables in step 3), such as the sysObjectID.0 scalar 213 or the snmpSetSerialNo.0 scalar of the SNMPv2-MIB [RFC3418]. 215 4. IANA Considerations 217 IANA has to create a registry for SnmpEngineID formats. The first 218 four ctets of an SnmpEngineID carry an enterprise number while the 219 fifth octet in a variable length SnmpEngineID value, called the 220 format octet, indicates how the following octets are formed. The 221 following format values were defined in [RFC3411]: 223 Format Description References 224 ------- ----------- ---------- 225 0 reserved, unused [RFC3411] 226 1 IPv4 address [RFC3411] 227 2 IPv6 address [RFC3411] 228 3 MAC address [RFC3411] 229 4 administratively assigned text [RFC3411] 230 5 administratively assigned octets [RFC3411] 231 6-127 reserved, unused [RFC3411] 232 128-255 enterprise specific [RFC3411] 234 IANA has to create a registry to assign new format values out of the 235 originally reserved number space 6-127. For new assignments, a 236 specification is required as per [RFC2434]. 238 This document requested the following assignment: 240 Format Description References 241 ------- ----------- ---------- 242 6 local engine [RFCXXXX] 244 5. Security Considerations 246 SNMP version 3 (SNMPv3) provides cryptographic security to protect 247 devices from unauthorized access. This specification recommends to 248 use the security services provided by SNMPv3. In particular, it is 249 recommended to use the security services provided by an SNMP security 250 model to protect the discovery exchange. 252 In situations where SNMPv3 is used without security (i.e., the 253 security level of noAuthNoPriv is used), the introduction of a 254 localEngineID may make it slightly easier for an attacker to discover 255 suitable snmpEngineID values. However, since SNMP messages with a 256 security level of noAuthNoPriv are normally carried in clear-text 257 over the wire, it is usually easy for an attacker to discover a 258 contextEngineID by sniffing on the wire and any attempts to keep the 259 snmpEngineIDs private won't lead to strong security. The usage of 260 SNMPv3 without security is therefore generally not recommended. 262 6. Acknowledgments 264 Dave Perkins suggested to introduce a "local" contextEngineID during 265 the interim meeting of the ISMS working group in Boston, 2006. Joe 266 Fernandez and David Harrington provided helpful review and feedback, 267 which helped to improve this document. 269 7. References 271 7.1. Normative References 273 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 274 Requirement Levels", BCP 14, March 1997. 276 [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An 277 Architecture for Describing Simple Network Management 278 Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, 279 December 2002. 281 [RFC3412] Case, J., Harrington, D., Presuhn, R., and B. Wijnen, 282 "Message Processing and Dispatching for the Simple Network 283 Management Protocol (SNMP)", STD 62, RFC 3412, 284 December 2002. 286 [RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model 287 (USM) for version 3 of the Simple Network Management 288 Protocol (SNMPv3)", STD 62, RFC 3414, December 2002. 290 [RFC3416] Presuhn, R., "Version 2 of the Protocol Operations for the 291 Simple Network Management Protocol (SNMP)", STD 62, 292 RFC 3416, December 2002. 294 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 295 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 296 October 1998. 298 7.2. Informative References 300 [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, 301 "Introduction and Applicability Statements for Internet- 302 Standard Management Framework", RFC 3410, December 2002. 304 [RFC3418] Presuhn, R., "Management Information Base (MIB) for the 305 Simple Network Management Protocol (SNMP)", STD 62, 306 RFC 3418, December 2002. 308 [I-D.TSM] Harrington, D., "Transport Security Model for SNMP", 309 draft-ietf-isms-transport-security-model-03.txt (work in 310 progress), February 2007. 312 Author's Address 314 Juergen Schoenwaelder 315 Jacobs University Bremen 316 Campus Ring 1 317 28725 Bremen 318 Germany 320 Phone: +49 421 200-3587 321 Email: j.schoenwaelder@iu-bremen.de 323 Full Copyright Statement 325 Copyright (C) The IETF Trust (2007). 327 This document is subject to the rights, licenses and restrictions 328 contained in BCP 78, and except as set forth therein, the authors 329 retain all their rights. 331 This document and the information contained herein are provided on an 332 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 333 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 334 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 335 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 336 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 337 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 339 Intellectual Property 341 The IETF takes no position regarding the validity or scope of any 342 Intellectual Property Rights or other rights that might be claimed to 343 pertain to the implementation or use of the technology described in 344 this document or the extent to which any license under such rights 345 might or might not be available; nor does it represent that it has 346 made any independent effort to identify any such rights. Information 347 on the procedures with respect to rights in RFC documents can be 348 found in BCP 78 and BCP 79. 350 Copies of IPR disclosures made to the IETF Secretariat and any 351 assurances of licenses to be made available, or the result of an 352 attempt made to obtain a general license or permission for the use of 353 such proprietary rights by implementers or users of this 354 specification can be obtained from the IETF on-line IPR repository at 355 http://www.ietf.org/ipr. 357 The IETF invites any interested party to bring to its attention any 358 copyrights, patents or patent applications, or other proprietary 359 rights that may cover technology that may be required to implement 360 this standard. Please address the information to the IETF at 361 ietf-ipr@ietf.org. 363 Acknowledgment 365 Funding for the RFC Editor function is provided by the IETF 366 Administrative Support Activity (IASA).