idnits 2.17.1 draft-ietf-snmpv3-next-gen-arch-03.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. ** 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. ** Expected the document's filename to be given on the first page, but didn't find any == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 12 longer pages, the longest (page 58) being 60 lines == It seems as if not all pages are separated by form feeds - found 57 form feeds but 59 pages 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 lines with control characters in the document. ** 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 375: '...his architecture SHOULD provide protec...' RFC 2119 keyword, line 1849: '... for a subsystem SHOULD support the st...' RFC 2119 keyword, line 1857: '...a Security Model MUST describe how the...' RFC 2119 keyword, line 1863: '...eceived messages MUST be validated by ...' RFC 2119 keyword, line 1869: '...l messages requiring privacy MUST also...' (2 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 330 has weird spacing: '...es with comma...' == Line 1994 has weird spacing: '...quently used ...' == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- Couldn't find a document date in the document -- date freshness check skipped. 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 1035, but not defined ** Obsolete undefined reference: RFC 1573 (Obsoleted by RFC 2233) == Unused Reference: 'RFC1155' is defined on line 1717, but no explicit reference was found in the text == Unused Reference: 'RFC1157' is defined on line 1721, but no explicit reference was found in the text == Unused Reference: 'RFC1212' is defined on line 1727, but no explicit reference was found in the text == Unused Reference: 'RFC1902' is defined on line 1734, but no explicit reference was found in the text == Unused Reference: 'RFC1903' is defined on line 1739, but no explicit reference was found in the text == Unused Reference: 'RFC1904' is defined on line 1743, but no explicit reference was found in the text == Unused Reference: 'RFC1905' is defined on line 1748, but no explicit reference was found in the text == Unused Reference: 'RFC1908' is defined on line 1763, but no explicit reference was found in the text == Unused Reference: 'RFC1909' is defined on line 1768, but no explicit reference was found in the text == Unused Reference: 'RFC1910' is defined on line 1771, 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 1905 (ref. 'RFC1902') (Obsoleted by RFC 3416) ** Obsolete normative reference: RFC 1903 (Obsoleted by RFC 2579) ** Obsolete normative reference: RFC 1904 (Obsoleted by RFC 2580) -- Duplicate reference: RFC1905, mentioned in 'RFC1905', was also mentioned in 'RFC1902'. ** 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 Summary: 24 errors (**), 0 flaws (~~), 17 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 stracts.txt'' listing contained in the Internet- Drafts Shadow 2 Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), 3 ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). 5 Abstract 7 This document describes an architecture for describing Internet 8 Management Frameworks. The architecture is designed to be modular 9 to allow the evolution of the protocol over time. The major portions 10 of the architecture are an SNMP engine containing a Message Processing 11 subsystem, a Security Subsystem and an Access Control Subsystem, and 12 possibly multiple SNMP applications which provide specific functional 13 processing of network management data. These SNMP applications are 14 of various types, including Command Generator and Command Responder 15 applications, Notification Originator and Notification Receiver 16 applications, and Proxy Forwarding applications. 18 Harrington/Wijnen Expires December 1997 [Page 1] 19 0. Issues 21 0.1. Issues to be resolved 22 . OID or Integer for auth/priv protocol identifiers 23 second interim meeting reached consensus on OIDs 24 some mailing list members still say Integers preferred 25 . forward references need to be handled 26 . Is Glossary needed to describe primitive parameters, or is the 27 expanded template adequate for this purpose? 28 . state_reference releases - are these consistently defined? 29 check documents. 30 . discuss utf8. - probably open WG discussion in Munich per NMAD 31 discuss tomorrow; remains open issue. 32 . need mechanism to discover securityModels supported 33 . new SnmpEngineID format rules to be discussed yet. 34 . needs changes to meet STDGUIDE guidelines 35 . add a "Decision History" section (as an appendix?) 36 . we punted snmpEngineMaxMessageSize at 2nd interim because that 37 info travels in each SNMPv3 message. However, we may want to 38 re-introduce it so that SNMPv1/v2c managers can learn the value!! 40 0.1.1. Issues discussed at second Interim Meeting: 42 . A "readable" introduction supplement may be done after Munich. 43 . Applications are responsible for retries, but implementations may 44 differ. 45 . TCs should not be defined just to describe primitive parameters. 46 If they cannot be described adequately in text, they can be defined 47 in a Glossary. Avoid describing implementation details. 48 . Is SnmpAdminString appropriate for all strings, such as 49 securityIdentifier and context and group? These had different 50 sizes and semantics. size and semantics may be defined in 51 syntax and description of OBJECT 52 . AdminString has size (0..255); revisit for utf8 discussions 53 . securityModel #s - 00 for IETF standards; from v2* documents 54 . protocol IDs - integer or OID? voted 13-0 for OID. 55 . uniqueness of securityName 56 . mapping between principal and securityName is outside scope of WG. 57 . principals may have more than one securityName in an entity 58 . mappings may exist between many types of MDID and a single 59 securityName 60 . mappings may exist between different (model, Name) and the same 61 securityName by varying the model or the Name. 62 . the securityName and a MDID may be identical. This can be defined 63 by the Security Model. 64 (user,"public") may map to securityName "public" 65 . [securityName, securityModel] yields zero or one MDName, with 66 exceptions for backwards compatibility. The exception is defined 67 by the model, and the problems are the province of the model to 68 resolve. 70 Harrington/Wijnen Expires December 1997 [Page 2] 71 0.2. Change Log 73 [version 4.4] 74 . Fixed one error in the MIB (found with SMICng) 75 . Reformatted text for SnmpAdminString, no change in text. 76 . Changed text for SnmpEngineID.. this is still under discussion. 77 But this new text seems to be getting close to what we want. 78 . Added an issue w.r.t. snmpEngineMaxMessageSize 79 . adapt Primitive names and parameters to very latest (july 11) names 80 . removed blank lines before the .p page controls. 82 [version 4.3] 83 . some minor editing adjustments 85 [version 4.2] 86 . modify abstract so there is no requirement for one entity 87 to contain both a command generator and a notification receiver. 88 . modify Introduction list of entities which are meant to be 89 supported 90 . reorganized sections 1 through 4 for more consistency in contents. 91 . described section contents in Introduction:Target Audience 92 . move documentation descriptions to section 2 93 . rewrite section 4 to be more like a real elements of procedure. 94 . modified SnmpSecurityModel and SnmpEngineID definitions 95 . replaced MIB with Bert's replacement 96 . added Randy's TC for SnmpAdminString 97 . modified the example algorithm text for SnmpEngineID 98 . rewrote security considerations for brevity. 99 . modified "context" description 100 . moved "Threats" to Goals/Requirements 101 . eliminated snmpEngineMaxMessageSize object 102 . posted to snmpv3 (by DBH) 104 [version 4.1] 105 . Adopt "abstract" to new terminology 106 . Addressed all comments I (BW) made to DBH in an earlier email 107 . Changed Introduction section to new terminology 108 . changed wording for "implementation" to indicate it may contain 109 multiple models. 110 . Section 2. Started some wording on Goals and Design decisions 111 . Added the overview picture of a traditional agent and a 112 traditional manager. This is in section 2. 113 . Changed overview figure in section 3. to address the comments 114 by Dave Levi. It now lists the type of applications 115 . At various places ensure that text (easily) fits within 72 116 columns as required by RFC-editors Guidelines document. 117 . Section 2.3 (new section) has the documents set overview. 118 I verified the claims about standards. Not sure I worded the 119 SNMPv2 std correctly,. We'll hear it if we did it wrong. 120 . Section 2.4 (new section) gives overview of SNMP entities based 121 on modified Dave Levi figure. I (Bert) wonder however if it would 123 Harrington/Wijnen Expires December 1997 [Page 3] 124 not be better to move it to after section 3.1.13 125 . Section 3. Added more figures... please let us know if you find 126 then useful and/or helpful. We could also move these back to 127 section 2 if such makes more sense. 128 . Added a picture in section 3.2. 129 It also shows some of access control, so not sure it really fits 130 here, although it does map principal to model dependent security 131 ID to securityName 132 . Replace "<" with "is lower than" in section 3.4.3 which seems 133 better in a text document. 134 . Renamed section 4.1 to "SNMP engine processing" instead of 135 "The Message Processing Subsystem" because the transport 136 mappings, mpc multiplexor and such is done in ARCH document so 137 it is done "in general in the engine" and it passes a specific 138 message to a Message Processing Subsystem. 139 . "bulletized" some stuff in section 4.2 and 4.3. 140 Dave, this is just how I (Bert) like it better. Feel free to 141 undo it if you strongly disagree 142 . Section 4.3 changed "initiate a transaction" to "originate a 143 notification". 144 . Inserted title line for section 4.4 (I think it was missing) 145 I have named it "Information Model" in accordance with the change 146 I made (after Russ's comments) in the document figure to lump SMI, 147 TC and Conformance together. 148 . Inserted a title for section 4.5 named "Operational Model" to 149 get in sync with the the lumping together of ProtoOps and Transport 150 Mappings in document overview 151 . Renumber section 4.4.4 to 4,5,1 and added 4.5.2 to follow the 152 document overview figure. If we really want to follow it, then 153 maybe we should also reorder some of these sections. Like 154 Access Control seems specifically misplaced. So I decided to move 155 it before applications as section 4.3, so the 4.x above should 156 all be read as 4.x+1 157 . Removed size from SnmpEngineID TC... why did you limit it to 158 (0..2048). Did we not decide to leave it open? 159 . Should we not remove snmpEngineMaxMessageSize from the MIB. 160 That was agreed at 2nd interim. It travels in every message and so 161 seems to be useless. However, I think it could indeed still help 162 SNMPv1 or SNMPv2c managers. 163 . I kept your definitions of registration-points for auth and priv 164 protocols, but my recollection is that they would be completely 165 removed from ARCH and that it would all be done in SEC document. 166 . Modified Security Considerations. Was still talking about LPM. 167 . Appendix. I am still wondering if we need to use capitals for 168 things like "Security Model" "Subsystem" and such. This is only 169 an appendix... but we better be consistent, no? Anyway 170 I changed it so it is consistent (at least I tried). 171 . Appendix, renamed imf to snmpFramework 172 . Appendix, changed state_reference and state_release to 173 stateReference and stateRelease to be consistent with other names 174 for abstract data and primitives. 176 Harrington/Wijnen Expires December 1997 [Page 4] 177 . A.2 changed MessageEngine to SNMP engine 178 . Fixed ASI primitives to be in sync with SEC document. 179 I also thought that our ARCH document-outline wanted to at least 180 have the primitives listed within the main body of the text, no? 181 . Adapted send_pdu to sendPdu primitive as reconciled by Randy 182 In fact I made sure all primitives are in-line with current 183 agreement on names and parameters. 184 . Rename title of A.2.4 and A.2.5 so it fits on 1 line in contents 185 . I did not look at appendix B. That is your (DBH) specialty is it 186 not ? ;-). 187 . Quick simple spell check done with "spell" on AIX 189 [version 4.0] 190 . move section 7 - Model Requirements to an appendix 191 . move Section 3 - Design Goals to an appendix 192 . modified Section 5 - Naming 193 . remove "possibly multiple" 194 . moved Section 5 to Section 3 195 . change orangelets to applications 196 . modify description of applications 197 . change scopedPDU-MMS and PDU-MMS to maxSizeResponseScopedPDU 198 . change Scoped-PDU and ScopedPDU to scopedPDU (no dash, lower case S) 199 . change imfxxx to snmpFrameworkxxx 200 . change security-entity to principal 201 . change securityIdentity to securityName 202 . change MIID to securityName 203 . eliminate all reference to groupName or group 204 . LoS ordering noAuthNoPriv < authNoPriv < authPriv 205 . Los TC naming - noAuthNoPriv(1), authNoPriv(2), authPriv(3) 206 . remove TCs not used in MIBs - securityIdentity TC etc 207 . changed Message Processing and Control to Message Processing 208 . changed future tense to present tense 209 . eliminate messageEngine 210 . added/updated primitives 211 . addressed issues raised on the mailing list 213 [version 3.1] 214 . change securityIdentity to MIID 215 . write text to explain the differences between security-identities, 216 model-dependent identifiers, and model-independent identifiers. 217 . write text to explain distinction within the LCD of the security 218 data, the access control data, and the orangelet data. 219 . identify issues 220 . publish as 222 [version 3.0] 223 . add section on threats for message security 224 . add section on threats for access control 225 . change application to orangelet 226 . remove references to F-Ts 227 . change securityIdentity to security-identity 229 Harrington/Wijnen Expires December 1997 [Page 5] 230 . change securityCookie to securityIdentity 231 . the format of securityIdentity is defined by the model 232 . add securityModel to passed parameters as needed 233 . eliminate group from passed parameters 234 . remove unused IMPORTS 235 . add glossary section with initial set of words to define 236 . differentiate the messageEngine from the contextEngine 237 . eliminate the term SNMPng 238 . rewrote 1.1. A Note on Terminology 239 . eliminated assumptions about SNMP processing always being 240 message related 241 . rewrote 4.x to reflect new thinking 242 . rewrote 5.x to reflect new thinking 243 . rewrote 6.x (the MIB) to reflect new thinking 244 . added MIB objects at this level (previously only TCs) 245 . rewrote 7.x 246 . sent to v3edit list 248 Harrington/Wijnen Expires December 1997 [Page 6] 249 1. Introduction 251 1.1. Target Audience 253 This document will have as its audience persons with varying levels 254 of technical understanding of SNMP. 256 This document does not provide a general introduction to SNMP. Other 257 documents and books can provide a much better introduction to SNMP. 258 Nor does this document provide a history of SNMP. That also can be 259 found in books and other documents. 261 This document does define a vocabulary for describing Internet 262 Management Frameworks, and an architecture for describing the 263 major portions of Internet Management Frameworks. 265 Section 1 describes the purpose, goals, and design decisions of 266 the architecture. 268 Section 2 describes various types of documents which define Internet 269 Frameworks, and how they fit into this architecture. It also provides 270 a minimal roadmap to the documents which have defined previous 271 SNMP frameworks. 273 Section 3 details the vocabulary of this architecture and its pieces. 274 This section is important for understanding the remaining sections, 275 and for understanding documents which are written to fit within this 276 architecture. 278 Section 4 describes the elements of procedure followed by an SNMP 279 engine in coordinating the processing of messages by the subsystems 280 of the engine and by applications. 282 Section 5 defines a collection of managed objects used to instrument 283 SNMP engines within this architecture. 285 Sections 6, 7, 8, and 9 are administrative in nature. 287 Appendix A contains guidelines for developers of Models which are 288 expected to fit within this architecture. 290 Appendix B contains a discussion of software design principles which 291 guided the development of this architecture. Many books provide a 292 more in-depth discussion of these topics. 294 1.2. Management Systems 296 A management system contains: 297 - several (potentially many) nodes, each with an SNMP entity 298 containing command responder and notification originator 299 applications, which have access to management instrumentation; 301 Harrington/Wijnen Expires December 1997 [Page 7] 302 - at least one SNMP entity containing command generator and/or 303 notification receiver applications; and, 304 - a management protocol, used to convey management information 305 between the SNMP entities. 307 SNMP entities executing command generator and notification receiver 308 applications monitor and control managed elements. Managed elements 309 are devices such as hosts, routers, terminal servers, etc., which 310 are monitored and controlled via access to their management 311 information. 313 Operations of the protocol are carried out under an administrative 314 framework which defines minimum requirements for standard services, 315 such as sending and receiving messages, countering security threats 316 to messages, controlling access to managed objects, and processing 317 various types of requests. 319 It is the purpose of this document to define an architecture which 320 can evolve to realize effective network management in a variety 321 of configurations and environments. The architecture has been 322 designed to meet the needs of implementations of: 323 - minimal SNMP entities with command responder and/or notification 324 originator applications (traditionally called SNMP agents), 325 - SNMP entities with proxy forwarder applications (traditionally 326 called SNMP proxy agent), 327 - command line driven SNMP entities with command generator and/or 328 notification receiver applications (traditionally called SNMP 329 command line managers), 330 - SNMP entities with command generator and/or notification 331 receiver, plus command responder and/or notification originator 332 applications (traditionally called SNMP mid-level managers or 333 dual-role entities), 334 - SNMP entities with command generator and/or notification 335 receiver and possibly other types of applications for managing 336 a potentially very large number of managed nodes (traditionally 337 called network enterprise management stations). 339 1.3. Goals of this Architecture 341 This architecture was driven by the following goals: 343 - Use existing materials as much as possible. 344 It is heavily based on previous work, informally 345 known as SNMPv2u and SNMPv2*. 346 - Address the need for secure SET support, which is considered 347 the most important deficiency in SNMPv1 and SNMPv2c. 348 - Make it possible to move portions of the architecture forward 349 in the standards track, even if consensus has not been reached 350 on all pieces. 351 - Define an architecture that allows for longevity of the SNMP 352 Frameworks that have been and will be defined. 354 Harrington/Wijnen Expires December 1997 [Page 8] 355 - Keep SNMP as simple as possible. 356 - Make it relatively inexpensive to deploy a minimal conformant 357 implementation 358 - Make it possible to upgrade portions of a framework as new 359 approaches become available, without disrupting the entire 360 framework. 361 - Make it possible to support features required in large networks, 362 but make the expense of supporting a feature directly related 363 to the support of the feature. 365 1.4. Security Requirements of this Architecture 367 Several of the classical threats to network protocols are applicable 368 to the network management problem and therefore would be applicable 369 to any Security Model used in an Internet Management Framework. Other 370 threats are not applicable to the network management problem. This 371 section discusses principal threats, secondary threats, and threats 372 which are of lesser importance. 374 The principal threats against which any Security Model used within 375 this architecture SHOULD provide protection are: 377 Modification of Information 378 The modification threat is the danger that some unauthorized SNMP 379 entity may alter in-transit SNMP messages generated on behalf of 380 an authorized principal in such a way as to effect unauthorized 381 management operations, including falsifying the value of an object. 383 Masquerade 384 The masquerade threat is the danger that management operations 385 not authorized for some principal may be attempted by assuming 386 the identity of another principal that has the appropriate 387 authorizations. 389 Message Stream Modification 390 The SNMP protocol is typically based upon a connectionless 391 transport service which may operate over any subnetwork service. 392 The re-ordering, delay or replay of messages can and does occur 393 through the natural operation of many such subnetwork services. 394 The message stream modification threat is the danger that messages 395 may be maliciously re-ordered, delayed or replayed to an extent 396 which is greater than can occur through the natural operation of 397 a subnetwork service, in order to effect unauthorized management 398 operations. 400 Disclosure 401 The disclosure threat is the danger of eavesdropping on the 402 exchanges between SNMP engines. Protecting against this threat 403 may be required as a matter of local policy. 405 Harrington/Wijnen Expires December 1997 [Page 9] 406 There are at least two threats against which a Security Model used by 407 a framework within this architecture need not protect. 409 Denial of Service 410 A Security Model need not attempt to address the broad range of 411 attacks by which service on behalf of authorized users is denied. 412 Indeed, such denial-of-service attacks are in many cases 413 indistinguishable from the type of network failures with which any 414 viable network management protocol must cope as a matter of course. 416 Traffic Analysis 417 A Security Model need not attempt to address traffic analysis 418 attacks. Many traffic patterns are predictable - entities may 419 be managed on a regular basis by a relatively small number of 420 management stations - and therefore there is no significant 421 advantage afforded by protecting against traffic analysis. 423 1.5. Design Decisions 425 Various designs decision were made in support of these goals: 427 - Architecture 428 An architecture should be defined which identifies the 429 conceptual boundaries between the documents of a framework. 430 Subsystems should be defined which describe the abstract 431 services provided by specific portions of the framework. 432 Abstract service interfaces, as described by service primitives, 433 define the abstract boundaries between documents, and the 434 abstract services that are provided by the conceptual 435 subsystems of a framework. 437 - Self-contained Documents 438 Elements of procedure plus the MIB objects which are needed for 439 processing for a specific portion of a framework should be 440 defined in the same document, and as much as possible, should 441 not be referenced in other documents. This allows various 442 pieces of SNMP Frameworks to be designed and documented as 443 independent and self-contained parts, which is consistent with 444 the general SNMP MIB module approach. As portions of SNMP change 445 over time, the documents describing other portions of the 446 framework are not directly impacted. This modularity allows, 447 for example, Security Models, authentication and privacy 448 mechanisms, and message formats to be upgraded and supplemented 449 as the need arises. The self-contained documents can move 450 along the standards track on different time-lines. 452 - Remote Configuration 453 The Security and Access Control Subsystems add a whole new set 454 of SNMP configuration parameters. The Security Subsystem also 455 requires frequent changes of secrets at the various SNMP 456 entities. To make this deployable in a large operational 457 environment, these SNMP parameters must be able to be remotely 458 configured. 460 - Controlled Complexity 461 It is recognized that simple managed devices want to keep the 462 resources used by SNMP to a minimum. At the same time, there 463 is a need for more complex configurations which can spend more 464 resources for SNMP and thus provide more functionality. 465 The design tries to keep the competing requirements of these 466 two environments in balance and allows the more complex 467 environments to logically extend the simple environment. 469 2. Documentation Overview 471 The following figure shows the set of documents that fit within the 472 SNMP Architecture. 473 Document Set 474 +--------------------------------------------------------------------+ 475 | | 476 | +------------+ +-----------------+ +----------------+ | 477 | | * | | * | | * | | 478 | | Document | | Applicability | | Coexistence | | 479 | | Roadmap | | Statement | | & Transition | | 480 | +------------+ +-----------------+ +----------------+ | 481 | | 482 | +-------------------+ +-----------------------------------------+ | 483 | | Operational Model | | Security and Administration | | 484 | | | | | | 485 | | +-------------+ | | +------------+ +----------+ +---------+ | | 486 | | | | | | | | | | | | | | 487 | | | Protocol | | | | Message | | Security | | Access | | | 488 | | | Operations | | | | Processing | | | | Control | | | 489 | | +-------------+ | | +------------+ +----------+ +---------+ | | 490 | | +-------------+ | | | | 491 | | | | | | +--------------+ +----------+ | | 492 | | | Transport | | | | | | | | | 493 | | | Mappings | | | | Applications | ......... | | | | 494 | | +-------------+ | | +--------------+ +----------+ | | 495 | | | | | | 496 | +-------------------+ +-----------------------------------------+ | 497 | | 498 | +----------------------------------------------------------------+ | 499 | | Information Model | | 500 | | | | 501 | | +--------------+ +--------------+ +---------------+ | | 502 | | | Structure of | | Textual | | Conformance | | | 503 | | | Management | | Conventions | | Statements | | | 504 | | | Information | | | | | | | 505 | | +--------------+ +--------------+ +---------------+ | | 506 | +----------------------------------------------------------------+ | 507 | | 508 | +----------------------------------------------------------------+ | 509 | | MIBs | | 510 | | | | 511 | | +-------------+ +-------------+ +----------+ +----------+ | | 512 | | | Standard v1 | | Standard v1 | | Historic | | Draft v2 | | | 513 | | | RFC1157 | | RFC1212 | | RFC14xx | | RFC19xx | | | 514 | | | format | | format | | format | | format | | | 515 | | +-------------+ +-------------+ +----------+ +----------+ | | 516 | +----------------------------------------------------------------+ | 517 | | 518 +--------------------------------------------------------------------+ 520 Those marked with an asterisk (*) are expected to be written in the 521 future. Each of these documents may be replaced or supplemented. 522 This Architecture document specifically describes how new documents 523 fit into the set of documents in the Security and Administration area. 525 2.1. Document Roadmap 527 One or more documents may be written that will describe how sets 528 of documents taken together form a specific SNMP framework. 529 The configuration of document sets might change over time, so the 530 "roadmap" should be maintained in a document separate from the 531 standards documents themselves. 533 2.2. Applicability Statement 535 SNMP is used in networks that vary widely in size and complexity, 536 by organizations that vary widely in their requirements of network 537 management. Some models will be designed to address specific 538 problems of network management, such as message security. 540 One or more documents may be written which describe the environments 541 to which certain versions of SNMP or models within SNMP would be 542 appropriately applied, and those to which a given model might be 543 inappropriately applied. 545 2.3. Coexistence and Transition 547 The purpose of an evolutionary architecture is to permit new models 548 to replace or supplement existing models. The interactions between 549 models could result in incompatibilities, security "holes", and 550 other undesirable effects. 552 The purpose of Coexistence documents is to detail recognized anomalies 553 and to describe required and recommended behaviors for resolving the 554 interactions between models within the architecture. 556 It would be very difficult to document all the possible interactions 557 between a model and all other previously existing models while in the 558 process of developing a new model. 560 Coexistence documents are therefore expected to be prepared separately 561 from model definition documents, to describe and resolve interaction 562 anomalies between a model definition and one or more other model 563 definitions. 565 Additionally, recommendations for transitions between models may 566 also be described, either in a coexistence document or in a separate 567 document. 569 2.4. Transport Mappings 571 SNMP messages are sent over various transports. It is the purpose of 572 Transport Mapping documents to define how the mapping between SNMP 573 and the transport is done. A specific implementation of an SNMP engine 574 defines which transports it supports. 576 2.5. Message Processing 578 A Message Processing Model document defines a message format, which is 579 typically identified by a version field in an SNMP message header. 580 The document may also define a MIB module for use in message 581 processing and for instrumentation of version-specific interactions. 583 An engine will include one or more Message Processing Models, and thus 584 may support sending and receiving multiple SNMP versions of 585 messages. 587 2.6. Security 589 Some environments require secure protocol interactions. Security is 590 normally applied at two different stages: 592 - in the transmission/receipt of messages, and 593 - in the processing of the contents of messages. 595 For purposes of this document, "security" refers to message-level 596 security; "access control" refers to the security applied to protocol 597 operations. 599 Authentication, encryption, and timeliness checking are common 600 functions of message level security. 602 A security document will describe a Security Model, the threats 603 against which the model protects, the goals of the Security Model, 604 the protocols which it uses to meet those goals, and it may define 605 a MIB module to describe the data used during processing, and to allow 606 the remote configuration of message-level security parameters, 607 such as passwords. 609 An SNMP engine may support multiple Security Models concurrently. 611 2.7. Access Control 613 During processing, it may be required to control access to certain 614 instrumentation for certain operations. An Access Control Model 615 determines whether access to an object should be allowed. The 616 mechanism by which access control is checked is defined by the 617 Access Control Model. 619 An Access Control Model document defines the mechanisms used to 620 determine whether access to a managed object should be allowed, 621 and may define a MIB module used during processing, and to allow 622 the remote configuration of access control policies. 624 2.8. Applications 626 An SNMP entity normally includes a number of applications. 627 Applications use the services of an SNMP engine to accomplish 628 specific tasks. They coordinate the processing of management 629 information operations, and may use SNMP messages to communicate 630 with other SNMP entities. 632 Applications documents describe the purpose of an application, the 633 services required of the associated SNMP engine, and the protocol 634 operations and informational model that the application uses to 635 perform network management operations. 637 An application document defines which set of documents are used to 638 specifically define the structure of management information, textual 639 conventions, conformance requirements, and operations supported by 640 the application. 642 2.9. Structure of Management Information 644 Management information is viewed as a collection of managed objects, 645 residing in a virtual information store, termed the Management 646 Information Base (MIB). Collections of related objects are defined 647 in MIB modules. 649 It is the purpose of a Structure of Management Information document 650 to establish the syntax for defining objects, modules, and other 651 elements of managed information. 653 2.10. Textual Conventions 655 When designing a MIB module, it is often useful to define new types 656 similar to those defined in the SMI, but with more precise semantics, 657 or which have special semantics associated with them. These newly 658 defined types are termed textual conventions, and may defined in 659 separate documents, or within a MIB module. 661 2.11. Conformance Statements 663 It may be useful to define the acceptable lower-bounds of 664 implementation, along with the actual level of implementation 665 achieved. It is the purpose of Conformance Statements to define 666 the notation used for these purposes. 668 2.12. Protocol Operations 670 SNMP messages encapsulate an SNMP Protocol Data Unit (PDU). It is the 671 purpose of a Protocol Operations document to define the operations 672 of the protocol with respect to the processing of the PDUs. 674 An application document defines which Protocol Operations documents 675 are supported by the application. 677 2.13. Management Information Base Modules 679 MIB documents describe collections of managed objects which 680 instrument some aspect of a managed node. 682 2.13.1. SNMP Instrumentation MIBs 684 An SNMP MIB document may define a collection of managed objects which 685 instrument the SNMP protocol itself. In addition, MIB modules may be 686 defined within the documents which describe portions of the SNMP 687 architecture, such as the documents for Message processing Models, 688 Security Models, etc. for the purpose of instrumenting those 689 Models, and for the purpose of allowing remote configuration of 690 the Model. 692 2.14. SNMP Framework Documents 694 This architecture is designed to allow an orderly evolution of 695 portions of SNMP Frameworks. 697 Throughout the rest of this document, the term "subsystem" refers 698 to an abstract and incomplete specification of a portion of 699 a Framework, that is further refined by a model specification. 701 A "model" describes a specific design of a subsystem, defining 702 additional constraints and rules for conformance to the model. 703 A model is sufficiently detailed to make it possible to implement 704 the specification. 706 An "implementation" is an instantiation of a subsystem, conforming 707 to one or more specific models. 709 SNMP version 1 (SNMPv1), is the original Internet-standard Network 710 Management Framework, as described in RFCs 1155, 1157, and 1212. 712 SNMP version 2 (SNMPv2) is an updated design of portions of SNMPv1, 713 as described in RFCs 1902-1908. SNMPv2 has an incomplete message 714 definition. 716 Community-based SNMP version 2 (SNMPv2c) is an experimental Framework 717 which supplements the incomplete message format of SNMPv2 with 718 portions of the message format of SNMPv1, as described in RFC1901. 720 SNMP version 3 (SNMPv3) Framework is a particular configuration of 721 implemented subsystems, consistent with the architecture described 722 in this document. 724 Other SNMP Frameworks, i.e. other configurations of implemented 725 subsystems, are expected to also be consistent with this architecture. 727 This document does not describe any framework, but describes an 728 architecture into which multiple frameworks may be fitted. 730 3. Naming 732 This architecture deals with three kinds of naming: 734 1) the naming of entities, 735 2) the naming of identities, and 736 3) the naming of management information. 738 This architecture also defines some names for other constructs that 739 are used in the documentation. 741 3.1. The Naming of Entities 743 The following picture shows detail about an SNMP entity and how 744 components within it are named. 746 +--------------------------------------------------------------------+ 747 | | 748 | SNMP entity | 749 | | 750 | +--------------------------------------------------------------+ | 751 | | | | 752 | | SNMP engine (identified by snmpEngineID) | | 753 | | | | 754 | | +---------------+ +--------------+ +---------------+ | | 755 | | | | | | | | | | 756 | | | Message | | Security | | Access | | | 757 | | | Processing | | Subsystem | | Control | | | 758 | | | Subsystem | | | | Subsystem | | | 759 | | | | | | | | | | 760 | | +---------------+ +--------------+ +---------------+ | | 761 | | | | 762 | +--------------------------------------------------------------+ | 763 | | 764 | +--------------------------------------------------------------+ | 765 | | | | 766 | | Application(s) | | 767 | | | | 768 | | +-------------+ +--------------+ +--------------+ | | 769 | | | Command | | Notification | | Proxy | | | 770 | | | Generator | | Receiver | | Forwarder | | | 771 | | +-------------+ +--------------+ +--------------+ | | 772 | | | | 773 | | +-------------+ +--------------+ +--------------+ | | 774 | | | Command | | Notification | | Other | | | 775 | | | Responder | | Originator | | | | | 776 | | +-------------+ +--------------+ +--------------+ | | 777 | | | | 778 | +--------------------------------------------------------------+ | 779 | | 780 +--------------------------------------------------------------------+ 782 3.1.1. SNMP entity 784 An SNMP entity is an implementation of this architecture. Each such 785 SNMP entity consists of an SNMP engine and one or more associated 786 applications. 788 3.1.2. SNMP engine 790 An SNMP engine has three subsystems: 792 1) a Message Processing Subsystem, 793 2) a Security Subsystem, and 794 3) an Access Control Subsystem. 796 3.1.3. snmpEngineID 798 Within an administrative domain, an snmpEngineID is the unique 799 and unambiguous identifier of an SNMP engine. Since there is a 800 one-to-one association between SNMP engines and SNMP entities, 801 it also uniquely and unambiguously identifies the SNMP entity. 803 3.1.4. Message Processing Subsystem 805 The Message Processing Subsystem is responsible for preparing and 806 sending messages, and receiving and distributing messages. 808 The Message Processing Subsystem potentially contains multiple 809 Message Processing Models as shown in the next picture. Those 810 marked with an asterisk (*) may be absent. 812 +------------------------------------------------------------------+ 813 | | 814 | Message Processing Subsystem | 815 | | 816 | +------------+ +------------+ +------------+ +------------+ | 817 | | | | * | | * | | * | | 818 | | SNMPv3 | | SNMPv1 | | SNMPv2c | | Other | | 819 | | Message | | Message | | Message | | Message | | 820 | | Processing | | Processing | | Processing | | Processing | | 821 | | Model | | Model | | Model | | Model | | 822 | | | | | | | | | | 823 | +------------+ +------------+ +------------+ +------------+ | 824 | | 825 +------------------------------------------------------------------+ 827 3.1.5. Message Processing Model 829 Each Message Processing Model defines the format of a particular 830 version of an SNMP message and coordinates the processing of each 831 version-specific message. 833 3.1.6. Security Subsystem 835 The Security Subsystem provides security services such as the 836 authentication and privacy of messages and potentially contains 837 multiple Security Models as shown in the next picture. Those 838 marked with an asterisk (*) may be absent. 840 +------------------------------------------------------------------+ 841 | | 842 | Security Subsystem | 843 | | 844 | +------------+ +-------------------+ +---------------------+ | 845 | | | | * | | * | | 846 | | User-Based | | Community-based | | Other | | 847 | | Security | | Security | | Security | | 848 | | Model | | Model | | Model | | 849 | | | | | | | | 850 | +------------+ +-------------------+ +---------------------+ | 851 | | 852 +------------------------------------------------------------------+ 854 3.1.7. Security Model 856 A Security Model defines the threats against which it protects, 857 the goals of its services, and the security protocols used to provide 858 security services such as authentication and privacy. 860 3.1.8. Security Protocol 862 A Security Protocol defines the mechanisms, procedures, and MIB 863 data used to provide a security service such as authentication 864 or privacy. 866 3.1.9. Access Control Subsystem 868 The Access Control Subsystem provides authorization services by 869 means of one or more Access Control Models. 871 +------------------------------------------------------------------+ 872 | | 873 | Access Control Subsystem | 874 | | 875 | +------------+ +-------------------+ +---------------------+ | 876 | | | | * | | * | | 877 | | View-Based | | Community | | Other | | 878 | | Access | | Access | | Access | | 879 | | Control | | Control | | Control | | 880 | | Model | | Model | | Model | | 881 | | | | | | | | 882 | +------------+ +-------------------+ +---------------------+ | 883 | | 884 +------------------------------------------------------------------+ 886 3.1.10. Access Control Model 888 An Access Control Model defines a particular access decision function 889 in order to support decisions regarding authorization. 891 3.1.11. Applications 893 There are several types of applications, which include: 895 - command generator, 896 - command responder, 897 - notification originator, 898 - notification receiver, and 899 - proxy forwarder. 901 These applications make use of the services provided by the Security 902 and Administration Framework. 904 3.1.12. SNMP Agent 906 An SNMP entity containing one or more command responder and/or 907 notification originator applications (along with their associated 908 SNMP engine) has traditionally been called an SNMP agent. 910 3.1.13. SNMP Manager 912 An SNMP entity containing one or more command generator and/or 913 notification receiver applications (along with their associated 914 SNMP engine) has traditionally been called an SNMP manager. 916 3.2. The Naming of Identities 918 principal <---------------------------------+ 919 | 920 +-------------------------------------|-----+ 921 | SNMP engine | | 922 | | | 923 | +-----------------------+ | | 924 | | Security Model | | | 925 | | +-------------+ | | | 926 wire | | | Model | +------------+--+ | 927 <----------->| Dependent |<-->| | securityName| | 928 | | | Security ID | +---------------+ | 929 | | +-------------+ | | 930 | | | | 931 | +-----------------------+ | 932 | | 933 | | 934 +-------------------------------------------+ 936 3.2.1. Principal 938 A principal is the "who" on whose behalf services are provided 939 or processing takes place. 941 A principal can be, among other things, an individual acting in 942 a particular role; a set of individuals, with each acting in a 943 particular role; an application; or a set of applications; 944 and combinations thereof. 946 3.2.2. securityName 948 A securityName is a human readable string representing a principal. 949 It has a model independent format, and can be used outside a 950 particular Security Model. 952 3.2.3. Model dependent security ID 954 A model dependent security ID is the model specific representation 955 of a securityName within a particular Security Model. 957 Model dependent security IDs may or may not be human readable, and 958 have a model dependent syntax. Examples include community names, 959 user names, and parties. 961 The transformation of model dependent security IDs into securityNames 962 and vice versa is the responsibility of the relevant Security Model. 964 3.3. The Naming of Management Information 966 Management information resides at an SNMP entity where a Command 967 Responder Application has local access to potentially multiple 968 contexts. Such a Command Responder application uses a contextEngineID 969 equal to the snmpEngineID of its associated SNMP engine. 971 +--------------------------------------------------------------+ 972 | SNMP entity (identified by snmpEngineID, example: abcd) | 973 | | 974 | +----------------------------------------------------------+ | 975 | | SNMP engine (identified by snmpEngineID) | | 976 | | | | 977 | | +---------------+ +--------------+ +---------------+ | | 978 | | | | | | | | | | 979 | | | Message | | Security | | Access | | | 980 | | | Processing | | Subsystem | | Control | | | 981 | | | Subsystem | | | | Subsystem | | | 982 | | | | | | | | | | 983 | | +---------------+ +--------------+ +---------------+ | | 984 | | | | 985 | +----------------------------------------------------------+ | 986 | | 987 | +----------------------------------------------------------+ | 988 | | Command Responder Application | | 989 | | (contextEngineID, example: abcd) | | 990 | | | | 991 | | example contextNames: | | 992 | | | | 993 | | "repeater1" "repeater2" "" (default) | | 994 | | ----------- ----------- ------------ | | 995 | | | | | | | 996 | +-----|-------------------|--------------------|-----------+ | 997 | | | | | 998 | +-----|-------------------|--------------------|-----------+ | 999 | | MIB | instrumentation | | | | 1000 | |-----v------------+ +----v-------------+ +----v-----------| | 1001 | | context | | context | | context | | 1002 | | | | | | | | 1003 | | +--------------+ | | +--------------+ | | +------------+ | | 1004 | | | repeater MIB | | | | repeater MIB | | | | other MIB | | | 1005 | | +--------------+ | | +--------------+ | | +------------+ | | 1006 | | | | | | | | 1007 | | | | | | +------------+ | | 1008 | | | | | | | some MIB | | | 1009 | | | | | | +------------+ | | 1010 | | | | | | | | 1011 +--------------------------------------------------------------+ 1013 3.3.1. An SNMP Context 1015 An SNMP context, or just "context" for short, is a collection of 1016 management information accessible by an SNMP entity. An item of 1017 management information may exist in more than one context. An SNMP 1018 engine potentially has access to many contexts. 1020 Typically, there are many instances of each managed object type within 1021 a management domain. For simplicity, the method for identifying 1022 instances specified by the MIB module does not allow each instance to 1023 be distinguished amongst the set of all instances within a management 1024 domain; rather, it allows each instance to be identified only within 1025 some scope or "context", where there are multiple such contexts within 1026 the management domain. Often, a context is a physical device, or 1027 perhaps, a logical device, although a context can also encompass 1028 multiple devices, or a subset of a single device, or even a subset of 1029 multiple devices, but a context is always defined as a subset of a 1030 single SNMP entity. Thus, in order to identify an individual item of 1031 management information within the management domain, its contextName 1032 and contextEngineID must be identified in addition to its object type 1033 and its instance. 1035 For example, the managed object type ifDescr [RFC1573], is defined as 1036 the description of a network interface. To identify the description 1037 of device-X's first network interface, four pieces of information are 1038 needed: the snmpEngineID of the SNMP entity which provides access to 1039 device-X, the contextName (device-X), the managed object type 1040 (ifDescr), and the instance ("1"). 1042 Each context has (at least) one unique identification within the 1043 management domain. The same item of management information can exist 1044 in multiple contexts. So, an item of management information can have 1045 multiple unique identifications, either because it exists in multiple 1046 contexts, and/or because each such context has multiple unique 1047 identifications. 1049 The combination of a contextEngineID and a contextName unambiguously 1050 identifies a context within an administrative domain. 1052 3.3.2. contextEngineID 1054 Within an administrative domain, a contextEngineID uniquely 1055 identifies an SNMP entity that may realize an instance of a 1056 context with a particular contextName. 1058 3.3.3. contextName 1060 A contextName is used to name a context. Each contextName 1061 MUST be unique within an SNMP entity. 1063 3.3.4. scopedPDU 1064 A scopedPDU is a block of data containing a contextEngineID, 1065 a contextName, and a PDU. 1067 The PDU is an SNMP Protocol Data Unit containing information 1068 named in the context which is unambiguously identified within 1069 an administrative domain by the combination of the contextEngineID 1070 and the contextName. See, for example, RFC1905 for more information 1071 about SNMP PDUs. 1073 3.4. Other Constructs 1075 3.4.1. maxSizeResponseScopedPDU 1077 The maxSizeResponseScopedPDU is the maximum size of a scopedPDU to 1078 be included in a response message, making allowance for the message 1079 header. 1081 3.4.2. Local Configuration Datastore 1083 The subsystems, models, and applications within an SNMP entity may 1084 need to retain their own sets of configuration information. 1086 Portions of the configuration information may be accessible as 1087 managed objects. 1089 The collection of these sets of information is referred to 1090 as an entity's Local Configuration Datastore (LCD). 1092 3.4.3. LoS 1094 This architecture recognizes three levels of security (LoS): 1096 - without authentication and without privacy (noAuthNoPriv) 1097 - with authentication but without privacy (authNoPriv) 1098 - with authentication and with privacy (authPriv) 1100 These three values are ordered such that noAuthNoPriv is lower than 1101 authNoPriv and authNoPriv is lower than authPriv. 1103 Every message has an associated LoS. All Subsystems (Message 1104 Processing, Security, Access Control) and applications are required 1105 to either supply a value of LoS or to abide by the supplied value of 1106 LoS while processing the message and its contents. 1108 4. Architectural Elements of Procedure 1110 The architecture described here contains three subsystems, each 1111 capable of being defined as one or more different models which may 1112 be replaced or supplemented as the growing needs of network management 1113 require. The architecture also includes applications which utilize the 1114 services provided by the subsystems. 1116 An SNMP engine deals with SNMP messages, and is responsible for 1117 sending and receiving messages, including having authentication 1118 and encryption services applied to the messages, and determining 1119 to which application the message contents should be delivered. 1121 Applications deal with processing network management operations. 1122 Depending on the network management service needed, an application 1123 may use the Access Control Subsystem, and may use SNMP messages to 1124 communicate with remote nodes. The network management service may 1125 be requested via the payload of an SNMP message, or may be requested 1126 via a local process. 1128 4.1. Operational Overview 1130 The following pictures show two communicating SNMP entities using 1131 the conceptual modularity described by the SNMP Architecture. 1132 The pictures represent SNMP entities that have traditionally been 1133 called SNMP manager and SNMP agent respectively. The boxes marked 1134 with an asterisk (*) may be absent. 1136 (traditional SNMP manager) 1137 +--------------------------------------------------------------------+ 1138 | SNMP entity | 1139 | | 1140 | +--------------+ +--------------+ +--------------+ | 1141 | | NOTIFICATION | | NOTIFICATION | | COMMAND | | 1142 | | ORIGINATOR | | RECEIVER | | GENERATOR | | 1143 | | applications | | applications | | applications | | 1144 | +--------------+ +--------------+ +--------------+ | 1145 | ^ ^ ^ | 1146 | | | | | 1147 | v v v | 1148 | +----------------------------------------------------------------+ | 1149 | | Message Processing Application Multiplexor | | 1150 | +----------------------------------------------------------------+ | 1151 | ^ ^ ^ ^ | 1152 | +-----------+ | | | | | 1153 | | | v v v v | 1154 | | Security | +------+ +---------+ +--------+ +-----------+ | 1155 | | Subsystem |<-->| v3MP | | v2cMP * | | v1MP * |...| otherMP * | | 1156 | | | +------+ +---------+ +--------+ +-----------+ | 1157 | +-----------+ ^ ^ ^ ^ | 1158 | | | | | | 1159 | v v v v | 1160 | +----------------------------------------------------------------+ | 1161 | | Message Processing Model selection (incoming only) | | 1162 | +----------------------------------------------------------------+ | 1163 | ^ | 1164 | | | 1165 | v | 1166 | +----------------------------------------------------------------+ | 1167 | | TRANSPORT MAPPING (for example RFC1906) | | 1168 | +----------------------------------------------------------------+ | 1169 +--------------------------------------------------------------------+ 1170 +-----+ +-----+ +-------+ 1171 | UDP | | IPX | . . . | other | 1172 +-----+ +-----+ +-------+ 1173 ^ ^ ^ 1174 | | | 1175 v v v 1176 +------------------------------+ 1177 | Network | 1178 +------------------------------+ 1179 +------------------------------+ 1180 | Network | 1181 +------------------------------+ 1182 ^ ^ ^ 1183 | | | 1184 v v v 1185 +-----+ +-----+ +-------+ 1186 | UDP | | IPX | . . . | other | 1187 +-----+ +-----+ +-------+ (traditional SNMP agent) 1188 +--------------------------------------------------------------------+ 1189 | +----------------------------------------------------------------+ | 1190 | | TRANSPORT MAPPING (for example RFC1906) | | 1191 | +----------------------------------------------------------------+ | 1192 | ^ | 1193 | | | 1194 | v | 1195 | +----------------------------------------------------------------+ | 1196 | | Message Processing Model selection (incoming only) | | 1197 | +----------------------------------------------------------------+ | 1198 | ^ ^ ^ ^ | 1199 | +-----------+ | | | | | 1200 | | | v v v v | 1201 | | Security | +------+ +---------+ +--------+ +-----------+ | 1202 | | Subsystem |<-->| v3MP | | v2cMP * | | v1MP * |...| otherMP * | | 1203 | | | +------+ +---------+ +--------+ +-----------+ | 1204 | +-----------+ ^ ^ ^ ^ | 1205 | | | | | | 1206 | v v v v | 1207 | +----------------------------------------------------------------+ | 1208 | | Message Processing Abstract Service Interface | | 1209 | +----------------------------------------------------------------+ | 1210 | ^ ^ ^ | 1211 | | | | | 1212 | v v v | 1213 | +-------------+ +---------+ +--------------+ +-------------+ | 1214 | | COMMAND | | ACCESS | | NOTIFICATION | | PROXY * | | 1215 | | RESPONDER |<->| CONTROL |<->| ORIGINATOR | | FORWARDER | | 1216 | | application | | | | applications | | application | | 1217 | +-------------+ +---------+ +--------------+ +-------------+ | 1218 | ^ ^ | 1219 | | | | 1220 | v v | 1221 | +----------------------------------------------+ | 1222 | | MIB instrumentation | SNMP entity | 1223 +--------------------------------------------------------------------+ 1225 4.2. Sending and Receiving SNMP Messages 1227 4.2.1. Send a Message to the Network 1229 Applications may request that messages be generated and sent. The 1230 application has the responsibility of providing the information 1231 necessary to generate the message, as detailed below, and of 1232 providing the transport address to which the message should be sent. 1234 The engine passes a request for a message to be generated to the 1235 specified Message Processing Model which, utilizing the services of 1236 the selected Security Model, generates the message and prepares it 1237 for sending. 1239 The SNMP engine sends the message to the specified transport address. 1240 It then advises the sending Message Processing Model about the success 1241 or failure of the sending of the message. 1243 4.2.2. Receive a Message from the Network 1245 It is the responsibility of the SNMP engine to listen for incoming 1246 messages at the appropriate local addresses. Some local addresses 1247 for listening are recommended by SNMP Transport Mapping documents, 1248 such as [RFC1906]. 1250 Upon receipt of an SNMP message, the SNMP engine increments the 1251 snmpInPkts counter [RFC1907]. 1253 SNMP messages received from the network use a format defined by a 1254 version-specific Message Processing Model, typically identified 1255 by a version field in the message header. 1257 The engine determines the SNMP version of an incoming message by 1258 inspecting the serialized values for a recognizable pattern. 1259 The mechanism by which it makes the determination of version is 1260 implementation-specific, and dependent on the Message Processing 1261 Models supported by the engine. 1263 If the engine has no Message Processing Model for the determined 1264 version, then the snmpInBadVersions counter [RFC1907] is incremented, 1265 and the message is discarded without further processing. 1267 The SNMP engine caches the msgID, which is subsequently used for 1268 coordinating all processing regarding this received message, and 1269 caches the origin network address so a possible response can be 1270 sent to the origin address. 1272 Based on the SNMP version of the message, the engine passes the 1273 message to the appropriate version-specific Message Processing Model. 1274 The Message Processing Model extracts the information in the message, 1275 utilizing services of the appropriate Security Model to authenticate 1276 and decrypt the message as needed. 1278 4.3. Send a Request or Notification Message for an Application 1280 The Application Multiplexor receives a request for the generation 1281 of an SNMP message from an application via the sendPdu primitive: 1283 sendPdu( 1284 transportDomain -- transport domain to be used 1285 transportAddress -- destination network address 1286 messageProcessingModel -- typically, SNMP version 1287 securityModel -- Security Model to use 1288 securityName -- on behalf of this principal 1289 LoS -- Level of Security requested 1290 contextEngineID -- data from/at this entity 1291 contextName -- data from/in this context 1292 PDU -- SNMP Protocol Data Unit 1293 expectResponse) -- TRUE or FALSE 1295 The SNMP engine checks the "expectResponse" parameter to determine if 1296 it is a message which is expected to receive a response, and if so, 1297 caches the msgID of the generated message and which application 1298 made the request. 1300 The engine sends the message according to the procedure detailed 1301 in section 4.2.1. Send a Message to the Network. 1303 4.4. Receive a Request or Notification Message from the Network 1305 The engine receives the message according to the procedure detailed 1306 in section 4.2.2. Receive a Message from the Network. 1308 The Application Demultiplexor looks into the scopedPDU to determine 1309 the contextEngineID and the PDU type, then determines which 1310 application has registered (see section 4.7) to support that PDU type 1311 for that contextEngineID. 1313 The Application Demultiplexor passes the request or notification 1314 to the registered application using the processPdu primitive: 1316 processPdu( 1317 contextEngineID -- data from/at this SNMP engine 1318 contextName -- data from/in this context 1319 PDU -- SNMP Protocol Data Unit 1320 maxSizeResponseScopedPDU -- maximum size of the Response PDU 1321 securityModel -- Security Model in use 1322 securityName -- on behalf of this principal 1323 LoS -- Level of Security 1324 stateReference) -- reference to state information 1325 -- needed when sending a response 1327 4.5. Generate a Response Message for an Application 1329 The Application Multiplexor receives a request for the generation 1330 of an SNMP response message from an application via the 1331 returnResponsePdu primitive: 1333 returnResponsePdu( 1334 contextEngineID -- data from/at this SNMP engine 1335 contextName -- data from/in this context 1336 securityModel -- Security Model in use 1337 securityName -- on behalf of this principal 1338 LoS -- Level of Security 1339 stateReference -- reference to state information 1340 -- as presented with the request 1341 PDU -- SNMP Protocol Data Unit 1342 maxSizeResponseScopedPDU -- maximum size of the Response PDU 1343 statusInformation -- success or errorIndication 1344 ) -- error counter OID/value if error 1346 The engine sends the message according to the procedure detailed 1347 in section 4.2.1. Send a Message to the Network. 1349 4.6. Receive a Response Message 1351 The engine receives the message according to the procedure detailed 1352 in section 4.2.2. Receive a Message from the Network. 1354 The Application Demultiplexor looks into the scopedPDU to determine 1355 the contextEngineID and the PDU type. 1357 If the PDU type is a Response PDU, the Demultiplexor matches the 1358 msgID of the incoming response to the cached msgIDs of messages 1359 sent by this SNMP engine. 1361 If a matching cached msgID is found, the cached msgID and the cached 1362 origin network address are released, and the response is passed to the 1363 associated application using the processResponsePdu primitive: 1365 processResponsePdu( 1366 contextEngineID -- data from/at this SNMP engine 1367 contextName -- data from/in this context 1368 PDU -- SNMP Protocol Data Unit 1369 LoS -- Level of Security 1370 statusInformation -- success or errorIndication 1371 ) 1373 4.7. Registering to Receive Asynchronous Messages 1375 When an SNMP engine receives a message that is not the response to a 1376 request from this SNMP engine, it must determine to which application 1377 the message should be given. 1379 An Application that wishes to receive asynchronous messages registers 1380 itself with the engine using the registration primitive. The 1381 application registers to handle all incoming messages containing 1382 a particular PDU type regarding a specific contextEngineID. 1384 statusInformation = -- success or errorIndication 1385 registerContextEngineID( 1386 contextEngineID -- take responsibility for this one 1387 pduType -- the pduType(s) to be registered 1388 ) 1390 Only one registration per PDU type per contextEngineID is permitted 1391 at the same time. Duplicate registrations are ignored. An 1392 errorIndication will be returned to the application if it attempts 1393 to duplicate an existing registration. 1395 An Application that wishes to stop receiving asynchronous messages 1396 should unregister itself with the SNMP engine. 1398 unregisterContextEngineID( 1399 contextEngineID -- give up responsibility for this one 1400 pduType -- the pduType(s) to be unregistered 1401 ) 1403 SNMP does not provide a mechanism for identifying an application, 1404 so the mechanism used to identify which application is registering 1405 is implementation-specific. 1407 5. Definition of Managed Objects for Internet Management Frameworks 1409 SNMP-FRAMEWORK-MIB DEFINITIONS ::= BEGIN 1411 IMPORTS 1412 MODULE-IDENTITY, OBJECT-TYPE, 1413 OBJECT-IDENTITY, 1414 snmpModules, Unsigned32, Integer32 FROM SNMPv2-SMI 1415 TEXTUAL-CONVENTION FROM SNMPv2-TC 1416 MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF; 1418 snmpFrameworkMIB MODULE-IDENTITY 1419 LAST-UPDATED "9707110000Z" -- 11 July 1997, midnight 1420 ORGANIZATION "SNMPv3 Working Group" 1421 CONTACT-INFO "WG-email: snmpv3@tis.com 1422 Subscribe: majordomo@tis.com 1423 In message body: subscribe snmpv3 1425 Chair: Russ Mundy 1426 Trusted Information Systems 1427 postal: 3060 Washington Rd 1428 Glenwood MD 21738 1429 USA 1430 email: mundy@tis.com 1431 phone: +1-301-854-6889 1433 Co-editor Dave Harrington 1434 Cabletron Systems, Inc 1435 postal: Post Office Box 5005 1436 MailStop: Durham 1437 35 Industrial Way 1438 Rochester NH 03867-5005 1439 USA 1440 email: dbh@cabletron.com 1441 phone: +1-603-337-7357 1443 Co-editor: Bert Wijnen 1444 IBM T.J. Watson Research 1445 postal: Schagen 33 1446 3461 GL Linschoten 1447 Netherlands 1448 email: wijnen@vnet.ibm.com 1449 phone: +31-348-432-794 1450 " 1451 DESCRIPTION "The Internet Management Architecture MIB" 1452 ::= { snmpModules 7 } -- DBH: check if this number is indeed OK 1454 -- Textual Conventions used in the Internet Management Architecture *** 1456 SnmpEngineID ::= TEXTUAL-CONVENTION 1457 STATUS current 1458 DESCRIPTION "An SNMP engine's administratively-unique identifier. 1460 The value for this object may not be all zeros or 1461 all 'ff'H. It may also not be the empty string. 1463 The initial value for this object may be configured 1464 via an operator console entry or via an algorithmic 1465 function. In the latter case, the following 1466 example algorithm for a twelve-octet identifier 1467 is recommended: 1469 1) The first four octets are set to the binary 1470 equivalent of the entity's SNMP network management 1471 private enterprise number as assigned by the 1472 Internet Assigned Numbers Authority (IANA). 1473 For example, if Acme Networks has been assigned 1474 { enterprises 696 }, the first four octets would 1475 be assigned '000002b8'H. 1477 2) The remaining eight octets are determined via 1478 one or more enterprise specific methods. Such 1479 methods must be designed so as to maximize the 1480 possibility that the value of this object will 1481 be unique in the entity's administrative domain. 1482 For example, it may be the IP address of the SNMP 1483 entity, or the MAC address of one of the 1484 interfaces, with each address suitably padded 1485 with random octets. If multiple methods are 1486 defined, then it is recommended that the first 1487 octet that indicates the method being used and 1488 the remaining octets are a function of the method. 1489 " 1490 SYNTAX OCTET STRING 1492 SnmpSecurityModel ::= TEXTUAL-CONVENTION 1493 STATUS current 1494 DESCRIPTION "An identifier that uniquely identifies a securityModel 1495 of the Security Subsystem within the Internet 1496 Management Architecture. 1498 The values for securityModel are allocated as follows: 1500 - Negative and zero values are reserved. 1501 - Values between 1 and 255, inclusive, are reserved 1502 for standards-track Security Models and are managed 1503 by the Internet Assigned Numbers Authority (IANA). 1504 - Values greater than 255 are allocated to enterprise 1505 specific Security Models. An enterprise specific 1506 securityModel value is defined to be: 1508 enterpriseID * 256 + security model within enterprise 1509 For example, the fourth Security Model defined by 1510 the enterprise whose enterpriseID is 1 would be 260. 1512 The eight bits allow a maximum of 255 (256-1 reserved) 1513 standards based Security Models. Similarly, they 1514 allow a maximum of 255 Security Models per enterprise. 1516 It is believed that the assignment of new 1517 securityModel values will be rare in practice 1518 because the larger the number of simultaneously 1519 utilized Security Models, the larger the chance that 1520 interoperability will suffer. Consequently, it is 1521 believed that such a range will be sufficient. 1522 In the unlikely event that the standards committee 1523 finds this number to be insufficient over time, an 1524 enterprise number can be allocated to obtain an 1525 additional 255 possible values. 1527 Note that the most significant bit must be zero; 1528 hence, there are 23 bits allocated for various 1529 organizations to design and define non-standard 1530 securityModels. This limits the ability to define 1531 new proprietary implementations of Security Models 1532 to the first 8,388,608 enterprises. 1534 It is worthwhile to note that, in its encoded form, 1535 the securityModel value will normally require only a 1536 single byte since, in practice, the leftmost bits will 1537 be zero for most messages and sign extension is 1538 suppressed by the encoding rules. 1540 As of this writing, there are several values of 1541 securityModel defined for use with SNMP or reserved 1542 for use with supporting MIB objects. They are as 1543 follows: 1545 0 reserved for 'none' 1546 1 reserved for SNMPv1 1547 2 reserved for SNMPv2c 1548 3 User-Base Security Model (USM) 1549 255 reserved for 'any' 1550 " 1551 SYNTAX INTEGER(0..2147483647) 1553 SnmpLoS ::= TEXTUAL-CONVENTION 1554 STATUS current 1555 DESCRIPTION "A Level of Security at which SNMP messages can be 1556 sent or with which operations are being processed; 1557 in particular, one of: 1559 noAuthNoPriv - without authentication and 1560 without privacy, 1561 authNoPriv - with authentication but 1562 without privacy, 1563 authPriv - with authentication and 1564 with privacy. 1566 These three values are ordered such that noAuthNoPriv 1567 is lower than authNoPriv and authNoPriv is lower than 1568 authPriv. 1569 " 1570 SYNTAX INTEGER { noAuthNoPriv(1), 1571 authNoPriv(2), 1572 authPriv(3) 1573 } 1575 SnmpAdminString ::= TEXTUAL-CONVENTION 1576 DISPLAY-HINT "255a" 1577 STATUS current 1578 DESCRIPTION "An octet string containing administrative information, 1579 preferably in human-readable form. 1581 To facilitate internationalization, this information 1582 is represented using the ISO/IEC IS 10646-1 character 1583 set, encoded as an octet string using the UTF-8 1584 character encoding scheme described in RFC 2044. 1586 Since additional code points are added by amendments 1587 to the 10646 standard from time to time, 1588 implementations must be prepared to encounter any code 1589 point from 0x00000000 to 0x7fffffff. 1591 The use of control codes should be avoided. 1593 For code points not directly supported by user 1594 interface hardware or software, an alternative means 1595 of entry and display, such as hexadecimal, may be 1596 provided. 1598 For information encoded in 7-bit US-ASCII, the UTF-8 1599 representation is identical to the US-ASCII encoding. 1600 " 1601 SYNTAX OCTET STRING (SIZE (0..255)) 1603 -- Administrative assignments **************************************** 1605 snmpFrameworkAdmin OBJECT IDENTIFIER ::= { snmpFrameworkMIB 1 } 1606 snmpFrameworkMIBObjects OBJECT IDENTIFIER ::= { snmpFrameworkMIB 2 } 1607 snmpFrameworkMIBConformance OBJECT IDENTIFIER ::= { snmpFrameworkMIB 3 } 1608 -- the snmpEngine Group ********************************************** 1610 snmpEngine OBJECT IDENTIFIER ::= { snmpFrameworkMIBObjects 1 } 1612 snmpEngineID OBJECT-TYPE 1613 SYNTAX SnmpEngineID 1614 MAX-ACCESS read-only 1615 STATUS current 1616 DESCRIPTION "An SNMP engine's administratively-unique identifier. 1617 " 1618 ::= { snmpEngine 1 } 1620 snmpEngineBoots OBJECT-TYPE 1621 SYNTAX Unsigned32 -- (1..4294967295) 1622 MAX-ACCESS read-only 1623 STATUS current 1624 DESCRIPTION "The number of times that the SNMP engine has 1625 (re-)initialized itself since its initial 1626 configuration. 1627 " 1628 ::= { snmpEngine 2 } 1630 snmpEngineTime OBJECT-TYPE 1631 SYNTAX Integer32 (0..2147483647) 1632 MAX-ACCESS read-only 1633 STATUS current 1634 DESCRIPTION "The number of seconds since the SNMP engine last 1635 incremented the snmpEngineBoots object. 1636 " 1637 ::= { snmpEngine 3 } 1639 -- Registration Points for IMF Authentication and Privacy Protocols ** 1641 snmpAuthProtocols OBJECT-IDENTITY 1642 STATUS current 1643 DESCRIPTION "Registration point for standards-track authentication 1644 protocols used in the Internet Management Framework. 1645 " 1646 ::= { snmpFrameworkAdmin 1 } 1648 snmpPrivProtocols OBJECT-IDENTITY 1649 STATUS current 1650 DESCRIPTION "Registration point for standards-track privacy 1651 protocols used in the Internet Management Framework. 1652 " 1653 ::= { snmpFrameworkAdmin 2 } 1655 -- Conformance information ******************************************* 1657 snmpFrameworkMIBCompliances 1658 OBJECT IDENTIFIER ::= { snmpFrameworkMIBConformance 1 } 1659 snmpFrameworkMIBGroups 1660 OBJECT IDENTIFIER ::= { snmpFrameworkMIBConformance 2 } 1662 -- compliance statements 1664 snmpFrameworkMIBCompliance MODULE-COMPLIANCE 1665 STATUS current 1666 DESCRIPTION "The compliance statement for SNMP engines which 1667 implement the Internet Management Framework MIB. 1668 " 1669 MODULE -- this module 1670 MANDATORY-GROUPS { snmpEngineGroup } 1672 ::= { snmpFrameworkMIBCompliances 1 } 1674 -- units of conformance 1676 snmpEngineGroup OBJECT-GROUP 1677 OBJECTS { 1678 snmpEngineID, 1679 snmpEngineBoots, 1680 snmpEngineTime 1681 } 1682 STATUS current 1683 DESCRIPTION "A collection of objects for identifying and 1684 determining the configuration and current timeliness 1685 values of an SNMP engine. 1686 " 1687 ::= { snmpFrameworkMIBGroups 1 } 1689 END 1690 6. Security Considerations 1692 This document describes how a framework can use a Security Model and 1693 an Access Control Model to achieve a level of security for network 1694 management messages and controlled access to management information. 1696 The level of security provided is determined by the specific Security 1697 Model implementation(s) and the specific Access Control Model 1698 implementation(s) incorporated into this framework. 1700 Applications have access to data which is not secured. Applications 1701 should take reasonable steps to protect the data from disclosure. 1703 It is the responsibility of the purchaser of a management framework 1704 implementation to ensure that: 1705 1) an implementation of this framework complies with the rules 1706 defined by this architecture, 1707 2) the Security and Access Control Models utilized satisfy the 1708 security and access control needs of the organization, 1709 3) the implementations of the Models and Applications comply with 1710 the model and application specifications, 1711 4) and the implementation protects configuration secrets from 1712 inadvertent disclosure. 1714 7. Glossary 1715 8. References 1717 [RFC1155] Rose, M., and K. McCloghrie, "Structure and Identification 1718 of Management Information for TCP/IP-based internets", STD 16, 1719 RFC 1155, May 1990. 1721 [RFC1157] Case, J., M. Fedor, M. Schoffstall, and J. Davin, 1722 "The Simple Network Management Protocol", STD 15, RFC 1157, 1723 University of Tennessee at Knoxville, Performance Systems s 1724 International, Performance International, and the MIT Laboratory 1725 for Computer Science, May 1990. 1727 [RFC1212] Rose, M., and K. McCloghrie, "Concise MIB Definitions", 1728 STD 16, RFC 1212, March 1991. 1730 [RFC1901] The SNMPv2 Working Group, Case, J., McCloghrie, K., 1731 Rose, M., and S., Waldbusser, "Introduction to 1732 Community-based SNMPv2", RFC 1901, January 1996. 1734 [RFC1902] The SNMPv2 Working Group, Case, J., McCloghrie, K., 1735 Rose, M., and S., Waldbusser, "Structure of Management 1736 Information for Version 2 of the Simple Network Management 1737 Protocol (SNMPv2)", RFC 1905, January 1996. 1739 [RFC1903] The SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., 1740 and S. Waldbusser, "Textual Conventions for Version 2 of the Simple 1741 Network Management Protocol (SNMPv2)", RFC 1903, January 1996. 1743 [RFC1904] The SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., 1744 and S., Waldbusser, "Conformance Statements for Version 2 of the 1745 Simple Network Management Protocol (SNMPv2)", RFC 1904, 1746 January 1996. 1748 [RFC1905] The SNMPv2 Working Group, Case, J., McCloghrie, K., 1749 Rose, M., and S., Waldbusser, "Protocol Operations for 1750 Version 2 of the Simple Network Management Protocol (SNMPv2)", 1751 RFC 1905, January 1996. 1753 [RFC1906] The SNMPv2 Working Group, Case, J., McCloghrie, K., 1754 Rose, M., and S. Waldbusser, "Transport Mappings for 1755 Version 2 of the Simple Network Management Protocol (SNMPv2)", 1756 RFC 1906, January 1996. 1758 [RFC1907] The SNMPv2 Working Group, Case, J., McCloghrie, K., 1759 Rose, M., and S. Waldbusser, "Management Information Base for 1760 Version 2 of the Simple Network Management Protocol (SNMPv2)", 1761 RFC 1907 January 1996. 1763 [RFC1908] The SNMPv2 Working Group, Case, J., McCloghrie, K., 1764 Rose, M., and S. Waldbusser, "Coexistence between Version 1 1765 and Version 2 of the Internet-standard Network Management 1766 Framework", RFC 1908, January 1996. 1768 [RFC1909] McCloghrie, K., Editor, "An Administrative Infrastructure 1769 for SNMPv2", RFC1909, February 1996 1771 [RFC1910] Waters, G., Editor, "User-based Security Model for SNMPv2", 1772 RFC1910, February 1996 1774 9. Editor's Addresses 1776 Co-editor: Bert Wijnen 1777 IBM T.J. Watson Research 1778 postal: Schagen 33 1779 3461 GL Linschoten 1780 Netherlands 1781 email: wijnen@vnet.ibm.com 1782 phone: +31-348-432-794 1784 Co-editor Dave Harrington 1785 Cabletron Systems, Inc 1786 postal: Post Office Box 5005 1787 MailStop: Durham 1788 35 Industrial Way 1789 Rochester NH 03867-5005 1790 USA 1791 email: dbh@cabletron.com 1792 phone: +1-603-337-7357 1794 10. Acknowledgements 1796 This document builds on the work of the SNMP Security and 1797 Administrative Framework Evolution team, composed of 1799 David Harrington (Cabletron Systems Inc.) 1800 Jeff Johnson (Cisco) 1801 David Levi (SNMP Research Inc.) 1802 John Linn (Openvision) 1803 Russ Mundy (Trusted Information Systems) chair 1804 Shawn Routhier (Epilogue) 1805 Glenn Waters (Nortel) 1806 Bert Wijnen (IBM T.J. Watson Research) 1808 APPENDIX A 1810 A. Guidelines for Model Designers 1812 This appendix describes guidelines for designers of models which 1813 are expected to fit into the architecture defined in this document. 1815 The basic design elements come from SNMPv2u and SNMPv2*, as 1816 described in RFCs 1909-1910, and from a set of internet drafts. 1817 these are the two most popular de facto "administrative framework" 1818 standards that include security and access control for SNMPv2. 1820 SNMPv1 and SNMPv2c [RFC1901] are two administrative frameworks based 1821 on communities to provide trivial authentication and access control. 1822 SNMPv1 and SNMPv2c Frameworks can coexist with Frameworks designed 1823 to fit into this architecture, and modified versions of SNMPv1 and 1824 SNMPv2c Frameworks could be fit into this architecture, but this 1825 document does not provide guidelines for that coexistence. 1827 Within any subsystem model, there should be no reference to any 1828 specific model of another subsystem, or to data defined by a specific 1829 model of another subsystem. 1831 Transfer of data between the subsystems is deliberately described 1833 as a fixed set of abstract data elements and primitive functions 1834 which can be overloaded to satisfy the needs of multiple model 1835 definitions. 1837 Documents which define models to be used within this architecture 1838 SHOULD use the standard primitives between subsystems, possibly 1839 defining specific mechanisms for converting the abstract data elements 1840 into model-usable formats. This constraint exists to allow subsystem 1841 and model documents to be written recognizing common borders of the 1842 subsystem and model. Vendors are not constrained to recognize these 1843 borders in their implementations. 1845 The architecture defines certain standard services to be provided 1846 between subsystems, and the architecture defines abstract service 1847 interfaces to request the services. 1849 Each model definition for a subsystem SHOULD support the standard 1850 service interfaces, but whether, or how, or how well, it performs 1851 the service is defined by the model definition. 1853 A.1. Security Model Design Requirements 1855 A.1.1. Threats 1857 A document describing a Security Model MUST describe how the model 1858 protects against the threats described under "Security Requirements 1859 of this Architecture", section 1.4. 1861 A.1.2. Security Processing 1863 Received messages MUST be validated by a Model of the Security 1864 Subsystem. Validation includes authentication and privacy processing 1865 if needed, but it is explicitly allowed to send messages which do 1866 not require authentication or privacy. 1868 A received message contains a specified Level of Security to be 1869 used during processing. All messages requiring privacy MUST also 1870 require authentication. 1872 A Security Model specifies rules by which authentication and privacy 1873 are to be done. A model may define mechanisms to provide additional 1874 security features, but the model definition is constrained to using 1875 (possibly a subset of) the abstract data elements defined in this 1876 document for transferring data between subsystems. 1878 Each Security Model may allow multiple security mechanisms to be used 1879 concurrently within an implementation of the model. Each Security Model 1880 defines how to determine which protocol to use, given the LoS and the 1881 security parameters relevant to the message. Each Security Model, with 1882 its associated protocol(s) defines how the sending/receiving entities 1883 are identified, and how secrets are configured. 1885 Authentication and Privacy protocols supported by Security Models are 1886 uniquely identified using Object Identifiers. IETF standard protocol 1887 for authentication or privacy should have an identifier defined within 1888 the snmpAuthProtocols or the snmpPrivProtocols subtrees. Enterprise 1889 specific protocol identifiers should be defined within the enterprise 1890 subtree. 1892 For privacy, the Security Model defines what portion of the message 1893 is encrypted. 1895 The persistent data used for security should be SNMP-manageable, but 1896 the Security Model defines whether an instantiation of the MIB is a 1897 conformance requirement. 1899 Security Models are replaceable within the Security Subsystem. 1900 Multiple Security Model implementations may exist concurrently within 1901 an SNMP engine. The number of Security Models defined by the SNMP 1902 community should remain small to promote interoperability. 1904 A.1.3. validate the security-stamp in a received message 1906 The Message Processing Model requests that the Security Model verify 1907 that the message has not been altered, and authenticate the 1908 identification of the principal for whom the message was generated. 1909 If encrypted, decrypt the message. 1911 Additional requirements may be defined by the model, and additional 1912 services provided by the model, but the model is constrained to use 1913 the following primitives for transferring data between subsystems. 1914 Implementations are not so constrained. 1916 The Message Processing Model uses the following primitive: 1918 processMsg( 1919 messageProcessingModel -- typically, SNMP version 1920 msgID -- of the received message 1921 mms -- of the sending SNMP entity 1922 msgFlags -- for the received message 1923 securityParameters -- for the received message 1924 securityModel -- for the received message 1925 LoS -- Level of Security 1926 wholeMsg -- as received on the wire 1927 wholeMsgLength -- length as received on the wire 1928 ) 1930 The Security Model uses the following primitive to respond: 1932 returnProcessedMsg( 1933 securityName -- identification of the principal 1934 scopedPDU, -- message (plaintext) payload 1935 maxSizeResponseScopedPDU -- maximum size of the Response PDU 1936 securityStateReference -- reference to security state 1937 -- information, needed for response 1938 statusInformation -- errorIndication or success 1939 ) -- error counter OID/value if error 1941 A.1.5. Security MIBs 1943 Each Security Model defines the MIB modules required for security 1944 processing, including any MIB modules required for the security 1945 mechanism(s) supported. The MIB modules SHOULD be defined concurrently 1946 with the procedures which use the MIB module. The MIB modules are 1947 subject to normal security and access control rules. 1949 The mapping between the model-dependent identifier and the securityName 1950 MUST be able to be determined using SNMP, if the model-dependent 1951 MIB is instantiated and access control policy allows access. 1953 A.1.6. Security State Cache 1955 For each message received, the Security Subsystem caches the state 1956 information such that a Response message can be generated using the 1957 same security state information, even if the Local Configuration 1958 Datastore is altered between the time of the incoming request and 1959 the outgoing response. 1961 Applications have the responsibility for explicitly releasing the 1962 cached data. To enable this, an abstract stateReference data element 1963 is passed from the Security Subsystem to the Message Processing 1964 Subsystem, which passes it to the application. 1966 The cached security data may be implicitly released via the 1967 generation of a response, or explicitly released by using the 1968 stateRelease primitive: 1970 stateRelease( 1971 stateReference -- handle of reference to be released 1972 ) 1974 A.2. SNMP engine and Message Processing Model Requirements 1976 An SNMP engine contains a Message Processing Subsystem which may 1977 contain multiple version-specific Message Processing Models. 1979 Within any version-specific Message Processing Model, there may be 1980 an explicit binding to a particular Security Model but there should 1981 be no reference to any data defined by a specific Security Model. 1982 There should be no reference to any specific application, or to any 1983 data defined by a specific application; there should be no reference 1984 to any specific Access Control Model, or to any data defined by a 1985 specific Access Control Model. 1987 The Message Processing Model MUST always (conceptually) pass the 1988 complete PDU, i.e. it never forwards less than the complete list of 1989 varBinds. 1991 A.2.1. Receiving an SNMP Message from the Network 1993 Upon receipt of a message from the network, the SNMP engine notes the 1994 msgID, which is subsequently used for coordinating all processing 1995 regarding this received message. 1997 A Message Processing Model specifies how to determine the values of 1998 the global data (mms, the securityModel, the LoS), and the security 1999 parameters block. The Message Processing Model calls the Security 2000 Model to provide security processing for the message using the 2001 primitive: 2003 processMsg( 2004 messageProcessingModel -- typically, SNMP version 2005 msgID -- of the received message 2006 mms -- of the sending SNMP entity 2007 msgFlags -- for the received message 2008 securityParameters -- for the received message 2009 securityModel -- for the received message 2010 LoS -- Level of Security 2011 wholeMsg -- as received on the wire 2012 wholeMsgLength -- length as received on the wire 2013 ) 2015 The Security Model uses the following primitive to respond: 2017 returnProcessedMsg( 2018 securityName -- identification of the principal 2019 scopedPDU, -- message (plaintext) payload 2020 maxSizeResponseScopedPDU -- maximum size of the Response PDU 2021 securityStateReference -- reference to security state 2022 -- information, needed for response 2023 statusInformation -- errorIndication or success 2024 ) -- error counter OID/value if error 2026 A.2.2. Send SNMP messages to the network 2028 The Message Processing Model passes a PDU, the 2029 securityName, and all global data to be included in the message to 2030 the Security model using the following primitives: 2032 For requests and notifications: 2034 generateRequestMsg( 2035 messageProcessingModel -- typically, SNMP version 2036 msgID -- for the outgoing message 2037 mms -- of the sending SNMP entity 2038 msgFlags -- for the outgoing message 2039 securityParameters -- filled in by Security Module 2040 securityModel -- for the outgoing message 2041 securityName -- on behalf of this principal 2042 LoS -- Level of Security requested 2043 snmpEngineID -- authoritative SNMP engine 2044 scopedPDU -- message (plaintext) payload 2045 ) 2047 For response messages: 2049 generateResponseMsg( 2050 messageProcessingModel -- typically, SNMP version 2051 msgID -- for the outgoing message 2052 mms -- of the sending SNMP entity 2053 msgFlags -- for the outgoing message 2054 securityParameters -- filled in by Security Module 2055 securityModel -- for the outgoing message 2056 scopedPDU -- message (plaintext) payload 2057 securityStateReference -- reference to security state 2058 -- information, as received in 2059 ) -- processPdu primitive 2061 The Security model constructs the message, and returns the completed 2062 message to the Message Processing Model using the returnGeneratedMsg 2063 primitive: 2065 returnGeneratedMsg( 2066 wholeMsg -- complete generated message 2067 wholeMsgLength -- length of the generated message 2068 statusInformation -- errorIndication or success 2069 ) 2071 The SNMP engine sends the message to the desired address using the 2072 appropriate transport. 2074 A.2.3. Generate Request or Notification Message for an Application 2075 The SNMP engine receives a request for the generation of an SNMP 2076 message from an application via the sendPdu primitive: 2078 sendPdu( 2079 transportDomain -- transport domain to be used 2080 transportAddress -- destination network address 2081 messageProcessingModel -- typically, SNMP version 2082 securityModel -- Security Model to use 2083 securityName -- on behalf of this principal 2084 LoS -- Level of Security requested 2085 contextEngineID -- data from/at this entity 2086 contextName -- data from/in this context 2087 PDU -- SNMP Protocol Data Unit 2088 expectResponse -- TRUE or FALSE 2089 ) 2091 The SNMP engine checks the "expectResponse" parameter to determine if 2092 it is a message which is expected to receive a response, and if so, 2093 caches the msgID of the generated message and the associated 2094 application. 2096 The Message Processing Model generates the message according to the 2097 process described in A.2.2. 2099 A.2.4. Pass Received Response Message to an Application 2101 The Message Processing Model receives the SNMP message according to 2102 the process described in A.2.1. 2104 The Message Processing Model determines which application is awaiting 2105 this response, using the msgID and the cached information from 2106 step A.2.3 2108 The Message Processing Model matches the msgID of an incoming response 2109 to the cached msgIDs of messages sent by this SNMP engine, and 2110 forwards the response to the associated application using the 2111 processResponsePdu primitive: 2113 processResponsePdu( -- process Response PDU 2114 contextEngineID -- data from/at this SNMP entity 2115 contextName -- data from/in this context 2116 PDU -- SNMP Protocol Data Unit 2117 LoS -- Level of Security 2118 statusInformation -- success or errorIndication 2119 ) 2121 A.2.5. Pass Received Request or Notification Message to Application 2123 The Message Processing Model receives the SNMP message according to 2124 the process described in A.2.1. 2126 The SNMP engine looks into the scopedPDU to determine the 2127 contextEngineID, then determine which application has registered to 2128 support that contextEngineID, and forwards the request or notification 2129 to the registered application using the processPdu primitive: 2131 processPdu( -- process Request/Notification PDU 2132 contextEngineID -- data from/at this SNMP engine 2133 contextName -- data from/in this context 2134 PDU -- SNMP Protocol Data Unit 2135 maxSizeResponseScopedPDU -- maximum size of the Response PDU 2136 securityModel -- Security Model in use 2137 securityName -- on behalf of this principal 2138 LoS -- Level of Security 2139 stateReference -- reference to state information 2140 ) -- needed when sending a response 2142 A.2.6. Generate a Response Message for an Application 2144 The SNMP engine receives a request for the generation of an SNMP 2145 response message from an application via the returnResponsePdu 2146 primitive: 2148 returnResponsePdu( 2149 contextEngineID -- data from/at this SNMP engine 2150 contextName -- data from/in this context 2151 PDU -- SNMP Protocol Data Unit 2152 maxSizeResponseScopedPDU -- maximum size of the Response PDU 2153 securityModel -- Security Model in use 2154 securityName -- on behalf of this principal 2155 LoS -- Level of Security 2156 stateReference -- reference to state information 2157 -- as presented with the request 2158 statusInformation -- success or errorIndication 2159 ) -- error counter OID/value if error 2161 The SNMP engine generates the message according to the process 2162 described in A.2.2. 2164 A.3. Application Design Requirements 2166 Within an application, there may be an explicit binding to a specific 2167 SNMP message version, i.e. a specific Message Processing Model, and to 2168 a specific Access Control Model, but there should be no reference to 2169 any data defined by a specific Message Processing Model or Access 2170 Control Model. 2172 Within an application, there should be no reference to any specific 2173 Security Model, or any data defined by a specific Security Model. 2175 An application determines whether explicit or implicit access control 2176 should be applied to the operation, and, if access control is needed, 2177 which Access Control Model should be used. 2179 An application has the responsibility to define any MIB modules used 2180 to provide application-specific services. 2182 Applications interact with the SNMP engine to initiate messages, 2183 receive responses, receive asynchronous messages, and send responses. 2185 A.3.1. Applications that Initiate Messages 2187 Applications may request that the SNMP engine send messages containing 2188 SNMP commands or notifications using the sendPdu primitive: 2190 sendPdu( 2191 transportDomain -- transport domain to be used 2192 transportAddress -- destination network address 2193 messageProcessingModel -- typically, SNMP version 2194 securityModel -- Security Model to use 2195 securityName -- on behalf of this principal 2196 LoS -- Level of Security requested 2197 contextEngineID -- data from/at this entity 2198 contextName -- data from/in this context 2199 PDU -- SNMP Protocol Data Unit 2200 expectResponse -- TRUE or FALSE 2201 ) 2203 If it is desired that a message be sent to multiple targets, it is the 2204 responsibility of the application to provide the iteration. 2206 The SNMP engine assumes necessary access control has been applied 2207 to the PDU, and provides no access control services. 2208 The SNMP engine looks at the "expectResponse" parameter, and for 2209 operations which elicit a response, the msgID and the associated 2210 application are cached. 2212 A.3.2. Applications that Receive Responses 2214 The SNMP engine matches the msgID of an incoming response to the 2215 cached msgIDs of messages sent by this SNMP engine, and forwards the 2216 response to the associated application using the processResponsePdu 2217 primitive: 2219 processResponsePdu( -- process Response PDU 2220 contextEngineID -- data from/at this SNMP entity 2221 contextName -- data from/in this context 2222 PDU -- SNMP Protocol Data Unit 2223 LoS -- Level of Security 2224 statusInformation -- success or errorIndication 2225 ) 2227 The SNMP engine then releases its own state information about this 2228 message. 2230 A.3.3. Applications that Receive Asynchronous Messages 2232 When an SNMP engine receives a message that is not the response to a 2233 request from this SNMP engine, it must determine to which application 2234 the message should be given. 2236 An Application that wishes to receive asynchronous messages registers 2237 itself with the engine using the registration primitive. 2238 An Application that wishes to stop receiving asynchronous messages 2239 should unregister itself with the SNMP engine. 2241 statusInformation = -- success or errorIndication 2242 registerContextEngineID( 2243 contextEngineID -- take responsibility for this one 2244 pduType -- the pduType(s) to be registered 2245 ) 2247 unregisterContextEngineID( 2248 contextEngineID -- give up responsibility for this one 2249 pduType -- the pduType(s) to be unregistered 2250 ) 2252 Only one registration per PDU type per contextEngineID is permitted 2253 at the same time. Duplicate registrations are ignored. An 2254 errorIndication will be returned to the application that attempts 2255 to duplicate a registration. 2257 All asynchronously received messages containing a registered 2258 PDU type and contextEngineID are sent to the application which 2259 registered to support that combination. 2261 The engine forwards the PDU to the registered application, using the 2262 processPdu primitive: 2264 processPdu( -- process Request/Notification PDU 2265 contextEngineID -- data from/at this SNMP engine 2266 contextName -- data from/in this context 2267 PDU -- SNMP Protocol Data Unit 2268 maxSizeResponseScopedPDU -- maximum size of the Response PDU 2269 securityModel -- Security Model in use 2270 securityName -- on behalf of this principal 2271 LoS -- Level of Security 2272 stateReference -- reference to state information 2273 ) -- needed when sending a response 2275 A.3.4. Applications that Send Responses 2276 Request operations require responses. These operations include Get 2277 requests, Set requests, and Inform requests. An application sends a 2278 response via the returnResponsePdu primitive: 2280 returnResponsePdu( 2281 contextEngineID -- data from/at this SNMP engine 2282 contextName -- data from/in this context 2283 PDU -- SNMP Protocol Data Unit 2284 maxSizeResponseScopedPDU -- maximum size of the Response PDU 2285 securityModel -- on behalf of this principal 2286 securityName -- on behalf of this principal 2287 LoS -- Level of Security 2288 stateReference -- reference to state information 2289 -- as presented with the request 2290 statusInformation -- success or errorIndication 2291 ) -- error counter OID/value if error 2293 The contextEngineID, contextName, securityModel, securityName, LoS, and 2294 stateReference parameters are from the initial processPdu primitive. 2295 The PDU and statusInformation are the results of processing. 2297 A.4. Access Control Model Design Requirements 2299 An Access Control Model determines whether the specified 2300 securityName is allowed to perform the requested operation on 2301 a specified managed object. The Access Control Model specifies the 2302 rules by which access control is determined. 2304 The persistent data used for access control should be manageable 2305 using SNMP, but the Access Control model defines whether an 2306 instantiation of the MIB is a conformance requirement. 2308 The following primitive is used to invoke the access control service: 2310 statusInformation = -- success or errorIndication 2311 isAccessAllowed( 2312 securityModel -- Security Model in use 2313 securityName -- principal who wants to access 2314 LoS -- Level of Security 2315 viewType -- read, write, or notify view 2316 contextName -- context containing variableName 2317 variableName -- OID for the managed object 2318 ) 2320 APPENDIX B 2322 B. An Evolutionary Architecture - Design Goals 2324 The goals of the architectural design are to use encapsulation, 2325 cohesion, hierarchical rules, and loose coupling to reduce complexity 2326 of design and make the evolution of portions of the architecture 2327 possible. 2329 B.1. Encapsulation 2331 Encapsulation describes the practice of hiding the details that are 2332 used internal to a process. Some data is required for a given 2333 procedure, but isn't needed by any other part of the process. 2335 In networking, the concept of a layered stack reflects this approach. 2336 The transport layer contains data specific to its processing; the data 2337 is not visible to the other layers. In programming this is reflected 2338 in language elements such as "file static" variables in C, and 2339 "private" in C++, etc. 2341 In this architecture, all data used for processing only within 2342 a functional portion of the architecture should have its visibility 2343 restricted to that portion if possible. The data should be accessed 2344 only by that functionality defined with the data. No reference to the 2345 data should be made from outside the functional portion of the 2346 architecture, except through predefined public interfaces. 2348 B.2. Cohesion 2350 Similar functions can be grouped together and their differences 2351 ignored, so they can be dealt with as a single entity. It is important 2352 that the functions which are grouped together are actually similar. 2353 Similarity of the data used to perform functions can be a good 2354 indicator of the similarity of the functions. 2356 For example, authentication and encryption are both security functions 2357 which are applied to a message. Access control, while similar in some 2358 ways, is dissimilar in that it is not applied to a message, it is 2359 applied to a (proposed) request for a management operation. 2360 The data required to perform authentication and encryption are 2361 different than the data needed to perform access control, and the 2362 two sets of services can be described independently. 2364 Similar functions, especially those that use the same data elements, 2365 should be defined together. The security functions which operate at 2366 the message level should be defined in a document together with the 2367 definitions for those data elements that are used only by those 2368 security functions. For example, a MIB with authentication keys is 2369 used only by authentication functions; they should be defined together. 2371 B.3. Hierarchical Rules 2373 Functionality can be grouped into hierarchies where each element in the 2374 hierarchy receives general characteristics from its direct superior, 2375 and passes on those characteristics to each of its direct subordinates. 2377 This architecture uses the hierarchical approach by defining 2378 subsystems, which specify the general rules of a portion of the system, 2379 models which define the specific rules to be followed by an 2380 implementation of the portion of the system, and implementations which 2381 encode those rules into reality for a portion of the system. 2383 Within portions of the system, hierarchical relationships are used to 2384 compartmentalize, or modularize, the implementation of specific 2385 functionality. For example, within the security portion of the system, 2386 authentication and privacy may be contained in separate modules, and 2387 multiple authentication and privacy mechanisms may be supported by 2388 allowing supplemental modules that provide protocol-specific 2389 authentication and privacy services. 2391 B.4. Coupling 2393 Coupling describes the amount of interdependence between parts of 2394 a system. Loose coupling indicates that two sub-systems are relatively 2395 independent of each other; tight coupling indicates a high degree of 2396 mutual dependence. 2398 To make it possible to evolve the architecture by replacing only part 2399 of the system, or by supplementing existing portions with alternate 2400 mechanisms for similar functionality, without obsoleting the complete 2401 system, it is necessary to limit the coupling of the parts. 2403 Encapsulation and cohesion help to reduce coupling by limiting the 2404 visibility of those parts that are only needed within portions of a 2405 system. Another mechanism is to constrain the nature of interactions 2406 between various parts of the system. 2408 This can be done by defining fixed, generic, flexible interfaces 2409 for transferring data between the parts of the system. The concept of 2410 plug-and-play hardware components is based on that type of interface 2411 between the hardware component and system into which it is "plugged." 2413 This approach has been chosen so individual portions of the system 2414 can be upgraded over time, while keeping the overall system intact. 2416 To avoid specifying fixed interfaces, which would constrain a vendor's 2417 choice of implementation strategies, a set of abstract data elements 2418 is used for (conceptually) transferring data between subsystems in 2419 documents which describe subsystem or model interactions. Documents 2420 describing the interaction of subsystems or models should use only 2421 the abstract data elements provided for transferring data but vendors 2422 are not constrained to using the described data elements for 2423 transferring data between portions of their implementation. 2425 Loose coupling works well with the IETF standards process. If we 2426 separate message-handling from security and from local processing, 2427 then the separate portions of the system can move through the standards 2428 process with less dependence on the status of the other portions of the 2429 standard. Security models may be able to be re-opened for discussion 2430 due to patents, new research, export laws, etc., as is clearly expected 2431 by the WG, without needing to reopen the documents which detail the 2432 message format or the local processing of PDUs. Thus, the standards 2433 track status of related, but independent, documents is not affected. 2435 Table of Contents 2437 0. Issues 2 2438 0.1. Issues to be resolved 2 2439 0.1.1. Issues discussed at second Interim Meeting: 2 2440 0.2. Change Log 3 2441 1. Introduction 7 2442 1.1. Target Audience 7 2443 1.2. Management Systems 7 2444 1.3. Goals of this Architecture 8 2445 1.4. Security Requirements of this Architecture 9 2446 1.5. Design Decisions 10 2447 2. Documentation Overview 12 2448 2.1. Document Roadmap 13 2449 2.2. Applicability Statement 13 2450 2.3. Coexistence and Transition 13 2451 2.4. Transport Mappings 14 2452 2.5. Message Processing 14 2453 2.6. Security 14 2454 2.7. Access Control 14 2455 2.8. Applications 15 2456 2.9. Structure of Management Information 15 2457 2.10. Textual Conventions 15 2458 2.11. Conformance Statements 15 2459 2.12. Protocol Operations 16 2460 2.13. Management Information Base Modules 16 2461 2.13.1. SNMP Instrumentation MIBs 16 2462 2.14. SNMP Framework Documents 16 2463 3. Naming 18 2464 3.1. The Naming of Entities 18 2465 3.1.1. SNMP entity 19 2466 3.1.2. SNMP engine 19 2467 3.1.3. snmpEngineID 19 2468 3.1.4. Message Processing Subsystem 19 2469 3.1.5. Message Processing Model 19 2470 3.1.6. Security Subsystem 20 2471 3.1.7. Security Model 20 2472 3.1.8. Security Protocol 20 2473 3.1.9. Access Control Subsystem 21 2474 3.1.10. Access Control Model 21 2475 3.1.11. Applications 21 2476 3.1.12. SNMP Agent 21 2477 3.1.13. SNMP Manager 21 2478 3.2. The Naming of Identities 22 2479 3.2.1. Principal 22 2480 3.2.2. securityName 22 2481 3.2.3. Model dependent security ID 22 2482 3.3. The Naming of Management Information 23 2483 3.3.1. An SNMP Context 24 2484 3.3.2. contextEngineID 24 2485 3.3.3. contextName 24 2486 3.3.4. scopedPDU 24 2487 3.4. Other Constructs 25 2489 \^L 2490 3.4.1. maxSizeResponseScopedPDU 25 2491 3.4.2. Local Configuration Datastore 25 2492 3.4.3. LoS 25 2493 4. Architectural Elements of Procedure 26 2494 4.1. Operational Overview 27 2495 4.2. Sending and Receiving SNMP Messages 29 2496 4.2.1. Send a Message to the Network 29 2497 4.2.2. Receive a Message from the Network 29 2498 4.3. Send a Request or Notification Message for an Application 30 2499 4.4. Receive a Request or Notification Message from the Network 30 2500 4.5. Generate a Response Message for an Application 31 2501 4.6. Receive a Response Message 31 2502 4.7. Registering to Receive Asynchronous Messages 31 2503 5. Definition of Managed Objects for Internet Management Frameworks 33 2504 6. Security Considerations 39 2505 7. Glossary 40 2506 8. References 40 2507 9. Editor's Addresses 42 2508 10. Acknowledgements 43 2509 A. Guidelines for Model Designers 44 2510 A.1. Security Model Design Requirements 44 2511 A.1.1. Threats 44 2512 A.1.2. Security Processing 45 2513 A.1.3. validate the security-stamp in a received message 45 2514 A.1.5. Security MIBs 46 2515 A.1.6. Security State Cache 46 2516 A.2. SNMP engine and Message Processing Model Requirements 48 2517 A.2.1. Receiving an SNMP Message from the Network 48 2518 A.2.2. Send SNMP messages to the network 49 2519 A.2.3. Generate Request or Notification Message for an Application 49 2520 A.2.4. Pass Received Response Message to an Application 50 2521 A.2.5. Pass Received Request or Notification Message to Application 50 2522 A.2.6. Generate a Response Message for an Application 51 2523 A.3. Application Design Requirements 51 2524 A.3.1. Applications that Initiate Messages 52 2525 A.3.2. Applications that Receive Responses 52 2526 A.3.3. Applications that Receive Asynchronous Messages 53 2527 A.3.4. Applications that Send Responses 53 2528 A.4. Access Control Model Design Requirements 54