idnits 2.17.1 draft-ietf-opsawg-snmp-engineid-discovery-01.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 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 362. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 373. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 380. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 386. 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 use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. (Using the creation date from RFC3411, updated by this document, for RFC5378 checks: 2001-02-27) -- 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 (January 21, 2008) is 5940 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFCXXXX' is mentioned on line 247, 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-07 Summary: 2 errors (**), 0 flaws (~~), 4 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 Updates: 3411 (if approved) January 21, 2008 5 Intended status: Standards Track 6 Expires: July 24, 2008 8 Simple Network Management Protocol (SNMP) Context EngineID Discovery 9 draft-ietf-opsawg-snmp-engineid-discovery-01.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on July 24, 2008. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2008). 40 Abstract 42 The Simple Network Management Protocol (SNMP) version three (SNMPv3) 43 requires that an application knows the identifier (snmpEngineID) of 44 the remote SNMP protocol engine in order to retrieve or manipulate 45 objects maintained on the remote SNMP entity. 47 This document introduces a well-known localEngineID and a discovery 48 mechanism which can be used to learn the snmpEngineID of a remote 49 SNMP protocol engine. The proposed mechanism is independent of the 50 features provided by SNMP security models and may also be used by 51 other protocol interfaces providing access to managed objects. 53 This document updates RFC 3411. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 3. Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 3.1. Local EngineID . . . . . . . . . . . . . . . . . . . . . . 4 61 3.2. EngineID Discovery . . . . . . . . . . . . . . . . . . . . 5 62 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 63 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 64 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 7 65 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 66 7.1. Normative References . . . . . . . . . . . . . . . . . . . 7 67 7.2. Informative References . . . . . . . . . . . . . . . . . . 8 68 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8 69 Intellectual Property and Copyright Statements . . . . . . . . . . 9 71 1. Introduction 73 To retrieve or manipulate management information using the third 74 version of the Simple Network Management Protocol (SNMPv3) [RFC3410], 75 it is necessary to know the identifier of the remote SNMP protocol 76 engine, the so called snmpEngineID [RFC3411]. While an appropriate 77 snmpEngineID can in principle be configured on each management 78 application for each SNMP agent, it is often desirable to discover 79 the snmpEngineID automatically. 81 This document introduces a discovery mechanism which can be used to 82 learn the snmpEngineID of a remote SNMP protocol engine. The 83 proposed mechanism is independent of the features provided by SNMP 84 security models. The mechanism has been designed to co-exist with 85 discovery mechanisms that may exist in SNMP security models, such as 86 the authoritative engine identifier discovery of the User-based 87 Security Model (USM) of SNMP [RFC3414]. 89 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 90 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 91 document are to be interpreted as described in RFC 2119 [RFC2119]. 93 2. Background 95 Within an administrative domain, an SNMP engine is uniquely 96 identified by an snmpEngineID value [RFC3411]. An SNMP entity, which 97 consists of an SNMP engine and several SNMP applications, may provide 98 access to multiple contexts. 100 An SNMP context is a collection of management information accessible 101 by an SNMP entity. An item of management information may exist in 102 more than one context and an SNMP entity potentially has access to 103 many contexts [RFC3411]. A context is identified by the snmpEngineID 104 value of the entity hosting the management information (also called a 105 contextEngineID) and a context name which identifies the specific 106 context (also called a contextName). 108 To identify an individual item of management information within an 109 administrative domain, a four tuple is used consisting of 111 1. a contextEngineID, 112 2. a contextName, 113 3. an object type, and 114 4. its instance identification. 116 The last two elements are encoded in an object identifier (OID) 117 value. The contextName is a character string (following the 118 SnmpAdminString textual convention of the SNMP-FRAMEWORK-MIB 119 [RFC3411]) while the contextEngineID is an octet string constructed 120 according to the rules defined as part of the SnmpEngineID textual 121 convention of the SNMP-FRAMEWORK-MIB [RFC3411]. 123 The SNMP protocol operations and the protocol data units (PDUs) 124 operate on OIDs and thus deal with object types and instances 125 [RFC3416]. The SNMP architecture [RFC3411] introduces the concept of 126 a scopedPDU as a data structure containing a contextEngineID, a 127 contextName, and a PDU. The SNMP version 3 (SNMPv3) message format 128 uses ScopedPDUs to exchange management information [RFC3412]. 130 Within the SNMP framework, contextEngineIDs serve as end-to-end 131 identifiers. This becomes important in situations where SNMP proxies 132 are deployed to translate between protocol versions or to cross 133 middleboxes such as network address translators. In addition, 134 snmpEngineIDs separate the identification of an SNMP engine from the 135 transport addresses used to communicate with an SNMP engine. This 136 property can be used to correlate management information easily even 137 in situations where multiple different transports were used to 138 retrieve the information or where transport addresses can change 139 dynamically. 141 To retrieve data from an SNMPv3 agent, it is necessary to know the 142 appropriate contextEngineID. The User-based Security Model (USM) of 143 SNMPv3 provides a mechanism to discover the snmpEngineID of the 144 remote SNMP engine since this is needed for security processing 145 reasons. The discovered snmpEngineID can subsequently be used as a 146 contextEngineID in a ScopedPDU to access management information local 147 to the remote SNMP engine. Other security models, such as the 148 Transport Security Model (TSM) [I-D.TSM], lack such a procedure and 149 may use the discovery mechanism defined in this memo. 151 3. Procedure 153 The proposed discovery mechanism consists of two parts, namely (i) 154 the definition of a special well-known snmpEngineID value, called the 155 localEngineID, which always refers to a local default context, and 156 (ii) the definition of a procedure to acquire the snmpEngineID scalar 157 of the SNMP-FRAMEWORK-MIB [RFC3411] using the special well-known 158 local localEngineID value. 160 3.1. Local EngineID 162 An SNMP command responder implementing this specification MUST 163 register their pduTypes using the localEngineID snmpEngineID value 164 (defined below) using the registerContextEngineID() Abstract Service 165 Interface (ASI) defined in RFC 3412 [RFC3412]. This registration is 166 done in addition to the normal registration under the SNMP engine's 167 snmpEngineID. This is consistent with the SNMPv3 specifications 168 since they explicitly allow to register multiple engineIDs and 169 multiple pduTypes [RFC3412]. 171 The SnmpEngineID textual convention [RFC3411] defines that an 172 snmpEngineID value MUST be between 5 and 32 octets long. This 173 specification proposes to use the variable length format 3) and to 174 allocate the reserved, unused format value 6, using the enterprise ID 175 0 for the localEngineID. An ASN.1 definition for localEngineID would 176 look like this: 178 localEngineID OCTET STRING ::= '8000000006'H 180 The localEngineID value always provides access to the default context 181 of an SNMP engine. 183 3.2. EngineID Discovery 185 Discovery of the snmpEngineID is done by sending a Read Class 186 protocol operation (see section 2.8 of [RFC3411]) to retrieve the 187 snmpEngineID scalar using the localEngineID defined above as a 188 contextEngineID value. Implementations SHOULD only perform this 189 discovery step when it is needed. In particular, if security models 190 are used that already discover the remote snmpEngineID (such as USM), 191 then no further discovery is necessary. The same is true in 192 situations where the application already knows a suitable 193 snmpEngineID value. 195 The procedure to discover the snmpEngineID of a remote SNMP engine 196 can be described as follows: 198 1. Check whether a suitable contextEngineID value is already known. 199 If yes, use the provided contextEngineID value and stop the 200 discovery procedure. 201 2. Check whether the selected security model supports discovery of 202 the remote snmpEngineID (e.g., USM with its discovery mechanism). 203 If yes, let the security model perform the discovery. If the 204 remote snmpEngineID value has been successfully determined, 205 assign it to the contextEngineID and stop the discovery 206 procedure. 207 3. Send a Read Class operation to the remote SNMP engine using the 208 localEngineID value as the contextEngineID in order to retrieve 209 the scalar snmpEngineID.0 of the SNMP-FRAMEWORK-MIB [RFC3411]. 210 If successful, set the contextEngineID to the retrieved value and 211 stop the discovery procedure. 213 4. Return an error indication that a suitable contextEngineID could 214 not be discovered. 216 The procedure outlined above is an example and can be modified to 217 retrieve more variables in step 3), such as the sysObjectID.0 scalar 218 or the snmpSetSerialNo.0 scalar of the SNMPv2-MIB [RFC3418]. 220 4. IANA Considerations 222 IANA has to create a registry for SnmpEngineID formats. The first 223 four octets of an SnmpEngineID carry an enterprise number while the 224 fifth octet in a variable length SnmpEngineID value, called the 225 format octet, indicates how the following octets are formed. The 226 following format values were defined in [RFC3411]: 228 Format Description References 229 ------- ----------- ---------- 230 0 reserved, unused [RFC3411] 231 1 IPv4 address [RFC3411] 232 2 IPv6 address [RFC3411] 233 3 MAC address [RFC3411] 234 4 administratively assigned text [RFC3411] 235 5 administratively assigned octets [RFC3411] 236 6-127 reserved, unused [RFC3411] 237 128-255 enterprise specific [RFC3411] 239 IANA has to create a registry to assign new format values out of the 240 originally assigned and reserved number space 1-127. For new 241 assignments, a specification is required as per [RFC2434]. 243 This document requested the following assignment: 245 Format Description References 246 ------- ----------- ---------- 247 6 local engine [RFCXXXX] 249 [RFC Ed.: replace XXXX with RFC number assigned to the document] 251 5. Security Considerations 253 SNMP version 3 (SNMPv3) provides cryptographic security to protect 254 devices from unauthorized access. This specification recommends to 255 use the security services provided by SNMPv3. In particular, it is 256 RECOMMENDED to protect the discovery exchange. 258 In situations where SNMPv3 is used without security (i.e., the 259 security level of noAuthNoPriv is used), the introduction of a 260 localEngineID may make it slightly easier for an attacker to discover 261 suitable snmpEngineID values. However, since SNMP messages with a 262 security level of noAuthNoPriv are normally carried in clear-text 263 over the wire, it is usually easy for an attacker to discover 264 snmpEngineID values by sniffing on the wire and any attempts to keep 265 snmpEngineID values private will not lead to strong security. The 266 usage of SNMPv3 without security is therefore generally NOT 267 RECOMMENDED. 269 If a device configuration permits non-secure SNMPv1/v2c access to a 270 target system, then reading the snmpEngineID variable of the SNMP- 271 FRAMEWORK-MIB will also reveal a suitable contextEngineID value for 272 subsequent SNMPv3 usage. However, implementations should not rely on 273 non-secure SNMPv1/v2c access and therefore MUST implement this 274 specification to enable secure contextEngineID discovery. 276 The isAccessAllowed() abstract service primitive of the SNMP access 277 control subsystem does not take the contextEngineID into account when 278 checking access rights [RFC3411]. As a consequence, it is not 279 possible to define a special view for context engineID discovery. A 280 request with a localEngineID is thus treated like a request with the 281 correct snmpEngineID by the access control subsystem. This is inline 282 with the SNMPv3 design where the authenticated identity is the 283 securityName (together with the securityModel and securityLevel 284 information) and transport addresses or knowledge of contextEngineID 285 values do not impact to the access control decision. 287 6. Acknowledgments 289 Dave Perkins suggested to introduce a "local" contextEngineID during 290 the interim meeting of the ISMS working group in Boston, 2006. Joe 291 Fernandez, David Harrington, and Dan Romascanu provided helpful 292 review and feedback, which helped to improve this document. 294 7. References 296 7.1. Normative References 298 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 299 Requirement Levels", BCP 14, RFC 2119, March 1997. 301 [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An 302 Architecture for Describing Simple Network Management 303 Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, 304 December 2002. 306 [RFC3412] Case, J., Harrington, D., Presuhn, R., and B. Wijnen, 307 "Message Processing and Dispatching for the Simple Network 308 Management Protocol (SNMP)", STD 62, RFC 3412, 309 December 2002. 311 [RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model 312 (USM) for version 3 of the Simple Network Management 313 Protocol (SNMPv3)", STD 62, RFC 3414, December 2002. 315 [RFC3416] Presuhn, R., "Version 2 of the Protocol Operations for the 316 Simple Network Management Protocol (SNMP)", STD 62, 317 RFC 3416, December 2002. 319 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 320 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 321 October 1998. 323 7.2. Informative References 325 [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, 326 "Introduction and Applicability Statements for Internet- 327 Standard Management Framework", RFC 3410, December 2002. 329 [RFC3418] Presuhn, R., "Management Information Base (MIB) for the 330 Simple Network Management Protocol (SNMP)", STD 62, 331 RFC 3418, December 2002. 333 [I-D.TSM] Harrington, D., "Transport Security Model for SNMP", 334 draft-ietf-isms-transport-security-model-07.txt (work in 335 progress), November 2007. 337 Author's Address 339 Juergen Schoenwaelder 340 Jacobs University Bremen 341 Campus Ring 1 342 28725 Bremen 343 Germany 345 Phone: +49 421 200-3587 346 Email: j.schoenwaelder@jacobs-university.de 348 Full Copyright Statement 350 Copyright (C) The IETF Trust (2008). 352 This document is subject to the rights, licenses and restrictions 353 contained in BCP 78, and except as set forth therein, the authors 354 retain all their rights. 356 This document and the information contained herein are provided on an 357 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 358 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 359 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 360 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 361 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 362 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 364 Intellectual Property 366 The IETF takes no position regarding the validity or scope of any 367 Intellectual Property Rights or other rights that might be claimed to 368 pertain to the implementation or use of the technology described in 369 this document or the extent to which any license under such rights 370 might or might not be available; nor does it represent that it has 371 made any independent effort to identify any such rights. Information 372 on the procedures with respect to rights in RFC documents can be 373 found in BCP 78 and BCP 79. 375 Copies of IPR disclosures made to the IETF Secretariat and any 376 assurances of licenses to be made available, or the result of an 377 attempt made to obtain a general license or permission for the use of 378 such proprietary rights by implementers or users of this 379 specification can be obtained from the IETF on-line IPR repository at 380 http://www.ietf.org/ipr. 382 The IETF invites any interested party to bring to its attention any 383 copyrights, patents or patent applications, or other proprietary 384 rights that may cover technology that may be required to implement 385 this standard. Please address the information to the IETF at 386 ietf-ipr@ietf.org. 388 Acknowledgment 390 Funding for the RFC Editor function is provided by the IETF 391 Administrative Support Activity (IASA).