idnits 2.17.1 draft-ietf-snmpv3-next-gen-arch-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 9 longer pages, the longest (page 63) being 60 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 537: '...his architecture SHOULD provide protec...' RFC 2119 keyword, line 614: '... the Security Subsystem SHOULD protect...' RFC 2119 keyword, line 2550: '... for a subsystem SHOULD support the st...' RFC 2119 keyword, line 2558: '...a Security Model MUST describe how the...' RFC 2119 keyword, line 2564: '...eceived messages MUST be validated by ...' (4 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 494 has weird spacing: '...es with comma...' == Line 975 has weird spacing: '...patcher v ...' -- 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 (1 August 1997) is 9765 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: 'RFC1573' is mentioned on line 1352, but not defined ** Obsolete undefined reference: RFC 1573 (Obsoleted by RFC 2233) == Unused Reference: 'RFC1155' is defined on line 2434, but no explicit reference was found in the text == Unused Reference: 'RFC1157' is defined on line 2438, but no explicit reference was found in the text == Unused Reference: 'RFC1212' is defined on line 2444, but no explicit reference was found in the text == Unused Reference: 'RFC1901' is defined on line 2447, but no explicit reference was found in the text == Unused Reference: 'RFC1902' is defined on line 2451, but no explicit reference was found in the text == Unused Reference: 'RFC1903' is defined on line 2456, but no explicit reference was found in the text == Unused Reference: 'RFC1904' is defined on line 2460, but no explicit reference was found in the text == Unused Reference: 'RFC1906' is defined on line 2470, but no explicit reference was found in the text == Unused Reference: 'RFC1907' is defined on line 2475, but no explicit reference was found in the text == Unused Reference: 'RFC1908' is defined on line 2480, but no explicit reference was found in the text == Unused Reference: 'RFC1909' is defined on line 2488, but no explicit reference was found in the text == Unused Reference: 'SNMP-MPD' is defined on line 2494, but no explicit reference was found in the text == Unused Reference: 'SNMP-USM' is defined on line 2499, but no explicit reference was found in the text == Unused Reference: 'SNMP-ACM' is defined on line 2504, but no explicit reference was found in the text == Unused Reference: 'SNMP-APPL' is defined on line 2509, but no explicit reference was found in the text ** Downref: Normative reference to an Historic RFC: RFC 1157 ** Downref: Normative reference to an Historic RFC: RFC 1901 ** Obsolete normative reference: RFC 1902 (Obsoleted by RFC 2578) ** Obsolete normative reference: RFC 1903 (Obsoleted by RFC 2579) ** Obsolete normative reference: RFC 1904 (Obsoleted by RFC 2580) ** Obsolete normative reference: RFC 1905 (Obsoleted by RFC 3416) ** Obsolete normative reference: RFC 1906 (Obsoleted by RFC 3417) ** Obsolete normative reference: RFC 1907 (Obsoleted by RFC 3418) ** Obsolete normative reference: RFC 1908 (Obsoleted by RFC 2576) ** Downref: Normative reference to an Historic RFC: RFC 1909 ** Downref: Normative reference to an Historic RFC: RFC 1910 == Outdated reference: A later version (-05) exists of draft-ietf-snmpv3-mpc-03 == Outdated reference: A later version (-03) exists of draft-ietf-snmpv3-usm-01 == Outdated reference: A later version (-04) exists of draft-ietf-snmpv3-acm-02 -- Possible downref: Non-RFC (?) normative reference: ref. 'SNMP-APPL' Summary: 23 errors (**), 0 flaws (~~), 23 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 An Architecture for Describing 3 SNMP Management Frameworks 5 1 August 1997 7 D. Harrington 8 Cabletron Systems, Inc. 9 dbh@cabletron.com 11 B. Wijnen 12 IBM T.J. Watson Research 13 wijnen@vnet.ibm.com 15 17 Status of this Memo 19 This document is an Internet-Draft. Internet-Drafts are working 20 documents of the Internet Engineering Task Force (IETF), its areas, 21 and its working groups. Note that other groups may also distribute 22 working documents as Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference material 27 or to cite them other than as ``work in progress.'' 29 To learn the current status of any Internet-Draft, please check the 30 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 31 Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), 32 ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). 34 Abstract 36 This document describes an architecture for describing SNMP Management 37 Frameworks. The architecture is designed to be modular to allow the 38 evolution of the SNMP protocol standards over time. The major portions 39 of the architecture are an SNMP engine containing a Message Processing 40 Subsystem, a Security Subsystem and an Access Control Subsystem, and 41 possibly multiple SNMP applications which provide specific functional 42 processing of network management data. 44 Harrington/Wijnen Expires February 1998 [Page 1] 45 Draft An Architecture for SNMP Management Frameworks August 1997 47 0. Issues 49 0.1. Resolved Issues 50 . contextEngineID in reportPDU = snmpEngineID of report generator 51 . returnResponsePDU - are all parameters needed? overrides allowed? 52 all parameters kept for future flexibility 53 overrides not supported by SNMPv3 54 . use of IN/OUT indicators in primitives accepted 55 . NT/Unix-like access control - can be defined as future model 56 . user-friendly names? yes, but with limits 57 . SnmpAdminString as index? yes, but restrict sizes 58 . need both MMS and maxSizeResponseScopedPDU? yes. 59 . synchronous vs. asynchronous primitives? synchronous preferred 60 . should we change MIB naming? no, it is acceptable 61 . is it ok that USM is bound to SNMPv3? while undesirable, it is 62 acceptable. A cleaner model may be defined in the future. 63 . should securityModel "any" be supported? for ACM use, not SNMPv3 64 . what defines SNMPv3? a document will be published after Munich 65 . Is an application-level handle needed for request/response matching? 66 yes. create sendPduhandle 67 . Is wildcard contextEngineID/pduType registration needed? No. This is 68 an internal interface, and wildcarding can be supported by an 69 implementation, but is not required in the standard. 70 . Should indices be integers or SnmpAdminStrings? SnmpAdminStrings 71 is the consensus. 72 . Should protocols be identified as OIDs or Integers? OIDs 73 . terminology: 74 securityLevel rather than LoS 75 msgXXXX to identify message fields in SNMPv3 76 . OID or Integer for auth/priv protocol identifiers 77 Consensus: use OID 78 . Is Glossary needed to describe primitive parameters, or is the 79 expanded template adequate for this purpose? 80 Consensus: Terms are basically all defined in section 3. 81 . state_reference releases 82 Consensus: documents checked; we think it is OK now 83 . new SnmpEngineID format rules to be discussed yet. 84 Consensus: Limit size to be 1..32 85 . needs changes to meet STDGUIDE guidelines 86 We think we're meeting them now 87 . we punted snmpEngineMaxMessageSize at 2nd interim because that 88 info travels in each SNMPv3 message. However, we may want to 89 re-introduce it so that SNMPv1/v2c managers can learn the value!! 90 Consensus: Nobody picked up on this, so it seems not needed. 91 . Do we need a mechanism to discover securityModels supported 92 Can be decided after Munich 93 . add a "Decision History" section (as an appendix?) 94 Can be decided after Munich 96 Harrington/Wijnen Expires February 1998 [Page 2] 97 Draft An Architecture for SNMP Management Frameworks August 1997 99 0.1.1. Issues discussed at second Interim Meeting: 101 . A "readable" introduction supplement may be done after Munich. 102 . Applications are responsible for retries, but implementations may 103 differ. 104 . TCs should not be defined just to describe primitive parameters. 105 If they cannot be described adequately in text, they can be defined 106 in a Glossary. Avoid describing implementation details. 107 . Is SnmpAdminString appropriate for all strings, such as 108 securityIdentifier and context and group? These had different 109 sizes and semantics. size and semantics may be defined in 110 syntax and description of OBJECT 111 . AdminString has size (0..255); revisit for utf8 discussions 112 . securityModel #s - 00 for IETF standards; from v2* documents 113 . protocol IDs - integer or OID? voted 13-0 for OID. 114 . uniqueness of securityName 115 . mapping between principal and securityName is outside scope of WG. 116 . principals may have more than one securityName in an entity 117 . mappings may exist between many types of MDID and a single 118 securityName 119 . mappings may exist between different (model, Name) and the same 120 securityName by varying the model or the Name. 121 . the securityName and a MDID may be identical. This can be defined 122 by the Security Model. 123 (user,"public") may map to securityName "public" 124 . [securityName, securityModel] yields zero or one MDName, with 125 exceptions for backwards compatibility. The exception is defined 126 by the model, and the problems are the province of the model to 127 resolve. 129 Harrington/Wijnen Expires February 1998 [Page 3] 130 Draft An Architecture for SNMP Management Frameworks August 1997 132 0.2. Change Log 134 [version 4.14] 135 . formatting 136 . pagination 137 [version 4.13] 138 . new acknowledgements 139 . updated references 140 . updated issues list 141 . ordered security, editors, acknowledgements, references sections 142 . checked line lengths 143 [version 4.12] 144 . cleanup 145 . added expectResponse to processIncomingMsg to address Levi-raised 146 concern 147 . acknowledgements 148 . MIB checked by SMICng 149 . post to snmpv3 mailing list 150 [version 4.11] 151 . Change Primitives between MP and SEC to try and address the issue 152 of architectural binding to message format. 153 . Added securityName and securityLevel to the returnResponsePdu 154 primitive so that architecturally it could be different for a 155 request and a response. 156 . Rename processMsg primitive to processIncomingMsg 158 [version 4.10] 159 . spell check 161 [version 4.9] 162 . editorial changes 163 . fix SnmpEngineID TC 164 . add a note to SnmpAdminString 165 . rename title of section 1.1 166 . expand description of Dispatcher a bit 168 [version 4.8] 169 . Added parameter pduVersion on primitives: 170 sendPdu 171 processPdu 172 returnResponsePdu 173 processResponsePdu 174 prepareDataElements 175 prepareOutgoingMessage 176 prepareResponseMessage 177 . Added parameter messageProcessingModel on the primitive: 178 processPdu 179 processResponsePdu 180 returnResponsePdu 181 . Removed messageProcessingModel parameter from primitives: 182 registerContextEngineID 184 Harrington/Wijnen Expires February 1998 [Page 4] 185 Draft An Architecture for SNMP Management Frameworks August 1997 187 unregisterContextEngineID 188 . Renamed SNMP Version Multiplexer to Dispatcher 189 . Renamed Version Multiplexer to Message Multiplexer 190 . Renamed Application Multiplexer to PDU Dispatcher 191 . Rearranged some parameters in various Primitives so the sequence 192 of parameters is now more consistent. 194 [version 4.7] 195 . editorial cleanup 196 . changed asterisk text 197 . modified snmpv3 framework description to eliminate dependencies 198 . reorder 4.2.x to reflect transaction order 199 . changed SnmpEngineID size to 1..32 201 [version 4.6] 202 . Changes to use synchronous primitives where possible 203 . Changes to describe SNMP Version Multiplexer 204 . Remove (empty) glossary 205 . Redraw documentation figure 206 . Redraw Operational Overview Figure 207 . Remove old section 4 (Architectural Elements of Procedure) 208 These moved to the MP document into the SNMP Version Multiplexer 209 section. 210 . Move Overview of all primitives from Appendix to Section 4. 211 . Simplify Appendix A to just described Model Designer Guidelines 212 and refer back to section 4 for specific primitives 213 . Remove Appendix B (An Evolutionary Architecture - Design Goals) 214 . added design decision regarding security 215 . Included latest Snmp SecurityModel TC (as it was actually posted 216 to the SNMPv3 mailing list). 218 [version 4.5] 219 . start with 220 . change vendor to implementor 221 . change LoS to securityLevel 222 . remove mention of enterprise 223 . change Internet Management Framework to SNMP Management Framework 224 . modify usage of "frameworks" to improve internal consistency. 225 . change Message Processing Abstract Service Interface to 226 Application Multiplexor 227 . change description of SNMP engine 228 . moved "one-to-one association" for entity and engine to discussion 229 of engine. 230 . changed distributing to dispatching 231 . added asterisks to indicate v3* items are also not required. 232 . changed "community access control" to "other access control" 233 . added TC for SnmpMessageProcessingModel 234 . modified Security Considerations 235 . modified acknowledgements 237 [version 4.4] 239 Harrington/Wijnen Expires February 1998 [Page 5] 240 Draft An Architecture for SNMP Management Frameworks August 1997 242 . Fixed one error in the MIB (found with SMICng) 243 . Reformatted text for SnmpAdminString, no change in text. 244 . Changed text for SnmpEngineID.. this is still under discussion. 245 But this new text seems to be getting close to what we want. 246 . Added an issue w.r.t. snmpEngineMaxMessageSize 247 . adapt Primitive names and parameters to very latest (july 11) names 248 . removed blank lines before the .p page controls. 249 . publish as 251 [version 4.3] 252 . some minor editing adjustments 253 [version 4.2] 254 . modify abstract so there is no requirement for one entity 255 to contain both a command generator and a notification receiver. 256 . modify Introduction list of entities which are meant to be 257 supported 258 . reorganized sections 1 through 4 for more consistency in contents. 259 . described section contents in Introduction:Target Audience 260 . move documentation descriptions to section 2 261 . rewrite section 4 to be more like a real elements of procedure. 262 . modified SnmpSecurityModel and SnmpEngineID definitions 263 . replaced MIB with Bert's replacement 264 . added Randy's TC for SnmpAdminString 265 . modified the example algorithm text for SnmpEngineID 266 . rewrote security considerations for brevity. 267 . modified "context" description 268 . moved "Threats" to Goals/Requirements 269 . eliminated snmpEngineMaxMessageSize object 270 . posted to snmpv3 (by DBH) 271 [version 4.1] 272 . Adopt "abstract" to new terminology 273 . Addressed all comments I (BW) made to DBH in an earlier email 274 . Changed Introduction section to new terminology 275 . changed wording for "implementation" to indicate it may contain 276 multiple models. 277 . Section 2. Started some wording on Goals and Design decisions 278 . Added the overview picture of a traditional agent and a 279 traditional manager. This is in section 2. 280 . Changed overview figure in section 3. to address the comments 281 by Dave Levi. It now lists the type of applications 282 . At various places ensure that text (easily) fits within 72 283 columns as required by RFC-editors Guidelines document. 284 . Section 2.3 (new section) has the documents set overview. 285 I verified the claims about standards. Not sure I worded the 286 SNMPv2 std correctly,. We'll hear it if we did it wrong. 287 . Section 2.4 (new section) gives overview of SNMP entities based 288 on modified Dave Levi figure. I (Bert) wonder however if it would 289 not be better to move it to after section 3.1.13 290 . Section 3. Added more figures... please let us know if you find 291 then useful and/or helpful. We could also move these back to 292 section 2 if such makes more sense. 294 Harrington/Wijnen Expires February 1998 [Page 6] 295 Draft An Architecture for SNMP Management Frameworks August 1997 297 . Added a picture in section 3.2. 298 It also shows some of access control, so not sure it really fits 299 here, although it does map principal to model dependent security 300 ID to securityName 301 . Replace "<" with "is lower than" in section 3.4.3 which seems 302 better in a text document. 303 . Renamed section 4.1 to "SNMP engine processing" instead of 304 "The Message Processing Subsystem" because the transport 305 mappings, mpc multiplexor and such is done in ARCH document so 306 it is done "in general in the engine" and it passes a specific 307 message to a Message Processing Subsystem. 308 . "bulletized" some stuff in section 4.2 and 4.3. 309 Dave, this is just how I (Bert) like it better. Feel free to 310 undo it if you strongly disagree 311 . Section 4.3 changed "initiate a transaction" to "originate a 312 notification". 313 . Inserted title line for section 4.4 (I think it was missing) 314 I have named it "Information Model" in accordance with the change 315 I made (after Russ's comments) in the document figure to lump SMI, 316 TC and Conformance together. 317 . Inserted a title for section 4.5 named "Operational Model" to 318 get in sync with the the lumping together of ProtoOps and Transport 319 Mappings in document overview 320 . Renumber section 4.4.4 to 4,5,1 and added 4.5.2 to follow the 321 document overview figure. If we really want to follow it, then 322 maybe we should also reorder some of these sections. Like 323 Access Control seems specifically misplaced. So I decided to move 324 it before applications as section 4.3, so the 4.x above should 325 all be read as 4.x+1 326 . Removed size from SnmpEngineID TC... why did you limit it to 327 (0..2048). Did we not decide to leave it open? 328 . Should we not remove snmpEngineMaxMessageSize from the MIB. 329 That was agreed at 2nd interim. It travels in every message and so 330 seems to be useless. However, I think it could indeed still help 331 SNMPv1 or SNMPv2c managers. 332 . I kept your definitions of registration-points for auth and priv 333 protocols, but my recollection is that they would be completely 334 removed from ARCH and that it would all be done in SEC document. 335 . Modified Security Considerations. Was still talking about LPM. 336 . Appendix. I am still wondering if we need to use capitals for 337 things like "Security Model" "Subsystem" and such. This is only 338 an appendix... but we better be consistent, no? Anyway 339 I changed it so it is consistent (at least I tried). 340 . Appendix, renamed imf to snmpFramework 341 . Appendix, changed state_reference and state_release to 342 stateReference and stateRelease to be consistent with other names 343 for abstract data and primitives. 344 . A.2 changed MessageEngine to SNMP engine 345 . Fixed ASI primitives to be in sync with SEC document. 346 I also thought that our ARCH document-outline wanted to at least 347 have the primitives listed within the main body of the text, no? 349 Harrington/Wijnen Expires February 1998 [Page 7] 350 Draft An Architecture for SNMP Management Frameworks August 1997 352 . Adapted send_pdu to sendPdu primitive as reconciled by Randy 353 In fact I made sure all primitives are in-line with current 354 agreement on names and parameters. 355 . Rename title of A.2.4 and A.2.5 so it fits on 1 line in contents 356 . I did not look at appendix B. That is your (DBH) specialty is it 357 not ? ;-). 358 . Quick simple spell check done with "spell" on AIX 359 [version 4.0] 360 . move section 7 - Model Requirements to an appendix 361 . move Section 3 - Design Goals to an appendix 362 . modified Section 5 - Naming 363 . remove "possibly multiple" 364 . moved Section 5 to Section 3 365 . change orangelets to applications 366 . modify description of applications 367 . change scopedPDU-MMS and PDU-MMS to maxSizeResponseScopedPDU 368 . change Scoped-PDU and ScopedPDU to scopedPDU (no dash, lower case S) 369 . change imfxxx to snmpFrameworkxxx 370 . change security-entity to principal 371 . change securityIdentity to securityName 372 . change MIID to securityName 373 . eliminate all reference to groupName or group 374 . LoS ordering noAuthNoPriv < authNoPriv < authPriv 375 . Los TC naming - noAuthNoPriv(1), authNoPriv(2), authPriv(3) 376 . remove TCs not used in MIBs - securityIdentity TC etc 377 . changed Message Processing and Control to Message Processing 378 . changed future tense to present tense 379 . eliminate messageEngine 380 . added/updated primitives 381 . addressed issues raised on the mailing list 383 [version 3.1] 384 . change securityIdentity to MIID 385 . write text to explain the differences between security-identities, 386 model-dependent identifiers, and model-independent identifiers. 387 . write text to explain distinction within the LCD of the security 388 data, the access control data, and the orangelet data. 389 . identify issues 390 . publish as 392 [version 3.0] 393 . add section on threats for message security 394 . add section on threats for access control 395 . change application to orangelet 396 . remove references to F-Ts 397 . change securityIdentity to security-identity 398 . change securityCookie to securityIdentity 399 . the format of securityIdentity is defined by the model 400 . add securityModel to passed parameters as needed 401 . eliminate group from passed parameters 402 . remove unused IMPORTS 404 Harrington/Wijnen Expires February 1998 [Page 8] 405 Draft An Architecture for SNMP Management Frameworks August 1997 407 . add glossary section with initial set of words to define 408 . differentiate the messageEngine from the contextEngine 409 . eliminate the term SNMPng 410 . rewrote 1.1. A Note on Terminology 411 . eliminated assumptions about SNMP processing always being 412 message related 413 . rewrote 4.x to reflect new thinking 414 . rewrote 5.x to reflect new thinking 415 . rewrote 6.x (the MIB) to reflect new thinking 416 . added MIB objects at this level (previously only TCs) 417 . rewrote 7.x 418 . sent to v3edit list 420 Harrington/Wijnen Expires February 1998 [Page 9] 421 Draft An Architecture for SNMP Management Frameworks August 1997 423 1. Introduction 425 1.1. Overview 427 This document assumes an audience with varying levels of technical 428 understanding of SNMP. 430 This document does not provide a general introduction to SNMP. Other 431 documents and books can provide a much better introduction to SNMP. 432 Nor does this document provide a history of SNMP. That also can be 433 found in books and other documents. 435 This document defines a vocabulary for describing SNMP Management 436 Frameworks, and an architecture for describing the major portions of 437 SNMP Management Frameworks. 439 Section 1 describes the purpose, goals, and design decisions of 440 this architecture. 442 Section 2 describes various types of documents which define SNMP 443 Frameworks, and how they fit into this architecture. It also provides 444 a minimal roadmap to the documents which have previously defined 445 SNMP frameworks. 447 Section 3 details the vocabulary of this architecture and its pieces. 448 This section is important for understanding the remaining sections, 449 and for understanding documents which are written to fit within this 450 architecture. 452 Section 4 describes the primitives used for the abstract service 453 interfaces between the various subsystems, models and applications 454 within this architecture. 456 Section 5 defines a collection of managed objects used to instrument 457 SNMP entities within this architecture. 459 Sections 6, 7, 8, and 9 are administrative in nature. 461 Appendix A contains guidelines for designers of Models which are 462 expected to fit within this architecture. 464 1.2. SNMP Management Systems 466 An SNMP management system contains: 467 - several (potentially many) nodes, each with an SNMP entity 468 containing command responder and notification originator 469 applications, which have access to management instrumentation; 470 - at least one SNMP entity containing command generator and/or 471 notification receiver applications; and, 472 - a management protocol, used to convey management information 473 between the SNMP entities. 475 Draft An Architecture for SNMP Management Frameworks August 1997 477 SNMP entities executing command generator and notification receiver 478 applications monitor and control managed elements. Managed elements 479 are devices such as hosts, routers, terminal servers, etc., which 480 are monitored and controlled via access to their management 481 information. 483 It is the purpose of this document to define an architecture which 484 can evolve to realize effective network management in a variety 485 of configurations and environments. The architecture has been 486 designed to meet the needs of implementations of: 487 - minimal SNMP entities with command responder and/or notification 488 originator applications (traditionally called SNMP agents), 489 - SNMP entities with proxy forwarder applications (traditionally 490 called SNMP proxy agent), 491 - command line driven SNMP entities with command generator and/or 492 notification receiver applications (traditionally called SNMP 493 command line managers), 494 - SNMP entities with command generator and/or notification 495 receiver, plus command responder and/or notification originator 496 applications (traditionally called SNMP mid-level managers or 497 dual-role entities), 498 - SNMP entities with command generator and/or notification 499 receiver and possibly other types of applications for managing 500 a potentially very large number of managed nodes (traditionally 501 called network management stations). 503 1.3. Goals of this Architecture 505 This architecture was driven by the following goals: 507 - Use existing materials as much as possible. It is heavily based 508 on previous work, informally known as SNMPv2u and SNMPv2*. 509 - Address the need for secure SET support, which is considered 510 the most important deficiency in SNMPv1 and SNMPv2c. 511 - Make it possible to move portions of the architecture forward 512 in the standards track, even if consensus has not been reached 513 on all pieces. 514 - Define an architecture that allows for longevity of the SNMP 515 Frameworks that have been and will be defined. 516 - Keep SNMP as simple as possible. 517 - Make it relatively inexpensive to deploy a minimal conformant 518 implementation 519 - Make it possible to upgrade portions of SNMP as new approaches 520 become available, without disrupting an entire SNMP framework. 521 - Make it possible to support features required in large networks, 522 but make the expense of supporting a feature directly related 523 to the support of the feature. 525 Draft An Architecture for SNMP Management Frameworks August 1997 527 1.4. Security Requirements of this Architecture 529 Several of the classical threats to network protocols are applicable 530 to the network management problem and therefore would be applicable 531 to any Security Model used in an SNMP Management Framework. Other 532 threats are not applicable to the network management problem. This 533 section discusses principal threats, secondary threats, and threats 534 which are of lesser importance. 536 The principal threats against which any Security Model used within 537 this architecture SHOULD provide protection are: 539 Modification of Information 540 The modification threat is the danger that some unauthorized SNMP 541 entity may alter in-transit SNMP messages generated on behalf of 542 an authorized principal in such a way as to effect unauthorized 543 management operations, including falsifying the value of an object. 545 Masquerade 546 The masquerade threat is the danger that management operations 547 not authorized for some principal may be attempted by assuming 548 the identity of another principal that has the appropriate 549 authorizations. 551 Message Stream Modification 552 The SNMP protocol is typically based upon a connectionless 553 transport service which may operate over any subnetwork service. 554 The re-ordering, delay or replay of messages can and does occur 555 through the natural operation of many such subnetwork services. 556 The message stream modification threat is the danger that messages 557 may be maliciously re-ordered, delayed or replayed to an extent 558 which is greater than can occur through the natural operation of 559 a subnetwork service, in order to effect unauthorized management 560 operations. 562 Disclosure 563 The disclosure threat is the danger of eavesdropping on the 564 exchanges between SNMP engines. Protecting against this threat 565 may be required as a matter of local policy. 567 There are at least two threats against which a Security Model within 568 this architecture need not protect. 570 Denial of Service 571 A Security Model need not attempt to address the broad range of 572 attacks by which service on behalf of authorized users is denied. 573 Indeed, such denial-of-service attacks are in many cases 574 indistinguishable from the type of network failures with which any 575 viable network management protocol must cope as a matter of course. 577 Traffic Analysis 578 Draft An Architecture for SNMP Management Frameworks August 1997 580 A Security Model need not attempt to address traffic analysis 581 attacks. Many traffic patterns are predictable - entities may 582 be managed on a regular basis by a relatively small number of 583 management stations - and therefore there is no significant 584 advantage afforded by protecting against traffic analysis. 586 1.5. Design Decisions 588 Various designs decision were made in support of the goals of the 589 architecture and the security requirements: 591 - Architecture 592 An architecture should be defined which identifies the conceptual 593 boundaries between the documents. Subsystems should be defined 594 which describe the abstract services provided by specific 595 portions of an SNMP framework. Abstract service interfaces, as 596 described by service primitives, define the abstract boundaries 597 between documents, and the abstract services that are provided 598 by the conceptual subsystems of an SNMP framework. 600 - Self-contained Documents 601 Elements of procedure plus the MIB objects which are needed for 602 processing for a specific portion of an SNMP framework should be 603 defined in the same document, and as much as possible, should 604 not be referenced in other documents. This allows pieces to be 605 designed and documented as independent and self-contained parts, 606 which is consistent with the general SNMP MIB module approach. 607 As portions of SNMP change over time, the documents describing 608 other portions of SNMP are not directly impacted. This modularity 609 allows, for example, Security Models, authentication and privacy 610 mechanisms, and message formats to be upgraded and supplemented 611 as the need arises. The self-contained documents can move along 612 the standards track on different time-lines. 614 - The Security Models in the Security Subsystem SHOULD protect 615 against the principal threats: modification of information, 616 masquerade, message stream modification and disclosure. 617 They do not need to protect against denial of service and 618 traffic analysis. 620 - Remote Configuration 621 The Security and Access Control Subsystems add a whole new set 622 of SNMP configuration parameters. The Security Subsystem also 623 requires frequent changes of secrets at the various SNMP 624 entities. To make this deployable in a large operational 625 environment, these SNMP parameters must be able to be remotely 626 configured. 628 - Controlled Complexity 629 It is recognized that simple managed devices want to keep the 630 resources used by SNMP to a minimum. At the same time, there 632 Draft An Architecture for SNMP Management Frameworks August 1997 634 is a need for more complex configurations which can spend more 635 resources for SNMP and thus provide more functionality. 636 The design tries to keep the competing requirements of these 637 two environments in balance and allows the more complex 638 environments to logically extend the simple environment. 640 Draft An Architecture for SNMP Management Frameworks August 1997 642 2. Documentation Overview 644 The following figure shows the set of documents that fit within the 645 SNMP Architecture. 647 +-------------------------- Document Set ----------------------------+ 648 | | 649 | +------------+ +-----------------+ +----------------+ | 650 | | Document * | | Applicability * | | Coexistence * | | 651 | | Roadmap | | Statement | | & Transition | | 652 | +------------+ +-----------------+ +----------------+ | 653 | | 654 | +----------------------------------------------------------------+ | 655 | | Message Handling | | 656 | | +-----------------+ +-----------------+ +-----------------+ | | 657 | | | Transport | | Message | | Security | | | 658 | | | Mappings | | Processing and | | | | | 659 | | | | | Dispatching | | | | | 660 | | +-----------------+ +-----------------+ +-----------------+ | | 661 | +----------------------------------------------------------------+ | 662 | | 663 | +----------------------------------------------------------------+ | 664 | | PDU Handling | | 665 | | +-----------------+ +-----------------+ +-----------------+ | | 666 | | | Protocol | | Applications | | Access | | | 667 | | | Operations | | | | Control | | | 668 | | +-----------------+ +-----------------+ +-----------------+ | | 669 | +----------------------------------------------------------------+ | 670 | | 671 | +----------------------------------------------------------------+ | 672 | | Information Model | | 673 | | +--------------+ +--------------+ +---------------+ | | 674 | | | Structure of | | Textual | | Conformance | | | 675 | | | Management | | Conventions | | Statements | | | 676 | | | Information | | | | | | | 677 | | +--------------+ +--------------+ +---------------+ | | 678 | +----------------------------------------------------------------+ | 679 | | 680 | +----------------------------------------------------------------+ | 681 | | MIBs | | 682 | | +-------------+ +-------------+ +----------+ +----------+ | | 683 | | | Standard v1 | | Standard v1 | | Historic | | Draft v2 | | | 684 | | | RFC1157 | | RFC1212 | | RFC14xx | | RFC19xx | | | 685 | | | format | | format | | format | | format | | | 686 | | +-------------+ +-------------+ +----------+ +----------+ | | 687 | +----------------------------------------------------------------+ | 688 | | 689 +--------------------------------------------------------------------+ 691 Those marked with an asterisk (*) are expected to be written in the 692 future. Each of these documents may be replaced or supplemented. 694 Draft An Architecture for SNMP Management Frameworks August 1997 696 This Architecture document specifically describes how new documents 697 fit into the set of documents in the area of Message and PDU handling. 699 2.1. Document Roadmap 701 One or more documents may be written to describe how sets of documents 702 taken together form specific Frameworks. The configuration of document 703 sets might change over time, so the "roadmap" should be maintained in 704 a document separate from the standards documents themselves. 706 2.2. Applicability Statement 708 SNMP is used in networks that vary widely in size and complexity, 709 by organizations that vary widely in their requirements of network 710 management. Some models will be designed to address specific problems 711 of network management, such as message security. 713 One or more documents may be written to describe the environments 714 to which certain versions of SNMP or models within SNMP would be 715 appropriately applied, and those to which a given model might be 716 inappropriately applied. 718 2.3. Coexistence and Transition 720 The purpose of an evolutionary architecture is to permit new models 721 to replace or supplement existing models. The interactions between 722 models could result in incompatibilities, security "holes", and 723 other undesirable effects. 725 The purpose of Coexistence documents is to detail recognized anomalies 726 and to describe required and recommended behaviors for resolving the 727 interactions between models within the architecture. 729 It would be very difficult to document all the possible interactions 730 between a model and all other previously existing models while in the 731 process of developing a new model. 733 Coexistence documents are therefore expected to be prepared separately 734 from model definition documents, to describe and resolve interaction 735 anomalies between a model definition and one or more other model 736 definitions. 738 Additionally, recommendations for transitions between models may 739 also be described, either in a coexistence document or in a separate 740 document. 742 Draft An Architecture for SNMP Management Frameworks August 1997 744 2.4. Transport Mappings 746 SNMP messages are sent over various transports. It is the purpose of 747 Transport Mapping documents to define how the mapping between SNMP 748 and the transport is done. 750 2.5. Message Processing 752 A Message Processing Model document defines a message format, which is 753 typically identified by a version field in an SNMP message header. 754 The document may also define a MIB module for use in message 755 processing and for instrumentation of version-specific interactions. 757 An SNMP engine includes one or more Message Processing Models, and thus 758 may support sending and receiving multiple versions of SNMP messages. 760 2.6. Security 762 Some environments require secure protocol interactions. Security is 763 normally applied at two different stages: 765 - in the transmission/receipt of messages, and 766 - in the processing of the contents of messages. 768 For purposes of this document, "security" refers to message-level 769 security; "access control" refers to the security applied to protocol 770 operations. 772 Authentication, encryption, and timeliness checking are common 773 functions of message level security. 775 A security document describes a Security Model, the threats against 776 which the model protects, the goals of the Security Model, the 777 protocols which it uses to meet those goals, and it may define a MIB 778 module to describe the data used during processing, and to allow the 779 remote configuration of message-level security parameters, such as 780 passwords. 782 An SNMP engine may support multiple Security Models concurrently. 784 2.7. Access Control 786 During processing, it may be required to control access to certain 787 instrumentation for certain operations. An Access Control Model 788 determines whether access to an object should be allowed. The 789 mechanism by which access control is checked is defined by the 790 Access Control Model. 792 An Access Control Model document defines the mechanisms used to 793 determine whether access to a managed object should be allowed, 794 and may define a MIB module used during processing, and to allow 795 Draft An Architecture for SNMP Management Frameworks August 1997 797 the remote configuration of access control policies. 799 2.8. Protocol Operations 801 SNMP messages encapsulate an SNMP Protocol Data Unit (PDU). It is the 802 purpose of a Protocol Operations document to define the operations 803 of the protocol with respect to the processing of the PDUs. 805 An application document defines which Protocol Operations documents 806 are supported by the application. 808 2.9. Applications 810 An SNMP entity normally includes a number of applications. 811 Applications use the services of an SNMP engine to accomplish 812 specific tasks. They coordinate the processing of management 813 information operations, and may use SNMP messages to communicate 814 with other SNMP entities. 816 Applications documents describe the purpose of an application, the 817 services required of the associated SNMP engine, and the protocol 818 operations and informational model that the application uses to 819 perform network management operations. 821 An application document defines which set of documents are used to 822 specifically define the structure of management information, textual 823 conventions, conformance requirements, and operations supported by 824 the application. 826 2.10. Structure of Management Information 828 Management information is viewed as a collection of managed objects, 829 residing in a virtual information store, termed the Management 830 Information Base (MIB). Collections of related objects are defined 831 in MIB modules. 833 It is the purpose of a Structure of Management Information document 834 to establish the syntax for defining objects, modules, and other 835 elements of managed information. 837 2.11. Textual Conventions 839 When designing a MIB module, it is often useful to define new types 840 similar to those defined in the SMI, but with more precise semantics, 841 or which have special semantics associated with them. These newly 842 defined types are termed textual conventions, and may defined in 843 separate documents, or within a MIB module. 845 2.12. Conformance Statements 846 Draft An Architecture for SNMP Management Frameworks August 1997 848 It may be useful to define the acceptable lower-bounds of 849 implementation, along with the actual level of implementation 850 achieved. It is the purpose of Conformance Statements to define 851 the notation used for these purposes. 853 2.13. Management Information Base Modules 855 MIB documents describe collections of managed objects which instrument 856 some aspect of a managed node. 858 2.13.1. SNMP Instrumentation MIBs 860 An SNMP MIB document may define a collection of managed objects which 861 instrument the SNMP protocol itself. In addition, MIB modules may be 862 defined within the documents which describe portions of the SNMP 863 architecture, such as the documents for Message processing Models, 864 Security Models, etc. for the purpose of instrumenting those Models, 865 and for the purpose of allowing remote configuration of the Model. 867 2.14. SNMP Framework Documents 869 This architecture is designed to allow an orderly evolution of 870 portions of SNMP Frameworks. 872 Throughout the rest of this document, the term "subsystem" refers 873 to an abstract and incomplete specification of a portion of 874 a Framework, that is further refined by a model specification. 876 A "model" describes a specific design of a subsystem, defining 877 additional constraints and rules for conformance to the model. 878 A model is sufficiently detailed to make it possible to implement 879 the specification. 881 An "implementation" is an instantiation of a subsystem, conforming 882 to one or more specific models. 884 SNMP version 1 (SNMPv1), is the original Internet-standard Network 885 Management Framework, as described in RFCs 1155, 1157, and 1212. 887 SNMP version 2 (SNMPv2), is the SNMPv2 Framework as derived from the 888 SNMPv1 Framework. It is described in RFCs 1902-1907. SNMPv2 has no 889 message definition. 891 Community-based SNMP version 2 (SNMPv2c), is an experimental SNMP 892 Framework which supplements the SNMPv2 Framework, as described in 893 RFC1901. It adds the SNMPv2c message format similar to the SNMPv1 894 message format. 896 SNMP version 3 (SNMPv3), is an extensible SNMP Framework which 897 supplements the SNMPv2 Framework, by supporting the following: 898 - a new SNMP message format, 900 Draft An Architecture for SNMP Management Frameworks August 1997 902 - Security for Messages, and 903 - Access Control. 905 Other SNMP Frameworks, i.e. other configurations of implemented 906 subsystems, are expected to also be consistent with this architecture. 908 Draft An Architecture for SNMP Management Frameworks August 1997 910 2.15. Operational Overview 912 The following pictures show two communicating SNMP entities using 913 the conceptual modularity described by this SNMP Architecture. 914 The pictures represent SNMP entities that have traditionally been 915 called SNMP manager and SNMP agent respectively. 916 * One or more models may be present. 918 (traditional SNMP manager) 919 +--------------------------------------------------------------------+ 920 | +--------------+ +--------------+ +--------------+ SNMP entity | 921 | | NOTIFICATION | | NOTIFICATION | | COMMAND | | 922 | | ORIGINATOR | | RECEIVER | | GENERATOR | | 923 | | applications | | applications | | applications | | 924 | +--------------+ +--------------+ +--------------+ | 925 | ^ ^ ^ | 926 | | | | | 927 | v v v | 928 | +-------+--------+-----------------+ | 929 | ^ | 930 | | +---------------------+ +-----------------+ | 931 | | | Message Processing | | Security | | 932 | Dispatcher v | Subsystem | | Subsystem | | 933 | +-------------------+ | +------------+ | | | | 934 | | PDU Dispatcher | | +->| v1MP * |<--->| +-------------+ | | 935 | | | | | +------------+ | | | Other | | | 936 | | | | | +------------+ | | | Security | | | 937 | | | | +->| v2cMP * |<--->| | Model | | | 938 | | Message | | | +------------+ | | +-------------+ | | 939 | | Dispatcher <--------->+ | | | | 940 | | | | | +------------+ | | +-------------+ | | 941 | | | | +->| v3MP * |<--->| | User-based | | | 942 | | Transport | | | +------------+ | | | Security | | | 943 | | Mapping | | | +------------+ | | | Model | | | 944 | | (e.g RFC1906) | | +->| otherMP * |<--->| +-------------+ | | 945 | +-------------------+ | +------------+ | | | | 946 | ^ +---------------------+ +-----------------+ | 947 | | | 948 | v | 949 +--------------------------------------------------------------------+ 950 +-----+ +-----+ +-------+ 951 | UDP | | IPX | . . . | other | 952 +-----+ +-----+ +-------+ 953 ^ ^ ^ 954 | | | 955 v v v 956 +------------------------------+ 957 | Network | 958 +------------------------------+ 960 Draft An Architecture for SNMP Management Frameworks August 1997 962 +------------------------------+ 963 | Network | 964 +------------------------------+ 965 ^ ^ ^ 966 | | | 967 v v v 968 +-----+ +-----+ +-------+ 969 | UDP | | IPX | . . . | other | 970 +-----+ +-----+ +-------+ (traditional SNMP agent) 971 +--------------------------------------------------------------------+ 972 | ^ | 973 | | +---------------------+ +-----------------+ | 974 | | | Message Processing | | Security | | 975 | Dispatcher v | Subsystem | | Subsystem | | 976 | +-------------------+ | +------------+ | | | | 977 | | Transport | | +->| v1MP * |<--->| +-------------+ | | 978 | | Mapping | | | +------------+ | | | Other | | | 979 | | (e.g. RFC1906) | | | +------------+ | | | Security | | | 980 | | | | +->| v2cMP * |<--->| | Model | | | 981 | | Message | | | +------------+ | | +-------------+ | | 982 | | Dispatcher <--------->+ | | | | 983 | | | | | +------------+ | | +-------------+ | | 984 | | | | +->| v3MP * |<--->| | User-based | | | 985 | | | | | +------------+ | | | Security | | | 986 | | | | | +------------+ | | | Model | | | 987 | | PDU Dispatcher | | +->| otherMP * |<--->| +-------------+ | | 988 | +-------------------+ | +------------+ | | | | 989 | ^ +---------------------+ +-----------------+ | 990 | | | 991 | v | 992 | +-------+-------------------------+----------------+ | 993 | ^ ^ ^ | 994 | | | | | 995 | v v v | 996 | +-------------+ +---------+ +--------------+ +-------------+ | 997 | | COMMAND | | ACCESS | | NOTIFICATION | | PROXY * | | 998 | | RESPONDER |<->| CONTROL |<->| ORIGINATOR | | FORWARDER | | 999 | | application | | | | applications | | application | | 1000 | +-------------+ +---------+ +--------------+ +-------------+ | 1001 | ^ ^ | 1002 | | | | 1003 | v v | 1004 | +----------------------------------------------+ | 1005 | | MIB instrumentation | SNMP entity | 1006 +--------------------------------------------------------------------+ 1008 Draft An Architecture for SNMP Management Frameworks August 1997 1010 3. Elements of the Architecture 1012 This section describes the various elements of the architecture and 1013 how they are named. There are three kinds of naming: 1015 1) the naming of entities, 1016 2) the naming of identities, and 1017 3) the naming of management information. 1019 This architecture also defines some names for other constructs that 1020 are used in the documentation. 1022 3.1. The Naming of Entities 1024 The following picture shows detail about an SNMP entity and how 1025 components within it are named. 1027 +--------------------------------------------------------------------+ 1028 | SNMP entity | 1029 | | 1030 | +--------------------------------------------------------------+ | 1031 | | SNMP engine (identified by snmpEngineID) | | 1032 | | | | 1033 | | +-------------+ +------------+ +-----------+ +-----------+ | | 1034 | | | | | | | | | | | | 1035 | | | Dispatcher | | Message | | Security | | Access | | | 1036 | | | | | Processing | | Subsystem | | Control | | | 1037 | | | | | Subsystem | | | | Subsystem | | | 1038 | | | | | | | | | | | | 1039 | | +-------------+ +------------+ +-----------+ +-----------+ | | 1040 | | | | 1041 | +--------------------------------------------------------------+ | 1042 | | 1043 | +--------------------------------------------------------------+ | 1044 | | Application(s) | | 1045 | | | | 1046 | | +-------------+ +--------------+ +--------------+ | | 1047 | | | Command | | Notification | | Proxy | | | 1048 | | | Generator | | Receiver | | Forwarder | | | 1049 | | +-------------+ +--------------+ +--------------+ | | 1050 | | | | 1051 | | +-------------+ +--------------+ +--------------+ | | 1052 | | | Command | | Notification | | Other | | | 1053 | | | Responder | | Originator | | | | | 1054 | | +-------------+ +--------------+ +--------------+ | | 1055 | | | | 1056 | +--------------------------------------------------------------+ | 1057 | | 1058 +--------------------------------------------------------------------+ 1060 Draft An Architecture for SNMP Management Frameworks August 1997 1062 3.1.1. SNMP entity 1064 An SNMP entity is an implementation of this architecture. Each such 1065 SNMP entity consists of an SNMP engine and one or more associated 1066 applications. 1068 3.1.2. SNMP engine 1070 An SNMP engine provides services for sending and receiving messages, 1071 authenticating and encrypting messages, and controlling access to 1072 managed objects. There is a one-to-one association between an SNMP 1073 engine and the SNMP entity which contains it. 1075 The engine contains: 1077 1) a Dispatcher, 1078 2) a Message Processing Subsystem, 1079 3) a Security Subsystem, and 1080 4) an Access Control Subsystem. 1082 3.1.3. snmpEngineID 1084 Within an administrative domain, an snmpEngineID is the unique 1085 and unambiguous identifier of an SNMP engine. Since there is a 1086 one-to-one association between SNMP engines and SNMP entities, 1087 it also uniquely and unambiguously identifies the SNMP entity. 1089 3.1.4. Dispatcher 1091 There is only one Dispatcher in an SNMP engine. It allows for 1092 concurrent support of multiple versions of SNMP messages in the 1093 SNMP engine. It does so by: 1095 - sending and receiving SNMP messages to/from the network, 1097 - determining the version of an SNMP message and interact 1098 with the corresponding Message Processing Model, 1100 - providing an abstract interface to SNMP applications for 1101 dispatching a PDU to an application. 1103 - providing an abstract interface for SNMP applications that 1104 allows them to send a PDU to a remote SNMP entity. 1106 Draft An Architecture for SNMP Management Frameworks August 1997 1108 3.1.5. Message Processing Subsystem 1110 The Message Processing Subsystem is responsible for preparing 1111 messages for sending, and extracting data from received messages. 1113 The Message Processing Subsystem potentially contains multiple 1114 Message Processing Models as shown in the next picture. 1115 * One or more Message Processing Models may be present. 1117 +------------------------------------------------------------------+ 1118 | | 1119 | Message Processing Subsystem | 1120 | | 1121 | +------------+ +------------+ +------------+ +------------+ | 1122 | | * | | * | | * | | * | | 1123 | | SNMPv3 | | SNMPv1 | | SNMPv2c | | Other | | 1124 | | Message | | Message | | Message | | Message | | 1125 | | Processing | | Processing | | Processing | | Processing | | 1126 | | Model | | Model | | Model | | Model | | 1127 | | | | | | | | | | 1128 | +------------+ +------------+ +------------+ +------------+ | 1129 | | 1130 +------------------------------------------------------------------+ 1132 3.1.6. Message Processing Model 1134 Each Message Processing Model defines the format of a particular 1135 version of an SNMP message and coordinates the preparation and 1136 extraction of each such version-specific messages. 1138 Draft An Architecture for SNMP Management Frameworks August 1997 1140 3.1.7. Security Subsystem 1142 The Security Subsystem provides security services such as the 1143 authentication and privacy of messages and potentially contains 1144 multiple Security Models as shown in the next picture. 1145 * One or more Security Models may be present. 1147 +------------------------------------------------------------------+ 1148 | | 1149 | Security Subsystem | 1150 | | 1151 | +----------------+ +-----------------+ +-------------------+ | 1152 | | * | | * | | * | | 1153 | | User-Based | | Other | | Other | | 1154 | | Security | | Security | | Security | | 1155 | | Model | | Model | | Model | | 1156 | | | | | | | | 1157 | +----------------+ +-----------------+ +-------------------+ | 1158 | | 1159 +------------------------------------------------------------------+ 1161 3.1.8. Security Model 1163 A Security Model defines the threats against which it protects, 1164 the goals of its services, and the security protocols used to provide 1165 security services such as authentication and privacy. 1167 3.1.9. Security Protocol 1169 A Security Protocol defines the mechanisms, procedures, and MIB 1170 data used to provide a security service such as authentication 1171 or privacy. 1173 Draft An Architecture for SNMP Management Frameworks August 1997 1175 3.1.10. Access Control Subsystem 1177 The Access Control Subsystem provides authorization services by 1178 means of one or more Access Control Models. 1180 +------------------------------------------------------------------+ 1181 | | 1182 | Access Control Subsystem | 1183 | | 1184 | +---------------+ +-----------------+ +------------------+ | 1185 | | * | | * | | * | | 1186 | | View-Based | | Other | | Other | | 1187 | | Access | | Access | | Access | | 1188 | | Control | | Control | | Control | | 1189 | | Model | | Model | | Model | | 1190 | | | | | | | | 1191 | +---------------+ +-----------------+ +------------------+ | 1192 | | 1193 +------------------------------------------------------------------+ 1195 3.1.11. Access Control Model 1197 An Access Control Model defines a particular access decision function 1198 in order to support decisions regarding access rights. 1200 Draft An Architecture for SNMP Management Frameworks August 1997 1202 3.1.12. Applications 1204 There are several types of applications, including: 1206 - command generators, which monitor and manipulate management data, 1207 - command responders, which provide access to management data, 1208 - notification originators, which initiate asynchronous messages, 1209 - notification receivers, which process asynchronous messages, and 1210 - proxy forwarders, which forward messages between entities. 1212 These applications make use of the services provided by the SNMP 1213 engine. 1215 3.1.13. SNMP Agent 1217 An SNMP entity containing one or more command responder and/or 1218 notification originator applications (along with their associated 1219 SNMP engine) has traditionally been called an SNMP agent. 1221 3.1.14. SNMP Manager 1223 An SNMP entity containing one or more command generator and/or 1224 notification receiver applications (along with their associated 1225 SNMP engine) has traditionally been called an SNMP manager. 1227 Draft An Architecture for SNMP Management Frameworks August 1997 1229 3.2. The Naming of Identities 1231 principal <---------------------------------+ 1232 | 1233 +-------------------------------------|-----+ 1234 | SNMP engine | | 1235 | | | 1236 | +-----------------------+ | | 1237 | | Security Model | | | 1238 | | +-------------+ | | | 1239 wire | | | Model | +------------+--+ | 1240 <----------->| Dependent |<-->| | securityName| | 1241 | | | Security ID | +---------------+ | 1242 | | +-------------+ | | 1243 | | | | 1244 | +-----------------------+ | 1245 | | 1246 | | 1247 +-------------------------------------------+ 1249 3.2.1. Principal 1251 A principal is the "who" on whose behalf services are provided 1252 or processing takes place. 1254 A principal can be, among other things, an individual acting in 1255 a particular role; a set of individuals, with each acting in a 1256 particular role; an application; or a set of applications; 1257 and combinations thereof. 1259 3.2.2. securityName 1261 A securityName is a human readable string representing a principal. 1262 It has a model independent format, and can be used outside a 1263 particular Security Model. 1265 3.2.3. Model dependent security ID 1267 A model dependent security ID is the model specific representation 1268 of a securityName within a particular Security Model. 1270 Model dependent security IDs may or may not be human readable, and 1271 have a model dependent syntax. Examples include community names, 1272 user names, and parties. 1274 The transformation of model dependent security IDs into securityNames 1275 and vice versa is the responsibility of the relevant Security Model. 1277 Draft An Architecture for SNMP Management Frameworks August 1997 1279 3.3. The Naming of Management Information 1281 Management information resides at an SNMP entity where a Command 1282 Responder Application has local access to potentially multiple 1283 contexts. Such a Command Responder application uses a contextEngineID 1284 equal to the snmpEngineID of its associated SNMP engine. 1286 +-----------------------------------------------------------------+ 1287 | SNMP entity (identified by snmpEngineID, example: abcd) | 1288 | | 1289 | +------------------------------------------------------------+ | 1290 | | SNMP engine (identified by snmpEngineID) | | 1291 | | | | 1292 | | +-------------+ +------------+ +-----------+ +-----------+ | | 1293 | | | | | | | | | | | | 1294 | | | Dispatcher | | Message | | Security | | Access | | | 1295 | | | | | Processing | | Subsystem | | Control | | | 1296 | | | | | Subsystem | | | | Subsystem | | | 1297 | | | | | | | | | | | | 1298 | | +-------------+ +------------+ +-----------+ +-----------+ | | 1299 | | | | 1300 | +------------------------------------------------------------+ | 1301 | | 1302 | +------------------------------------------------------------+ | 1303 | | Command Responder Application | | 1304 | | (contextEngineID, example: abcd) | | 1305 | | | | 1306 | | example contextNames: | | 1307 | | | | 1308 | | "bridge1" "bridge2" "" (default) | | 1309 | | --------- --------- ------------ | | 1310 | | | | | | | 1311 | +------|------------------|-------------------|--------------+ | 1312 | | | | | 1313 | +------|------------------|-------------------|--------------+ | 1314 | | MIB | instrumentation | | | | 1315 | | +---v------------+ +---v------------+ +----v-----------+ | | 1316 | | | context | | context | | context | | | 1317 | | | | | | | | | | 1318 | | | +------------+ | | +------------+ | | +------------+ | | | 1319 | | | | bridge MIB | | | | bridge MIB | | | | other MIB | | | | 1320 | | | +------------+ | | +------------+ | | +------------+ | | | 1321 | | | | | | | | | | 1322 | | | | | | | +------------+ | | | 1323 | | | | | | | | some MIB | | | | 1324 | | | | | | | +------------+ | | | 1325 | | | | | | | | | | 1326 +-----------------------------------------------------------------+ 1328 Draft An Architecture for SNMP Management Frameworks August 1997 1330 3.3.1. An SNMP Context 1332 An SNMP context, or just "context" for short, is a collection of 1333 management information accessible by an SNMP entity. An item of 1334 management information may exist in more than one context. An SNMP 1335 engine potentially has access to many contexts. 1337 Typically, there are many instances of each managed object type within 1338 a management domain. For simplicity, the method for identifying 1339 instances specified by the MIB module does not allow each instance to 1340 be distinguished amongst the set of all instances within a management 1341 domain; rather, it allows each instance to be identified only within 1342 some scope or "context", where there are multiple such contexts within 1343 the management domain. Often, a context is a physical device, or 1344 perhaps, a logical device, although a context can also encompass 1345 multiple devices, or a subset of a single device, or even a subset of 1346 multiple devices, but a context is always defined as a subset of a 1347 single SNMP entity. Thus, in order to identify an individual item of 1348 management information within the management domain, its contextName 1349 and contextEngineID must be identified in addition to its object type 1350 and its instance. 1352 For example, the managed object type ifDescr [RFC1573], is defined as 1353 the description of a network interface. To identify the description 1354 of device-X's first network interface, four pieces of information are 1355 needed: the snmpEngineID of the SNMP entity which provides access to 1356 the management information at device-X, the contextName (device-X), 1357 the managed object type (ifDescr), and the instance ("1"). 1359 Each context has (at least) one unique identification within the 1360 management domain. The same item of management information can exist 1361 in multiple contexts. So, an item of management information can have 1362 multiple unique identifications, either because it exists in multiple 1363 contexts, and/or because each such context has multiple unique 1364 identifications. 1366 The combination of a contextEngineID and a contextName unambiguously 1367 identifies a context within an administrative domain. 1369 3.3.2. contextEngineID 1371 Within an administrative domain, a contextEngineID uniquely 1372 identifies an SNMP entity that may realize an instance of a 1373 context with a particular contextName. 1375 3.3.3. contextName 1377 A contextName is used to name a context. Each contextName 1378 MUST be unique within an SNMP entity. 1380 Draft An Architecture for SNMP Management Frameworks August 1997 1382 3.3.4. scopedPDU 1384 A scopedPDU is a block of data containing a contextEngineID, 1385 a contextName, and a PDU. 1387 The PDU is an SNMP Protocol Data Unit containing information 1388 named in the context which is unambiguously identified within 1389 an administrative domain by the combination of the contextEngineID 1390 and the contextName. See, for example, RFC1905 for more information 1391 about SNMP PDUs. 1393 3.4. Other Constructs 1395 3.4.1. maxSizeResponseScopedPDU 1397 The maxSizeResponseScopedPDU is the maximum size of a scopedPDU to 1398 be included in a response message, making allowance for the message 1399 header. 1401 3.4.2. Local Configuration Datastore 1403 The subsystems, models, and applications within an SNMP entity may 1404 need to retain their own sets of configuration information. 1406 Portions of the configuration information may be accessible as 1407 managed objects. 1409 The collection of these sets of information is referred to 1410 as an entity's Local Configuration Datastore (LCD). 1412 3.4.3. securityLevel 1414 This architecture recognizes three levels of security: 1416 - without authentication and without privacy (noAuthNoPriv) 1417 - with authentication but without privacy (authNoPriv) 1418 - with authentication and with privacy (authPriv) 1420 These three values are ordered such that noAuthNoPriv is less than 1421 authNoPriv and authNoPriv is less than authPriv. 1423 Every message has an associated securityLevel. All Subsystems (Message 1424 Processing, Security, Access Control) and applications are required 1425 to either supply a value of securityLevel or to abide by the supplied 1426 value of securityLevel while processing the message and its contents. 1428 Draft An Architecture for SNMP Management Frameworks August 1997 1430 4. Abstract Service Interfaces. 1432 Abstract service interfaces have been defined to describe the 1433 conceptual interfaces between the various subsystems within an SNMP 1434 entity. 1436 These abstract service interfaces are defined by a set of primitives 1437 that define the services provided and the abstract data elements that 1438 are to be passed when the services are invoked. This section lists 1439 the primitives that have been defined for the various subsystems. 1441 4.1. Common Primitives 1443 These primitive(s) are provided by multiple Subsystems. 1445 4.1.1. Release State Reference Information 1447 All Subsystems which pass stateReference information also provide a 1448 primitive to release the memory that holds the referenced state 1449 information: 1451 stateRelease( 1452 IN stateReference -- handle of reference to be released 1453 ) 1455 4.2. Dispatcher Primitives 1457 The Dispatcher typically provides services to the SNMP applications via 1458 its PDU Dispatcher. This section describes the primitives provided by 1459 the PDU Dispatcher. 1461 4.2.1. Generate Outgoing Request or Notification 1463 The PDU Dispatcher provides the following primitive for an application 1464 to send an SNMP Request or Notification to another SNMP entity: 1466 statusInformation = -- sendPduHandle if success 1467 -- errorIndication if failure 1468 sendPdu( 1469 IN transportDomain -- transport domain to be used 1470 IN transportAddress -- transport address to be used 1471 IN messageProcessingModel -- typically, SNMP version 1472 IN securityModel -- Security Model to use 1473 IN securityName -- on behalf of this principal 1474 IN securityLevel -- Level of Security requested 1475 IN contextEngineID -- data from/at this entity 1476 IN contextName -- data from/in this context 1477 IN pduVersion -- the version of the PDU 1478 IN PDU -- SNMP Protocol Data Unit 1479 IN expectResponse -- TRUE or FALSE 1480 ) 1482 Draft An Architecture for SNMP Management Frameworks August 1997 1484 4.2.2. Process Incoming Request or Notification PDU 1486 The PDU Dispatcher provides the following primitive to pass an incoming 1487 SNMP PDU to an application: 1489 processPdu( -- process Request/Notification PDU 1490 IN messageProcessingModel -- typically, SNMP version 1491 IN securityModel -- Security Model in use 1492 IN securityName -- on behalf of this principal 1493 IN securityLevel -- Level of Security 1494 IN contextEngineID -- data from/at this SNMP entity 1495 IN contextName -- data from/in this context 1496 IN pduVersion -- the version of the PDU 1497 IN PDU -- SNMP Protocol Data Unit 1498 IN maxSizeResponseScopedPDU -- maximum size of the Response PDU 1499 IN stateReference -- reference to state information 1500 ) -- needed when sending a response 1502 4.2.3. Generate Outgoing Response 1504 The PDU Dispatcher provides the following primitive for an application 1505 to return an SNMP Response PDU to the PDU Dispatcher: 1507 returnResponsePdu( 1508 IN messageProcessingModel -- typically, SNMP version 1509 IN securityModel -- Security Model in use 1510 IN securityName -- on behalf of this principal 1511 IN securityLevel -- same as on incoming request 1512 IN contextEngineID -- data from/at this SNMP entity 1513 IN contextName -- data from/in this context 1514 IN pduVersion -- the version of the PDU 1515 IN PDU -- SNMP Protocol Data Unit 1516 IN maxSizeResponseScopedPDU -- maximum size of the Response PDU 1517 IN stateReference -- reference to state information 1518 -- as presented with the request 1519 IN statusInformation -- success or errorIndication 1520 ) -- error counter OID/value if error 1522 4.2.4. Process Incoming Response PDU 1524 The PDU Dispatcher provides the following primitive to pass an incoming 1525 SNMP Response PDU to an application: 1527 processResponsePdu( -- process Response PDU 1528 IN messageProcessingModel -- typically, SNMP version 1529 IN securityModel -- Security Model in use 1530 IN securityName -- on behalf of this principal 1531 IN securityLevel -- Level of Security 1532 IN contextEngineID -- data from/at this SNMP entity 1533 IN contextName -- data from/in this context 1535 Draft An Architecture for SNMP Management Frameworks August 1997 1537 IN pduVersion -- the version of the PDU 1538 IN PDU -- SNMP Protocol Data Unit 1539 IN statusInformation -- success or errorIndication 1540 IN sendPduHandle -- handle from sendPDU 1541 ) 1543 4.2.5. Registering Responsibility for Handling SNMP PDUs. 1545 Applications can register/unregister responsibility for a specific 1546 contextEngineID, for specific pduTypes, with the PDU Dispatcher 1547 according to these primitives: 1549 statusInformation = -- success or errorIndication 1550 registerContextEngineID( 1551 IN contextEngineID -- take responsibility for this one 1552 IN pduType -- the pduType(s) to be registered 1553 ) 1555 unregisterContextEngineID( 1556 IN contextEngineID -- give up responsibility for this one 1557 IN pduType -- the pduType(s) to be unregistered 1558 ) 1560 4.3. Message Processing Subsystem Primitives 1562 The Dispatcher interacts with a Message Processing Model to process a 1563 specific version of an SNMP Message. This section describes the 1564 primitives provided by the Message Processing Subsystem. 1566 4.3.1. Prepare an Outgoing SNMP Request or Notification Message 1568 The Message Processing Subsystem provides this service primitive for 1569 preparing an outgoing SNMP Request or Notification Message: 1571 statusInformation = -- success or errorIndication 1572 prepareOutgoingMessage( 1573 IN transportDomain -- transport domain to be used 1574 IN transportAddress -- transport address to be used 1575 IN messageProcessingModel -- typically, SNMP version 1576 IN securityModel -- Security Model to use 1577 IN securityName -- on behalf of this principal 1578 IN securityLevel -- Level of Security requested 1579 IN contextEngineID -- data from/at this entity 1580 IN contextName -- data from/in this context 1581 IN pduVersion -- the version of the PDU 1582 IN PDU -- SNMP Protocol Data Unit 1583 IN expectResponse -- TRUE or FALSE 1584 IN sendPduHandle -- the handle for matching 1585 -- incoming responses 1586 OUT destTransportDomain -- destination transport domain 1587 OUT destTransportAddress -- destination transport address 1589 Draft An Architecture for SNMP Management Frameworks August 1997 1591 OUT outgoingMessage -- the message to send 1592 OUT outgoingMessageLength -- its length 1593 ) 1595 4.3.2. Prepare an Outgoing SNMP Response Message 1597 The Message Processing Subsystem provides this service primitive for 1598 preparing an outgoing SNMP Response Message: 1600 result = -- SUCCESS or FAILURE 1601 prepareResponseMessage( 1602 IN messageProcessingModel -- typically, SNMP version 1603 IN securityModel -- same as on incoming request 1604 IN securityName -- same as on incoming request 1605 IN securityLevel -- same as on incoming request 1606 IN contextEngineID -- data from/at this SNMP entity 1607 IN contextName -- data from/in this context 1608 IN pduVersion -- the version of the PDU 1609 IN PDU -- SNMP Protocol Data Unit 1610 IN maxSizeResponseScopedPDU -- maximum size of the Response PDU 1611 IN stateReference -- reference to state information 1612 -- as presented with the request 1613 IN statusInformation -- success or errorIndication 1614 -- error counter OID/value if error 1615 OUT destTransportDomain -- destination transport domain 1616 OUT destTransportAddress -- destination transport address 1617 OUT outgoingMessage -- the message to send 1618 OUT outgoingMessageLength -- its length 1619 ) 1621 4.3.3. Prepare Data Elements from an Incoming SNMP Message 1623 The Message Processing Subsystem provides this service primitive for 1624 preparing the abstract data elements from an incoming SNMP message: 1626 result = -- SUCCESS or errorIndication 1627 prepareDataElements( 1628 IN transportDomain -- origin transport domain 1629 IN transportAddress -- origin transport address 1630 IN wholeMsg -- as received from the network 1631 IN wholeMsglength -- as received from the network 1632 OUT messageProcessingModel -- typically, SNMP version 1633 OUT securityModel -- Security Model to use 1634 OUT securityName -- on behalf of this principal 1635 OUT securityLevel -- Level of Security requested 1636 OUT contextEngineID -- data from/at this entity 1637 OUT contextName -- data from/in this context 1638 OUT pduVersion -- the version of the PDU 1639 OUT PDU -- SNMP Protocol Data Unit 1640 OUT pduType -- SNMP PDU type 1641 OUT sendPduHandle -- handle for matched request 1643 Draft An Architecture for SNMP Management Frameworks August 1997 1645 OUT maxSizeResponseScopedPDU -- maximum size of the Response PDU 1646 OUT statusInformation -- success or errorIndication 1647 -- error counter OID/value if error 1648 OUT stateReference -- reference to state information 1649 -- to be used for a possible Response 1650 ) 1652 4.4. Access Control Subsystem Primitives 1654 Applications are the typical clients of the service(s) of the Access 1655 Control Subsystem. 1657 The following primitive is provided by the Access Control Subsystem 1658 to check if access is allowed: 1660 statusInformation = -- success or errorIndication 1661 isAccessAllowed( 1662 IN securityModel -- Security Model in use 1663 IN securityName -- principal who wants to access 1664 IN securityLevel -- Level of Security 1665 IN viewType -- read, write, or notify view 1666 IN contextName -- context containing variableName 1667 IN variableName -- OID for the managed object 1668 ) 1670 4.5. Security Subsystem Primitives 1672 The Message Processing Subsystem is the typical client of the services 1673 of the Security Subsystem. 1675 4.5.1. Generate a Request or Notification Message 1677 The Security Subsystem provides the following primitive to generate 1678 a Request or Notification message: 1680 statusInformation = 1681 generateRequestMsg( 1682 IN messageProcessingModel -- typically, SNMP version 1683 IN globalData -- message header, admin data 1684 IN maxMessageSize -- of the sending SNMP entity 1685 IN securityModel -- for the outgoing message 1686 IN securityEngineID -- authoritative SNMP entity 1687 IN securityName -- on behalf of this principal 1688 IN securityLevel -- Level of Security requested 1689 IN scopedPDU -- message (plaintext) payload 1690 OUT securityParameters -- filled in by Security Module 1691 OUT wholeMsg -- complete generated message 1692 OUT wholeMsgLength -- length of the generated message 1693 ) 1695 4.5.2. Process Incoming Message 1696 Draft An Architecture for SNMP Management Frameworks August 1997 1698 The Security Subsystem provides the following primitive to process 1699 an incoming message: 1701 statusInformation = -- errorIndication or success 1702 -- error counter OID/value if error 1703 processIncomingMsg( 1704 IN messageProcessingModel -- typically, SNMP version 1705 IN maxMessageSize -- of the sending SNMP entity 1706 IN securityParameters -- for the received message 1707 IN securityModel -- for the received message 1708 IN securityLevel -- Level of Security 1709 IN wholeMsg -- as received on the wire 1710 IN wholeMsgLength -- length as received on the wire 1711 OUT securityEngineID -- identification of the principal 1712 OUT securityName -- identification of the principal 1713 OUT scopedPDU, -- message (plaintext) payload 1714 OUT maxSizeResponseScopedPDU -- maximum size of the Response PDU 1715 OUT securityStateReference -- reference to security state 1716 ) -- information, needed for response 1718 4.5.3. Generate a Response Message 1720 The Security Subsystem provides the following primitive to generate 1721 a Response message: 1723 statusInformation = 1724 generateResponseMsg( 1725 IN messageProcessingModel -- typically, SNMP version 1726 IN globalData -- message header, admin data 1727 IN maxMessageSize -- of the sending SNMP entity 1728 IN securityModel -- for the outgoing message 1729 IN securityEngineID -- authoritative SNMP entity 1730 IN securityName -- on behalf of this principal 1731 IN securityLevel -- for the outgoing message 1732 IN scopedPDU -- message (plaintext) payload 1733 IN securityStateReference -- reference to security state 1734 -- information from original request 1735 OUT securityParameters -- filled in by Security Module 1736 OUT wholeMsg -- complete generated message 1737 OUT wholeMsgLength -- length of the generated message 1738 ) 1740 4.6. User Based Security Model Internal Primitives 1742 4.6.1. User-based Security Model Primitives for Authentication 1744 The User-based Security Model provides the following internal 1745 primitives to pass data back and forth between the Security Model 1746 itself and the authentication service: 1748 Draft An Architecture for SNMP Management Frameworks August 1997 1750 statusInformation = 1751 authenticateOutgoingMsg( 1752 IN authKey -- secret key for authentication 1753 IN wholeMsg -- unauthenticated complete message 1754 OUT authenticatedWholeMsg -- complete authenticated message 1755 ) 1757 statusInformation = 1758 authenticateIncomingMsg( 1759 IN authKey -- secret key for authentication 1760 IN authParameters -- as received on the wire 1761 IN wholeMsg -- as received on the wire 1762 OUT authenticatedWholeMsg -- complete authenticated message 1763 ) 1765 4.6.2. User-based Security Model Primitives for Privacy 1767 The User-based Security Model provides the following internal 1768 primitives to pass data back and forth between the Security Model 1769 itself and the privacy service: 1771 statusInformation = 1772 encryptData( 1773 IN encryptKey -- secret key for encryption 1774 IN dataToEncrypt -- data to encrypt (scopedPDU) 1775 OUT encryptedData -- encrypted data (encryptedPDU) 1776 OUT privParameters -- filled in by service provider 1777 ) 1779 statusInformation = 1780 decryptData( 1781 IN decryptKey -- secret key for decrypting 1782 IN privParameters -- as received on the wire 1783 IN encryptedData -- encrypted data (encryptedPDU) 1784 OUT decryptedData -- decrypted data (scopedPDU) 1785 ) 1787 Draft An Architecture for SNMP Management Frameworks August 1997 1789 4.7. Scenario Diagrams 1791 4.7.1. Command Generator or Notification Originator Application 1793 This diagram shows how a Command Generator or Notification Originator 1794 application requests that a PDU be sent, and how the response is 1795 returned (asynchronously) to that application. 1797 Command Dispatcher Message Security 1798 Generator | Processing Model 1799 | | Model | 1800 | | | | 1801 | sendPdu | | | 1802 |------------------->| | | 1803 | | prepareOutgoingMessage | | 1804 : |------------------------->| | 1805 : | | generateRequestMsg | 1806 : | |-------------------->| 1807 : | | | 1808 : | |<--------------------| 1809 : | | | 1810 : |<-------------------------| | 1811 : | | | 1812 : |------------------+ | | 1813 : | Send SNMP | | | 1814 : | Request Message | | | 1815 : | to Network | | | 1816 : | v | | 1817 : : : : : 1818 : : : : : 1819 : : : : : 1820 : | | | | 1821 : | | | | 1822 : | Receive SNMP | | | 1823 : | Response Message | | | 1824 : | from Network | | | 1825 : |<-----------------+ | | 1826 : | | | 1827 : | prepareDataElements | | 1828 : |------------------------->| | 1829 : | | processIncomingMsg | 1830 : | |-------------------->| 1831 : | | | 1832 : | |<--------------------| 1833 : | | | 1834 : |<-------------------------| | 1835 | processResponsePdu | | | 1836 |<-------------------| | | 1837 | | | | 1838 Draft An Architecture for SNMP Management Frameworks August 1997 1840 4.7.2. Scenario Diagram for a Command Responder Application 1842 This diagram shows how a Command Responder or Notification Receiver 1843 application registers for handling a pduType, how a PDU is dispatched 1844 to the application after a SNMP message is received, and how the 1845 Response is (asynchronously) send back to the network. 1847 Command Dispatcher Message Security 1848 Responder | Processing Model 1849 | | Model | 1850 | | | | 1851 | registerContextEngineID | | | 1852 |------------------------>| | | 1853 |<------------------------| | | | 1854 | | Receive SNMP | | | 1855 : | Message | | | 1856 : | from Network | | | 1857 : |<-------------+ | | 1858 : | | | 1859 : | prepareDataElements | | 1860 : |-------------------->| | 1861 : | | processIncomingMsg | 1862 : | |-------------------->| 1863 : | | | 1864 : | |<--------------------| 1865 : | | | 1866 : |<--------------------| | 1867 | processPdu | | | 1868 |<------------------------| | | 1869 | | | | 1870 : : : : 1871 : : : : 1872 | returnResponsePdu | | | 1873 |------------------------>| | | 1874 : | prepareResponseMsg | | 1875 : |-------------------->| | 1876 : | | generateResponseMsg | 1877 : | |-------------------->| 1878 : | | | 1879 : | |<--------------------| 1880 : | | | 1881 : |<--------------------| | 1882 : | | | 1883 : |--------------+ | | 1884 : | Send SNMP | | | 1885 : | Message | | | 1886 : | to Network | | | 1887 : | v | | 1888 Draft An Architecture for SNMP Management Frameworks August 1997 1890 5. Definition of Managed Objects for SNMP Management Frameworks 1892 SNMP-FRAMEWORK-MIB DEFINITIONS ::= BEGIN 1894 IMPORTS 1895 MODULE-IDENTITY, OBJECT-TYPE, 1896 OBJECT-IDENTITY, 1897 snmpModules, Unsigned32, Integer32 FROM SNMPv2-SMI 1898 TEXTUAL-CONVENTION FROM SNMPv2-TC 1899 MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF; 1901 snmpFrameworkMIB MODULE-IDENTITY 1902 LAST-UPDATED "9707260000Z" -- 26 July 1997, midnight 1903 ORGANIZATION "SNMPv3 Working Group" 1904 CONTACT-INFO "WG-email: snmpv3@tis.com 1905 Subscribe: majordomo@tis.com 1906 In message body: subscribe snmpv3 1908 Chair: Russ Mundy 1909 Trusted Information Systems 1910 postal: 3060 Washington Rd 1911 Glenwood MD 21738 1912 USA 1913 email: mundy@tis.com 1914 phone: +1-301-854-6889 1916 Co-editor Dave Harrington 1917 Cabletron Systems, Inc 1918 postal: Post Office Box 5005 1919 MailStop: Durham 1920 35 Industrial Way 1921 Rochester NH 03867-5005 1922 USA 1923 email: dbh@cabletron.com 1924 phone: +1-603-337-7357 1926 Co-editor: Bert Wijnen 1927 IBM T.J. Watson Research 1928 postal: Schagen 33 1929 3461 GL Linschoten 1930 Netherlands 1931 email: wijnen@vnet.ibm.com 1932 phone: +31-348-432-794 1933 " 1934 DESCRIPTION "The SNMP Management Architecture MIB" 1935 ::= { snmpModules 7 } -- DBH: check if this number is indeed OK 1937 -- Textual Conventions used in the SNMP Management Architecture *** 1939 SnmpEngineID ::= TEXTUAL-CONVENTION 1940 STATUS current 1942 Draft An Architecture for SNMP Management Frameworks August 1997 1944 DESCRIPTION "An SNMP engine's administratively-unique identifier. 1946 The value for this object may not be all zeros or 1947 all 'ff'H or the empty (zero length) string. 1949 The initial value for this object may be configured 1950 via an operator console entry or via an algorithmic 1951 function. In the latter case, the following 1952 example algorithm is recommended. 1954 1) The very first bit is used to indicate how the 1955 rest of the data is composed. 1957 0 - as defined by enterprise using former methods 1958 that existed before SNMPv3. See item 2 below. 1960 1 - as defined by this architecture, see item 3 1961 below. 1963 Note that this allows existing uses of the 1964 engineID (also known as AgentID [RFC1910]) to 1965 co-exist with any new uses. 1967 2) The snmpEngineID has a length of 12 octets. 1969 The first four octets are set to the binary 1970 equivalent of the agent's SNMP network management 1971 private enterprise number as assigned by the 1972 Internet Assigned Numbers Authority (IANA). 1973 For example, if Acme Networks has been assigned 1974 { enterprises 696 }, the first four octets would 1975 be assigned '000002b8'H. 1977 The remaining eight octets are determined via 1978 one or more enterprise specific methods. Such 1979 methods must be designed so as to maximize the 1980 possibility that the value of this object will 1981 be unique in the agent's administrative domain. 1982 For example, it may be the IP address of the SNMP 1983 entity, or the MAC address of one of the 1984 interfaces, with each address suitably padded 1985 with random octets. If multiple methods are 1986 defined, then it is recommended that the first 1987 octet indicate the method being used and the 1988 remaining octets be a function of the method. 1990 3) The length of the octet strings varies. 1992 The first four octets are set to the binary 1993 equivalent of the agent's SNMP network management 1994 private enterprise number as assigned by the 1996 Draft An Architecture for SNMP Management Frameworks August 1997 1998 Internet Assigned Numbers Authority (IANA). 1999 For example, if Acme Networks has been assigned 2000 { enterprises 696 }, the first four octets would 2001 be assigned '000002b8'H. 2003 The very first bit is set to 1. For example, the 2004 above value for Acme Networks now changes to be 2005 '800002b8'H. 2007 The fifth octet indicates how the rest (6th and 2008 following octets) are formatted. The values for 2009 the fifth octet are: 2011 0 - reserved, unused. 2013 1 - IPv4 address (4 octets) 2014 lowest non-special IP address 2016 2 - IPv6 address (16 octets) 2017 lowest non-special IP address 2019 3 - MAC address (6 octets) 2020 lowest IEEE MAC address, canonical order 2022 4 - Text, administratively assigned 2023 Maximum remaining length 27 2025 5 - Octets, administratively assigned 2026 Maximum remaining length 27 2028 6-127 - reserved, unused 2030 127-255 - as defined by the enterprise 2031 Maximum remaining length 27 2032 " 2033 SYNTAX OCTET STRING (SIZE(1..32)) 2035 SnmpSecurityModel ::= TEXTUAL-CONVENTION 2036 STATUS current 2037 DESCRIPTION "An identifier that uniquely identifies a securityModel 2038 of the Security Subsystem within the SNMP 2039 Management Architecture. 2041 The values for securityModel are allocated as follows: 2043 - The zero value is reserved. 2044 - Values between 1 and 255, inclusive, are reserved 2045 for standards-track Security Models and are managed 2046 by the Internet Assigned Numbers Authority (IANA). 2047 - Values greater than 255 are allocated to enterprise 2048 specific Security Models. An enterprise specific 2050 Draft An Architecture for SNMP Management Frameworks August 1997 2052 securityModel value is defined to be: 2054 enterpriseID * 256 + security model within enterprise 2056 For example, the fourth Security Model defined by 2057 the enterprise whose enterpriseID is 1 would be 260. 2059 The eight bits allow a maximum of 255 (256-1 reserved) 2060 standards based Security Models. Similarly, they 2061 allow a maximum of 255 Security Models per enterprise. 2063 It is believed that the assignment of new 2064 securityModel values will be rare in practice 2065 because the larger the number of simultaneously 2066 utilized Security Models, the larger the chance that 2067 interoperability will suffer. Consequently, it is 2068 believed that such a range will be sufficient. 2069 In the unlikely event that the standards committee 2070 finds this number to be insufficient over time, an 2071 enterprise number can be allocated to obtain an 2072 additional 255 possible values. 2074 Note that the most significant bit must be zero; 2075 hence, there are 23 bits allocated for various 2076 organizations to design and define non-standard 2077 securityModels. This limits the ability to define 2078 new proprietary implementations of Security Models 2079 to the first 8,388,608 enterprises. 2081 It is worthwhile to note that, in its encoded form, 2082 the securityModel value will normally require only a 2083 single byte since, in practice, the leftmost bits will 2084 be zero for most messages and sign extension is 2085 suppressed by the encoding rules. 2087 As of this writing, there are several values of 2088 securityModel defined for use with SNMP or reserved 2089 for use with supporting MIB objects. They are as 2090 follows: 2092 0 reserved for 'none' 2093 1 reserved for SNMPv1 2094 2 reserved for SNMPv2c 2095 3 User-Base Security Model (USM) 2096 255 reserved for 'any' 2097 " 2098 SYNTAX INTEGER(0..2147483647) 2100 SnmpMessageProcessingModel ::= TEXTUAL-CONVENTION 2101 STATUS current 2102 DESCRIPTION "An identifier that uniquely identifies a Message 2104 Draft An Architecture for SNMP Management Frameworks August 1997 2106 Processing Model of the Message Processing Subsystem 2107 within a SNMP Management Architecture. 2109 The values for messageProcessingModel are allocated 2110 as follows: 2112 - Values between 0 and 255, inclusive, are reserved 2113 for standards-track Message Processing Models and 2114 are managed by the Internet Assigned Numbers 2115 Authority (IANA). 2116 - Values greater than 255 are allocated to enterprise 2117 specific Message Processing Models. An enterprise 2118 messageProcessingModel value is defined to be: 2120 enterpriseID * 256 + 2121 messageProcessingModel within enterprise 2123 For example, the fourth Message Processing Model 2124 defined by the enterprise whose enterpriseID is 1 2125 would be 260. 2127 The eight bits allow a maximum of 256 standards based 2128 Message Processing Models. Similarly, they allow a 2129 maximum 256 Message Processing Models per enterprise. 2131 It is believed that the assignment of new 2132 messageProcessingModel values will be rare in practice 2133 because the larger the number of simultaneously 2134 utilized Message Processing Models, the larger the 2135 chance that interoperability will suffer. It is 2136 believed that such a range will be sufficient. 2137 In the unlikely event that the standards committee 2138 finds this number to be insufficient over time, an 2139 enterprise number can be allocated to obtain an 2140 additional 256 possible values. 2142 Note that the most significant bit must be zero; 2143 hence, there are 23 bits allocated for various 2144 organizations to design and define non-standard 2145 messageProcessingModels. This limits the ability 2146 to define new proprietary implementations of Message 2147 Processing Models to the first 8,388,608 enterprises. 2149 It is worthwhile to note that, in its encoded form, 2150 the securityModel value will normally require only a 2151 single byte since, in practice, the leftmost bits will 2152 be zero for most messages and sign extension is 2153 suppressed by the encoding rules. 2155 As of this writing, there are several values of 2156 messageProcessingModel defined for use with SNMP. 2158 Draft An Architecture for SNMP Management Frameworks August 1997 2160 They are as follows: 2162 0 reserved for SNMPv1 2163 1 reserved for SNMPv2c 2164 2 reserved for SNMPv2u 2165 3 reserved for SNMPv3 2166 " 2167 SYNTAX INTEGER(0..2147483647) 2169 SnmpSecurityLevel ::= TEXTUAL-CONVENTION 2170 STATUS current 2171 DESCRIPTION "A Level of Security at which SNMP messages can be 2172 sent or with which operations are being processed; 2173 in particular, one of: 2175 noAuthNoPriv - without authentication and 2176 without privacy, 2177 authNoPriv - with authentication but 2178 without privacy, 2179 authPriv - with authentication and 2180 with privacy. 2182 These three values are ordered such that noAuthNoPriv 2183 is less than authNoPriv and authNoPriv is less than 2184 authPriv. 2185 " 2186 SYNTAX INTEGER { noAuthNoPriv(1), 2187 authNoPriv(2), 2188 authPriv(3) 2189 } 2191 SnmpAdminString ::= TEXTUAL-CONVENTION 2192 DISPLAY-HINT "255a" 2193 STATUS current 2194 DESCRIPTION "An octet string containing administrative information, 2195 preferably in human-readable form. 2197 To facilitate internationalization, this information 2198 is represented using the ISO/IEC IS 10646-1 character 2199 set, encoded as an octet string using the UTF-8 2200 character encoding scheme described in RFC 2044. 2202 Since additional code points are added by amendments 2203 to the 10646 standard from time to time, 2204 implementations must be prepared to encounter any code 2205 point from 0x00000000 to 0x7fffffff. 2207 The use of control codes should be avoided. 2209 For code points not directly supported by user 2210 interface hardware or software, an alternative means 2212 Draft An Architecture for SNMP Management Frameworks August 1997 2214 of entry and display, such as hexadecimal, may be 2215 provided. 2217 For information encoded in 7-bit US-ASCII, the UTF-8 2218 representation is identical to the US-ASCII encoding. 2220 Note that when this TC is used for an object that 2221 is used or envisioned to be used as an index, then a 2222 SIZE restriction must be specified so that the number 2223 sub-identifiers for any object instance do not exceed 2224 the limit of 128, as defined by [RFC1905]. 2225 " 2226 SYNTAX OCTET STRING (SIZE (0..255)) 2228 -- Administrative assignments **************************************** 2230 snmpFrameworkAdmin OBJECT IDENTIFIER ::= { snmpFrameworkMIB 1 } 2231 snmpFrameworkMIBObjects OBJECT IDENTIFIER ::= { snmpFrameworkMIB 2 } 2232 snmpFrameworkMIBConformance OBJECT IDENTIFIER ::= { snmpFrameworkMIB 3 } 2234 -- the snmpEngine Group ********************************************** 2236 snmpEngine OBJECT IDENTIFIER ::= { snmpFrameworkMIBObjects 1 } 2238 snmpEngineID OBJECT-TYPE 2239 SYNTAX SnmpEngineID 2240 MAX-ACCESS read-only 2241 STATUS current 2242 DESCRIPTION "An SNMP engine's administratively-unique identifier. 2243 " 2244 ::= { snmpEngine 1 } 2246 snmpEngineBoots OBJECT-TYPE 2247 SYNTAX Unsigned32 -- (1..4294967295) 2248 MAX-ACCESS read-only 2249 STATUS current 2250 DESCRIPTION "The number of times that the SNMP engine has 2251 (re-)initialized itself since its initial 2252 configuration. 2253 " 2254 ::= { snmpEngine 2 } 2256 snmpEngineTime OBJECT-TYPE 2257 SYNTAX Integer32 (0..2147483647) 2258 MAX-ACCESS read-only 2259 STATUS current 2260 DESCRIPTION "The number of seconds since the SNMP engine last 2261 incremented the snmpEngineBoots object. 2262 " 2263 ::= { snmpEngine 3 } 2265 Draft An Architecture for SNMP Management Frameworks August 1997 2267 -- Registration Points for Authentication and Privacy Protocols ** 2269 snmpAuthProtocols OBJECT-IDENTITY 2270 STATUS current 2271 DESCRIPTION "Registration point for standards-track authentication 2272 protocols used in SNMP Management Frameworks. 2273 " 2274 ::= { snmpFrameworkAdmin 1 } 2276 snmpPrivProtocols OBJECT-IDENTITY 2277 STATUS current 2278 DESCRIPTION "Registration point for standards-track privacy 2279 protocols used in SNMP Management Frameworks. 2280 " 2281 ::= { snmpFrameworkAdmin 2 } 2283 -- Conformance information ******************************************* 2285 snmpFrameworkMIBCompliances 2286 OBJECT IDENTIFIER ::= { snmpFrameworkMIBConformance 1 } 2287 snmpFrameworkMIBGroups 2288 OBJECT IDENTIFIER ::= { snmpFrameworkMIBConformance 2 } 2290 -- compliance statements 2292 snmpFrameworkMIBCompliance MODULE-COMPLIANCE 2293 STATUS current 2294 DESCRIPTION "The compliance statement for SNMP engines which 2295 implement the SNMP Management Framework MIB. 2296 " 2297 MODULE -- this module 2298 MANDATORY-GROUPS { snmpEngineGroup } 2300 ::= { snmpFrameworkMIBCompliances 1 } 2302 -- units of conformance 2304 snmpEngineGroup OBJECT-GROUP 2305 OBJECTS { 2306 snmpEngineID, 2307 snmpEngineBoots, 2308 snmpEngineTime 2309 } 2310 STATUS current 2311 DESCRIPTION "A collection of objects for identifying and 2312 determining the configuration and current timeliness 2313 values of an SNMP engine. 2314 " 2315 ::= { snmpFrameworkMIBGroups 1 } 2317 Draft An Architecture for SNMP Management Frameworks August 1997 2319 END 2320 Draft An Architecture for SNMP Management Frameworks August 1997 2322 6. Security Considerations 2324 This document describes how an implementation can include a Security 2325 Model to protect network management messages and an Access Control 2326 Model to control access to management information. 2328 The level of security provided is determined by the specific Security 2329 Model implementation(s) and the specific Access Control Model 2330 implementation(s) used. 2332 Applications have access to data which is not secured. Applications 2333 should take reasonable steps to protect the data from disclosure. 2335 It is the responsibility of the purchaser of an implementation to 2336 ensure that: 2337 1) an implementation complies with the rules defined by this 2338 architecture, 2339 2) the Security and Access Control Models utilized satisfy the 2340 security and access control needs of the organization, 2341 3) the implementations of the Models and Applications comply with 2342 the model and application specifications, 2343 4) and the implementation protects configuration secrets from 2344 inadvertent disclosure. 2346 Draft An Architecture for SNMP Management Frameworks August 1997 2348 7. Editor's Addresses 2350 Co-editor: Bert Wijnen 2351 IBM T.J. Watson Research 2352 postal: Schagen 33 2353 3461 GL Linschoten 2354 Netherlands 2355 email: wijnen@vnet.ibm.com 2356 phone: +31-348-432-794 2358 Co-editor Dave Harrington 2359 Cabletron Systems, Inc 2360 postal: Post Office Box 5005 2361 MailStop: Durham 2362 35 Industrial Way 2363 Rochester NH 03867-5005 2364 USA 2365 email: dbh@cabletron.com 2366 phone: +1-603-337-7357 2368 Draft An Architecture for SNMP Management Frameworks August 1997 2370 8. Acknowledgements 2372 This document is the result of the efforts of the SNMPv3 Working Group. 2373 Some special thanks are in order to the following SNMPv3 WG members: 2375 Dave Battle (SNMP Research, Inc.) 2376 Uri Blumenthal (IBM T.J. Watson Research Center) 2377 Jeff Case (SNMP Research, Inc.) 2378 John Curran (BBN) 2379 T. Max Devlin (Hi-TECH Connections) 2380 John Flick (Hewlett Packard) 2381 David Harrington (Cabletron Systems Inc.) 2382 N.C. Hien (IBM T.J. Watson Research Center) 2383 Dave Levi (SNMP Research, Inc.) 2384 Louis A Mamakos (UUNET Technologies Inc.) 2385 Paul Meyer (Secure Computing Corporation) 2386 Keith McCloghrie (Cisco Systems) 2387 Russ Mundy (Trusted Information Systems, Inc.) 2388 Bob Natale (ACE*COMM Corporation) 2389 Mike O'Dell (UUNET Technologies Inc.) 2390 Dave Perkins (DeskTalk) 2391 Peter Polkinghorne (Brunel University) 2392 Randy Presuhn (BMC Software, Inc.) 2393 David Reid (SNMP Research, Inc.) 2394 Shawn Routhier (Epilogue) 2395 Juergen Schoenwaelder (TU Braunschweig) 2396 Bob Stewart (Cisco Systems) 2397 Bert Wijnen (IBM T.J. Watson Research Center) 2399 The document is based on recommendations of the IETF Security and 2400 Administrative Framework Evolution for SNMP Advisory Team. 2401 Members of that Advisory Team were: 2403 David Harrington (Cabletron Systems Inc.) 2404 Jeff Johnson (Cisco Systems) 2405 David Levi (SNMP Research Inc.) 2406 John Linn (Openvision) 2407 Russ Mundy (Trusted Information Systems) chair 2408 Shawn Routhier (Epilogue) 2409 Glenn Waters (Nortel) 2410 Bert Wijnen (IBM T. J. Watson Research Center) 2412 As recommended by the Advisory Team and the SNMPv3 Working Group 2413 Charter, the design incorporates as much as practical from previous 2414 RFCs and drafts. As a result, special thanks are due to the authors 2415 of previous designs known as SNMPv2u and SNMPv2*: 2417 Jeff Case (SNMP Research, Inc.) 2418 David Harrington (Cabletron Systems Inc.) 2419 David Levi (SNMP Research, Inc.) 2420 Keith McCloghrie (Cisco Systems) 2422 Draft An Architecture for SNMP Management Frameworks August 1997 2424 Brian O'Keefe (Hewlett Packard) 2425 Marshall T. Rose (Dover Beach Consulting) 2426 Jon Saperia (BGS Systems Inc.) 2427 Steve Waldbusser (International Network Services) 2428 Glenn W. Waters (Bell-Northern Research Ltd.) 2430 Draft An Architecture for SNMP Management Frameworks August 1997 2432 9. References 2434 [RFC1155] Rose, M., and K. McCloghrie, "Structure and Identification 2435 of Management Information for TCP/IP-based internets", STD 16, 2436 RFC 1155, May 1990. 2438 [RFC1157] Case, J., M. Fedor, M. Schoffstall, and J. Davin, 2439 "The Simple Network Management Protocol", STD 15, RFC 1157, 2440 University of Tennessee at Knoxville, Performance Systems s 2441 International, Performance International, and the MIT Laboratory 2442 for Computer Science, May 1990. 2444 [RFC1212] Rose, M., and K. McCloghrie, "Concise MIB Definitions", 2445 STD 16, RFC 1212, March 1991. 2447 [RFC1901] The SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., 2448 and S., Waldbusser, "Introduction to Community-based SNMPv2", 2449 RFC 1901, January 1996. 2451 [RFC1902] The SNMPv2 Working Group, Case, J., McCloghrie, K., 2452 Rose, M., and S., Waldbusser, "Structure of Management 2453 Information for Version 2 of the Simple Network Management 2454 Protocol (SNMPv2)", RFC 1902, January 1996. 2456 [RFC1903] The SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., 2457 and S. Waldbusser, "Textual Conventions for Version 2 of the Simple 2458 Network Management Protocol (SNMPv2)", RFC 1903, January 1996. 2460 [RFC1904] The SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., 2461 and S., Waldbusser, "Conformance Statements for Version 2 of the 2462 Simple Network Management Protocol (SNMPv2)", RFC 1904, 2463 January 1996. 2465 [RFC1905] The SNMPv2 Working Group, Case, J., McCloghrie, K., 2466 Rose, M., and S., Waldbusser, "Protocol Operations for 2467 Version 2 of the Simple Network Management Protocol (SNMPv2)", 2468 RFC 1905, January 1996. 2470 [RFC1906] The SNMPv2 Working Group, Case, J., McCloghrie, K., 2471 Rose, M., and S. Waldbusser, "Transport Mappings for 2472 Version 2 of the Simple Network Management Protocol (SNMPv2)", 2473 RFC 1906, January 1996. 2475 [RFC1907] The SNMPv2 Working Group, Case, J., McCloghrie, K., 2476 Rose, M., and S. Waldbusser, "Management Information Base for 2477 Version 2 of the Simple Network Management Protocol (SNMPv2)", 2478 RFC 1907 January 1996. 2480 [RFC1908] The SNMPv2 Working Group, Case, J., McCloghrie, K., 2481 Rose, M., and S. Waldbusser, "Coexistence between Version 1 2482 and Version 2 of the SNMP-standard Network Management 2484 Draft An Architecture for SNMP Management Frameworks August 1997 2486 Framework", RFC 1908, January 1996. 2488 [RFC1909] McCloghrie, K., Editor, "An Administrative Infrastructure 2489 for SNMPv2", RFC1909, February 1996 2491 [RFC1910] Waters, G., Editor, "User-based Security Model for SNMPv2", 2492 RFC1910, February 1996 2494 [SNMP-MPD] The SNMPv3 Working Group, Case, J., Harrington, D., 2495 Wijnen, B., "Message Processing and Dispatching for the Simple 2496 Network Management Protocol (SNMP)", 2497 draft-ietf-snmpv3-mpc-03.txt, August 1997 2499 [SNMP-USM] The SNMPv3 Working Group, Blumenthal, U., Wijnen, B., 2500 "The User-Based Security Model for Version 3 of the Simple 2501 Network Management Protocol (SNMPv3)", 2502 draft-ietf-snmpv3-usm-01.txt, August 1997. 2504 [SNMP-ACM] The SNMPv3 Working Group, Wijnen, B., Presuhn, R., 2505 McCloghrie, K., "View-based Access Control Model for the Simple 2506 Network Management Protocol (SNMP)", 2507 draft-ietf-snmpv3-acm-02.txt, August 1997. 2509 [SNMP-APPL] The SNMPv3 Working Group, Levi, D. B., Meyer, P., 2510 Stewart, B., "SNMPv3 Applications", 2511 , August 1997 2513 Draft An Architecture for SNMP Management Frameworks August 1997 2515 APPENDIX A 2517 A. Guidelines for Model Designers 2519 This appendix describes guidelines for designers of models which are 2520 expected to fit into the architecture defined in this document. 2522 SNMPv1 and SNMPv2c are two SNMP frameworks which use communities to 2523 provide trivial authentication and access control. SNMPv1 and SNMPv2c 2524 Frameworks can coexist with Frameworks designed according to this 2525 architecture, and modified versions of SNMPv1 and SNMPv2c Frameworks 2526 could be designed to meet the requirements of this architecture, but 2527 this document does not provide guidelines for that 2528 coexistence. 2530 Within any subsystem model, there should be no reference to any 2531 specific model of another subsystem, or to data defined by a specific 2532 model of another subsystem. 2534 Transfer of data between the subsystems is deliberately described as 2535 a fixed set of abstract data elements and primitive functions which 2536 can be overloaded to satisfy the needs of multiple model definitions. 2538 Documents which define models to be used within this architecture 2539 SHOULD use the standard primitives between subsystems, possibly 2540 defining specific mechanisms for converting the abstract data elements 2541 into model-usable formats. This constraint exists to allow subsystem 2542 and model documents to be written recognizing common borders of the 2543 subsystem and model. Vendors are not constrained to recognize these 2544 borders in their implementations. 2546 The architecture defines certain standard services to be provided 2547 between subsystems, and the architecture defines abstract service 2548 interfaces to request these services. 2550 Each model definition for a subsystem SHOULD support the standard 2551 service interfaces, but whether, or how, or how well, it performs 2552 the service is dependent on the model definition. 2554 A.1. Security Model Design Requirements 2556 A.1.1. Threats 2558 A document describing a Security Model MUST describe how the model 2559 protects against the threats described under "Security Requirements 2560 of this Architecture", section 1.4. 2562 A.1.2. Security Processing 2564 Received messages MUST be validated by a Model of the Security 2565 Subsystem. Validation includes authentication and privacy processing 2566 Draft An Architecture for SNMP Management Frameworks August 1997 2568 if needed, but it is explicitly allowed to send messages which do not 2569 require authentication or privacy. 2571 A received message contains a specified Level of Security to be used 2572 during processing. All messages requiring privacy MUST also require 2573 authentication. 2575 A Security Model specifies rules by which authentication and privacy 2576 are to be done. A model may define mechanisms to provide additional 2577 security features, but the model definition is constrained to using 2578 (possibly a subset of) the abstract data elements defined in this 2579 document for transferring data between subsystems. 2581 Each Security Model may allow multiple security protocols to be used 2582 concurrently within an implementation of the model. Each Security 2583 Model defines how to determine which protocol to use, given the 2584 securityLevel and the security parameters relevant to the message. 2585 Each Security Model, with its associated protocol(s) defines how the 2586 sending/receiving entities are identified, and how secrets are 2587 configured. 2589 Authentication and Privacy protocols supported by Security Models are 2590 uniquely identified using Object Identifiers. IETF standard protocols 2591 for authentication or privacy should have an identifier defined within 2592 the snmpAuthProtocols or the snmpPrivProtocols subtrees. Enterprise 2593 specific protocol identifiers should be defined within the enterprise 2594 subtree. 2596 For privacy, the Security Model defines what portion of the message 2597 is encrypted. 2599 The persistent data used for security should be SNMP-manageable, but 2600 the Security Model defines whether an instantiation of the MIB is a 2601 conformance requirement. 2603 Security Models are replaceable within the Security Subsystem. 2604 Multiple Security Model implementations may exist concurrently within 2605 an SNMP engine. The number of Security Models defined by the SNMP 2606 community should remain small to promote interoperability. 2608 A.1.3. Validate the security-stamp in a received message 2610 A Message Processing Model requests that a Security Model: 2611 - verifies that the message has not been altered, 2612 - authenticates the identification of the principal for whom the 2613 message was generated. 2614 - decrypts the message if it was encrypted. 2616 Additional requirements may be defined by the model, and additional 2617 services may be provided by the model, but the model is constrained 2618 to use the following primitives for transferring data between 2619 Draft An Architecture for SNMP Management Frameworks August 1997 2621 subsystems. Implementations are not so constrained. 2623 A Message Processing Model uses the processMsg primitive as 2624 described in section 4.5. 2626 A.1.4. Security MIBs 2628 Each Security Model defines the MIB module(s) required for security 2629 processing, including any MIB module(s) required for the security 2630 protocol(s) supported. The MIB module(s) SHOULD be defined 2631 concurrently with the procedures which use the MIB module(s). The 2632 MIB module(s) are subject to normal access control rules. 2634 The mapping between the model dependent security ID and the 2635 securityName MUST be able to be determined using SNMP, if the model 2636 dependent MIB is instantiated and if access control policy allows 2637 access. 2639 A.1.5. Cached Security Data 2641 For each message received, the Security Model caches the state 2642 information such that a Response message can be generated using the 2643 same security information, even if the Local Configuration Datastore 2644 is altered between the time of the incoming request and the outgoing 2645 response. 2647 A Message Processing Model has the responsibility for explicitly 2648 releasing the cached data if such data is no longer needed. To enable 2649 this, an abstract securityStateReference data element is passed from 2650 the Security Model to the Message Processing Model. 2652 The cached security data may be implicitly released via the generation 2653 of a response, or explicitly released by using the stateRelease 2654 primitive, as described in section 4.1. 2656 Draft An Architecture for SNMP Management Frameworks August 1997 2658 A.2. Message Processing Model Design Requirements 2660 An SNMP engine contains a Message Processing Subsystem which may 2661 contain multiple Message Processing Models. 2663 The Message Processing Model MUST always (conceptually) pass the 2664 complete PDU, i.e. it never forwards less than the complete list of 2665 varBinds. 2667 A.2.1. Receiving an SNMP Message from the Network 2669 Upon receipt of a message from the network, the Dispatcher in the 2670 SNMP engine determines the version of the SNMP message and interacts 2671 with the corresponding Message Processing Model to determine the 2672 abstract data elements. 2674 A Message Processing Model specifies the SNMP Message format it 2675 supports and describes how to determine the values of the abstract 2676 data elements (like msgID, msgMaxSize, msgFlags, msgSecurityParameters, 2677 securityModel, securityLevel etc). A Message Processing Model interacts 2678 with a Security Model to provide security processing for the message 2679 using the processMsg primitive, as described in section 4.5. 2681 A.2.2. Sending an SNMP Message to the Network 2683 The Dispatcher in the SNMP engine interacts with a Message Processing 2684 Model to prepare an outgoing message. For that it uses the following 2685 primitives: 2687 - for requests and notifications: 2688 prepareOutgoingMessage, as described in section 4.4 2690 - for response messages: 2691 prepareResponseMessage, as described in section 4.4 2693 A Message Processing Model, when preparing an Outgoing SNMP Message, 2694 interacts with a Security Model to secure the message. For that it uses 2695 the following primitives: 2697 - for requests and notifications: 2698 generateRequestMsg, as described in section 4.5. 2700 - for response messages: 2701 generateResponseMsg as described in section 4.5. 2703 Once the SNMP message is prepared by a Message Processing Model, the 2704 Dispatcher sends the message to the desired address using the appropriate 2705 transport. 2707 A.3. Application Design Requirements 2708 Draft An Architecture for SNMP Management Frameworks August 1997 2710 Within an application, there may be an explicit binding to a specific 2711 SNMP message version, i.e. a specific Message Processing Model, and to 2712 a specific Access Control Model, but there should be no reference to 2713 any data defined by a specific Message Processing Model or Access 2714 Control Model. 2716 Within an application, there should be no reference to any specific 2717 Security Model, or any data defined by a specific Security Model. 2719 An application determines whether explicit or implicit access control 2720 should be applied to the operation, and, if access control is needed, 2721 which Access Control Model should be used. 2723 An application has the responsibility to define any MIB module(s) used 2724 to provide application-specific services. 2726 Applications interact with the SNMP engine to initiate messages, 2727 receive responses, receive asynchronous messages, and send responses. 2729 A.3.1. Applications that Initiate Messages 2731 Applications may request that the SNMP engine send messages containing 2732 SNMP commands or notifications using the sendPdu primitive as described 2733 in section 4.2. 2735 If it is desired that a message be sent to multiple targets, it is the 2736 responsibility of the application to provide the iteration. 2738 The SNMP engine assumes necessary access control has been applied to 2739 the PDU, and provides no access control services. 2741 The SNMP engine looks at the "expectResponse" parameter, and if a 2742 response is expected, then the appropriate information is cached such 2743 that a later response can be associated to this message, and can then 2744 be returned to the application. A sendPduHandle is returned to the 2745 application so it can later correspond the response with this message 2746 as well. 2748 A.3.2. Applications that Receive Responses 2750 The SNMP engine matches the incoming response messages to outstanding 2751 messages sent by this SNMP engine, and forwards the response to the 2752 associated application using the processResponsePdu primitive, as 2753 described in section 4.2. 2755 A.3.3. Applications that Receive Asynchronous Messages 2757 When an SNMP engine receives a message that is not the response to a 2758 request from this SNMP engine, it must determine to which application 2759 the message should be given. 2761 Draft An Architecture for SNMP Management Frameworks August 1997 2763 An Application that wishes to receive asynchronous messages registers 2764 itself with the engine using the primitive registerContextEngineID 2765 as described in section 4.2. 2767 An Application that wishes to stop receiving asynchronous messages 2768 should unregister itself with the SNMP engine using the primitive 2769 unregisterContextEngineID as described in section 4.2. 2771 Only one registration per combination of PDU type and contextEngineID 2772 is permitted at the same time. Duplicate registrations are ignored. 2773 An errorIndication will be returned to the application that attempts 2774 to duplicate a registration. 2776 All asynchronously received messages containing a registered 2777 combination of PDU type and contextEngineID are sent to the 2778 application which registered to support that combination. 2780 The engine forwards the PDU to the registered application, using the 2781 processPdu primitive, as described in section 4.2. 2783 A.3.4. Applications that Send Responses 2785 Request operations require responses. An application sends 2786 a response via the returnResponsePdu primitive, as described in 2787 section 4.2. 2789 The contextEngineID, contextName, securityModel, securityName, 2790 securityLevel, and stateReference parameters are from the initial 2791 processPdu primitive. The PDU and statusInformation are the results 2792 of processing. 2794 A.4. Access Control Model Design Requirements 2796 An Access Control Model determines whether the specified securityName 2797 is allowed to perform the requested operation on a specified managed 2798 object. The Access Control Model specifies the rules by which access 2799 control is determined. 2801 The persistent data used for access control should be manageable using 2802 SNMP, but the Access Control Model defines whether an instantiation of 2803 the MIB is a conformance requirement. 2805 The Access Control Model must provide the primitive isAccessAllowed 2806 Draft An Architecture for SNMP Management Frameworks August 1997 2808 Table of Contents 2810 0. Issues 2 2811 0.1. Resolved Issues 2 2812 0.1.1. Issues discussed at second Interim Meeting: 3 2813 0.2. Change Log 4 2814 1. Introduction 10 2815 1.1. Overview 10 2816 1.2. SNMP Management Systems 10 2817 1.3. Goals of this Architecture 11 2818 1.4. Security Requirements of this Architecture 12 2819 1.5. Design Decisions 13 2820 2. Documentation Overview 15 2821 2.1. Document Roadmap 16 2822 2.2. Applicability Statement 16 2823 2.3. Coexistence and Transition 16 2824 2.4. Transport Mappings 17 2825 2.5. Message Processing 17 2826 2.6. Security 17 2827 2.7. Access Control 17 2828 2.8. Protocol Operations 18 2829 2.9. Applications 18 2830 2.10. Structure of Management Information 18 2831 2.11. Textual Conventions 18 2832 2.12. Conformance Statements 18 2833 2.13. Management Information Base Modules 19 2834 2.13.1. SNMP Instrumentation MIBs 19 2835 2.14. SNMP Framework Documents 19 2836 2.15. Operational Overview 21 2837 3. Elements of the Architecture 23 2838 3.1. The Naming of Entities 23 2839 3.1.1. SNMP entity 24 2840 3.1.2. SNMP engine 24 2841 3.1.3. snmpEngineID 24 2842 3.1.4. Dispatcher 24 2843 3.1.5. Message Processing Subsystem 25 2844 3.1.6. Message Processing Model 25 2845 3.1.7. Security Subsystem 26 2846 3.1.8. Security Model 26 2847 3.1.9. Security Protocol 26 2848 3.1.10. Access Control Subsystem 27 2849 3.1.11. Access Control Model 27 2850 3.1.12. Applications 28 2851 3.1.13. SNMP Agent 28 2852 3.1.14. SNMP Manager 28 2853 3.2. The Naming of Identities 29 2854 3.2.1. Principal 29 2855 3.2.2. securityName 29 2856 3.2.3. Model dependent security ID 29 2857 3.3. The Naming of Management Information 30 2858 3.3.1. An SNMP Context 31 2859 3.3.2. contextEngineID 31 2860 3.3.3. contextName 31 2861 Draft An Architecture for SNMP Management Frameworks August 1997 2863 3.3.4. scopedPDU 32 2864 3.4. Other Constructs 32 2865 3.4.1. maxSizeResponseScopedPDU 32 2866 3.4.2. Local Configuration Datastore 32 2867 3.4.3. securityLevel 32 2868 4. Abstract Service Interfaces. 33 2869 4.1. Common Primitives 33 2870 4.1.1. Release State Reference Information 33 2871 4.2. Dispatcher Primitives 33 2872 4.2.1. Generate Outgoing Request or Notification 33 2873 4.2.2. Process Incoming Request or Notification PDU 34 2874 4.2.3. Generate Outgoing Response 34 2875 4.2.4. Process Incoming Response PDU 34 2876 4.2.5. Registering Responsibility for Handling SNMP PDUs. 35 2877 4.3. Message Processing Subsystem Primitives 35 2878 4.3.1. Prepare an Outgoing SNMP Request or Notification Message 35 2879 4.3.2. Prepare an Outgoing SNMP Response Message 36 2880 4.3.3. Prepare Data Elements from an Incoming SNMP Message 36 2881 4.4. Access Control Subsystem Primitives 37 2882 4.5. Security Subsystem Primitives 37 2883 4.5.1. Generate a Request or Notification Message 37 2884 4.5.2. Process Incoming Message 37 2885 4.5.3. Generate a Response Message 38 2886 4.6. User Based Security Model Internal Primitives 38 2887 4.6.1. User-based Security Model Primitives for Authentication 38 2888 4.6.2. User-based Security Model Primitives for Privacy 39 2889 4.7. Scenario Diagrams 40 2890 4.7.1. Command Generator or Notification Originator Application 40 2891 4.7.2. Scenario Diagram for a Command Responder Application 41 2892 5. Definition of Managed Objects for SNMP Management Frameworks 42 2893 6. Security Considerations 51 2894 7. Editor's Addresses 52 2895 8. Acknowledgements 53 2896 9. References 55 2897 A. Guidelines for Model Designers 57 2898 A.1. Security Model Design Requirements 57 2899 A.1.1. Threats 57 2900 A.1.2. Security Processing 57 2901 A.1.3. Validate the security-stamp in a received message 58 2902 A.1.4. Security MIBs 59 2903 A.1.5. Cached Security Data 59 2904 A.2. Message Processing Model Design Requirements 60 2905 A.2.1. Receiving an SNMP Message from the Network 60 2906 A.2.2. Sending an SNMP Message to the Network 60 2907 A.3. Application Design Requirements 60 2908 A.3.1. Applications that Initiate Messages 61 2909 A.3.2. Applications that Receive Responses 61 2910 A.3.3. Applications that Receive Asynchronous Messages 61 2911 A.3.4. Applications that Send Responses 62 2912 A.4. Access Control Model Design Requirements 62