idnits 2.17.1 draft-ietf-snmpv3-mpc-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** 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. == No 'Intended status' indicated for this document; assuming Proposed Standard 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 2 instances of too long lines in the document, the longest one being 3 characters in excess of 72. ** 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: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (10 February 1999) is 9201 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 231, but not defined == Unused Reference: 'RFC1902' is defined on line 1786, but no explicit reference was found in the text == Unused Reference: 'RFC1908' is defined on line 1806, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 1811, but no explicit reference was found in the text == Unused Reference: 'RFC2028' is defined on line 1814, but no explicit reference was found in the text == Unused Reference: 'SNMP-USM' is defined on line 1821, but no explicit reference was found in the text == Unused Reference: 'SNMP-ACM' is defined on line 1825, but no explicit reference was found in the text == Unused Reference: 'SNMP-APPL' is defined on line 1829, but no explicit reference was found in the text == Unused Reference: 'SNMP-INTRO' is defined on line 1832, but no explicit reference was found in the text ** Downref: Normative reference to an Historic RFC: RFC 1901 ** Obsolete normative reference: RFC 1902 (Obsoleted by RFC 2578) ** 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) ** Obsolete normative reference: RFC 2028 (Obsoleted by RFC 9281) -- Possible downref: Non-RFC (?) normative reference: ref. 'SNMP-ARCH' -- Possible downref: Non-RFC (?) normative reference: ref. 'SNMP-USM' -- Possible downref: Non-RFC (?) normative reference: ref. 'SNMP-ACM' -- Possible downref: Non-RFC (?) normative reference: ref. 'SNMP-APPL' -- Possible downref: Non-RFC (?) normative reference: ref. 'SNMP-INTRO' Summary: 14 errors (**), 0 flaws (~~), 11 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT J. Case 2 Will Obsolete: 2272 SNMP Research, Inc. 3 D. Harrington 4 Cabletron Systems, Inc. 5 R. Presuhn 6 BMC Software, Inc. 7 B. Wijnen 8 IBM T. J. Watson Research 9 10 February 1999 11 Message Processing and Dispatching for the 12 Simple Network Management Protocol (SNMP) 13 15 Status of this Memo 17 This document is an Internet-Draft and is in full conformance with 18 all provisions of Section 10 of RFC2026. Internet-Drafts are working 19 documents of the Internet Engineering Task Force (IETF), its areas, 20 and its working groups. Note that other groups may also distribute 21 working documents as Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html 34 Copyright Notice 36 Copyright (C) The Internet Society (1999). All Rights Reserved. 38 Abstract 40 This document describes the Message Processing and Dispatching for 41 SNMP messages within the SNMP architecture [SNMP-ARCH]. It defines 42 the procedures for dispatching potentially multiple versions of SNMP 43 messages to the proper SNMP Message Processing Models, and for 44 dispatching PDUs to SNMP applications. This document also describes 45 one Message Processing Model - the SNMPv3 Message Processing Model. 47 Table of Contents 49 1. Introduction ................................................ 3 50 2. Overview .................................................... 3 51 2.1. The Dispatcher. .......................................... 5 52 2.2. Message Processing Subsystem .............................. 5 53 3. Elements of Message Processing and Dispatching .............. 5 54 3.1. messageProcessingModel .................................... 6 55 3.2. pduVersion ................................................ 6 56 3.3. pduType ................................................... 7 57 3.4. sendPduHandle ............................................. 7 58 4. Dispatcher Elements of Procedure ............................ 8 59 4.1. Sending an SNMP Message to the Network .................... 8 60 4.1.1. Sending a Request or Notification ....................... 8 61 4.1.2. Sending a Response to the Network ....................... 9 62 4.2. Receiving an SNMP Message from the Network ................ 11 63 4.2.1. Message Dispatching of received SNMP Messages ........... 11 64 4.2.2. PDU Dispatching for Incoming Messages ................... 12 65 4.2.2.1. Incoming Requests and Notifications ................... 12 66 4.2.2.2. Incoming Responses .................................... 14 67 4.3. Application Registration for Handling PDU types ........... 15 68 4.4. Application Unregistration for Handling PDU Types ......... 16 69 5. Definitions ................................................. 16 70 5.1. Definitions for SNMP Message Processing and Dispatching ... 16 71 6. The SNMPv3 Message Format ................................... 20 72 6.1. msgVersion ................................................ 21 73 6.2. msgID ..................................................... 21 74 6.3. msgMaxSize ................................................ 21 75 6.4. msgFlags .................................................. 22 76 6.5. msgSecurityModel .......................................... 24 77 6.6. msgSecurityParameters ..................................... 24 78 6.7. scopedPduData ............................................. 24 79 6.8. scopedPDU ................................................. 24 80 6.8.1. contextEngineID ......................................... 25 81 6.8.2. contextName ............................................. 25 82 6.8.3. data .................................................... 25 83 7. Elements of Procedure for v3MP .............................. 25 84 7.1. Prepare an Outgoing SNMP Message .......................... 26 85 7.2. Prepare Data Elements from an Incoming SNMP Message ....... 31 86 8. Intellectual Property ....................................... 37 87 9. Acknowledgements ............................................ 37 88 10. Security Considerations .................................... 39 89 11. References ................................................. 40 90 12. Editors' Addresses ......................................... 41 91 A. Issues ...................................................... 43 92 A.1. Open Issues ............................................... 43 93 A.2. Change Log ................................................ 43 94 B. Full Copyright Statement .................................... 44 96 1. Introduction 98 The Architecture for describing Internet Management Frameworks 99 [SNMP-ARCH] describes that an SNMP engine is composed of: 101 1) a Dispatcher 102 2) a Message Processing Subsystem, 103 3) a Security Subsystem, and 104 4) an Access Control Subsystem. 106 Applications make use of the services of these subsystems. 108 It is important to understand the SNMP architecture and its 109 terminology to understand where the Message Processing Subsystem and 110 Dispatcher described in this document fit into the architecture and 111 interact with other subsystems within the architecture. The reader 112 is expected to have read and understood the description of the SNMP 113 architecture, defined in [SNMP-ARCH]. 115 The Dispatcher in the SNMP engine sends and receives SNMP messages. 116 It also dispatches SNMP PDUs to SNMP applications. When an SNMP 117 message needs to be prepared or when data needs to be extracted from 118 an SNMP message, the Dispatcher delegates these tasks to a message 119 version-specific Message Processing Model within the Message 120 Processing Subsystem. 122 A Message Processing Model is responsible for processing a SNMP 123 version-specific message and for coordinating the interaction with 124 the Security Subsystem to ensure proper security is applied to the 125 SNMP message being handled. 127 Interactions between the Dispatcher, the Message Processing 128 Subsystem, and applications are modeled using abstract data elements 129 and abstract service interface primitives defined by the SNMP 130 architecture. 132 Similarly, interactions between the Message Processing Subsystem and 133 the Security Subsystem are modeled using abstract data elements and 134 abstract service interface primitives as defined by the SNMP 135 architecture. 137 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 138 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 139 document are to be interpreted as described in RFC 2119. 141 2. Overview 143 The following illustration depicts the Message Processing in relation 144 to SNMP applications, the Security Subsystem and Transport Mappings. 146 +-------------------------------------------------------------------+ 147 | SNMP Entity | 148 | | 149 | +---------------------------------------------------------------+ | 150 | | Applications | | 151 | | +-----------+ +--------------+ | | 152 | | | Command | | Notification | | | 153 | | | Generator | | Originator | +-----------+ +--------------+| | 154 | | +-----------+ +--------------+ | Proxy | | Other | | 155 | | +-----------+ +--------------+ | Forwarder | |Application(s)|| | 156 | | | Command | | Notification | +-----------+ +--------------+| | 157 | | | Responder | | Receiver | | | 158 | | +-----------+ +--------------+ | | 159 | +---------------------------------------------------------------+ | 160 | ^ ^ ^ ^ | 161 | | | | | | 162 | v v v v | 163 | +--------+-------+---------------+-----------+ | 164 | ^ | 165 | | +---------------------+ +-----------------+ | 166 | | | Message Processing | | Security | | 167 | Dispatcher v | Subsystem | | Subsystem | | 168 | +------------------+ | +------------+ | | | | 169 | | PDU Dispatcher | | +->| v1MP * |<--->| +-------------+ | | 170 | | | | | +------------+ | | | Other | | | 171 | | | | | +------------+ | | | Security | | | 172 | | | | +->| v2cMP * |<--->| | Model | | | 173 | | Message | | | +------------+ | | +-------------+ | | 174 | | Dispatcher <-------->+ | | | | 175 | | | | | +------------+ | | +-------------+ | | 176 | | | | +->| v3MP * |<--->| | User-based | | | 177 | | Transport | | | +------------+ | | | Security | | | 178 | | Mapping | | | +------------+ | | | Model | | | 179 | | (e.g RFC 1906) | | +->| otherMP * |<--->| +-------------+ | | 180 | +------------------+ | +------------+ | | | | 181 | ^ +---------------------+ +-----------------+ | 182 | | | 183 +----------|--------------------------------------------------------+ 184 v 185 +------------------+ 186 | Network | 187 +------------------+ 189 2.1. The Dispatcher. 191 The Dispatcher is a key piece of an SNMP engine. There is only one in 192 an SNMP engine, and its job is to dispatch tasks to the multiple 193 version-specific Message Processing Models, and to dispatch PDUs to 194 various applications. 196 For outgoing messages, an application provides a PDU to be sent, plus 197 the data needed to prepare and send the message, and the application 198 specifies which version-specific Message Processing Model will be 199 used to prepare the message with the desired security processing. 200 Once the message is prepared, the Dispatcher sends the message. 202 For incoming messages, the Dispatcher determines the SNMP version of 203 the incoming message and passes the message to the version-specific 204 Message Processing Model to extract the components of the message and 205 to coordinate the processing of security services for the message. 206 After version-specific processing, the PDU Dispatcher determines 207 which application, if any, should receive the PDU for processing and 208 forwards it accordingly. 210 The Dispatcher, while sending and receiving SNMP messages, collects 211 statistics about SNMP messages and the behavior of the SNMP engine in 212 managed objects to make them accessible to remote SNMP entities. 213 This document defines these managed objects, the MIB module which 214 contains them, and how these managed objects might be used to provide 215 useful management. 217 2.2. Message Processing Subsystem 219 The SNMP Message Processing Subsystem is the part of an SNMP engine 220 which interacts with the Dispatcher to handle the version-specific 221 SNMP messages. It contains one or more Message Processing Models. 223 This document describes one Message Processing Model, the SNMPv3 224 Message Processing Model, in Section 6. The SNMPv3 Message Processing 225 Model is defined in a separate section to show that multiple 226 (independent) Message Processing Models can exist at the same time 227 and that such Models can be described in different documents. The 228 SNMPv3 Message Processing Model can be replaced or supplemented with 229 other Message Processing Models in the future. Two Message Processing 230 Models which are expected to be developed in the future are the 231 SNMPv1 message format [RFC1157] and the SNMPv2c message format 232 [RFC1901]. Others may be developed as needed. 234 3. Elements of Message Processing and Dispatching 236 See [SNMP-ARCH] for the definitions of 237 contextEngineID 238 contextName 239 scopedPDU 240 maxSizeResponseScopedPDU 241 securityModel 242 securityName 243 securityLevel 244 messageProcessingModel 246 For incoming messages, a version-specific message processing module 247 provides these values to the Dispatcher. For outgoing messages, an 248 application provides these values to the Dispatcher. 250 For some version-specific processing, the values may be extracted 251 from received messages; for other versions, the values may be 252 determined by algorithm, or by an implementation-defined mechanism. 253 The mechanism by which the value is determined is irrelevant to the 254 Dispatcher. 256 The following additional or expanded definitions are for use within 257 the Dispatcher. 259 3.1. messageProcessingModel 261 The value of messageProcessingModel identifies a Message Processing 262 Model. A Message Processing Model describes the version-specific 263 procedures for extracting data from messages, generating messages, 264 calling upon a securityModel to apply its security services to 265 messages, for converting data from a version-specific message format 266 into a generic format usable by the Dispatcher, and for converting 267 data from Dispatcher format into a version-specific message format. 269 3.2. pduVersion 271 The value of pduVersion represents a specific version of protocol 272 operation and its associated PDU formats, such as SNMPv1 or SNMPv2 273 [RFC1905]. The values of pduVersion are specific to the version of 274 the PDU contained in a message, and the PDUs processed by 275 applications. The Dispatcher does not use the value of pduVersion 276 directly. 278 An application specifies the pduVersion when it requests the PDU 279 Dispatcher to send a PDU to another SNMP engine. The Dispatcher 280 passes the pduVersion to a Message Processing Model, so it knows how 281 to handle the PDU properly. 283 For incoming messages, pduVersion is provided to the Dispatcher by a 284 version-specific Message Processing module. The PDU Dispatcher passes 285 the pduVersion to the application so it knows how to handle the PDU 286 properly. For example, a command responder application needs to know 287 whether to use [RFC1905] elements of procedure and syntax instead of 288 those specified for SNMPv1. 290 3.3. pduType 292 A value of pduType represents a specific type of protocol operation. 293 The values of pduType are specific to the version of the PDU 294 contained in a message. 296 Applications register to support particular pduTypes for particular 297 contextEngineIDs. 299 For incoming messages, pduType is provided to the Dispatcher by a 300 version-specific Message Processing module. It is subsequently used 301 to dispatch the PDU to the application which registered for the 302 pduType for the contextEngineID of the associated scopedPDU. 304 3.4. sendPduHandle 306 This handle is generated for coordinating the processing of requests 307 and responses between the SNMP engine and an application. The handle 308 must be unique across all version-specific Message Processing Models, 309 and is of local significance only. 311 4. Dispatcher Elements of Procedure 313 This section describes the procedures followed by the Dispatcher when 314 generating and processing SNMP messages. 316 4.1. Sending an SNMP Message to the Network 318 This section describes the procedure followed by an SNMP engine 319 whenever it sends an SNMP message. 321 4.1.1. Sending a Request or Notification 323 The following procedures are followed by the Dispatcher when an 324 application wants to send an SNMP PDU to another (remote) 325 application, i.e., to initiate a communication by originating a 326 message, such as one containing a request or a trap. 328 1) The application requests this using the abstract service 329 primitive: 331 statusInformation = -- sendPduHandle if success 332 -- errorIndication if failure 333 sendPdu( 334 IN transportDomain -- transport domain to be used 335 IN transportAddress -- destination network address 336 IN messageProcessingModel -- typically, SNMP version 337 IN securityModel -- Security Model to use 338 IN securityName -- on behalf of this principal 339 IN securityLevel -- Level of Security requested 340 IN contextEngineID -- data from/at this entity 341 IN contextName -- data from/in this context 342 IN pduVersion -- the version of the PDU 343 IN PDU -- SNMP Protocol Data Unit 344 IN expectResponse -- TRUE or FALSE 345 ) 347 2) If the messageProcessingModel value does not represent a Message 348 Processing Model known to the Dispatcher, then an errorIndication 349 (implementation-dependent) is returned to the calling application. 350 No further processing is performed. 352 3) The Dispatcher generates a sendPduHandle to coordinate subsequent 353 processing. 355 4) The Message Dispatcher sends the request to the version-specific 356 Message Processing module identified by messageProcessingModel 357 using the abstract service primitive: 359 statusInformation = - success or error indication 360 prepareOutgoingMessage( 361 IN transportDomain -- as specified by application 362 IN transportAddress -- as specified by application 363 IN messageProcessingModel -- as specified by application 364 IN securityModel -- as specified by application 365 IN securityName -- as specified by application 366 IN securityLevel -- as specified by application 367 IN contextEngineID -- as specified by application 368 IN contextName -- as specified by application 369 IN pduVersion -- as specified by application 370 IN PDU -- as specified by application 371 IN expectResponse -- as specified by application 372 IN sendPduHandle -- as determined in step 3. 373 OUT destTransportDomain -- destination transport domain 374 OUT destTransportAddress -- destination transport address 375 OUT outgoingMessage -- the message to send 376 OUT outgoingMessageLength -- the message length 377 ) 379 5) If the statusInformation indicates an error, the errorIndication 380 is returned to the calling application. No further processing is 381 performed. 383 6) If the statusInformation indicates success, the sendPduHandle is 384 returned to the application, and the outgoingMessage is sent via 385 the transport specified by the transportDomain to the address 386 specified by the transportAddress. 388 Outgoing Message Processing is complete. 390 4.1.2. Sending a Response to the Network 392 The following procedure is followed when an application wants to 393 return a response back to the originator of an SNMP Request. 395 1) An application can request this using the abstract service 396 primitive: 398 result = 399 returnResponsePdu( 400 IN messageProcessingModel -- typically, SNMP version 401 IN securityModel -- Security Model in use 402 IN securityName -- on behalf of this principal 403 IN securityLevel -- same as on incoming request 404 IN contextEngineID -- data from/at this SNMP entity 405 IN contextName -- data from/in this context 406 IN pduVersion -- the version of the PDU 407 IN PDU -- SNMP Protocol Data Unit 408 IN maxSizeResponseScopedPDU -- maximum size of Response PDU 409 IN stateReference -- reference to state information 410 -- as presented with the request 411 IN statusInformation -- success or errorIndication 412 ) -- (error counter OID and value 413 -- when errorIndication) 415 2) The Message Dispatcher sends the request to the appropriate 416 Message Processing Model indicated by the received value of 417 messageProcessingModel using the abstract service primitive: 419 result = -- SUCCESS or errorIndication 420 prepareResponseMessage( 421 IN messageProcessingModel -- specified by application 422 IN securityModel -- specified by application 423 IN securityName -- specified by application 424 IN securityLevel -- specified by application 425 IN contextEngineID -- specified by application 426 IN contextName -- specified by application 427 IN pduVersion -- specified by application 428 IN PDU -- specified by application 429 IN maxSizeResponseScopedPDU -- specified by application 430 IN stateReference -- specified by application 431 IN statusInformation -- specified by application 432 OUT destTransportDomain -- destination transport domain 433 OUT destTransportAddress -- destination transport address 434 OUT outgoingMessage -- the message to send 435 OUT outgoingMessageLength -- the message length 436 ) 438 3) If the result is an errorIndication, the errorIndication is 439 returned to the calling application. No further processing is 440 performed. 442 4) If the result is success, the outgoingMessage is sent over the 443 transport specified by the transportDomain to the address 444 specified by the transportAddress. 446 Message Processing is complete. 448 4.2. Receiving an SNMP Message from the Network 450 This section describes the procedure followed by an SNMP engine 451 whenever it receives an SNMP message. 453 Please note, that for the sake of clarity and to prevent the text 454 from being even longer and more complicated, some details were 455 omitted from the steps below. In particular, The elements of 456 procedure do not always explicitly indicate when state information 457 needs to be released. The general rule is that if state information 458 is available when a message is to be "discarded without further 459 processing", then the state information must also be released at that 460 same time. 462 4.2.1. Message Dispatching of received SNMP Messages 464 1) The snmpInPkts counter [RFC1907] is incremented. 466 2) The version of the SNMP message is determined in an 467 implementation-dependent manner. If the packet cannot be 468 sufficiently parsed to determine the version of the SNMP message, 469 then the snmpInASNParseErrs [RFC1907] counter is incremented, and 470 the message is discarded without further processing. If the 471 version is not supported, then the snmpInBadVersions [RFC1907] 472 counter is incremented, and the message is discarded without 473 further processing. 475 3) The origin transportDomain and origin transportAddress are 476 determined. 478 4) The message is passed to the version-specific Message Processing 479 Model which returns the abstract data elements required by the 480 Dispatcher. This is performed using the abstract service 481 primitive: 483 result = -- SUCCESS or errorIndication 484 prepareDataElements( 485 IN transportDomain -- origin as determined in step 3. 486 IN transportAddress -- origin as determined in step 3. 487 IN wholeMsg -- as received from the network 488 IN wholeMsgLength -- as received from the network 489 OUT messageProcessingModel -- typically, SNMP version 490 OUT securityModel -- Security Model specified 491 OUT securityName -- on behalf of this principal 492 OUT securityLevel -- Level of Security specified 493 OUT contextEngineID -- data from/at this entity 494 OUT contextName -- data from/in this context 495 OUT pduVersion -- the version of the PDU 496 OUT PDU -- SNMP Protocol Data Unit 497 OUT pduType -- SNMP PDU type 498 OUT sendPduHandle -- handle for a matched request 499 OUT maxSizeResponseScopedPDU -- maximum size of Response PDU 500 OUT statusInformation -- success or errorIndication 501 -- (error counter OID and value 502 -- when errorIndication) 503 OUT stateReference -- reference to state information 504 -- to be used for a possible 505 ) -- Response 507 5) If the result is a FAILURE errorIndication, the message is 508 discarded without further processing. 510 6) At this point, the abstract data elements have been prepared and 511 processing continues as described in Section 4.2.2, PDU 512 Dispatching for Incoming Messages. 514 4.2.2. PDU Dispatching for Incoming Messages 516 The elements of procedure for the dispatching of PDUs depends on the 517 value of sendPduHandle. If the value of sendPduHandle is , 518 then this is a request or notification and the procedures specified 519 in Section 4.2.2.1 apply. If the value of snmpPduHandle is not 520 , then this is a response and the procedures specified in 521 Section 4.2.2.2 apply. 523 4.2.2.1. Incoming Requests and Notifications 525 The following procedures are followed for the dispatching of PDUs 526 when the value of sendPduHandle is , indicating this is a 527 request or notification. 529 1) The combination of contextEngineID and pduType is used to 530 determine which application has registered for this request or 531 notification. 533 2) If no application has registered for the combination, then 535 a) The snmpUnknownPDUHandlers counter is incremented. 537 b) A Response message is generated using the abstract service 538 primitive: 540 result = -- SUCCESS or FAILURE 541 prepareResponseMessage( 542 IN messageProcessingModel -- as provided by MP module 543 IN securityModel -- as provided by MP module 544 IN securityName -- as provided by MP module 545 IN securityLevel -- as provided by MP module 546 IN contextEngineID -- as provided by MP module 547 IN contextName -- as provided by MP module 548 IN pduVersion -- as provided by MP module 549 IN PDU -- as provided by MP module 550 IN maxSizeResponseScopedPDU -- as provided by MP module 551 IN stateReference -- as provided by MP module 552 IN statusInformation -- errorIndication plus 553 -- snmpUnknownPDUHandlers OID 554 -- value pair. 555 OUT destTransportDomain -- destination transportDomain 556 OUT destTransportAddress -- destination transportAddress 557 OUT outgoingMessage -- the message to send 558 OUT outgoingMessageLength -- its length 559 ) 561 c) If the result is SUCCESS, then the prepared message is sent to 562 the originator of the request as identified by the 563 transportDomain and transportAddress. 565 d) The incoming message is discarded without further processing. 566 Message Processing for this message is complete. 568 3) The PDU is dispatched to the application, using the abstract 569 service primitive: 571 processPdu( -- process Request/Notification 572 IN messageProcessingModel -- as provided by MP module 573 IN securityModel -- as provided by MP module 574 IN securityName -- as provided by MP module 575 IN securityLevel -- as provided by MP module 576 IN contextEngineID -- as provided by MP module 577 IN contextName -- as provided by MP module 578 IN pduVersion -- as provided by MP module 579 IN PDU -- as provided by MP module 580 IN maxSizeResponseScopedPDU -- as provided by MP module 581 IN stateReference -- as provided by MP module 582 -- needed when sending response 583 ) 585 Message processing for this message is complete. 587 4.2.2.2. Incoming Responses 589 The following procedures are followed for the dispatching of PDUs 590 when the value of sendPduHandle is not , indicating this is a 591 response. 593 1) The value of sendPduHandle is used to determine, in an 594 implementation-defined manner, which application is waiting for 595 a response associated with this sendPduHandle. 597 2) If no waiting application is found, the message is discarded 598 without further processing, and the stateReference is released. 599 The snmpUnknownPDUHandlers counter is incremented. Message 600 Processing is complete for this message. 602 3) Any cached information, including stateReference, about the 603 message is discarded. 605 4) The response is dispatched to the application using the 606 abstract service primitive: 608 processResponsePdu( -- process Response PDU 609 IN messageProcessingModel -- provided by the MP module 610 IN securityModel -- provided by the MP module 611 IN securityName -- provided by the MP module 612 IN securityLevel -- provided by the MP module 613 IN contextEngineID -- provided by the MP module 614 IN contextName -- provided by the MP module 615 IN pduVersion -- provided by the MP module 616 IN PDU -- provided by the MP module 617 IN statusInformation -- provided by the MP module 618 IN sendPduHandle -- provided by the MP module 619 ) 621 Message Processing is complete for this message. 623 4.3. Application Registration for Handling PDU types 625 Applications that want to process certain PDUs must register with the 626 PDU Dispatcher. Applications specify the combination of 627 contextEngineID and pduType(s) for which they want to take 628 responsibility 630 1) An application registers according to the abstract interface 631 primitive: 633 statusInformation = -- success or errorIndication 634 registerContextEngineID( 635 IN contextEngineID -- take responsibility for this one 636 IN pduType -- the pduType(s) to be registered 637 ) 639 Note: implementations may provide a means of requesting 640 registration for simultaneous multiple contextEngineID values, 641 e.g., all contextEngineID values, and may also provide means for 642 requesting simultaneous registration for multiple values of 643 pduType. 645 2) The parameters may be checked for validity; if they are not, then 646 an errorIndication (invalidParameter) is returned to the 647 application. 649 3) Each combination of contextEngineID and pduType can be registered 650 only once. If another application has already registered for the 651 specified combination, then an errorIndication (alreadyRegistered) 652 is returned to the application. 654 4) Otherwise, the registration is saved so that SNMP PDUs can be 655 dispatched to this application. 657 4.4. Application Unregistration for Handling PDU Types 659 Applications that no longer want to process certain PDUs must 660 unregister with the PDU Dispatcher. 662 1) An application unregisters using the abstract service primitive: 664 unregisterContextEngineID( 665 IN contextEngineID -- give up responsibility for this 666 IN pduType -- the pduType(s) to be unregistered 667 ) 668 Note: implementations may provide means for requesting 669 unregistration for simultaneous multiple contextEngineID values, 670 e.g., all contextEngineID values, and may also provide means for 671 requesting simultaneous unregistration for multiple values of 672 pduType. 674 2) If the contextEngineID and pduType combination has been 675 registered, then the registration is deleted. 677 If no such registration exists, then the request is ignored. 679 5. Definitions 681 5.1. Definitions for SNMP Message Processing and Dispatching 683 SNMP-MPD-MIB DEFINITIONS ::= BEGIN 685 IMPORTS 686 MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF 687 MODULE-IDENTITY, OBJECT-TYPE, 688 snmpModules, Counter32 FROM SNMPv2-SMI; 690 snmpMPDMIB MODULE-IDENTITY 691 LAST-UPDATED "9901190000Z" -- 19 January 1999 692 ORGANIZATION "SNMPv3 Working Group" 693 CONTACT-INFO "WG-EMail: snmpv3@tis.com 694 Subscribe: majordomo@tis.com 695 In message body: subscribe snmpv3 697 Chair: Russ Mundy 698 TIS Labs at Network Associates 699 postal: 3060 Washington Road 700 Glenwood, MD 21738 701 USA 702 EMail: mundy@tis.com 703 phone: +1 301-854-6889 704 Co-editor: Jeffrey Case 705 SNMP Research, Inc. 706 postal: 3001 Kimberlin Heights Road 707 Knoxville, TN 37920-9716 708 USA 709 EMail: case@snmp.com 710 phone: +1 423-573-1434 712 Co-editor Dave Harrington 713 Cabletron Systems, Inc. 714 postal: Post Office Box 5005 715 MailStop: Durham 716 35 Industrial Way 717 Rochester, NH 03867-5005 718 USA 719 EMail: dbh@ctron.com 720 phone: +1 603-337-7357 722 Co-editor: Randy Presuhn 723 BMC Software, Inc. 724 postal: 965 Stewart Drive 725 Sunnyvale, CA 94086 726 USA 727 EMail: randy_presuhn@bmc.com 728 phone: +1 408-616-3100 730 Co-editor: Bert Wijnen 731 IBM T. J. Watson Research 732 postal: Schagen 33 733 3461 GL Linschoten 734 Netherlands 735 EMail: wijnen@vnet.ibm.com 736 phone: +31 348-432-794 738 " 739 DESCRIPTION "The MIB for Message Processing and Dispatching" 740 REVISION "9901190000Z" -- 19 January 1999 741 DESCRIPTION "Corrected co-editors' address information." 742 REVISION "9709300000Z" -- 30 September 1997 743 DESCRIPTION "Original version, published as RFC 2272." 744 ::= { snmpModules 11 } 746 -- Administrative assignments *************************************** 748 snmpMPDAdmin OBJECT IDENTIFIER ::= { snmpMPDMIB 1 } 749 snmpMPDMIBObjects OBJECT IDENTIFIER ::= { snmpMPDMIB 2 } 750 snmpMPDMIBConformance OBJECT IDENTIFIER ::= { snmpMPDMIB 3 } 751 -- Statistics for SNMP Messages ************************************* 753 snmpMPDStats OBJECT IDENTIFIER ::= { snmpMPDMIBObjects 1 } 755 snmpUnknownSecurityModels OBJECT-TYPE 756 SYNTAX Counter32 757 MAX-ACCESS read-only 758 STATUS current 759 DESCRIPTION "The total number of packets received by the SNMP 760 engine which were dropped because they referenced a 761 securityModel that was not known to or supported by 762 the SNMP engine. 763 " 764 ::= { snmpMPDStats 1 } 766 snmpInvalidMsgs OBJECT-TYPE 767 SYNTAX Counter32 768 MAX-ACCESS read-only 769 STATUS current 770 DESCRIPTION "The total number of packets received by the SNMP 771 engine which were dropped because there were invalid 772 or inconsistent components in the SNMP message. 773 " 774 ::= { snmpMPDStats 2 } 776 snmpUnknownPDUHandlers OBJECT-TYPE 777 SYNTAX Counter32 778 MAX-ACCESS read-only 779 STATUS current 780 DESCRIPTION "The total number of packets received by the SNMP 781 engine which were dropped because the PDU contained 782 in the packet could not be passed to an application 783 responsible for handling the pduType, e.g. no SNMP 784 application had registered for the proper 785 combination of the contextEngineID and the pduType. 786 " 787 ::= { snmpMPDStats 3 } 789 -- Conformance information ****************************************** 791 snmpMPDMIBCompliances OBJECT IDENTIFIER ::= {snmpMPDMIBConformance 1} 792 snmpMPDMIBGroups OBJECT IDENTIFIER ::= {snmpMPDMIBConformance 2} 794 -- Compliance statements 796 snmpMPDCompliance MODULE-COMPLIANCE 797 STATUS current 798 DESCRIPTION "The compliance statement for SNMP entities which 799 implement the SNMP-MPD-MIB. 800 " 802 MODULE -- this module 803 MANDATORY-GROUPS { snmpMPDGroup } 805 ::= { snmpMPDMIBCompliances 1 } 807 snmpMPDGroup OBJECT-GROUP 808 OBJECTS { 809 snmpUnknownSecurityModels, 810 snmpInvalidMsgs, 811 snmpUnknownPDUHandlers 812 } 813 STATUS current 814 DESCRIPTION "A collection of objects providing for remote 815 monitoring of the SNMP Message Processing and 816 Dispatching process. 817 " 818 ::= { snmpMPDMIBGroups 1 } 820 END 822 6. The SNMPv3 Message Format 824 This section defines the SNMPv3 message format and the corresponding 825 SNMP version 3 Message Processing Model (v3MP). 826 SNMPv3MessageSyntax DEFINITIONS IMPLICIT TAGS ::= BEGIN 828 SNMPv3Message ::= SEQUENCE { 829 -- identify the layout of the SNMPv3Message 830 -- this element is in same position as in SNMPv1 831 -- and SNMPv2c, allowing recognition 832 -- the value 3 is used for snmpv3 833 msgVersion INTEGER ( 0 .. 2147483647 ), 834 -- administrative parameters 835 msgGlobalData HeaderData, 836 -- security model-specific parameters 837 -- format defined by Security Model 838 msgSecurityParameters OCTET STRING, 839 msgData ScopedPduData 840 } 842 HeaderData ::= SEQUENCE { 843 msgID INTEGER (0..2147483647), 844 msgMaxSize INTEGER (484..2147483647), 846 msgFlags OCTET STRING (SIZE(1)), 847 -- .... ...1 authFlag 848 -- .... ..1. privFlag 849 -- .... .1.. reportableFlag 850 -- Please observe: 851 -- .... ..00 is OK, means noAuthNoPriv 852 -- .... ..01 is OK, means authNoPriv 853 -- .... ..10 reserved, must NOT be used. 854 -- .... ..11 is OK, means authPriv 856 msgSecurityModel INTEGER (1..2147483647) 857 } 859 ScopedPduData ::= CHOICE { 860 plaintext ScopedPDU, 861 encryptedPDU OCTET STRING -- encrypted scopedPDU value 862 } 864 ScopedPDU ::= SEQUENCE { 865 contextEngineID OCTET STRING, 866 contextName OCTET STRING, 867 data ANY -- e.g., PDUs as defined in RFC 1905 868 } 869 END 871 6.1. msgVersion 873 The msgVersion field is set to snmpv3(3) and identifies the message 874 as an SNMP version 3 Message. 876 6.2. msgID 878 The msgID is used between two SNMP entities to coordinate request 879 messages and responses, and by the v3MP to coordinate the processing 880 of the message by different subsystem models within the architecture. 882 Values for msgID SHOULD be generated in a manner that avoids re-use 883 of any outstanding values. Doing so provides protection against some 884 replay attacks. One possible implementation strategy would be to use 885 the low-order bits of snmpEngineBoots [SNMP-ARCH] as the high-order 886 portion of the msgID value and a monotonically increasing integer for 887 the low-order portion of msgID. 889 Note that the request-id in a PDU may be used by SNMP applications to 890 identify the PDU; the msgID is used by the engine to identify the 891 message which carries a PDU. The engine needs to identify the message 892 even if decryption of the PDU (and request-id) fails. No assumption 893 should be made that the value of the msgID and the value of the 894 request-id are equivalent. 896 The value of the msgID field for a response takes the value of the 897 msgID field from the message to which it is a response. By use of 898 the msgID value, an engine can distinguish the (potentially multiple) 899 outstanding requests, and thereby correlate incoming responses with 900 outstanding requests. In cases where an unreliable datagram service 901 is used, the msgID also provides a simple means of identifying 902 messages duplicated by the network. If a request is retransmitted, a 903 new msgID value SHOULD be used for each retransmission. 905 6.3. msgMaxSize 907 The msgMaxSize field of the message conveys the maximum message size 908 supported by the sender of the message, i.e., the maximum message 909 size that the sender can accept when another SNMP engine sends an 910 SNMP message (be it a response or any other message) to the sender of 911 this message on the transport in use for this message. 913 When an SNMP message is being generated, the msgMaxSize is provided 914 by the SNMP engine which generates the message. At the receiving 915 SNMP engine, the msgMaxSize is used to determine the maximum message 916 size the sender can accommodate. 918 6.4. msgFlags 920 The msgFlags field of the message contains several bit fields which 921 control processing of the message. 923 The reportableFlag is a secondary aid in determining whether a Report 924 PDU must be sent. It is only used in cases where the PDU portion of 925 a message cannot be decoded, due to, for example, an incorrect 926 encryption key. If the PDU can be decoded, the PDU type forms the 927 basis for decisions on sending Report PDUs. 929 When the reportableFlag is used, if its value is one, a Report PDU 930 MUST be returned to the sender under those conditions which can cause 931 the generation of Report PDUs. Similarly, when the reportableFlag is 932 used and its value is zero, then a Report PDU MUST NOT be sent. The 933 reportableFlag MUST always be zero when the message contains a PDU 934 from the Unconfirmed Class, such as a Report PDU, a response-type PDU 935 (such as a Response PDU), or an unacknowledged notification-type PDU 936 (such as an SNMPv2-trap PDU). The reportableFlag MUST always be one 937 for a PDU from the Confirmed Class, include request-type PDUs (such 938 as a Get PDU) and an acknowledged notification-type PDUs (such as an 939 Inform PDU). 941 If the reportableFlag is set to one for a message containing a PDU 942 from the Unconfirmed Class, such as a Report PDU, a response-type PDU 943 (such as a Response PDU), or an unacknowledged notification-type PDU 944 (such as an SNMPv2-trap PDU), then the receiver of that message MUST 945 process it as though the reportableFlag had been set to zero. 947 If the reportableFlag is set to zero for a message containing a 948 request-type PDU (such as a Get PDU) or an acknowledged notification- 949 type PDU (such as an Inform PDU), then the receiver of that message 950 must process it as though the reportableFlag had been set to one. 952 Report PDUs are generated directly by the SNMPv3 Message Processing 953 Model, and support engine-to-engine communications, but may be passed 954 to applications for processing. 956 An SNMP engine that receives a reportPDU may use it to determine what 957 kind of problem was detected by the remote SNMP engine. It can do so 958 based on the error counter included as the first (and only) varBind 959 of the reportPDU. Based on the detected error, the SNMP engine may 960 try to send a corrected SNMP message. If that is not possible, it 961 may pass an indication of the error to the application on whose 962 behalf the failed SNMP request was issued. 964 The authFlag and privFlag portions of the msgFlags field are set by 965 the sender to indicate the securityLevel that was applied to the 966 message before it was sent on the wire. The receiver of the message 967 MUST apply the same securityLevel when the message is received and 968 the contents are being processed. 970 There are three securityLevels, namely noAuthNoPriv, which is less 971 than authNoPriv, which is in turn less than authPriv. See the SNMP 972 architecture document [SNMP-ARCH] for details about the 973 securityLevel. 975 a) authFlag 977 If the authFlag is set to one, then the securityModel used by the 978 SNMP engine which sent the message MUST identify the securityName 979 on whose behalf the SNMP message was generated and MUST provide, 980 in a securityModel-specific manner, sufficient data for the 981 receiver of the message to be able to authenticate that 982 identification. In general, this authentication will allow the 983 receiver to determine with reasonable certainty that the message 984 was: 986 - sent on behalf of the principal associated with the 987 securityName, 989 - was not redirected, 991 - was not modified in transit, and 993 - was not replayed. 995 If the authFlag is zero, then the securityModel used by the SNMP 996 engine which sent the message must identify the securityName on 997 whose behalf the SNMP message was generated but it does not need 998 to provide sufficient data for the receiver of the message to 999 authenticate the identification, as there is no need to 1000 authenticate the message in this case. 1002 b) privFlag 1004 If the privFlag is set, then the securityModel used by the SNMP 1005 engine which sent the message MUST also protect the scopedPDU in 1006 an SNMP message from disclosure, i.e., it MUST encrypt/decrypt the 1007 scopedPDU. If the privFlag is zero, then the securityModel in use 1008 does not need to protect the data from disclosure. 1010 It is an explicit requirement of the SNMP architecture that if 1011 privacy is selected, then authentication is also required. That 1012 means that if the privFlag is set, then the authFlag MUST also be 1013 set to one. 1015 The combination of the authFlag and the privFlag comprises a Level 1016 of Security as follows: 1017 authFlag zero, privFlag zero -> securityLevel is noAuthNoPriv 1018 authFlag zero, privFlag one -> invalid combination, see below 1019 authFlag one, privFlag zero -> securityLevel is authNoPriv 1020 authFlag one, privFlag one -> securityLevel is authPriv 1022 The elements of procedure (see below) describe the action to be taken 1023 when the invalid combination of authFlag equal to zero and privFlag 1024 equal to one is encountered. 1026 The remaining bits in msgFlags are reserved, and MUST be set to zero 1027 when sending a message and SHOULD be ignored when receiving a 1028 message. 1030 6.5. msgSecurityModel 1032 The v3MP supports the concurrent existence of multiple Security 1033 Models to provide security services for SNMPv3 messages. The 1034 msgSecurityModel field in an SNMPv3 Message identifies which Security 1035 Model was used by the sender to generate the message and therefore 1036 which securityModel must be used by the receiver to perform security 1037 processing for the message. The mapping to the appropriate 1038 securityModel implementation within an SNMP engine is accomplished in 1039 an implementation-dependent manner. 1041 6.6. msgSecurityParameters 1043 The msgSecurityParameters field of the SNMPv3 Message is used for 1044 communication between the Security Model modules in the sending and 1045 receiving SNMP engines. The data in the msgSecurityParameters field 1046 is used exclusively by the Security Model, and the contents and 1047 format of the data is defined by the Security Model. This OCTET 1048 STRING is not interpreted by the v3MP, but is passed to the local 1049 implementation of the Security Model indicated by the 1050 msgSecurityModel field in the message. 1052 6.7. scopedPduData 1054 The scopedPduData field represents either the plain text scopedPDU if 1055 the privFlag in the msgFlags is zero, or it represents an 1056 encryptedPDU (encoded as an OCTET STRING) which must be decrypted by 1057 the securityModel in use to produce a plaintext scopedPDU. 1059 6.8. scopedPDU 1061 The scopedPDU contains information to identify an administratively 1062 unique context and a PDU. The object identifiers in the PDU refer to 1063 managed objects which are (expected to be) accessible within the 1064 specified context. 1066 6.8.1. contextEngineID 1068 The contextEngineID in the SNMPv3 message, uniquely identifies, 1069 within an administrative domain, an SNMP entity that may realize an 1070 instance of a context with a particular contextName. 1072 For incoming messages, the contextEngineID is used in conjunction 1073 with pduType to determine to which application the scopedPDU will be 1074 sent for processing. 1076 For outgoing messages, the v3MP sets the contextEngineID to the value 1077 provided by the application in the request for a message to be sent. 1079 6.8.2. contextName 1081 The contextName field in an SNMPv3 message, in conjunction with the 1082 contextEngineID field, identifies the particular context associated 1083 with the management information contained in the PDU portion of the 1084 message. The contextName is unique within the SNMP entity specified 1085 by the contextEngineID, which may realize the managed objects 1086 referenced within the PDU. An application which originates a message 1087 provides the value for the contextName field and this value may be 1088 used during processing by an application at the receiving SNMP 1089 Engine. 1091 6.8.3. data 1093 The data field of the SNMPv3 Message contains the PDU. Among other 1094 things, the PDU contains the PDU type that is used by the v3MP to 1095 determine the type of the incoming SNMP message. The v3MP specifies 1096 that the PDU must be one of those specified in [RFC1905]. 1098 7. Elements of Procedure for v3MP 1100 This section describes the procedures followed by an SNMP engine when 1101 generating and processing SNMP messages according to the SNMPv3 1102 Message Processing Model. 1104 Please note, that for the sake of clarity and to prevent the text 1105 from being even longer and more complicated, some details were 1106 omitted from the steps below. 1108 a) Some steps specify that when some error conditions are 1109 encountered when processing a received message, a message 1110 containing a Report PDU is generated and the received message 1111 is discarded without further processing. However, a Report-PDU 1112 must not be generated unless the PDU causing generation of the 1113 Report PDU can be determine to be a member of the Confirmed 1114 Class, or the reportableFlag is set to one and the PDU class 1115 cannot be determined. 1117 b) The elements of procedure do not always explicitly indicate 1118 when state information needs to be released. The general rule 1119 is that if state information is available when a message is to 1120 be "discarded without further processing", then the state 1121 information should also be released at that same time. 1123 7.1. Prepare an Outgoing SNMP Message 1125 This section describes the procedure followed to prepare an SNMPv3 1126 message from the data elements passed by the Message Dispatcher. 1128 1) The Message Dispatcher may request that an SNMPv3 message 1129 containing a Read Class, Write Class, or Notification Class PDU be 1130 prepared for sending. 1132 a) It makes such a request according to the abstract service 1133 primitive: 1135 statusInformation = -- success or errorIndication 1136 prepareOutgoingMessage( 1137 IN transportDomain -- requested transport domain 1138 IN transportAddress -- requested destination address 1139 IN messageProcessingModel -- typically, SNMP version 1140 IN securityModel -- Security Model to use 1141 IN securityName -- on behalf of this principal 1142 IN securityLevel -- Level of Security requested 1143 IN contextEngineID -- data from/at this entity 1144 IN contextName -- data from/in this context 1145 IN pduVersion -- version of the PDU 1146 IN PDU -- SNMP Protocol Data Unit 1147 IN expectResponse -- TRUE or FALSE * 1148 IN sendPduHandle -- the handle for matching 1149 -- incoming responses 1150 OUT destTransportDomain -- destination transport domain 1151 OUT destTransportAddress -- destination transport address 1152 OUT outgoingMessage -- the message to send 1153 OUT outgoingMessageLength -- the length of the message 1154 ) 1156 * The SNMPv3 Message Processing Model does not use the values of 1157 expectResponse or pduVersion. 1159 b) A unique msgID is generated. The number used for msgID should 1160 not have been used recently, and must not be the same as was 1161 used for any outstanding request. 1163 2) The Message Dispatcher may request that an SNMPv3 message 1164 containing a Response Class or Internal Class PDU be prepared for 1165 sending. 1167 a) It makes such a request according to the abstract service 1168 primitive: 1170 result = -- SUCCESS or FAILURE 1171 prepareResponseMessage( 1172 IN messageProcessingModel -- typically, SNMP version 1173 IN securityModel -- same as on incoming request 1174 IN securityName -- same as on incoming request 1175 IN securityLevel -- same as on incoming request 1176 IN contextEngineID -- data from/at this SNMP entity 1177 IN contextName -- data from/in this context 1178 IN pduVersion -- version of the PDU 1179 IN PDU -- SNMP Protocol Data Unit 1180 IN maxSizeResponseScopedPDU -- maximum size sender can accept 1181 IN stateReference -- reference to state 1182 -- information presented with 1183 -- the request 1184 IN statusInformation -- success or errorIndication 1185 -- error counter OID and value 1186 -- when errorIndication 1187 OUT destTransportDomain -- destination transport domain 1188 OUT destTransportAddress -- destination transport address 1189 OUT outgoingMessage -- the message to send 1190 OUT outgoingMessageLength -- the length of the message 1191 ) 1193 b) The cached information for the original request is retrieved 1194 via the stateReference, including 1196 - msgID, 1197 - contextEngineID, 1198 - contextName, 1199 - securityModel, 1200 - securityName, 1201 - securityLevel, 1202 - securityStateReference, 1203 - reportableFlag, 1204 - transportDomain, and 1205 - transportAddress. 1207 The SNMPv3 Message Processing Model does not allow cached data 1208 to be overridden, except by error indications as detailed in 1209 (3) below. 1211 3) If statusInformation contains values for an OID/value combination 1212 (potentially also containing a securityLevel value, 1213 contextEngineID value, or contextName value), then 1215 a) If reportableFlag is zero, then the original message is 1216 discarded, and no further processing is done. A result of 1217 FAILURE is returned. SNMPv3 Message Processing is complete. 1219 b) If a PDU is provided, it is the PDU from the original request. 1220 If possible, extract the request-id. 1222 c) A Report PDU is prepared: 1224 1) the varBindList is set to contain the OID and value from the 1225 statusInformation 1227 2) error-status is set to 0 1229 3) error-index is set to 0. 1231 4) request-id is set to the value extracted in step b) 1232 Otherwise, request-id is set to 0 1234 d) The errorIndication in statusInformation may be accompanied by 1235 a securityLevel value, a contextEngineID value, or a 1236 contextName value. 1238 1) If statusInformation contains a value for securityLevel, 1239 then securityLevel is set to that value, otherwise it is set 1240 to noAuthNoPriv. 1242 2) If statusInformation contains a value for contextEngineID, 1243 then contextEngineID is set to that value, otherwise it is 1244 set to the value of this entity's snmpEngineID. 1246 3) If statusInformation contains a value for contextName, then 1247 contextName is set to that value, otherwise it is set to the 1248 default context of "" (zero-length string). 1250 e) PDU is set to refer to the new Report-PDU. The old PDU is 1251 discarded. 1253 f) Processing continues with step 6) below. 1255 4) If contextEngineID is not yet determined, then the contextEngineID 1256 is determined, in an implementation-dependent manner, possibly 1257 using the transportDomain and transportAddress. 1259 5) If the contextName is not yet determined, the contextName is set 1260 to the default context. 1262 6) A scopedPDU is prepared from the contextEngineID, contextName, and 1263 PDU. 1265 7) msgGlobalData is constructed as follows 1267 a) The msgVersion field is set to snmpv3(3). 1269 b) msgID is set as determined in step 1 or 2 above. 1271 c) msgMaxSize is set to an implementation-dependent value. 1273 d) msgFlags are set as follows: 1275 - If securityLevel specifies noAuthNoPriv, then authFlag and 1276 privFlag are both set to zero. 1278 - If securityLevel specifies authNoPriv, then authFlag is set 1279 to one and privFlag is set to zero. 1281 - If securityLevel specifies authPriv, then authFlag is set to 1282 one and privFlag is set to one. 1284 - If the PDU is from the Unconfirmed Class, then the 1285 reportableFlag is set to zero. 1287 - If the PDU is from the Confirmed Class then the 1288 reportableFlag is set to one. 1290 - All other msgFlags bits are set to zero. 1292 e) msgSecurityModel is set to the value of securityModel 1294 8) If the PDU is from the Response Class or the Internal Class, then 1295 a) The specified Security Model is called to generate the message 1296 according to the primitive: 1298 statusInformation = 1299 generateResponseMsg( 1300 IN messageProcessingModel -- SNMPv3 Message Processing 1301 -- Model 1302 IN globalData -- msgGlobalData from step 7 1303 IN maxMessageSize -- from msgMaxSize (step 7c) 1304 IN securityModel -- as determined in step 7e 1305 IN securityEngineID -- the value of snmpEngineID 1306 IN securityName -- on behalf of this principal 1307 IN securityLevel -- for the outgoing message 1308 IN scopedPDU -- as prepared in step 6) 1309 IN securityStateReference -- as determined in step 2 1310 OUT securityParameters -- filled in by Security Module 1311 OUT wholeMsg -- complete generated message 1312 OUT wholeMsgLength -- length of generated message 1313 ) 1315 If, upon return from the Security Model, the statusInformation 1316 includes an errorIndication, then any cached information about 1317 the outstanding request message is discarded, and an 1318 errorIndication is returned, so it can be returned to the 1319 calling application. SNMPv3 Message Processing is complete. 1321 b) A SUCCESS result is returned. SNMPv3 Message Processing is 1322 complete. 1324 9) If the PDU is from the Confirmed Class or the Notification Class, 1325 then 1327 a) If the PDU is from the Unconfirmed Class, then securityEngineID 1328 is set to the value of this entity's snmpEngineID. 1330 Otherwise, the snmpEngineID of the target entity is determined, 1331 in an implementation-dependent manner, possibly using 1332 transportDomain and transportAddress. The value of 1333 securityEngineID is set to the value of the target entity's 1334 snmpEngineID. 1336 b) The specified Security Model is called to generate the message 1337 according to the primitive: 1339 statusInformation = 1340 generateRequestMsg( 1341 IN messageProcessingModel -- SNMPv3 Message Processing Model 1342 IN globalData -- msgGlobalData, from step 7 1343 IN maxMessageSize -- from msgMaxSize in step 7 c) 1344 IN securityModel -- as provided by caller 1345 IN securityEngineID -- authoritative SNMP entity from 9 a) 1346 IN securityName -- as provided by caller 1347 IN securityLevel -- as provided by caller 1348 IN scopedPDU -- as prepared in step 6 1349 OUT securityParameters -- filled in by Security Module 1350 OUT wholeMsg -- complete generated message 1351 OUT wholeMsgLength -- length of the generated message 1352 ) 1354 If, upon return from the Security Model, the statusInformation 1355 includes an errorIndication, then the message is discarded, and 1356 the errorIndication is returned, so it can be returned to the 1357 calling application, and no further processing is done. 1358 SNMPv3 Message Processing is complete. 1360 c) If the PDU is from the Confirmed Class, information about the 1361 outgoing message is cached, and a (implementation-specific) 1362 stateReference is created. Information to be cached includes 1363 the values of: 1365 - sendPduHandle 1366 - msgID 1367 - snmpEngineID 1368 - securityModel 1369 - securityName 1370 - securityLevel 1371 - contextEngineID 1372 - contextName 1374 d) A SUCCESS result is returned. SNMPv3 Message Processing is 1375 complete. 1377 7.2. Prepare Data Elements from an Incoming SNMP Message 1379 This section describes the procedure followed to extract data from an 1380 SNMPv3 message, and to prepare the data elements required for further 1381 processing of the message by the Message Dispatcher. 1383 1) The message is passed in from the Message Dispatcher according to 1384 the abstract service primitive: 1386 result = -- SUCCESS or errorIndication 1387 prepareDataElements( 1388 IN transportDomain -- origin transport domain 1389 IN transportAddress -- origin transport address 1390 IN wholeMsg -- as received from the network 1391 IN wholeMsgLength -- as received from the network 1392 OUT messageProcessingModel -- typically, SNMP version 1393 OUT securityModel -- Security Model to use 1394 OUT securityName -- on behalf of this principal 1395 OUT securityLevel -- Level of Security requested 1396 OUT contextEngineID -- data from/at this entity 1397 OUT contextName -- data from/in this context 1398 OUT pduVersion -- version of the PDU 1399 OUT PDU -- SNMP Protocol Data Unit 1400 OUT pduType -- SNMP PDU type 1401 OUT sendPduHandle -- handle for matched request 1402 OUT maxSizeResponseScopedPDU -- maximum size sender can accept 1403 OUT statusInformation -- success or errorIndication 1404 -- error counter OID and value 1405 -- when errorIndication 1406 OUT stateReference -- reference to state information 1407 -- to be used for a possible 1408 ) -- Response 1410 2) If the received message is not the serialization (according to 1411 the conventions of [RFC1906]) of an SNMPv3Message value, then the 1412 snmpInASNParseErrs counter [RFC1907] is incremented, the message 1413 is discarded without further processing, and a FAILURE result is 1414 returned. SNMPv3 Message Processing is complete. 1416 3) The values for msgVersion, msgID, msgMaxSize, msgFlags, 1417 msgSecurityModel, msgSecurityParameters, and msgData are 1418 extracted from the message. 1420 4) If the value of the msgSecurityModel component does not match a 1421 supported securityModel, then the snmpUnknownSecurityModels 1422 counter is incremented, the message is discarded without further 1423 processing, and a FAILURE result is returned. SNMPv3 Message 1424 Processing is complete. 1426 5) The securityLevel is determined from the authFlag and the 1427 privFlag bits of the msgFlags component as follows: 1429 a) If the authFlag is not set and the privFlag is not set, then 1430 securityLevel is set to noAuthNoPriv. 1432 b) If the authFlag is set and the privFlag is not set, then 1433 securityLevel is set to authNoPriv. 1435 c) If the authFlag is set and the privFlag is set, then 1436 securityLevel is set to authPriv. 1438 d) If the authFlag is not set and privFlag is set, then the 1439 snmpInvalidMsgs counter is incremented, the message is 1440 discarded without further processing, and a FAILURE result is 1441 returned. SNMPv3 Message Processing is complete. 1443 e) Any other bits in the msgFlags are ignored. 1445 6) The security module implementing the Security Model as specified 1446 by the securityModel component is called for authentication and 1447 privacy services. This is done according to the abstract service 1448 primitive: 1450 statusInformation = -- errorIndication or success 1451 -- error counter OID and 1452 -- value if error 1453 processIncomingMsg( 1454 IN messageProcessingModel -- SNMPv3 Message Processing Model 1455 IN maxMessageSize -- of the sending SNMP entity 1456 IN securityParameters -- for the received message 1457 IN securityModel -- for the received message 1458 IN securityLevel -- Level of Security 1459 IN wholeMsg -- as received on the wire 1460 IN wholeMsgLength -- length as received on the wire 1461 OUT securityEngineID -- authoritative SNMP entity 1462 OUT securityName -- identification of the principal 1463 OUT scopedPDU, -- message (plaintext) payload 1464 OUT maxSizeResponseScopedPDU -- maximum size sender can accept 1465 OUT securityStateReference -- reference to security state 1466 ) -- information, needed for 1467 -- response 1469 If an errorIndication is returned by the security module, then 1471 a) If statusInformation contains values for an OID/value pair, 1472 then generation of a Report PDU is attempted (see step 3 in 1473 section 7.1). 1475 1) If the scopedPDU has been returned from processIncomingMsg 1476 then determine contextEngineID, contextName, and PDU. 1478 2) Information about the message is cached and a 1479 stateReference is created (implementation-specific). 1481 Information to be cached includes the values of: 1483 msgVersion, 1484 msgID, 1485 securityLevel, 1486 msgFlags, 1487 msgMaxSize, 1488 securityModel, 1489 maxSizeResponseScopedPDU, 1490 securityStateReference 1492 3) Request that a Report-PDU be prepared and sent, according 1493 to the abstract service primitive: 1495 result = -- SUCCESS or FAILURE 1496 returnResponsePdu( 1497 IN messageProcessingModel -- SNMPv3(3) 1498 IN securityModel -- same as on incoming request 1499 IN securityName -- from processIncomingMsg 1500 IN securityLevel -- same as on incoming request 1501 IN contextEngineID -- from step 6 a) 1) 1502 IN contextName -- from step 6 a) 1) 1503 IN pduVersion -- SNMPv2-PDU 1504 IN PDU -- from step 6 a) 1) 1505 IN maxSizeResponseScopedPDU -- from processIncomingMsg 1506 IN stateReference -- from step 6 a) 2) 1507 IN statusInformation -- from processIncomingMsg 1508 ) 1510 b) The incoming message is discarded without further processing, 1511 and a FAILURE result is returned. SNMPv3 Message Processing is 1512 complete. 1514 7) The scopedPDU is parsed to extract the contextEngineID, the 1515 contextName and the PDU. If any parse error occurs, then the 1516 snmpInASNParseErrs counter [RFC1907] is incremented, the security 1517 state information is discarded, the message is discarded without 1518 further processing, and a FAILURE result is returned. SNMPv3 1519 Message Processing is complete. Treating an unknown PDU type is 1520 treated as a parse error is an implementation option. 1522 8) The pduVersion is determined in an implementation-dependent 1523 manner. For SNMPv3, the pduVersion would be an SNMPv2-PDU. 1525 9) The pduType is determined, in an implementation-dependent manner. 1526 For RFC 1905, the pduTypes include: 1528 - GetRequest-PDU, 1529 - GetNextRequest-PDU, 1530 - GetBulkRequest-PDU, 1531 - SetRequest-PDU, 1532 - InformRequest-PDU, 1533 - SNMPv2-Trap-PDU, 1534 - Response-PDU, 1535 - Report-PDU. 1537 10) If the pduType is from the Response Class or the Internal Class, 1538 then 1540 a) The value of the msgID component is used to find the cached 1541 information for a corresponding outstanding Request message. 1542 If no such outstanding Request message is found, then the 1543 security state information is discarded, the message is 1544 discarded without further processing, and a FAILURE result is 1545 returned. SNMPv3 Message Processing is complete. 1547 b) sendPduHandle is retrieved from the cached information. 1549 Otherwise, sendPduHandle is set to , an implementation 1550 defined value. 1552 11) If the pduType is from the Internal Class, then 1554 a) statusInformation is created using the contents of the 1555 Report-PDU, in an implementation-dependent manner. This 1556 statusInformation will be forwarded to the application 1557 associated with the sendPduHandle. 1559 b) The cached data for the outstanding message, referred to by 1560 stateReference, is retrieved. If the securityModel or 1561 securityLevel values differ from the cached ones, it is 1562 important to recognize that Internal Class PDUs delivered at 1563 the security level of noAuthNoPriv open a window of 1564 opportunity for spoofing or replay attacks. If the receiver 1565 of such messages is aware of these risks, the use of such 1566 unauthenticated messages is acceptable and may provide a 1567 useful function for discovering engine IDs or for detecting 1568 misconfiguration at remote nodes. 1570 When the securityModel or securityLevel values differ from the 1571 cached ones, an implementation may retain the cached information 1572 about the outstanding Request message, in anticipation of the 1573 possibility that the Internal Class PDU received might be 1574 illegitimate. Otherwise, any cached information about the 1575 outstanding Request message message is discarded. 1577 c) The security state information for this incoming message is 1578 discarded. 1580 d) stateReference is set to 1582 e) A SUCCESS result is returned. SNMPv3 Message Processing is 1583 complete. 1585 12) If the pduType is from the Response Class, then 1587 a) The cached data for the outstanding request, referred to by 1588 stateReference, is retrieved, including 1590 - snmpEngineID 1591 - securityModel 1592 - securityName 1593 - securityLevel 1594 - contextEngineID 1595 - contextName 1597 b) If the values extracted from the incoming message differ 1598 from the cached data, then any cached information about the 1599 outstanding Request message is discarded, the incoming 1600 message is discarded without further processing, and a 1601 FAILURE result is returned. SNMPv3 Message Processing is 1602 complete. 1604 c) Otherwise, any cached information about the outstanding 1605 Request message is discarded, and stateReference is set to 1606 . 1608 d) A SUCCESS result is returned. SNMPv3 Message Processing is 1609 complete. 1611 13) If the pduType is from the Confirmed Class, then 1613 a) If the value of securityEngineID is not equal to the value 1614 of snmpEngineID, then the security state information is 1615 discarded, any cached information about this message is 1616 discarded, the incoming message is discarded without further 1617 processing, and a FAILURE result is returned. SNMPv3 1618 Message Processing is complete. 1620 b) Information about the message is cached and a stateReference 1621 is created (implementation-specific). Information to be 1622 cached includes the values of: 1624 msgVersion, 1625 msgID, 1626 securityLevel, 1627 msgFlags, 1628 msgMaxSize, 1629 securityModel, 1630 maxSizeResponseScopedPDU, 1631 securityStateReference 1633 d) A SUCCESS result is returned. SNMPv3 Message Processing is 1634 complete. 1636 14) If the pduType is from the Unconfirmed Class, then A SUCCESS 1637 result is returned. SNMPv3 Message Processing is complete. 1639 8. Intellectual Property 1641 The IETF takes no position regarding the validity or scope of any 1642 intellectual property or other rights that might be claimed to 1643 pertain to the implementation or use of the technology described in 1644 this document or the extent to which any license under such rights 1645 might or might not be available; neither does it represent that it 1646 has made any effort to identify any such rights. Information on the 1647 IETF's procedures with respect to rights in standards-track and 1648 standards-related documentation can be found in BCP-11. Copies of 1649 claims of rights made available for publication and any assurances of 1650 licenses to be made available, or the result of an attempt made to 1651 obtain a general license or permission for the use of such 1652 proprietary rights by implementors or users of this specification can 1653 be obtained from the IETF Secretariat. 1655 The IETF invites any interested party to bring to its attention any 1656 copyrights, patents or patent applications, or other proprietary 1657 rights which may cover technology that may be required to practice 1658 this standard. Please address the information to the IETF Executive 1659 Director. 1661 9. Acknowledgements 1663 This document is the result of the efforts of the SNMPv3 Working 1664 Group. Some special thanks are in order to the following SNMPv3 WG 1665 members: 1667 Harald Tveit Alvestrand (Maxware) 1668 Dave Battle (SNMP Research, Inc.) 1669 Alan Beard (Disney Worldwide Services) 1670 Paul Berrevoets (SWI Systemware/Halcyon Inc.) 1671 Martin Bjorklund (Ericsson) 1672 Uri Blumenthal (IBM T.J. Watson Research Center) 1673 Jeff Case (SNMP Research, Inc.) 1674 John Curran (BBN) 1675 Mike Daniele (Compaq Computer Corporation) 1676 T. Max Devlin (Eltrax Systems) 1677 John Flick (Hewlett Packard) 1678 Rob Frye (MCI) 1679 Wes Hardaker (U.C.Davis, Information Technology - D.C.A.S.) 1680 David Harrington (Cabletron Systems Inc.) 1681 Lauren Heintz (BMC Software, Inc.) 1682 N.C. Hien (IBM T.J. Watson Research Center) 1683 Michael Kirkham (InterWorking Labs, Inc.) 1684 Dave Levi (SNMP Research, Inc.) 1685 Louis A Mamakos (UUNET Technologies Inc.) 1686 Joe Marzot (Nortel Networks) 1687 Paul Meyer (Secure Computing Corporation) 1688 Keith McCloghrie (Cisco Systems) 1689 Bob Moore (IBM) 1690 Russ Mundy (TIS Labs at Network Associates) 1691 Bob Natale (ACE*COMM Corporation) 1692 Mike O'Dell (UUNET Technologies Inc.) 1693 Dave Perkins (DeskTalk) 1694 Peter Polkinghorne (Brunel University) 1695 Randy Presuhn (BMC Software, Inc.) 1696 David Reeder (TIS Labs at Network Associates) 1697 David Reid (SNMP Research, Inc.) 1698 Aleksey Romanov (Quality Quorum) 1699 Shawn Routhier (Epilogue) 1700 Juergen Schoenwaelder (TU Braunschweig) 1701 Bob Stewart (Cisco Systems) 1702 Mike Thatcher (Independent Consultant) 1703 Bert Wijnen (IBM T.J. Watson Research Center) 1705 The document is based on recommendations of the IETF Security and 1706 Administrative Framework Evolution for SNMP Advisory Team. Members 1707 of that Advisory Team were: 1709 David Harrington (Cabletron Systems Inc.) 1710 Jeff Johnson (Cisco Systems) 1711 David Levi (SNMP Research Inc.) 1712 John Linn (Openvision) 1713 Russ Mundy (Trusted Information Systems) chair 1714 Shawn Routhier (Epilogue) 1715 Glenn Waters (Nortel) 1716 Bert Wijnen (IBM T. J. Watson Research Center) 1718 As recommended by the Advisory Team and the SNMPv3 Working Group 1719 Charter, the design incorporates as much as practical from previous 1720 RFCs and drafts. As a result, special thanks are due to the authors 1721 of previous designs known as SNMPv2u and SNMPv2*: 1723 Jeff Case (SNMP Research, Inc.) 1724 David Harrington (Cabletron Systems Inc.) 1725 David Levi (SNMP Research, Inc.) 1726 Keith McCloghrie (Cisco Systems) 1727 Brian O'Keefe (Hewlett Packard) 1728 Marshall T. Rose (Dover Beach Consulting) 1729 Jon Saperia (BGS Systems Inc.) 1730 Steve Waldbusser (International Network Services) 1731 Glenn W. Waters (Bell-Northern Research Ltd.) 1733 10. Security Considerations 1735 The Dispatcher coordinates the processing of messages to provide a 1736 level of security for management messages and to direct the SNMP PDUs 1737 to the proper SNMP application(s). 1739 A Message Processing Model, and in particular the V3MP defined in 1740 this document, interacts as part of the Message Processing with 1741 Security Models in the Security Subsystem via the abstract service 1742 interface primitives defined in [SNMP-ARCH] and elaborated above. 1744 The level of security actually provided is primarily determined by 1745 the specific Security Model implementation(s) and the specific SNMP 1746 application implementation(s) incorporated into this framework. 1747 Applications have access to data which is not secured. Applications 1748 should take reasonable steps to protect the data from disclosure, and 1749 when they send data across the network, they should obey the 1750 securityLevel and call upon the services of an Access Control Model 1751 as they apply access control. 1753 The values for the msgID element used in communication between SNMP 1754 entities must be chosen to avoid replay attacks. The values do not 1755 need to be unpredictable; it is sufficient that they not repeat. 1757 When exchanges are carried out over an insecure network, there is an 1758 open opportunity for a third party to spoof or replay messages when 1759 any message of an exchange is given at the security level of 1760 noAuthNoPriv. For most exchanges, all messages exist at the same 1761 security level. In the case where the final message is an Internal 1762 Class PDU, this message may be delivered at a level of noAuthNoPriv 1763 or authNoPriv, independent of the security level of the preceding 1764 messages. Internal Class PDUs delivered at the level of authNoPriv 1765 are not considered to pose a security hazard. Internal Class PDUs 1766 delivered at the security level of noAuthNoPriv open a window of 1767 opportunity for spoofing or replay attacks. If the receiver of such 1768 messages is aware of these risks, the use of such unauthenticated 1769 messages is acceptable and may provide a useful function for 1770 discovering engine IDs or for detecting misconfiguration at remote 1771 nodes. 1773 This document also contains a MIB definition module. None of the 1774 objects defined is writable, and the information they represent is 1775 not deemed to be particularly sensitive. However, if they are deemed 1776 sensitive in a particular environment, access to them should be 1777 restricted through the use of appropriately configured Security and 1778 Access Control models. 1780 11. References 1782 [RFC1901] The SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, 1783 M. and S. Waldbusser, "Introduction to Community-based SNMPv2", 1784 RFC 1901, January 1996. 1786 [RFC1902] The SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, 1787 M. and S. Waldbusser, "Structure of Management Information for 1788 Version 2 of the Simple Network Management Protocol (SNMPv2)", 1789 RFC 1902, January 1996. 1791 [RFC1905] The SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, 1792 M. and S. Waldbusser, "Protocol Operations for Version 2 of the 1793 Simple Network Management Protocol (SNMPv2)", RFC 1905, January 1794 1996. 1796 [RFC1906] The SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, 1797 M. and S. Waldbusser, "Transport Mappings for Version 2 of the 1798 Simple Network Management Protocol (SNMPv2)", RFC 1906, January 1799 1996. 1801 [RFC1907] The SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, 1802 M. and S. Waldbusser, "Management Information Base for Version 2 1803 of the Simple Network Management Protocol (SNMPv2)", RFC 1907 1804 January 1996. 1806 [RFC1908] The SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, 1807 M. and S. Waldbusser, "Coexistence between Version 1 and Version 2 1808 of the Internet-standard Network Management Framework", RFC 1908, 1809 January 1996. 1811 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1812 Requirement Levels", RFC 2119, BCP 14, March 1997. 1814 [RFC2028] Hovey, R. and S. Bradner, "The Organizations Involved in 1815 the IETF Standards Process", BCP 11, RFC 2028, October 1996. 1817 [SNMP-ARCH] Harrington, D., Presuhn, R. and B. Wijnen, "An 1818 Architecture for describing SNMP Management Frameworks", , February 1999. 1821 [SNMP-USM] Blumenthal, U. and B. Wijnen, "The User-Based Security 1822 Model for Version 3 of the Simple Network Management Protocol 1823 (SNMPv3)", , February 1999. 1825 [SNMP-ACM] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based 1826 Access Control Model for the Simple Network Management Protocol 1827 (SNMP)", , February 1999. 1829 [SNMP-APPL] Levi, D. B., Meyer, P. and B. Stewart, "SNMPv3 1830 Applications", , January 1999. 1832 [SNMP-INTRO] Case, J., Mundy, R., Partain, D. and B. Stewart, 1833 "Introduction to Version 3 of the Internet-standard Network 1834 Management Framework", , January 1835 1999. 1837 12. Editors' Addresses 1839 Jeffrey Case 1840 SNMP Research, Inc. 1841 3001 Kimberlin Heights Road 1842 Knoxville, TN 37920-9716 1843 USA 1845 Phone: +1 423-573-1434 1846 EMail: case@snmp.com 1848 Dave Harrington 1849 Cabletron Systems, Inc 1850 Post Office Box 5005 1851 Mail Stop: Durham 1852 35 Industrial Way 1853 Rochester, NH 03867-5005 1854 USA 1856 Phone: +1 603-337-7357 1857 EMail: dbh@ctron.com 1858 Randy Presuhn 1859 BMC Software, Inc. 1860 965 Stewart Drive 1861 Sunnyvale, CA 94086 1862 USA 1864 Phone: +1 408-616-3100 1865 EMail: randy_presuhn@bmc.com 1867 Bert Wijnen 1868 IBM T. J. Watson Research 1869 Schagen 33 1870 3461 GL Linschoten 1871 Netherlands 1873 Phone: +31 348-432-794 1874 EMail: wijnen@vnet.ibm.com 1876 APPENDIX A 1878 A. Issues 1880 This section will be deleted in the transition from internet-draft to 1881 RFC. 1883 A.1. Open Issues 1885 No open issues remain. 1887 A.2. Change Log 1889 The following change log records major changes from the previous 1890 internet draft. 1892 - Updated contact information for editors. 1894 Made parameter identification in prepareResponseMessage() 1895 consistent, both internally and with architecture. 1897 - Made references to processIncomingMsg() consistent, both 1898 internally and with architecture. 1900 - Deleted superfluous expectResponse parameter from 1901 processIncomingMsg(), consistent with architecture. 1903 - Fixed typos. 1905 - Removed sending of a report PDU from step 4 on page 30 on RFC 1906 2272. (Technical change, editor believes there was WG 1907 agreement.) 1909 - The document directly refers to RFC 1905 PDU types which binds 1910 the version 3 message model to RFC 1905. The text should 1911 instead use "PDU classes" so that additional PDU types can be 1912 added over time without having to change the message processing 1913 model. Resolved: the binding of MPD to USM was a conscious 1914 decision. 1916 First cut at using PDU Class concept to reduce RFC 1905 1917 dependencies. 1919 - Added intro document to references. 1921 - What security name is used for sending reports when the auth 1922 flag is not set but the priv flag is set? (7.2.5, similar 1923 questions for 7.2.6) Resolved by using securityName from 1924 incoming message. 1926 - What action is taken upon receipt of illegal combinations of 1927 the msgFlags bits? What action is taken if the "reserved" bits 1928 are non-zero upon receipt? Resolved by adding text saying 1929 reserved are ignored; text specifies handling of illegal 1930 combination. 1932 - The purpose of Report PDUs (engine-to-engine communications) 1933 might be made clearer. What text (if any) should be added 1934 explaining what actions (if any) are taken upon receipt of a 1935 report PDU? Issue resolved by adding text. 1937 - Various possible points of clarifications, especially the ones 1938 raised by Martin Bjorklund and others on the mailing list. 1940 - The more precise specification of the handling of the 1941 reportableFlag begs the question of what an engine is supposed 1942 to do when it receives a message with an illegal combination of 1943 the reportableFlag and PDU type. Issue resolved; all cases 1944 covered in text. 1946 - New PDU types can cause different error reactions, e.g. sending 1947 an snmpUnknownPDUHandlers report or just incrementing the ASN.1 1948 parse error counter. To allow smooth deployment, text needs to 1949 be added how to recognize PDU types and a report should be sent 1950 if a received PDU type is unknown. Resolved per Chicago 1951 meeting and mailing list discussion. 1953 - The handling of the reportableFlag has been made consistent. 1955 - The acknowledgement list has been updated. 1957 - New I-D boilerplate for first page. 1959 - Fixed more typos. 1961 B. Full Copyright Statement 1963 Copyright (C) The Internet Society (1999). All Rights Reserved. 1965 This document and translations of it may be copied and furnished to 1966 others, and derivative works that comment on or otherwise explain it 1967 or assist in its implementation may be prepared, copied, published 1968 and distributed, in whole or in part, without restriction of any 1969 kind, provided that the above copyright notice and this paragraph are 1970 included on all such copies and derivative works. However, this 1971 document itself may not be modified in any way, such as by removing 1972 the copyright notice or references to the Internet Society or other 1973 Internet organizations, except as needed for the purpose of 1974 developing Internet standards in which case the procedures for 1975 copyrights defined in the Internet Standards process must be 1976 followed, or as required to translate it into languages other than 1977 English. 1979 The limited permissions granted above are perpetual and will not be 1980 revoked by the Internet Society or its successors or assigns. 1982 This document and the information contained herein is provided on an 1983 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1984 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1985 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1986 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1987 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.