idnits 2.17.1 draft-ietf-snmpv3-v3mpc-model-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 9 longer pages, the longest (page 35) being 60 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 9 instances of too long lines in the document, the longest one being 4 characters in excess of 72. ** There are 5 instances of lines with control characters in the document. ** The abstract seems to contain references ([SNMP-ARCH]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 453 has weird spacing: '... data scope...' == Line 564 has weird spacing: '...lag one and p...' == Line 565 has weird spacing: '...lag one and p...' == Line 783 has weird spacing: '...ossible secur...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (11 July 1997) is 9786 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC1157' is mentioned on line 263, but not defined == Unused Reference: 'RFC1902' is defined on line 1346, but no explicit reference was found in the text == Unused Reference: 'RFC1908' is defined on line 1366, but no explicit reference was found in the text == Unused Reference: 'SNMPv3-ACM' is defined on line 1375, but no explicit reference was found in the text == Unused Reference: 'SNMPv3-USM' is defined on line 1380, but no explicit reference was found in the text ** Downref: Normative reference to an Historic RFC: RFC 1901 ** Obsolete normative reference: RFC 1905 (ref. 'RFC1902') (Obsoleted by RFC 3416) -- 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) == Outdated reference: A later version (-06) exists of draft-ietf-snmpv3-next-gen-arch-03 == Outdated reference: A later version (-04) exists of draft-ietf-snmpv3-acm-01 == Outdated reference: A later version (-03) exists of draft-ietf-snmpv3-usm-00 Summary: 18 errors (**), 0 flaws (~~), 14 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Message Processing Model for version 3 of the 2 Simple Network Management Protocol (SNMPv3) 4 11 July 1997 6 J. Case 7 SNMP Research Inc. 8 case@snmp.com 10 D. Harrington 11 Cabletron Systems, Inc. 12 dbh@cabletron.com 14 B. Wijnen 15 IBM T. J. Watson Research 16 wijnen@vnet.ibm.com 18 19 21 Status of this Memo 23 This document is an Internet-Draft. Internet-Drafts are working 24 documents of the Internet Engineering Task Force (IETF), its areas, and 25 its working groups. Note that other groups may also distribute working 26 documents as Internet-Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet- Drafts as reference material 31 or to cite them other than as ``work in progress.'' 33 To learn the current status of any Internet-Draft, please check the 34 ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow 35 Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), 36 ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). 38 Abstract 40 This document describes the SNMP version 3 Message Processing Model 41 for use in the SNMP architecture [SNMP-ARCH]. It defines the SNMP 42 version 3 message format, and the procedures for coordinating the 43 processing of a message in SNMPv3 format. 45 Case/Harrington/Wijnen Expires December 1997 [Page 1] 46 0. Issues 47 . Message ::= instead of snmpV3Message ::= ? is this ok? 48 . verify the abstract service primitives once more... names 49 of primitives and parameters seem to keep changing. 50 . Do we need to expand in section 2.2.2.x 51 . Do we want the MIB to be a logical extension of the SNMPv2 52 MIB? Instead of having our own snmpV3MIB, we could import 53 snmp and snmpMIBObjects from the SNMPv2-MIB (RFC1907) and 54 then start assinging the counter from { snmp 33 } onwards. 55 We could then also import snmpMIBCompliances and snmpMIBGroups 56 from SNMPv2-MIB and define the snmpV3Compliance and snmpV3Group 57 under those existing Registration points. Since we link SNMPv3 58 MP with RFC1902-1908 anyways, this actually seems better to me. 59 . Someone needs to check elements of procedures. 60 . acknowledgements needs expansion 61 . snmpUnknownPduHandlers needs to be included in elements of procedure 62 . should we have one complete snmpV3AllCompliance that includes the 63 snmpCompliance from RFC1907? see MIB below. 64 Or we could keep two and have snmpV2andV3Compliance 65 . must we return the original Request PDU, so the application can 66 determine the request that led to an errorIndication? Conceptually 67 the SNMP engine needs to also cache the outgoing requests when it 68 caches info about a outgoing Request message. Should we describe 69 what processResponsePDU() returns in that circumstance. 70 . do we want to define snmpCommunityGroup here or under coexistence? 71 . should version-selection and application multiplexing elements of 72 procedure be described in MP document or Architecture document? 73 This is especially problematic considering snmpInPkts and 74 snmpInBadVersions counters. 76 Case/Harrington/Wijnen Expires December 1997 [Page 2] 77 0.1. Change Log 79 [version 3.4] 80 . engine, not Message Processing, interacts with network 81 . editorial changes 82 . registration is per PDU type 83 . fields in MsgFlags modified and discussed 84 . Changes as to address comments by dbh 85 . Changes to get Primitives inline with latest list 86 . ran MIB through SMICng 87 . updated picture in Overview 88 . update primitives to match editors' discussions 89 . updates addresses to international format 90 . removed editors' notes as appropriate 91 . converted editors' notes into Issues as appropriate 92 . modified text as per editors' discussions 93 . posted to snmpv3 mailing list 94 [version 3.3] 95 . spelling changes 96 . elements of procedure expanded 97 . changes snmpMPCxxxx to snmpV3xxxx in MIB 98 [version 3.2] 99 . updated change log 100 [version 3.1] 101 . changes as a result of 2nd interim meeting 102 . adopt to new abstract service interface primitives 103 . use new agreed upon names for things 104 . add a new overview of Message Processing Subsystem 105 . Remove MP Model selection descriptions 106 . Remove Multiplexing layer descriptions 107 . Rewrite all the elements of procedure 108 . Redo the SNMPv3-MIB 109 . Removed security threats section. 110 . Did a quick spell check on AIX 111 . Message Processing and Control changed to Message Processing 112 . change orangelets to applications 113 . stats counters should be in the module where they make sense 114 . statistics counters moved between documents on a case-by-case 115 basic, according to where they make the most sense 116 . modified to match consitent terminology 117 . improved pictures 118 . added elements of procedure 119 . changed snmpv3Message to Message 120 . modified naming of msgFlags 121 . securityParameters size limitation removed 122 . removed limits on lengths of contextEngineID and contextName 123 . new names for the application types 124 . more bullets to make it easier to read 125 . primitives have consistent format with expanded comments 126 . glossary (not filled in) removed 127 [version 3.0] 129 Case/Harrington/Wijnen Expires December 1997 [Page 3] 130 . published as draft-ietf-snmpv3-mpc-model-01.txt 131 [version 2.1] 132 . ?? not sure if there were any changes 133 [version 2.0] 134 . changes as a result of 1st interim meeting 135 . some new wording in introduction 136 . rewording in overview with a drawing 137 . added reportFlag to msgFlags 138 . describe overall MPC model: MPC Selection mechanism 139 . describe overall MPC model: MPC Multiplexing Layer 140 . describe v3MPC model. 141 . added the abstract interface definitions for interacting 142 with SNMPv3 USEC Model 143 . added the abstract interface definitions for interacting 144 with applications 145 . added MIB definitions for error Counters (statistics) 146 . removed references to LPM and Access Control 147 [version 1.2] 148 . add text regarding security threats 149 . add text regarding access control 150 . remove text regarding agent installation of views 151 . removed Naming-Scope 152 . removed discussion of MPC determining to which application a 153 message/request should be forwarded. 154 . added Issues section 155 . added sending a notification for an application 156 . spell-check, renumber, paginate 157 [version 1.1] 158 . separated architecture from Message Processing and Control 159 Model for SNMPv3 160 . clarified snmpV3Message definition 161 . rewrote introduction and overviews 162 . wrote transport mappings 163 . documented snmpV3Message format 164 . changed Quality of Service (QoS) to Level of Security (LoS) 165 . changed end-user to security entity 166 . Tried to clarify MMS of engine versus MMS of message. 167 . change security entity to securityIdentity 168 [version 1.0] 169 . Initial document, with SNMPng architecture and MPCv3 merged. 171 Case/Harrington/Wijnen Expires December 1997 [Page 4] 172 1. Introduction 174 The Architecture for describing Internet Management Frameworks 175 [SNMP-ARCH] is composed of multiple subsystems: 176 1) a Message Processing Subsystem, 177 2) a Security Subsystem, 178 3) an Access Control Subsystem, 179 Applications make use of the services of these subsystems. 181 It is important to understand the SNMP architecture and its 182 terminology to understand where the version-specific Message 183 Processing Model described in this document fits into the architecture 184 and interacts with other subsystems within the architecture. The 185 reader is expected to have read and understood the description of the 186 SNMP architecture, as defined in [SNMP-ARCH]. 188 The Message Processing Subsystem of an SNMP engine interacts with the 189 SNMP engine, interacts with the Security Subsystem and interacts with 190 applications. It uses data elements defined by the SNMPv3 Message 191 Processing Model, within the constraints of the architecture, and 192 interacts with other models within the constraints of the architecture. 194 A Message Processing Model has the responsibility for coordinating the 195 sending and receiving of SNMP messages via the SNMP engine, and for 196 coordinating the interaction with other subsystems to acquire the 197 desired services for the processing of an SNMP message. 199 It is the purpose of this document to define the specific SNMPv3 200 Message Processing Model. 202 Other (future) documents can add specific models for Message Processing 203 of other SNMP versions (like a v1MP and/or a v2cMP) which then fit 204 into the overall SNMP architecture. 206 Case/Harrington/Wijnen Expires December 1997 [Page 5] 207 2. Overview 209 The following illustration depicts the Message Processing in relation 210 to SNMP applications, the Security Subsystem and Transport Mappings. 212 +--------------------------------------------------------------------+ 213 | SNMP Entity | 214 | | 215 | +----------------------------------------------------------------+ | 216 | | Applications | | 217 | | +------------+ +--------------+ | | 218 | | | Command | | Notification | | | 219 | | | Generator | | Originator | +-----------+ +-------------+ | | 220 | | +------------+ +--------------+ | Proxy | | Other | | | 221 | | +------------+ +--------------+ | Forwarder | | Application | | | 222 | | | Command | | Notification | +-----------+ +-------------+ | | 223 | | | Responder | | Receiver | | | 224 | | +------------+ +--------------+ | | 225 | +----------------------------------------------------------------+ | 226 | ^ ^ ^ ^ | 227 | | | | | | 228 | | | | | | 229 | v v v v | 230 | +----------------------------------------------------------------+ | 231 | | Message | Message Processing Abstract Service Interface | | | 232 | | Processing +-----------------------------------------------+ | | 233 | | Subsystem ^ ^ ^ ^ | | 234 | | | | | | | | 235 | +--------------+ | | | | | | 236 | +------------+ | | | | | | | 237 | | Security | | | | | | | | 238 | | Subsystem | | | | | | | | 239 | | | | v v v v | | 240 | |+----------+| | +------+ +---------+ +--------+ +-----------+ | | 241 | ||User-based||<->| v3MP | | v2cMP * | | v1MP * |..| otherMP * | | | 242 | ||Security || | +------+ +---------+ +--------+ +-----------+ | | 243 | ||Model || | ^ ^ ^ ^ | | 244 | |+----------+| | | | | | | | 245 | | | +----|---------|-----------|------------|---------+ | 246 | +------------+ | | | | | 247 | v v v v | 248 | +----------------------------------------------------------+ | 249 | | Message Processing Model selection (incoming only) | | 250 | +----------------------------------------------------------+ | 251 | ^ | 252 | | | 253 | v | 254 | +-----------------------------------------------------------+ | 255 | | TRANSPORT MAPPING (for example RFC1906) | | 256 +--------------------------------------------------------------------+ 258 Case/Harrington/Wijnen Expires December 1997 [Page 6] 259 2.1. Message Processing Subsystem 261 The SNMP Message Processing Subsystem is part of an SNMP engine within 262 an SNMP entity. It can possibly handle multiple SNMP Message formats 263 (like the SNMPv1 [RFC1157], SNMPv2c [RFC1901] and SNMPv3 message 264 formats). The Message Processing Model selection mechanism receives 265 and sends messages from/to the network. For incoming messages, the 266 SNMP engine determines the specific message format of an incoming SNMP 267 message and then selects the corresponding version-specific Message 268 Processing module to further process the SNMP message. For outgoing 269 messages, an application specifies which SNMP message format must be 270 used and based on that the SNMP engine selects the corresponding 271 version-specific Message Processing module, within the Message 272 Processing Subsystem, to generate and send the message. 273 The details of how the SNMP engine selects the proper version-specific 274 Message Processing module are implementation dependent. 276 This document defines the SNMP version3 Message Processing (v3MP) 277 Model and the corresponding SNMPv3 message format. 279 The SNMP engine and the Message Processing Subsystem, while sending 280 and receiving SNMP messages, collect statistics about SNMP messages 281 and the behavior of the SNMP engine. These statistics are maintained 282 in managed objects to make them accessible to remote SNMP entities. 283 For example, the snmpInPkts counter [RFC1907] counts all incoming SNMP 284 packets regardless of the message format. The details on how this 285 is done in a system that supports multiple message formats is outside 286 the scope of this document. 288 This document defines the v3MP managed objects, and the MIB module 289 which contains them. This document also describes how these managed 290 objects might be used to provide useful network management. 292 The v3MP Model is designed to guarantee certain behaviors and to meet 293 a particular set of requirements. These goals are met by controlling 294 the processing of messages, sometimes by defining a fixed behavior 295 that must be adhered to by a conforming implementation of this model, 296 sometimes by defining options which can be specified by the user to 297 cause processing to meet optional requirements. 299 This document describes how the internal interactions are coordinated 300 and constrained by the v3MP Model. 302 2.2. Message Processing External Interfaces 304 The SNMPv3 Message Processing Model is a specification of a model of 305 Message Processing within the Message Processing Subsystem, which 306 interacts with other subsystems, requesting services from, and 307 performing services for, those other subsystems. 309 Case/Harrington/Wijnen Expires December 1997 [Page 7] 310 2.2.1. Message Processing Interface to Security Subsystem 312 An SNMPv3 Message Processing module interacts with one or more SNMP 313 Security Models to ensure that the proper security measures 314 (authentication, timeliness checking, en/decryption) are applied to 315 the SNMP messages being sent and received. It uses the abstract 316 service interface to the Security Model, as defined by the SNMP 317 architecture, to request services from such a security module. 319 2.2.2. Message Processing Abstract Service Interface 321 When an application wants to send an SNMP PDU, it does so according to 322 the abstract service interface of the Message Processing Subsystem, 323 as defined by the SNMP architecture [SNMP-ARCH]. 325 2.2.2.1. Sending an SNMP Request or Notification 327 The Message Processing Subsystem provides the following primitive for 328 an application to send an SNMP Request or Notification to another SNMP 329 entity: 331 sendPdu( 332 transportDomain -- transport domain to be used 333 transportAddress -- destination network address 334 messageProcessingModel -- typically, SNMP version 335 securityModel -- Security Model to use 336 securityName -- on behalf of this principal 337 LoS -- Level of Security requested 338 contextEngineID -- data from/at this entity 339 contextName -- data from/in this context 340 PDU -- SNMP Protocol Data Unit 341 expectResponse -- TRUE or FALSE 342 ) 344 Case/Harrington/Wijnen Expires December 1997 [Page 8] 345 2.2.2.2. Registering Responsibility for Handling SNMP PDUs 347 An application may want to take responsibility for handling a 348 specific set of SNMP operations, for a specific contextEngineID. 349 Applications register/unregister responsibility for a specific 350 contextEngineID, for specific pduTypes, with the Application 351 Multiplexor according to these primitives: 353 statusInformation = -- success or errorIndication 354 registerContextEngineID( 355 contextEngineID -- take responsibility for this one 356 pduType -- the pduType(s) to be registered 357 ) 359 unregisterContextEngineID( 360 contextEngineID -- give up responsibility for this one 361 pduType -- the pduType(s) to be unregistered 362 ) 364 2.2.2.3. Processing an incoming SNMP Request or Notification 366 Once an incoming message has passed the version-specific Message 367 Processing (v3MP) and is ready for processing by an application, 368 then the message is passed to the proper application. The 369 Application Multiplexor determines the PDU type and contextEngineID 370 for the scopedPDU, then determines which application has registered 371 to handle that PDU type and contextEngineID. 373 The Application Multiplexor uses the following primitive 374 to pass an incoming SNMP Response PDU to an application: 376 processPdu( -- process Request/Notification PDU 377 contextEngineID -- data from/at this SNMP entity 378 contextName -- data from/in this context 379 PDU -- SNMP Protocol Data Unit 380 maxSizeResponseScopedPDU -- maximum size of the Response PDU 381 securityModel -- Security Model in use 382 securityName -- on behalf of this principal 383 LoS -- Level of Security 384 stateReference -- reference to state information 385 ) -- needed when sending a response 387 2.2.2.4. Sending an SNMP Response 389 The Message Processing Subsystem provides the following primitive for 390 an application to return an SNMP Response PDU to a processed SNMP 391 Request or Notification: 393 returnResponsePdu( 394 contextEngineID -- data from/at this SNMP entity 395 contextName -- data from/in this context 397 Case/Harrington/Wijnen Expires December 1997 [Page 9] 398 PDU -- SNMP Protocol Data Unit 399 maxSizeResponseScopedPDU -- maximum size of the Response PDU 400 securityModel -- same as on incoming request 401 securityName -- same as on incoming request 402 LoS -- same as on incoming request 403 stateReference -- reference to state information 404 -- as presented with the request 405 statusInformation -- success or errorIndication 406 ) -- error counter OID/value if error 408 2.2.2.5. Processing an incoming SNMP Response 410 The Message Processing Subsystem provides the following primitive to 411 pass an incoming SNMP Response PDU to an application: 413 processResponsePdu( -- process Response PDU 414 contextEngineID -- data from/at this SNMP entity 415 contextName -- data from/in this context 416 PDU -- SNMP Protocol Data Unit 417 LoS -- Level of Security 418 statusInformation -- success or errorIndication 419 ) 421 3. The SNMPv3 Message Format 423 This is the format of an SNMP message for the SNMPv3 Message 424 Processing Model. 426 DEFINITIONS ::= BEGIN 428 Message ::= SEQUENCE { 429 -- administrative parameters (globalData) 430 version INTEGER { snmpv3 (3) }, 431 msgID INTEGER (0..2147483647), 432 mms INTEGER (484..2147483647), 434 msgFlags OCTET STRING (SIZE(1)), 435 -- .... ...1 authFlag 436 -- .... ..1. privFlag 437 -- .... .1.. reportableFlag 438 -- .... 1... reportFlag 439 -- 440 -- Please observe: 441 -- .... ..00 is OK, means noAuthNoPriv 442 -- .... ..01 is OK, means authNoPriv 443 -- .... ..10 reserved, must NOT be used. 444 -- .... ..11 is OK, means authPriv 446 securityModel INTEGER (0..2147483647), 448 -- security model-specific parameters 449 -- format defined by Security Model 450 securityParameters OCTET STRING 452 -- local-processing model-specific data 453 data scopedPduData 454 } 456 scopedPduData ::= CHOICE { 457 plaintext scopedPDU, 458 encryptedPDU OCTET STRING -- encrypted value 459 } 461 scopedPDU ::= SEQUENCE { 462 contextEngineID OCTET STRING 463 contextName OCTET STRING 464 data 465 ANY -- e.g. PDUs as defined in RFC1905 466 } 467 END 468 3.1. version 470 The version field is set to snmpv3(3) and identifies the message as 471 an SNMP version 3 Message. 473 3.2. msgID 475 The msgID is used between two SNMP entities to coordinate request 476 messages and responses, and by the v3MP to coordinate the processing 477 of the message by different subsystem models within the architecture. 479 Note that the request-id in the PDU is used by SNMP applications 480 to identify the request; the msgID is used by the engine to identify 481 the message which carries a request. The engine may need to identify 482 the message even if the decryption of the request (and request-id) 483 fails. No assumption should be made that the value of the msgID and 484 the value of the request-id are equivalent. 486 3.3. mms 488 The maximum message size supported by the sender of the message. 489 That is the maximum message size that the sender can accept when 490 another SNMP engine sends an SNMP message (be it a response or 491 any other message) to the sender of this message. 493 When an SNMP message is being generated, the mms is provided by the 494 SNMP engine which generates the message. At the receiving SNMP engine 495 the mms is used to determine how big the Response to a Request message 496 can be made. 498 3.4. msgFlags 500 The msgFlags field contains flags to control the processing of the 501 message. 503 a) reportableFlag 505 If the reportableFlag is set, then Report PDUs are allowed to be 506 returned to the sender under those conditions which cause the 507 generation of Report PDUs. If the reportableFlag is zero, then a 508 Report PDU must not be sent. The reportableFlag should always be 509 zero when the message is a Report PDU, a Response PDU, or an 510 SNMPv2-trap PDU. 512 b) reportFlag 514 ReportPDUs are engine-to-engine communications and are processed 515 directly by the Message Processing model, and are not passed to 516 applications for processing, unlike all other PDU types. The 517 reportFlag is set for a Report PDU so the Message Processing Model 518 can easily recognize a Report PDU. 520 The authFlag and privFlag in the msgFlags are used to indicate the 521 Level of Security (LoS) that has been applied to the message before 522 sending it on the wire. The same Level of Security should be applied 523 when the message is received and when the contents of the message is 524 being processed. There are 3 Levels of Security, namely noAuthNoPriv, 525 which is lower than authNoPriv, which is in turn lower than authPriv. 526 See the SNMP architecture document [SNMP-ARCH] for details about the 527 Level of Security. 529 a) authFlag 531 If the authFlag is set, then the securityModel in use, must identify 532 the securityName on whose behalf an SNMP message is being processed 533 or generated and must authenticate such identification. In 534 addition , the contents of the message must be authenticated to 535 ensure that: 536 - the message was not modified in transit 537 - the message was not replayed 538 - the message was not redirected 540 If the authFlag is not set, then the securityModel in use must 541 identify the securityName on whose behalf a request is being 542 processed or generated, but it does not need to authenticate such 543 identification. Also there is no need to authenticate the message 544 in this case. 546 b) privFlag 548 If the privFlag is set, then the securityModel in use, must also 549 protect the scopedPDU in an SNMP message from disclosure, i.e. must 550 encrypt/decrypt the scopedPDU. If the privFlag is zero, then the 551 securityModel in use does not need to protect the data from 552 disclosure. 554 It is an explicit requirement of the SNMP architecture that if 555 privacy is selected, then authentication is also required. That 556 means that if the privFlag is set, then the authFlag should also 557 be set. 559 The combination of the authFlag and the privFlag comprises a Level of 560 Security (LoS) as follows: 562 authFlag zero and privFlag one -> invalid combination 563 authFlag zero and privFlag zero -> LoS is noAuthNoPriv 564 authFlag one and privFlag zero -> LoS is authNoPriv 565 authFlag one and privFlag one -> LoS is authPriv 567 3.5. securityModel 569 The v3MP supports the concurrent existence of multiple security models 570 to provide security services for SNMPv3 messages. The securityModel 571 identifies which security model should be used to provide security 572 processing for the message. The mapping to the appropriate 573 implementation within an SNMP engine is done in an implementation 574 dependent manner. 576 3.6. securityParameters 578 The securityParameters filed is used for communication between the 579 Security Model modules in the sending and receiving SNMP engines. 580 This data is used exclusively by the security model, and the contents 581 and format of the data is defined by the Security Model. 582 This OCTET STRING is not interpreted by the v3MP, but is passed to the 583 local implementation of the Security Model indicated by the 584 securityModel field in the message. 586 3.7. scopedPduData 588 The scopedPduData represents either the plain text scopedPDU if the 589 privFlag in the msgFlags is zero, or it represents an encryptedPDU 590 which must be decrypted by the securityModel in use to produce a 591 plaintext scopedPDU. 593 3.8. scopedPDU 595 The scopedPDU contains information to identify an administratively 596 unique context and a PDU. The object identifiers in the PDU refer to 597 managed objects which are (expected to be) accessible within the 598 specified context. 600 3.8.1. contextEngineID 602 The contextEngineID in the SNMPv3 message, uniquely identifies, within 603 an administrative domain, an SNMP entity that may realize an instance 604 of a context with a particular contextName. 606 For incoming messages, the cpontextID is used to determine to which 607 application the scopedPDU should be sent for processing. 609 For outgoing messages, the v3MP just sets the contextEngineID as 610 provided by the application that requests for a message to be sent. 612 3.8.2. contextName 614 This is a locally unique name for a context, within the SNMP entity 615 specified by the contextEngineID, which may realize the managed 616 objects referenced within the PDU. An application uses the 617 contextName during processing. 619 The v3MP, for outgoing messages, just set the contextName as provided 620 by the application that requests for a message to be sent. 622 3.8.3. data 624 The data contains the PDU. The PDU contains the PDU type that is also 625 used by the v3MP to determine the type of incoming SNMP message. 626 The v3MP specifies that the PDU must be one of those specified in 627 [RFC1905]. 629 4. Elements of Procedure 631 This section describes the procedures followed by an SNMP engine when 632 processing SNMP messages according to the SNMPv3 Message Processing 633 Model. 635 4.1. Receiving an SNMP Message from the Network 637 This section describes the procedure followed by an SNMP engine 638 whenever it receives an SNMP message. Please note that some steps 639 might be done in the SNMP engine itself, specifically if the 640 implementations supports multiple Message Processing Models. Yet 641 the complete procedure is described here, so that for a single-version 642 implementation, the complete elements of procedure are in one place. 644 Please note, that in order to not make the procedures too complicated, 645 we do not always explicitly say when state information needs to be 646 released. The general rule is, that if state information is available 647 when a message gets discarded for further processing, that at that 648 time the state information must also be released. 650 1) The snmpInPkts counter [RFC1907] is incremented. That is if 651 such has not been done yet by a possible Message Processing 652 Model selection process in the SNMP engine. 654 2) If the received message is not the serialization (according to 655 the conventions of [RFC1906]) of a Message value, then the 656 snmpInASNParseErrs counter [RFC1907] is incremented, and the 657 message is discarded without further processing. 659 3) The values for the various message components are extracted 660 from the message. 662 4) If the value of the version component has a value other than 3 663 then the message is either processed according to some other 664 version-specific Message Processing Model, or the 665 snmpInBadVersions counter [RFC1907] is incremented (that is if 666 not yet done by a possible Message Processing Model selection 667 process in the SNMP engine), and the message is discarded without 668 further processing. 670 5) If the value of the securityModel component does not match a 671 supported securityModel, then the snmpUnknownSecurityModels 672 counter is incremented, a Report PDU is generated and the 673 message is discarded without further processing. 675 6) The Level of Security (LoS) is determined from the msgFlags 676 component as follows: 677 a) if neither the authFlag nor the privFlag is set, then the LoS 678 is set to noAuthNoPriv. 680 Otherwise, 682 b) If the authFlag is set and the privFlag is zero, then the LoS 683 is set to authNoPriv. 685 Otherwise, 687 c) If the authFlag is set and the privFlag is set, then the LoS 688 is set to authPriv. 690 Otherwise, 692 d) The snmpInvalidMsgFlags counter is incremented, a Report PDU 693 is generated and the message is discarded without further 694 processing. 696 7) The security module implementing the Security Model as specified 697 by the securityModel component is called for authentication and 698 privacy services. This is done according to the abstract service 699 primitive: 701 processMsg( 702 messageProcessingModel -- typically, SNMP version 703 msgID -- of the received message 704 mms -- of the sending SNMP entity 705 msgFlags -- for the received message 706 securityParameters -- for the received message 707 securityModel -- for the received message 708 LoS -- Level of Security 709 wholeMsg -- as received on the wire 710 wholeMsgLength -- length as received on the wire 711 ) 713 The security module returns the results according to the abstract 714 service interface primitive: 716 returnProcessedMsg( 717 securityName -- identification of the principal 718 scopedPDU, -- message (plaintext) payload 719 maxSizeResponseScopedPDU -- maximum size of a Response PDU 720 securityStateReference -- reference to security state 721 -- information, needed for response 722 statusInformation -- errorIndication or success 723 ) -- error counter OID/value if error 725 If an errorIndication is returned by the security module, then 726 a Report PDU is generated with the returned errorCounter in the 727 varBindList, and the message is discarded without further 728 processing. 730 8) If the reportFlag in the msgFlags component is set, then the 731 scopedPDU is parsed. 733 a) If the PDU is not a Report PDU, then the message is discarded 734 without further processing. This also means that any possible 735 security state information is discarded. 737 Otherwise, 739 b) The errorCounter is inspected to determine the cause for the 740 Report PDU. The value of the msgID component is used to 741 determine from the list of outstanding SNMP messages, which 742 application is to be posted with an errorIndication. If no 743 such outstanding SNMP message is found, then the message is 744 discarded without further processing. This also means that 745 any possible security state information is discarded. 747 Otherwise, 749 c) The application is informed according to the abstract service 750 primitive: 752 processResponsePdu( -- process Response PDU 753 contextEngineID -- data from/at this SNMP entity 754 contextName -- data from/in this context 755 PDU -- SNMP Protocol Data Unit 756 LoS -- Level of Security 757 statusInformation -- success or errorIndication 758 ) 760 Any cached information about the message, generated by this SNMP 761 engine, with the same msgID as the value of the msgID component 762 is discarded. This includes any possible security state 763 information. Processing of the message is complete as far as 764 the Message Processing module is concerned. 766 9) The scopedPDU is parsed to extract the contextEngineID, the 767 contextName and the PDU. If any parse error occurs, then the 768 snmpInASNParseErrs counter [RFC1907] is incremented, a report PDU 769 is generated, and the message is discarded without further 770 processing. This also means that any possible security state 771 information is discarded. 773 10) The message type is determined (how is an implementation issue) 774 to be either a Response message or a Request or Notification 775 message. 777 a) If this is a Response message, then the value of the msgID 778 component is used to determine from the list of outstanding 779 SNMP messages, which application is to process the Response PDU. 781 1) If no such outstanding SNMP message is found, then the 782 message is discarded without further processing. This also 783 means that any possible security state information is 784 discarded. 786 Otherwise, 788 2) The Response PDU is passed to the application according to 789 the abstract service primitive: 791 processResponsePdu( -- process Response PDU 792 contextEngineID -- data from/at this SNMP entity 793 contextName -- data from/in this context 794 PDU -- SNMP Protocol Data Unit 795 LoS -- Level of Security 796 statusInformation -- success or errorIndication 797 ) 799 Any cached information about the message, generated by this 800 SNMP engine, with the same msgID as the value of the msgID 801 component is discarded. This includes any possible security 802 state information. Processing of the message is complete as 803 far as the Message Processing module is concerned. 805 Otherwise, 807 b) If this is a Request message or a Notification message, then 808 it is determined which application should process the message. 809 This is based on the PDU type and the list of applications and 810 their registered contextEngineIDs. 812 1) If no such application can be found because none registered 813 for the contextEngineID, then the snmpUnknownContextEngineIDs 814 counter is incremented, a Report PDU is generated, and the 815 message is discarded without further processing. This also 816 means that any possible security state information is 817 discarded. 819 Otherwise, 821 2) If no such application can be found for other reasons, 822 then the snmpUnknownApplications counter is incremented, 823 a Report PDU is generated, and the message is discarded 824 without further processing. This also means that any 825 possible security state information is discarded. 827 Otherwise, 829 3) Information about the message is cached and a stateReference 830 is created (implementation specific). Information to be 831 cached includes: 833 value version component, 834 value msgID component, 835 value of LoS, 836 value of msgFlags component, 837 value of mms component, 838 value of securityModel component, 839 value of maxSizeResponseScopedPDU, 840 securityStateReference 842 11) The SNMP PDU is passed to the selected application according to 843 the abstract service interface primitive: 845 processPdu( -- process Request/Notification PDU 846 contextEngineID -- data from/at this SNMP entity 847 contextName -- data from/in this context 848 PDU -- SNMP Protocol Data Unit 849 maxSizeResponseScopedPDU -- maximum size of the Response PDU 850 securityModel -- Security Model in use 851 securityName -- on behalf of this principal 852 LoS -- Level of Security 853 stateReference -- reference to state information 854 ) -- needed when sending a response 856 Processing of the message is complete. The application processes 857 the PDU and when done will return a Response PDU using the 858 abstract service interface primitive: 860 returnResponsePdu( 861 contextEngineID -- data from/at this SNMP entity 862 contextName -- data from/in this context 863 PDU -- SNMP Protocol Data Unit 864 maxSizeResponseScopedPDU -- maximum size of the Response PDU 865 securityModel -- same as on incoming request 866 securityName -- same as on incoming request 867 LoS -- same as on incoming request 868 stateReference -- reference to state information 869 -- as presented with the request 870 statusInformation -- success or errorIndication 871 ) -- error counter OID/value if error 873 The v3MP procedures for this returned Response PDU are described 874 in section 4.2. 876 4.2. Sending an SNMP Message to the Network 878 This section describes the procedure followed by an SNMP engine 879 whenever it must send an SNMP message. There are three ways that can 880 cause a message to be sent: 882 - An application wants an SNMP PDU to be sent to another (remote) 883 application. The application can request this according to the 884 abstract service primitive: 886 sendPdu( 887 transportDomain -- transport domain to be used 888 transportAddress -- destination network address 889 messageProcessingModel -- typically, SNMP version 890 securityModel -- Security Model to use 891 securityName -- on behalf of this principal 892 LoS -- Level of Security requested 893 contextEngineID -- data from/at this entity 894 contextName -- data from/in this context 895 PDU -- SNMP Protocol Data Unit 896 expectResponse -- TRUE or FALSE 897 ) 899 - An application wants a response to be sent back to the originator 900 of an SNMP Request. This means that this is the resulting 901 response of step 11) of section 4.1. 903 - A Report PDU needs to be send as the result of a v3MP internal 904 detection of a problem, or as the result of a security module or 905 an application returning statusInformation which contains an 906 errorIndication and the OID and value of an (incremented) error 907 counter. 909 The following elements of procedures are followed to generate the 910 SNMP message according to the SNMPv3 message format. 912 1) a) If the request to send a message is caused by the sendPdu 913 primitive, then: 915 1) If the messageProcessingModel has a value other than 3, then 916 the request is either processed according to some other 917 version-specific Message Processing Model, or an error 918 (implementation specific) is returned to the calling 919 application. 921 Otherwise, 923 2) The parameters are verified to be valid and supported by the 924 SNMPv3 Message Processing module. If not, then an error 925 (implementation specific) is returned to the calling 926 application. 928 Otherwise, 930 3) All parameters are valid; use these values in the process: 931 - expectResponse switch as passed by application. 932 - a unique msgID is generated. It is best to use 933 unpredictable numbers for the msgID. 934 - msgFlags are set as follows: 935 - if LoS specifies noAuthNoPriv, then authFlag and 936 privFlag are both set to zero. 937 - if LoS specifies authNoPriv, then authFlag is set 938 to one and privFlag is set to zero. 939 - If LoS specifies authPriv, then authFlag is set to 940 one and privFlag is set to one. 941 - If expectResponse is TRUE, then the reportableFlag is 942 set to one otherwise it is set to zero. 943 - All other msgFlags bits are set to zero. 944 - the transportDomain and transportAddress as passed by the 945 application. 947 Otherwise, 949 b) If the request to send a message is caused by the 950 returnResponsePdu primitive, then: 952 1) The parameters are verified to be valid and are in accordance 953 with the cached state information pointed to by the 954 stateReference parameter. If not, then an (implementation 955 specific) error is returned to the calling application. 957 Otherwise: 959 2) If the statusInformation indicates an error that should 960 cause a Report PDU, then a Report PDU is constructed with 961 a varBindList that contains the OID and value of the 962 increment error counter that was returned; continue with 963 step 1.c. 965 Otherwise, 967 3) If the statusInformation indicates noError then this is a 968 Response PDU and all parameters are valid; then use these 969 values in the process: 970 - expectResponse switch is FALSE. 971 - msgID as is obtained via stateReference 972 - msgFlags are set as follows: 973 - if LoS specifies noAuthNoPriv, then authFlag and 974 privFlag are both set to zero. 975 - if LoS specifies authNoPriv, then authFlag is set 976 to one and privFlag is set to zero. 977 - If LoS specifies authPriv, then authFlag is set to 978 one and privFlag is set to one. 979 - All other msgFlags bits are set to zero. 980 - the transportDomain and transportAddress as saved in the 981 state information. 983 c) If the request to send a message is caused by a Report PDU, then 984 the internal v3MP process passes the proper parameters that are 985 needed in the following steps: 986 - expectResponse switch is FALSE. 987 - msgID as in the received message or from the state 988 information 989 - msgFlags are set as follows: 990 - If the Report PDU is cause by a notInTimeWindow error 991 then the authFlag is set to one, otherwise it is set 992 to zero. 993 - The reportFlag is set to one. 994 - all other msgFlags bits are set to zero. 995 - the transportDomain and transportAddress as in the 996 received message or as saved in the state information. 998 2) The version component of the message is set to snmpv3 (3). 1000 3) The mms is set to an implementation defined value within the range 1001 allowed by the definition of mms in section 3. 1003 4) The msgFlags are set as specified in step 1. 1005 5) The securityModel is set to the securityModel as specified or as 1006 obtained from the state information. 1008 6) An SNMP message is to be generated by the security module. The 1009 securityModel is used to determine which Security Model to use. 1011 a) If the expectResponse switch is TRUE, then an SNMP Response 1012 message is to be generated. The security module is called 1013 according to the abstract service interface primitive: 1015 generateResponseMsg( 1016 messageProcessingModel -- typically, SNMP version 1017 msgID -- for the outgoing message 1018 mms -- of the sending SNMP entity 1019 msgFlags -- for the outgoing message 1020 securityParameters -- filled in by Security Module 1021 securityModel -- for the outgoing message 1022 scopedPDU -- message (plaintext) payload 1023 securityStateReference -- reference to security state 1024 -- information, as received in 1025 ) -- processPdu primitive 1027 Otherwise, 1029 b) If the expectResponse switch is FALSE, then an SNMP Response 1030 message is to be generated. The security module is called 1031 according to the abstract service interface primitive: 1033 generateRequestMsg( 1034 messageProcessingModel -- typically, SNMP version 1035 msgID -- for the outgoing message 1036 mms -- of the sending SNMP entity 1037 msgFlags -- for the outgoing message 1038 securityParameters -- filled in by Security Module 1039 securityModel -- for the outgoing message 1040 securityName -- on behalf of this principal 1041 LoS -- Level of Security requested 1042 snmpEngineID -- authoritative SNMP entity 1043 scopedPDU -- message (plaintext) payload 1044 ) 1046 7) Upon completion of the security processing, the security module 1047 returns a completed message according to the abstract service 1048 interface primitive: 1050 returnGeneratedMsg( 1051 wholeMsg -- complete generated message 1052 wholeMsgLength -- length of the generated message 1053 statusInformation -- errorIndication or success 1054 ) 1056 a) If the statusInformation returns an errorIndication, then an 1057 errorIndication is returned to the calling application or 1058 v3MP internal function. 1060 Otherwise, 1062 b) The generated message is sent over the transport specified by 1063 the transportDomain to the address specified by the 1064 transportAddress. 1066 Processing is complete as far as the Message Processing module 1067 is concerned. 1069 4.3. Application Registration for Handling PDU types 1071 Applications that want to process certain PDUs must register with the 1072 Message Processing Subsystem and specify which contextEngineID and 1073 which PDU types they want to take responsibility for. 1075 The following procedures are followed for this registration process. 1077 1) An application registers according to the abstract interface 1078 primitive: 1080 statusInformation = -- success or errorIndication 1081 registerContextEngineID( 1082 contextEngineID -- take responsibility for this one 1083 pduType -- the pduType(s) to be registered 1084 ) 1086 2) The parameters are checked to be valid; if not an errorIndication 1087 (invalidParameter) is returned to the application. 1089 3) a) If the contextEngineID is equal to the snmpEngineID of the 1090 processing SNMP engine, then only one application can register 1091 for each pduType. 1093 1) If another application already registered, then an 1094 errorIndication (alreadyRegistered) is returned to the 1095 application. 1097 Otherwise, 1099 2) The registration is saved so that SNMP messages with a 1100 payload that matches the registered contextEngineID and 1101 pduType(s) can be dispatched to this application. 1103 b) If the contextEngineID is not equal to the snmpEngineID of the 1104 processing SNMP engine, then the registration is saved so that 1105 SNMP messages with a payload that matches the registered 1106 contextEngineID and pduType(s) can be dispatched to this 1107 application. 1109 4.3. Application Unregistration for Handling Payloads (PDUs) 1111 Applications that no longer want to process certain PDUs must 1112 unregister with the Message Processing Subsystem and specify which 1113 contextEngineID and which PDU types they no longer want to take 1114 responsibility for. 1116 The following procedures are followed for this unregistration process. 1118 1) An application unregisters according to the abstract interface 1119 primitive: 1121 unregisterContextEngineID( 1122 contextEngineID -- give up responsibility for this one 1123 pduType -- the pduType(s) to be unregistered 1124 ) 1126 2) The parameters are checked to be valid; if not the request is 1127 ignored. 1129 3) a) If the contextEngineID and pduType combination have indeed 1130 been registered, then the registration is deleted. 1132 b) If nu such registration exists, then the request is ignored. 1134 5. Definitions 1136 5.1. Definitions for the SNMPv3 Message Processing Model 1138 SNMPv3-MIB DEFINITIONS ::= BEGIN 1140 IMPORTS 1141 MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF 1142 MODULE-IDENTITY, OBJECT-TYPE, 1143 snmpModules, Counter32 FROM SNMPv2-SMI; 1145 snmpV3MIB MODULE-IDENTITY 1146 LAST-UPDATED "9707110000Z" -- 11 July 1997, midnight 1147 ORGANIZATION "SNMPv3 Working Group" 1148 CONTACT-INFO "WG-email: snmpv3@tis.com 1149 Subscribe: majordomo@tis.com 1150 In message body: subscribe snmpv3 1152 Chair: Russ Mundy 1153 Trusted Information Systems 1154 postal: 3060 Washington Rd 1155 Glenwood MD 21738 1156 USA 1157 email: mundy@tis.com 1158 phone: +1-301-854-6889 1160 Co-editor: Dr. Jeffrey Case 1161 SNMP Research, Inc. 1162 postal: 3001 Kimberlain Heights Rd 1163 Knoxville, TN 37920-9716 1164 USA 1165 email: case@snmp.com 1166 phone: +1-615-573-1434 1168 Co-editor Dave Harrington 1169 Cabletron Systems, Inc 1170 postal: Post Office Box 5005 1171 MailStop: Durham 1172 35 Industrial Way 1173 Rochester NH 03867-5005 1174 USA 1175 email: dbh@cabletron.com 1176 phone: +1- 603-337-7357 1178 Co-editor: Bert Wijnen 1179 IBM T. J. Watson Research 1180 postal: Schagen 33 1181 3461 GL Linschoten 1182 Netherlands 1183 email: wijnen@vnet.ibm.com 1184 phone: +31-348-432-794 1186 " 1187 DESCRIPTION "The MIB for the SNMPv3 Message Processing Model" 1188 ::= { snmpModules 8 } -- check if assignment is OK 1190 -- Administrative assignments **************************************** 1192 snmpV3Admin OBJECT IDENTIFIER ::= { snmpV3MIB 1 } 1193 snmpV3MIBObjects OBJECT IDENTIFIER ::= { snmpV3MIB 2 } 1194 snmpV3MIBConformance OBJECT IDENTIFIER ::= { snmpV3MIB 3 } 1196 -- Statistics for SNMPv3 Message Processing Model ******************** 1198 snmpV3Stats OBJECT IDENTIFIER ::= { snmpV3MIBObjects 1 } 1200 snmpUnknownSecurityModels OBJECT-TYPE 1201 SYNTAX Counter32 1202 MAX-ACCESS read-only 1203 STATUS current 1204 DESCRIPTION "The total number of packets received by the SNMP 1205 engine which were dropped because they referenced a 1206 securityModel that was not known to or supported by 1207 the SNMP engine, e.g. was not registered by any 1208 application. 1209 " 1210 ::= { snmpV3Stats 1 } 1212 snmpInvalidMsgFlags OBJECT-TYPE 1213 SYNTAX Counter32 1214 MAX-ACCESS read-only 1215 STATUS current 1216 DESCRIPTION "The total number of packets received by the SNMP 1217 engine which were dropped because the msgFlags 1218 component of the message specified invalid flags. 1219 " 1220 ::= { snmpV3Stats 2 } 1222 snmpUnknownContextEngineIDs OBJECT-TYPE 1223 SYNTAX Counter32 1224 MAX-ACCESS read-only 1225 STATUS current 1226 DESCRIPTION "The total number of packets received by the SNMP 1227 engine which were dropped because they referenced a 1228 contextEngineID that was not known to the SNMP engine 1229 e.g. was not registered by any application. 1230 " 1231 ::= { snmpV3Stats 3 } 1233 snmpUnknownApplications OBJECT-TYPE 1234 SYNTAX Counter32 1235 MAX-ACCESS read-only 1236 STATUS current 1237 DESCRIPTION "The total number of packets received by the SNMP 1238 engine which were dropped because they could not be 1239 passed to an application for undefined reasons. 1240 " 1241 ::= { snmpV3Stats 4 } 1243 snmpUnknownPduHandlers OBJECT-TYPE 1244 SYNTAX Counter32 1245 MAX-ACCESS read-only 1246 STATUS current 1247 DESCRIPTION "The total number of packets received by the SNMP 1248 engine which were dropped because they referenced a 1249 contextEngineID that was known, but no application 1250 has registered for the received pduType (yet). 1251 " 1252 ::= { snmpV3Stats 5 } 1254 -- Conformance information ******************************************* 1256 snmpV3MIBCompliances OBJECT IDENTIFIER ::= { snmpV3MIBConformance 1 } 1257 snmpV3MIBGroups OBJECT IDENTIFIER ::= { snmpV3MIBConformance 2 } 1259 -- Compliance statements 1261 snmpV3Compliance MODULE-COMPLIANCE 1262 STATUS current 1263 DESCRIPTION "The compliance statement for SNMP entities which 1264 implement the SNMPv3-MIB. 1265 " 1267 MODULE -- this module 1268 MANDATORY-GROUPS { snmpV3Group } 1270 ::= { snmpV3MIBCompliances 1 } 1272 snmpV3AllCompliance MODULE-COMPLIANCE 1273 STATUS current 1274 DESCRIPTION "The compliance statement for SNMP entities which 1275 implement the SNMPv2-MIB and the SNMPv3-MIB. 1276 " 1278 MODULE -- this module 1279 MANDATORY-GROUPS { 1280 -- must import following before we can reference them 1281 -- snmpGroup, snmpSetGroup, systemGroup, 1282 -- snmpBasicNotificationsGroup, 1283 snmpV3Group 1284 } 1286 ::= { snmpV3MIBCompliances 2 } 1288 snmpV2cAndV3Compliance MODULE-COMPLIANCE 1289 STATUS current 1290 DESCRIPTION "The compliance statement for SNMP entities which 1291 implement the SNMPv2-MIB and the SNMPv3-MIB. 1292 " 1294 MODULE -- this module 1295 MANDATORY-GROUPS { 1296 -- must import following before we can reference them 1297 -- snmpGroup, snmpSetGroup, systemGroup, 1298 -- snmpBasicNotificationsGroup, 1299 snmpV3Group 1300 } 1302 -- GROUP snmpCommunityGroup 1303 -- DESCRIPTION "This group is mandatory for SNMP entities that 1304 -- support Community-based authentication. 1305 -- " 1307 ::= { snmpV3MIBCompliances 3 } 1309 snmpV3Group OBJECT-GROUP 1310 OBJECTS { 1311 snmpUnknownSecurityModels, 1312 snmpUnknownContextEngineIDs, 1313 snmpInvalidMsgFlags, 1314 snmpUnknownApplications, 1315 snmpUnknownPduHandlers 1316 } 1317 STATUS current 1318 DESCRIPTION "A collection of objects providing for remote 1319 monitoring of an implementation of the SNMPv3 1320 Message Processing Model. 1321 " 1322 ::= { snmpV3MIBGroups 1 } 1324 END 1325 6. Security Consideration 1327 The SNMPv3 Message Processing Model coordinates the processing of 1328 messages to provide a level of security for network management 1329 messages and to direct the SNMP Message payload to the proper SNMP 1330 application(s). 1332 The level of security actually provided is primarily determined by 1333 the specific Security Model implementation(s) and the specific 1334 SNMP application implementation(s) incorporated into this framework. 1335 Applications have access to data which is not secured. Applications 1336 should take reasonable steps to protect the data from disclosure, and 1337 when they send data across the network, they should obey the LoS and 1338 call upon an Access Control Model services to apply access control. 1340 7. References 1342 [RFC1901] The SNMPv2 Working Group, Case, J., McCloghrie, K., 1343 Rose, M., and S., Waldbusser, "Introduction to 1344 Community-based SNMPv2", RFC 1901, January 1996. 1346 [RFC1902] The SNMPv2 Working Group, Case, J., McCloghrie, K., 1347 Rose, M., and S., Waldbusser, "Structure of Management 1348 Information for Version 2 of the Simple Network Management 1349 Protocol (SNMPv2)", RFC 1905, January 1996. 1351 [RFC1905] The SNMPv2 Working Group, Case, J., McCloghrie, K., 1352 Rose, M., and S., Waldbusser, "Protocol Operations for 1353 Version 2 of the Simple Network Management Protocol (SNMPv2)", 1354 RFC 1905, January 1996. 1356 [RFC1906] The SNMPv2 Working Group, Case, J., McCloghrie, K., 1357 Rose, M., and S. Waldbusser, "Transport Mappings for 1358 Version 2 of the Simple Network Management Protocol (SNMPv2)", 1359 RFC 1906, January 1996. 1361 [RFC1907] The SNMPv2 Working Group, Case, J., McCloghrie, K., 1362 Rose, M., and S. Waldbusser, "Management Information Base for 1363 Version 2 of the Simple Network Management Protocol (SNMPv2)", 1364 RFC 1907 January 1996. 1366 [RFC1908] The SNMPv2 Working Group, Case, J., McCloghrie, K., 1367 Rose, M., and S. Waldbusser, "Coexistence between Version 1 1368 and Version 2 of the Internet-standard Network Management 1369 Framework", RFC 1908, January 1996. 1371 [SNMP-ARCH] The SNMPv3 Working Group, Harrington, D., Wijnen, B., 1372 "An Architecture for describing Internet Management Frameworks", 1373 draft-ietf-snmpv3-next-gen-arch-03.txt, July 1997. 1375 [SNMPv3-ACM] The SNMPv3 Working Group, Wijnen, B., Presuhn, R., 1376 McCloghrie, K., "View-based Access Control Model for the 1377 Simple Network Management Protocol (SNMP)", 1378 draft-ietf-snmpv3-acm-01.txt, July 1997. 1380 [SNMPv3-USM] The SNMPv3 Working Group, Blumenthal, U., Wijnen, B. 1381 "User-Based Security Model for version 3 of the Simple Network 1382 Management Protocol (SNMPv3)", 1383 draft-ietf-snmpv3-usm-00.txt, July 1997. 1385 8. Editor's Addresses 1387 Co-editor: Dr. Jeffrey Case 1388 SNMP Research, Inc. 1389 postal: 3001 Kimberlain Heights Rd 1390 Knoxville, TN 37920-9716 1391 USA 1392 email: case@snmp.com 1393 phone: +1-615-573-1434 1395 Co-editor Dave Harrington 1396 Cabletron Systems, Inc 1397 postal: Post Office Box 5005 1398 MailStop: Durham 1399 35 Industrial Way 1400 Rochester NH 03867-5005 1401 USA 1402 email: dbh@cabletron.com 1403 phone: +1-603-337-7357 1405 Co-editor: Bert Wijnen 1406 IBM T. J. Watson Research 1407 postal: Schagen 33 1408 3461 GL Linschoten 1409 Netherlands 1410 email: wijnen@vnet.ibm.com 1411 phone: +31-348-432-794 1413 9. Acknowledgements 1415 This document builds on the work of the SNMP Security and 1416 Administrative Framework Evolution team, comprised of 1418 David Harrington (Cabletron Systems Inc.) 1419 Jeff Johnson (Cisco) 1420 David Levi (SNMP Research Inc.) 1421 John Linn (Openvision) 1422 Russ Mundy (Trusted Information Systems) chair 1423 Shawn Routhier (Epilogue) 1424 Glenn Waters (Nortel) 1425 Bert Wijnen (IBM T.J. Watson Research) 1427 Table of Contents 1429 0. Issues 2 1430 0.1. Change Log 3 1431 1. Introduction 5 1432 2. Overview 6 1433 2.1. Message Processing Subsystem 7 1434 2.2. Message Processing External Interfaces 7 1435 2.2.1. Message Processing Interface to Security Subsystem 8 1436 2.2.2. Message Processing Abstract Service Interface 8 1437 2.2.2.1. Sending an SNMP Request or Notification 8 1438 2.2.2.2. Registering Responsibility for Handling SNMP PDUs 9 1439 2.2.2.3. Processing an incoming SNMP Request or Notification 9 1440 2.2.2.4. Sending an SNMP Response 9 1441 2.2.2.5. Processing an incoming SNMP Response 10 1442 3. The SNMPv3 Message Format 11 1443 3.1. version 12 1444 3.2. msgID 12 1445 3.3. mms 12 1446 3.4. msgFlags 12 1447 3.5. securityModel 14 1448 3.6. securityParameters 14 1449 3.7. scopedPduData 14 1450 3.8. scopedPDU 15 1451 3.8.1. contextEngineID 15 1452 3.8.2. contextName 15 1453 3.8.3. data 15 1454 4. Elements of Procedure 16 1455 4.1. Receiving an SNMP Message from the Network 16 1456 10) The message type is determined (how is an implementation issue) 19 1457 11) The SNMP PDU is passed to the selected application according to 20 1458 4.2. Sending an SNMP Message to the Network 21 1459 4.3. Application Registration for Handling PDU types 24 1460 4.3. Application Unregistration for Handling Payloads (PDUs) 25 1461 5. Definitions 27 1462 5.1. Definitions for the SNMPv3 Message Processing Model 27 1463 6. Security Consideration 31 1464 7. References 32 1465 8. Editor's Addresses 33 1466 9. Acknowledgements 34