idnits 2.17.1 draft-ietf-snmpv3-mpc-01.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. ** 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 Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of too long lines in the document, the longest one being 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 (21 October 1998) is 9311 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 1715, but no explicit reference was found in the text == Unused Reference: 'RFC1908' is defined on line 1735, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 1740, but no explicit reference was found in the text == Unused Reference: 'RFC2028' is defined on line 1743, but no explicit reference was found in the text == Unused Reference: 'SNMP-USM' is defined on line 1750, but no explicit reference was found in the text == Unused Reference: 'SNMP-ACM' is defined on line 1754, but no explicit reference was found in the text == Unused Reference: 'SNMP-APPL' is defined on line 1758, but no explicit reference was found in the text == Unused Reference: 'SNMP-INTRO' is defined on line 1761, 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' == Outdated reference: A later version (-04) exists of draft-ietf-snmpv3-intro-01 ** Downref: Normative reference to an Informational draft: draft-ietf-snmpv3-intro (ref. 'SNMP-INTRO') Summary: 18 errors (**), 0 flaws (~~), 12 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT J. Case 3 Will Obsolete: 2272 SNMP Research, Inc. 4 D. Harrington 5 Cabletron Systems, Inc. 6 R. Presuhn 7 BMC Software, Inc. 8 B. Wijnen 9 IBM T. J. Watson Research 10 21 October 1998 12 Message Processing and Dispatching for the 13 Simple Network Management Protocol (SNMP) 14 16 Status of this Memo 18 This document is an Internet-Draft. 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 To view the entire list of current Internet-Drafts, please check the 29 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 30 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern 31 Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific 32 Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 34 Copyright Notice 36 Copyright (C) The Internet Society (1998). 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 .................................................. 21 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 ......................................... 24 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 .................................... 38 89 11. References ................................................. 39 90 12. Editors' Addresses ......................................... 40 91 A. Issues ...................................................... 42 92 A.1. Open Issues ............................................... 42 93 A.2. Change Log ................................................ 42 94 B. Full Copyright Statement .................................... 43 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 responsibile 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 modelled 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 modelled 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 RFC1906) | | +->| 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 -- the version of the PDU 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 returnResponsePdu( 399 IN messageProcessingModel -- typically, SNMP version 400 IN securityModel -- Security Model in use 401 IN securityName -- on behalf of this principal 402 IN securityLevel -- same as on incoming request 403 IN contextEngineID -- data from/at this SNMP entity 404 IN contextName -- data from/in this context 405 IN pduVersion -- the version of the PDU 406 IN PDU -- SNMP Protocol Data Unit 407 IN maxSizeResponseScopedPDU -- maximum size of Response PDU 408 IN stateReference -- reference to state information 409 -- as presented with the request 410 IN statusInformation -- success or errorIndication 411 ) -- (error counter OID and value 412 -- when errorIndication) 414 2) The Message Dispatcher sends the request to the appropriate 415 Message Processing Model indicated by the received value of 416 messageProcessingModel using the abstract service primitive: 418 result = -- SUCCESS or errorIndication 419 prepareResponseMessage( 420 IN messageProcessingModel -- specified by application 421 IN securityModel -- specified by application 422 IN securityName -- specified by application 423 IN securityLevel -- specified by application 424 IN contextEngineID -- specified by application 425 IN contextName -- specified by application 426 IN pduVersion -- specified by application 427 IN PDU -- specified by application 428 IN maxSizeResponseScopedPDU -- specified by application 429 IN stateReference -- specified by application 430 IN statusInformation -- specified by application 431 OUT destTransportDomain -- destination transport domain 432 OUT destTransportAddress -- destination transport address 433 OUT outgoingMessage -- the message to send 434 OUT outgoingMessageLength -- the message length 435 ) 437 3) If the result is an errorIndication, the errorIndication is 438 returned to the calling application. No further processing is 439 performed. 441 4) If the result is success, the outgoingMessage is sent over the 442 transport specified by the transportDomain to the address 443 specified by the transportAddress. 445 Message Processing is complete. 447 4.2. Receiving an SNMP Message from the Network 449 This section describes the procedure followed by an SNMP engine 450 whenever it receives an SNMP message. 452 Please note, that for the sake of clarity and to prevent the text 453 from being even longer and more complicated, some details were 454 omitted from the steps below. In particular, The elements of 455 procedure do not always explicitly indicate when state information 456 needs to be released. The general rule is that if state information 457 is available when a message is to be "discarded without further 458 processing", then the state information must also be released at that 459 same time. 461 4.2.1. Message Dispatching of received SNMP Messages 463 1) The snmpInPkts counter [RFC1907] is incremented. 465 2) The version of the SNMP message is determined in an 466 implementation-dependent manner. If the packet cannot be 467 sufficiently parsed to determine the version of the SNMP message, 468 then the snmpInASNParseErrs [RFC1907] counter is incremented, and 469 the message is discarded without further processing. If the 470 version is not supported, then the snmpInBadVersions [RFC1907] 471 counter is incremented, and the message is discarded without 472 further processing. 474 3) The origin transportDomain and origin transportAddress are 475 determined. 477 4) The message is passed to the version-specific Message Processing 478 Model which returns the abstract data elements required by the 479 Dispatcher. This is performed using the abstract service 480 primitive: 482 result = -- SUCCESS or errorIndication 483 prepareDataElements( 484 IN transportDomain -- origin as determined in step 3. 485 IN transportAddress -- origin as determined in step 3. 486 IN wholeMsg -- as received from the network 487 IN wholeMsgLength -- as received from the network 488 OUT messageProcessingModel -- typically, SNMP version 489 OUT securityModel -- Security Model to use 490 OUT securityName -- on behalf of this principal 491 OUT securityLevel -- Level of Security requested 492 OUT contextEngineID -- data from/at this entity 493 OUT contextName -- data from/in this context 494 OUT pduVersion -- the version of the PDU 495 OUT PDU -- SNMP Protocol Data Unit 496 OUT pduType -- SNMP PDU type 497 OUT sendPduHandle -- handle for a matched request 498 OUT maxSizeResponseScopedPDU -- maximum size of Response PDU 499 OUT statusInformation -- success or errorIndication 500 -- (error counter OID and value 501 -- when errorIndication) 502 OUT stateReference -- reference to state information 503 -- to be used for a possible 504 ) -- Response 506 5) If the result is a FAILURE errorIndication, the message is 507 discarded without further processing. 509 6) At this point, the abstract data elements have been prepared and 510 processing continues as described in Section 4.2.2, PDU 511 Dispatching for Incoming Messages. 513 4.2.2. PDU Dispatching for Incoming Messages 515 The elements of procedure for the dispatching of PDUs depends on the 516 value of sendPduHandle. If the value of sendPduHandle is , 517 then this is a request or notification and the procedures specified 518 in Section 4.2.2.1 apply. If the value of snmpPduHandle is not 519 , then this is a response and the procedures specified in 520 Section 4.2.2.2 apply. 522 4.2.2.1. Incoming Requests and Notifications 524 The following procedures are followed for the dispatching of PDUs 525 when the value of sendPduHandle is , indicating this is a 526 request or notification. 528 1) The combination of contextEngineID and pduType is used to 529 determine which application has registered for this request or 530 notification. 532 2) If no application has registered for the combination, then 534 a) The snmpUnknownPDUHandlers counter is incremented. 536 b) A Response message is generated using the abstract service 537 primitive: 539 result = -- SUCCESS or FAILURE 540 prepareResponseMessage( 541 IN messageProcessingModel -- as provided by MP module 542 IN securityModel -- as provided by MP module 543 IN securityName -- as provided by MP module 544 IN securityLevel -- as provided by MP module 545 IN contextEngineID -- as provided by MP module 546 IN contextName -- as provided by MP module 547 IN pduVersion -- as provided by MP module 548 IN PDU -- as provided by MP module 549 IN maxSizeResponseScopedPDU -- as provided by MP module 550 IN stateReference -- as provided by MP module 551 IN statusInformation -- errorIndication plus 552 -- snmpUnknownPDUHandlers OID 553 -- value pair. 554 OUT destTransportDomain -- destination transportDomain 555 OUT destTransportAddress -- destination transportAddress 556 OUT outgoingMessage -- the message to send 557 OUT outgoingMessageLength -- its length 558 ) 560 c) If the result is SUCCESS, then the prepared message is sent to 561 the originator of the request as identified by the 562 transportDomain and transportAddress. 564 d) The incoming message is discarded without further processing. 565 Message Processing for this message is complete. 567 3) The PDU is dispatched to the application, using the abstract 568 service primitive: 570 processPdu( -- process Request/Notification 571 IN messageProcessingModel -- as provided by MP module 572 IN securityModel -- as provided by MP module 573 IN securityName -- as provided by MP module 574 IN securityLevel -- as provided by MP module 575 IN contextEngineID -- as provided by MP module 576 IN contextName -- as provided by MP module 577 IN pduVersion -- as provided by MP module 578 IN PDU -- as provided by MP module 579 IN maxSizeResponseScopedPDU -- as provided by MP module 580 IN stateReference -- as provided by MP module 581 -- needed when sending response 582 ) 584 Message processing for this message is complete. 586 4.2.2.2. Incoming Responses 588 The following procedures are followed for the dispatching of PDUs 589 when the value of sendPduHandle is not , indicating this is a 590 response. 592 1) The value of sendPduHandle is used to determine, in an 593 implementation-defined manner, which application is waiting for 594 a response PDU associated with this sendPduHandle. 596 2) If no waiting application is found, the message is discarded 597 without further processing, and the stateReference is released. 598 The snmpUnknownPDUHandlers counter is incremented. Message 599 Processing is complete for this message. 601 3) Any cached information, including stateReference, about the 602 message is discarded. 604 4) The response is dispatched to the application using the 605 abstract service primitive: 607 processResponsePdu( -- process Response PDU 608 IN messageProcessingModel -- provided by the MP module 609 IN securityModel -- provided by the MP module 610 IN securityName -- provided by the MP module 611 IN securityLevel -- provided by the MP module 612 IN contextEngineID -- provided by the MP module 613 IN contextName -- provided by the MP module 614 IN pduVersion -- provided by the MP module 615 IN PDU -- provided by the MP module 616 IN statusInformation -- provided by the MP module 617 IN sendPduHandle -- provided by the MP module 618 ) 620 Message Processing is complete for this message. 622 4.3. Application Registration for Handling PDU types 624 Applications that want to process certain PDUs must register with the 625 PDU Dispatcher. Applications specify the combination of 626 contextEngineID and pduType(s) for which they want to take 627 responsibility 629 1) An application registers according to the abstract interface 630 primitive: 632 statusInformation = -- success or errorIndication 633 registerContextEngineID( 634 IN contextEngineID -- take responsibility for this one 635 IN pduType -- the pduType(s) to be registered 636 ) 638 Note: implementations may provide a means of requesting 639 registration for simultaneous multiple contextEngineID values, 640 e.g., all contextEngineID values, and may also provide means for 641 requesting simultaneous registration for multiple values of 642 pduType. 644 2) The parameters may be checked for validity; if they are not, then 645 an errorIndication (invalidParameter) is returned to the 646 application. 648 3) Each combination of contextEngineID and pduType can be registered 649 only once. If another application has already registered for the 650 specified combination, then an errorIndication (alreadyRegistered) 651 is returned to the application. 653 4) Otherwise, the registration is saved so that SNMP PDUs can be 654 dispatched to this application. 656 4.4. Application Unregistration for Handling PDU Types 658 Applications that no longer want to process certain PDUs must 659 unregister with the PDU Dispatcher. 661 1) An application unregisters using the abstract service primitive: 663 unregisterContextEngineID( 664 IN contextEngineID -- give up responsibility for this 665 IN pduType -- the pduType(s) to be unregistered 666 ) 667 Note: implementations may provide means for requesting 668 unregistration for simultaneous multiple contextEngineID values, 669 e.g., all contextEngineID values, and may also provide means for 670 requesting simultaneous unregistration for multiple values of 671 pduType. 673 2) If the contextEngineID and pduType combination has been 674 registered, then the registration is deleted. 676 If no such registration exists, then the request is ignored. 678 5. Definitions 680 5.1. Definitions for SNMP Message Processing and Dispatching 682 SNMP-MPD-MIB DEFINITIONS ::= BEGIN 684 IMPORTS 685 MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF 686 MODULE-IDENTITY, OBJECT-TYPE, 687 snmpModules, Counter32 FROM SNMPv2-SMI; 689 snmpMPDMIB MODULE-IDENTITY 690 LAST-UPDATED "9808071707Z" -- 07 August 1998 691 ORGANIZATION "SNMPv3 Working Group" 692 CONTACT-INFO "WG-email: snmpv3@tis.com 693 Subscribe: majordomo@tis.com 694 In message body: subscribe snmpv3 696 Chair: Russ Mundy 697 Trusted Information Systems 698 postal: 3060 Washington Road 699 Glenwood, MD 21738 700 USA 701 email: mundy@tis.com 702 phone: +1 301-854-6889 703 Co-editor: Jeffrey Case 704 SNMP Research, Inc. 705 postal: 3001 Kimberlin Heights Road 706 Knoxville, TN 37920-9716 707 USA 708 email: case@snmp.com 709 phone: +1 423-573-1434 711 Co-editor Dave Harrington 712 Cabletron Systems, Inc. 713 postal: Post Office Box 5005 714 MailStop: Durham 715 35 Industrial Way 716 Rochester, NH 03867-5005 717 USA 718 email: dbh@ctron.com 719 phone: +1 603-337-7357 721 Co-editor: Randy Presuhn 722 BMC Software, Inc. 723 postal: 1190 Saratoga Ave, Suite 190 724 San Jose, CA 95120 725 USA 726 email: rpresuhn@bmc.com 727 phone: +1 408-616-3100 729 Co-editor: Bert Wijnen 730 IBM T. J. Watson Research 731 postal: Schagen 33 732 3461 GL Linschoten 733 Netherlands 734 email: wijnen@vnet.ibm.com 735 phone: +31 348-432-794 737 " 738 DESCRIPTION "The MIB for Message Processing and Dispatching" 739 ::= { snmpModules 11 } 741 -- Administrative assignments *************************************** 743 snmpMPDAdmin OBJECT IDENTIFIER ::= { snmpMPDMIB 1 } 744 snmpMPDMIBObjects OBJECT IDENTIFIER ::= { snmpMPDMIB 2 } 745 snmpMPDMIBConformance OBJECT IDENTIFIER ::= { snmpMPDMIB 3 } 747 -- Statistics for SNMP Messages ************************************* 749 snmpMPDStats OBJECT IDENTIFIER ::= { snmpMPDMIBObjects 1 } 750 snmpUnknownSecurityModels OBJECT-TYPE 751 SYNTAX Counter32 752 MAX-ACCESS read-only 753 STATUS current 754 DESCRIPTION "The total number of packets received by the SNMP 755 engine which were dropped because they referenced a 756 securityModel that was not known to or supported by 757 the SNMP engine. 758 " 759 ::= { snmpMPDStats 1 } 761 snmpInvalidMsgs OBJECT-TYPE 762 SYNTAX Counter32 763 MAX-ACCESS read-only 764 STATUS current 765 DESCRIPTION "The total number of packets received by the SNMP 766 engine which were dropped because there were invalid 767 or inconsistent components in the SNMP message. 768 " 769 ::= { snmpMPDStats 2 } 771 snmpUnknownPDUHandlers OBJECT-TYPE 772 SYNTAX Counter32 773 MAX-ACCESS read-only 774 STATUS current 775 DESCRIPTION "The total number of packets received by the SNMP 776 engine which were dropped because the PDU contained 777 in the packet could not be passed to an application 778 responsible for handling the pduType, e.g. no SNMP 779 application had registered for the proper 780 combination of the contextEngineID and the pduType. 781 " 782 ::= { snmpMPDStats 3 } 784 -- Conformance information ****************************************** 786 snmpMPDMIBCompliances OBJECT IDENTIFIER ::= {snmpMPDMIBConformance 1} 787 snmpMPDMIBGroups OBJECT IDENTIFIER ::= {snmpMPDMIBConformance 2} 789 -- Compliance statements 791 snmpMPDCompliance MODULE-COMPLIANCE 792 STATUS current 793 DESCRIPTION "The compliance statement for SNMP entities which 794 implement the SNMP-MPD-MIB. 795 " 797 MODULE -- this module 798 MANDATORY-GROUPS { snmpMPDGroup } 800 ::= { snmpMPDMIBCompliances 1 } 802 snmpMPDGroup OBJECT-GROUP 803 OBJECTS { 804 snmpUnknownSecurityModels, 805 snmpInvalidMsgs, 806 snmpUnknownPDUHandlers 807 } 808 STATUS current 809 DESCRIPTION "A collection of objects providing for remote 810 monitoring of the SNMP Message Processing and 811 Dispatching process. 812 " 813 ::= { snmpMPDMIBGroups 1 } 815 END 817 6. The SNMPv3 Message Format 819 This section defines the SNMPv3 message format and the corresponding 820 SNMP version 3 Message Processing Model (v3MP). 822 SNMPv3MessageSyntax DEFINITIONS IMPLICIT TAGS ::= BEGIN 824 SNMPv3Message ::= SEQUENCE { 825 -- identify the layout of the SNMPv3Message 826 -- this element is in same position as in SNMPv1 827 -- and SNMPv2c, allowing recognition 828 msgVersion INTEGER { snmpv3 (3) }, 829 -- administrative parameters 830 msgGlobalData HeaderData, 831 -- security model-specific parameters 832 -- format defined by Security Model 833 msgSecurityParameters OCTET STRING, 834 msgData ScopedPduData 835 } 837 HeaderData ::= SEQUENCE { 838 msgID INTEGER (0..2147483647), 839 msgMaxSize INTEGER (484..2147483647), 841 msgFlags OCTET STRING (SIZE(1)), 842 -- .... ...1 authFlag 843 -- .... ..1. privFlag 844 -- .... .1.. reportableFlag 845 -- Please observe: 846 -- .... ..00 is OK, means noAuthNoPriv 847 -- .... ..01 is OK, means authNoPriv 848 -- .... ..10 reserved, must NOT be used. 849 -- .... ..11 is OK, means authPriv 851 msgSecurityModel INTEGER (0..2147483647) 852 } 854 ScopedPduData ::= CHOICE { 855 plaintext ScopedPDU, 856 encryptedPDU OCTET STRING -- encrypted scopedPDU value 857 } 859 ScopedPDU ::= SEQUENCE { 860 contextEngineID OCTET STRING, 861 contextName OCTET STRING, 862 data ANY -- e.g., PDUs as defined in RFC1905 863 } 864 END 866 6.1. msgVersion 868 The msgVersion field is set to snmpv3(3) and identifies the message 869 as an SNMP version 3 Message. 871 6.2. msgID 873 The msgID is used between two SNMP entities to coordinate request 874 messages and responses, and by the v3MP to coordinate the processing 875 of the message by different subsystem models within the architecture. 877 Values for msgID should be generated in a manner that avoids re-use 878 of any outstanding values. Doing so provides protection against some 879 replay attacks. One possible implementation strategy would be to use 880 the low-order bits of snmpEngineBoots [SNMP-ARCH] as the high-order 881 portion of the msgID value and a monotonically increasing integer for 882 the low-order portion of msgID. 884 Note that the request-id in a PDU is used by SNMP applications to 885 identify the PDU; the msgID is used by the engine to identify the 886 message which carries a PDU. The engine may need to identify the 887 message even if decrypting of the PDU (and request-id) fails. No 888 assumption should be made that the value of the msgID and the value 889 of the request-id are equivalent. 891 6.3. msgMaxSize 893 The msgMaxSize field of the message conveys the maximum message size 894 supported by the sender of the message, i.e., the maximum message 895 size that the sender can accept when another SNMP engine sends an 896 SNMP message (be it a response or any other message) to the sender of 897 this message on the transport in use for this message. 899 When an SNMP message is being generated, the msgMaxSize is provided 900 by the SNMP engine which generates the message. At the receiving 901 SNMP engine, the msgMaxSize is used to determine how big the Response 902 to a Request message can be. 904 6.4. msgFlags 906 The msgFlags field of the message contains several bit fields which 907 control processing of the message. 909 When the reportableFlag is one, a Report PDU must be returned to the 910 sender under those conditions which can cause the generation of 911 Report PDUs. When the reportableFlag is zero, then a Report PDU must 912 not be sent. The reportableFlag must always be zero when the message 913 contains a Report PDU, a response-type PDU (such as a Response PDU), 914 or an unacknowledged notification-type PDU (such as an SNMPv2-trap 915 PDU). The reportableFlag must always be one for a request-type PDU 916 (such as a Get PDU) and an acknowledged notification-type PDU (such 917 as an Inform PDU). 919 If the reportableFlag is set to one for a message containing a Report 920 PDU, a response-type PDU (such as a Response PDU), or an 921 unacknowledged notification-type PDU (such as an SNMPv2-trap PDU), 922 then the receiver of that message must process it as though the 923 reportableFlag had been set to zero. 925 If the reportableFlag is set to zero for a message containing a 926 request-type PDU (such as a Get PDU) or an acknowledged notification- 927 type PDU (such as an Inform PDU), then the receiver of that message 928 must process it as though the reportableFlag had been set to one. 930 Report PDUs are engine-to-engine communications and are processed 931 directly by the SNMPv3 Message Processing Model, and are generally 932 not passed to applications for processing, unlike all other PDU 933 types. 935 An SNMP engine that receives a reportPDU may use it to determine what 936 kind of problem was detected by the remote SNMP engine. It can do so 937 based on the error counter included as the first (and only) varBind 938 of the reportPDU. Based on the detected error, the SNMP engine may 939 try to send a corrected SNMP message. If that is not possible, it 940 may pass an indication of the error to the application on whose 941 behalf the failed SNMP request was issued. 943 Note that the reportableFlag is a secondary aid in determining 944 whether a Report PDU must be sent. It is only used in cases where 945 the PDU portion of a message cannot be decoded, due to, for example, 946 an incorrect ecryption key. If the PDU can be decoded, the PDU type 947 forms the basis for decisions on sending Report PDUs. 949 The authFlag and privFlag portions of the msgFlags field are set by 950 the sender to indicate the securityLevel that was applied to the 951 message before it was sent on the wire. The receiver of the message 952 MUST apply the same securityLevel when the message is received and 953 the contents are being processed. 955 There are three securityLevels, namely noAuthNoPriv, which is less 956 than authNoPriv, which is in turn less than authPriv. See the SNMP 957 architecture document [SNMP-ARCH] for details about the 958 securityLevel. 960 a) authFlag 961 If the authFlag is set to one, then the securityModel used by the 962 SNMP engine which sent the message MUST identify the securityName 963 on whose behalf the SNMP message was generated and MUST provide, 964 in a securityModel-specific manner, sufficient data for the 965 receiver of the message to be able to authenticate that 966 identification. In general, this authentication will allow the 967 receiver to determine with reasonable certainty that the message 968 was: 970 - sent on behalf of the principal associated with the 971 securityName, 973 - was not redirected, 975 - was not modified in transit, and 977 - was not replayed. 979 If the authFlag is zero, then the securityModel used by the SNMP 980 engine which sent the message must identify the securityName on 981 whose behalf the SNMP message was generated but it does not need 982 to provide sufficient data for the receiver of the message to 983 authenticate the identification, as there is no need to 984 authenticate the message in this case. 986 b) privFlag 988 If the privFlag is set, then the securityModel used by the SNMP 989 engine which sent the message MUST also protect the scopedPDU in 990 an SNMP message from disclosure, i.e., it MUST encrypt/decrypt the 991 scopedPDU. If the privFlag is zero, then the securityModel in use 992 does not need to protect the data from disclosure. 994 It is an explicit requirement of the SNMP architecture that if 995 privacy is selected, then authentication is also required. That 996 means that if the privFlag is set, then the authFlag MUST also be 997 set to one. 999 The combination of the authFlag and the privFlag comprises a Level 1000 of Security as follows: 1001 authFlag zero, privFlag zero -> securityLevel is noAuthNoPriv 1002 authFlag zero, privFlag one -> invalid combination, see below 1003 authFlag one, privFlag zero -> securityLevel is authNoPriv 1004 authFlag one, privFlag one -> securityLevel is authPriv 1006 The elements of procedure (see below) describe the action to be take 1007 when the invalid combination of authFlag equal to zero and privFlag 1008 equal to one is encountered. 1010 The remaining bits in msgFlags are reserved, and must be set to zero 1011 when sending a message and should be ignored when receiving a 1012 message. 1014 6.5. msgSecurityModel 1016 The v3MP supports the concurrent existence of multiple Security 1017 Models to provide security services for SNMPv3 messages. The 1018 msgSecurityModel field in an SNMPv3 Message identifies which Security 1019 Model was used by the sender to generate the message and therefore 1020 which securityModel must be used by the receiver to perform security 1021 processing for the message. The mapping to the appropriate 1022 securityModel implementation within an SNMP engine is accomplished in 1023 an implementation-dependent manner. 1025 6.6. msgSecurityParameters 1027 The msgSecurityParameters field of the SNMPv3 Message is used for 1028 communication between the Security Model modules in the sending and 1029 receiving SNMP engines. The data in the msgSecurityParameters field 1030 is used exclusively by the Security Model, and the contents and 1031 format of the data is defined by the Security Model. This OCTET 1032 STRING is not interpreted by the v3MP, but is passed to the local 1033 implementation of the Security Model indicated by the 1034 msgSecurityModel field in the message. 1036 6.7. scopedPduData 1038 The scopedPduData field represents either the plain text scopedPDU if 1039 the privFlag in the msgFlags is zero, or it represents an 1040 encryptedPDU (encoded as an OCTET STRING) which must be decrypted by 1041 the securityModel in use to produce a plaintext scopedPDU. 1043 6.8. scopedPDU 1045 The scopedPDU contains information to identify an administratively 1046 unique context and a PDU. The object identifiers in the PDU refer to 1047 managed objects which are (expected to be) accessible within the 1048 specified context. 1050 6.8.1. contextEngineID 1052 The contextEngineID in the SNMPv3 message, uniquely identifies, 1053 within an administrative domain, an SNMP entity that may realize an 1054 instance of a context with a particular contextName. 1056 For incoming messages, the contextEngineID is used to determine to 1057 which application the scopedPDU will be sent for processing. 1059 For outgoing messages, the v3MP sets the contextEngineID to the value 1060 provided by the application in the request for a message to be sent. 1062 6.8.2. contextName 1064 The contextName field in an SNMPv3 message, in conjunction with the 1065 contextEngineID field, identifies the particular context associated 1066 with the management information contained in the PDU portion of the 1067 message. The contextName is unique within the SNMP entity specified 1068 by the contextEngineID, which may realize the managed objects 1069 referenced within the PDU. An application which originates a message 1070 provides the value for the contextName field and this value may be 1071 used during processing by an application at the receiving SNMP 1072 Engine. 1074 6.8.3. data 1076 The data field of the SNMPv3 Message contains the PDU. Among other 1077 things, the PDU contains the PDU type that is used by the v3MP to 1078 determine the type of the incoming SNMP message. The v3MP specifies 1079 that the PDU must be one of those specified in [RFC1905]. 1081 7. Elements of Procedure for v3MP 1083 This section describes the procedures followed by an SNMP engine when 1084 generating and processing SNMP messages according to the SNMPv3 1085 Message Processing Model. 1087 Please note, that for the sake of clarity and to prevent the text 1088 from being even longer and more complicated, some details were 1089 omitted from the steps below. 1091 a) Some steps specify that when some error conditions are 1092 encountered when processing a received message, a message 1093 containing a Report PDU is generated and the received message 1094 is discarded without further processing. However, a Report-PDU 1095 must not be generated unless the reportableFlag is set in the 1096 received message, or the condition in point 5 d) in section 7.2 1097 (below) applies. 1099 b) The elements of procedure do not always explicitly indicate 1100 when state information needs to be released. The general rule 1101 is that if state information is available when a message is to 1102 be "discarded without further processing", then the state 1103 information must also be released at that same time. 1105 7.1. Prepare an Outgoing SNMP Message 1107 This section describes the procedure followed to prepare an SNMPv3 1108 message from the data elements passed by the Message Dispatcher. 1110 1) The Message Dispatcher may request that an SNMPv3 message 1111 containing a GetRequest-PDU, GetNextRequest-PDU, GetBulkRequest- 1112 PDU, SetRequest-PDU, InformRequest-PDU, or SNMPv2-Trap-PDU be 1113 prepared for sending. 1115 a) It makes such a request according to the abstract service 1116 primitive: 1118 statusInformation = -- success or errorIndication 1119 prepareOutgoingMessage( 1120 IN transportDomain -- requested transport domain 1121 IN transportAddress -- requested destination address 1122 IN messageProcessingModel -- typically, SNMP version 1123 IN securityModel -- Security Model to use 1124 IN securityName -- on behalf of this principal 1125 IN securityLevel -- Level of Security requested 1126 IN contextEngineID -- data from/at this entity 1127 IN contextName -- data from/in this context 1128 IN pduVersion -- version of the PDU 1129 IN PDU -- SNMP Protocol Data Unit 1130 IN expectResponse -- TRUE or FALSE * 1131 IN sendPduHandle -- the handle for matching 1132 -- incoming responses 1133 OUT destTransportDomain -- destination transport domain 1134 OUT destTransportAddress -- destination transport address 1135 OUT outgoingMessage -- the message to send 1136 OUT outgoingMessageLength -- the length of the message 1137 ) 1139 * The SNMPv3 Message Processing Model does not use the values of 1140 expectResponse or pduVersion. 1142 b) A unique msgID is generated. The number used for msgID should 1143 not have been used recently, and must not be the same as was 1144 used for any outstanding request. 1146 2) The Message Dispatcher may request that an SNMPv3 message 1147 containing a Response-PDU or Report-PDU be prepared for sending. 1149 a) It makes such a request according to the abstract service 1150 primitive: 1152 result = -- SUCCESS or FAILURE 1153 prepareResponseMessage( 1154 IN messageProcessingModel -- typically, SNMP version 1155 IN securityModel -- same as on incoming request 1156 IN securityName -- same as on incoming request 1157 IN securityLevel -- same as on incoming request 1158 IN contextEngineID -- data from/at this SNMP entity 1159 IN contextName -- data from/in this context 1160 IN pduVersion -- version of the PDU 1161 IN PDU -- SNMP Protocol Data Unit 1162 IN maxSizeResponseScopedPDU -- maximum size of Response PDU 1163 IN stateReference -- reference to state 1164 -- information presented with 1165 -- the request 1166 IN statusInformation -- success or errorIndication 1167 -- error counter OID and value 1168 -- when errorIndication 1169 OUT destTransportDomain -- destination transport domain 1170 OUT destTransportAddress -- destination transport address 1171 OUT outgoingMessage -- the message to send 1172 OUT outgoingMessageLength -- the length of the message 1173 ) 1175 b) The cached information for the original request is retrieved 1176 via the stateReference, including 1178 - msgID, 1179 - contextEngineID, 1180 - contextName, 1181 - securityModel, 1182 - securityName, 1183 - securityLevel, 1184 - securityStateReference, 1185 - reportableFlag, 1186 - transportDomain, and 1187 - transportAddress. 1189 The SNMPv3 Message Processing Model does not allow cached data 1190 to be overridden, except by error indications as detailed in 1191 (3) below. 1193 3) If statusInformation contains values for an OID/value combination 1194 (potentially also containing a securityLevel value, 1195 contextEngineID value, or contextName value), then 1196 a) If reportableFlag is zero, then the original message is 1197 discarded, and no further processing is done. A result of 1198 FAILURE is returned. SNMPv3 Message Processing is complete. 1200 b) If a PDU is provided, it is the PDU from the original request. 1201 If possible, extract the request-id. 1203 c) A Report PDU is prepared: 1205 1) the varBindList is set to contain the OID and value from the 1206 statusInformation 1208 2) error-status is set to 0 1210 3) error-index is set to 0. 1212 4) request-id is set to the value extracted in step b) 1213 Otherwise, request-id is set to 0 1215 d) The errorIndication in statusInformation may be accompanied by 1216 a securityLevel value, a contextEngineID value, or a 1217 contextName value. 1219 1) If statusInformation contains a value for securityLevel, 1220 then securityLevel is set to that value, otherwise it is set 1221 to noAuthNoPriv. 1223 2) If statusInformation contains a value for contextEngineID, 1224 then contextEngineID is set to that value, otherwise it is 1225 set to the value of this entity's snmpEngineID. 1227 3) If statusInformation contains a value for contextName, then 1228 contextName is set to that value, otherwise it is set to the 1229 default context of "" (zero-length string). 1231 e) PDU is set to refer to the new Report-PDU. The old PDU is 1232 discarded. 1234 f) Processing continues with step 6) below. 1236 4) If contextEngineID is not yet determined, then the contextEngineID 1237 is determined, in an implementation-dependent manner, possibly 1238 using the transportDomain and transportAddress. 1240 5) If the contextName is not yet determined, the contextName is set 1241 to the default context. 1243 6) A scopedPDU is prepared from the contextEngineID, contextName, and 1244 PDU. 1246 7) msgGlobalData is constructed as follows 1248 a) The msgVersion field is set to snmpv3(3). 1250 b) msgID is set as determined in step 1 or 2 above. 1252 c) msgMaxSize is set to an implementation-dependent value. 1254 d) msgFlags are set as follows: 1256 - If securityLevel specifies noAuthNoPriv, then authFlag and 1257 privFlag are both set to zero. 1259 - If securityLevel specifies authNoPriv, then authFlag is set 1260 to one and privFlag is set to zero. 1262 - If securityLevel specifies authPriv, then authFlag is set to 1263 one and privFlag is set to one. 1265 - If the PDU is a Response-PDU, Report-PDU or SNMPv2-Trap-PDU, 1266 then the reportableFlag is set to zero. 1268 - If the PDU is a GetRequest-PDU, GetNextRequest-PDU, 1269 GetBulkRequest-PDU, SetRequest-PDU, or InformRequest-PDU 1270 then the reportableFlag is set to one. 1272 - All other msgFlags bits are set to zero. 1274 e) msgSecurityModel is set to the value of securityModel 1276 8) If the PDU is a Response-PDU or Report-PDU, then 1277 a) The specified Security Model is called to generate the message 1278 according to the primitive: 1280 statusInformation = 1281 generateResponseMsg( 1282 IN messageProcessingModel -- SNMPv3 Message Processing 1283 -- Model 1284 IN globalData -- msgGlobalData from step 7 1285 IN maxMessageSize -- from msgMaxSize (step 7c) 1286 IN securityModel -- as determined in step 7e 1287 IN securityEngineID -- the value of snmpEngineID 1288 IN securityName -- on behalf of this principal 1289 IN securityLevel -- for the outgoing message 1290 IN scopedPDU -- as prepared in step 6) 1291 IN securityStateReference -- as determined in step 2 1292 OUT securityParameters -- filled in by Security Module 1293 OUT wholeMsg -- complete generated message 1294 OUT wholeMsgLength -- length of generated message 1295 ) 1297 If, upon return from the Security Model, the statusInformation 1298 includes an errorIndication, then any cached information about 1299 the outstanding request message is discarded, and an 1300 errorIndication is returned, so it can be returned to the 1301 calling application. SNMPv3 Message Processing is complete. 1303 b) A SUCCESS result is returned. SNMPv3 Message Processing is 1304 complete. 1306 9) If the PDU is a GetRequest-PDU, GetNextRequest-PDU, 1307 GetBulkRequest-PDU, SetRequest-PDU, InformRequest-PDU, or 1308 SNMPv2-Trap-PDU, then 1310 a) If the PDU is an SNMPv2-Trap-PDU, then securityEngineID is set 1311 to the value of this entity's snmpEngineID. 1313 Otherwise, the snmpEngineID of the target entity is determined, 1314 in an implementation-dependent manner, possibly using 1315 transportDomain and transportAddress. The value of 1316 securityEngineID is set to the value of the target entity's 1317 snmpEngineID. 1319 b) The specified Security Model is called to generate the message 1320 according to the primitive: 1322 statusInformation = 1323 generateRequestMsg( 1324 IN messageProcessingModel -- SNMPv3 Message Processing Model 1325 IN globalData -- msgGlobalData, from step 7 1326 IN maxMessageSize -- from msgMaxSize in step 7 c) 1327 IN securityModel -- as provided by caller 1328 IN securityEngineID -- authoritative SNMP entity from 9 a) 1329 IN securityName -- as provided by caller 1330 IN securityLevel -- as provided by caller 1331 IN scopedPDU -- as prepared in step 6 1332 OUT securityParameters -- filled in by Security Module 1333 OUT wholeMsg -- complete generated message 1334 OUT wholeMsgLength -- length of the generated message 1335 ) 1337 If, upon return from the Security Model, the statusInformation 1338 includes an errorIndication, then the message is discarded, and 1339 the errorIndication is returned, so it can be returned to the 1340 calling application, and no further processing is done. 1341 SNMPv3 Message Processing is complete. 1343 c) Information about the outgoing message is cached, and a 1344 stateReference is created (implementation-specific). 1345 Information to be cached includes the values of: 1347 - sendPduHandle 1348 - msgID 1349 - snmpEngineID 1350 - securityModel 1351 - securityName 1352 - securityLevel 1353 - contextEngineID 1354 - contextName 1356 d) A SUCCESS result is returned. SNMPv3 Message Processing is 1357 complete. 1359 7.2. Prepare Data Elements from an Incoming SNMP Message 1361 This section describes the procedure followed to extract data from an 1362 SNMPv3 message, and to prepare the data elements required for further 1363 processing of the message by the Message Dispatcher. 1365 1) The message is passed in from the Message Dispatcher according to 1366 the abstract service primitive: 1368 result = -- SUCCESS or errorIndication 1369 prepareDataElements( 1370 IN transportDomain -- origin transport domain 1371 IN transportAddress -- origin transport address 1372 IN wholeMsg -- as received from the network 1373 IN wholeMsgLength -- as received from the network 1374 OUT messageProcessingModel -- typically, SNMP version 1375 OUT securityModel -- Security Model to use 1376 OUT securityName -- on behalf of this principal 1377 OUT securityLevel -- Level of Security requested 1378 OUT contextEngineID -- data from/at this entity 1379 OUT contextName -- data from/in this context 1380 OUT pduVersion -- version of the PDU 1381 OUT PDU -- SNMP Protocol Data Unit 1382 OUT pduType -- SNMP PDU type 1383 OUT sendPduHandle -- handle for matched request 1384 OUT maxSizeResponseScopedPDU -- maximum size of Response PDU 1385 OUT statusInformation -- success or errorIndication 1386 -- error counter OID and value 1387 -- when errorIndication 1388 OUT stateReference -- reference to state information 1389 -- to be used for a possible 1390 ) -- Response 1392 2) If the received message is not the serialization (according to 1393 the conventions of [RFC1906]) of an SNMPv3Message value, then the 1394 snmpInASNParseErrs counter [RFC1907] is incremented, the message 1395 is discarded without further processing, and a FAILURE result is 1396 returned. SNMPv3 Message Processing is complete. 1398 3) The values for msgVersion, msgID, msgMaxSize, msgFlags, 1399 msgSecurityModel, msgSecurityParameters, and msgData are 1400 extracted from the message. 1402 4) If the value of the msgSecurityModel component does not match a 1403 supported securityModel, then the snmpUnknownSecurityModels 1404 counter is incremented, the message is discarded without further 1405 processing, and a FAILURE result is returned. SNMPv3 Message 1406 Processing is complete. 1408 5) The securityLevel is determined from the authFlag and the 1409 privFlag bits of the msgFlags component as follows: 1411 a) If the authFlag is not set and the privFlag is not set, then 1412 securityLevel is set to noAuthNoPriv. 1414 b) If the authFlag is set and the privFlag is not set, then 1415 securityLevel is set to authNoPriv. 1417 c) If the authFlag is set and the privFlag is set, then 1418 securityLevel is set to authPriv. 1420 d) If the authFlag is not set and privFlag is set, then the 1421 snmpInvalidMsgs counter is incremented, a Report PDU, using 1422 the same securityName as the received message, is generated, 1423 the message is discarded without further processing, and a 1424 FAILURE result is returned. SNMPv3 Message Processing is 1425 complete. 1427 e) Any other bits in the msgFlags are ignored. 1429 6) The security module implementing the Security Model as specified 1430 by the securityModel component is called for authentication and 1431 privacy services. This is done according to the abstract service 1432 primitive: 1434 statusInformation = -- errorIndication or success 1435 -- error counter OID and 1436 -- value if error 1437 processIncomingMsg( 1438 IN messageProcessingModel -- SNMPv3 Message Processing Model 1439 IN maxMessageSize -- of the sending SNMP entity 1440 IN securityParameters -- for the received message 1441 IN securityModel -- for the received message 1442 IN securityLevel -- Level of Security 1443 IN wholeMsg -- as received on the wire 1444 IN wholeMsgLength -- length as received on the wire 1445 OUT securityEngineID -- authoritative SNMP entity 1446 OUT securityName -- identification of the principal 1447 OUT scopedPDU, -- message (plaintext) payload 1448 OUT maxSizeResponseScopedPDU -- maximum size of Response PDU 1449 OUT securityStateReference -- reference to security state 1450 ) -- information, needed for 1451 -- response 1453 If an errorIndication is returned by the security module, then 1455 a) If statusInformation contains values for an OID/value pair, 1456 then a Report PDU is generated. 1458 1) If the scopedPDU has been returned from processIncomingMsg 1459 then determine contextEngineID, contextName, and PDU. 1461 2) Information about the message is cached and a 1462 stateReference is created (implementation-specific). 1463 Information to be cached includes the values of: 1465 msgVersion, 1466 msgID, 1467 securityLevel, 1468 msgFlags, 1469 msgMaxSize, 1470 securityModel, 1471 maxSizeResponseScopedPDU, 1472 securityStateReference 1474 3) Request that a Report-PDU be prepared and sent, according 1475 to the abstract service primitive: 1477 result = -- SUCCESS or FAILURE 1478 returnResponsePdu( 1479 IN messageProcessingModel -- SNMPv3(3) 1480 IN securityModel -- same as on incoming request 1481 IN securityName -- from processIncomingMsg 1482 IN securityLevel -- same as on incoming request 1483 IN contextEngineID -- from step 6 a) 1) 1484 IN contextName -- from step 6 a) 1) 1485 IN pduVersion -- SNMPv2-PDU 1486 IN PDU -- from step 6 a) 1) 1487 IN maxSizeResponseScopedPDU -- from processIncomingMsg 1488 IN stateReference -- from step 6 a) 2) 1489 IN statusInformation -- from processIncomingMsg 1490 ) 1492 b) The incoming message is discarded without further processing, 1493 and a FAILURE result is returned. SNMPv3 Message Processing is 1494 complete. 1496 7) The scopedPDU is parsed to extract the contextEngineID, the 1497 contextName and the PDU. If any parse error occurs, then the 1498 snmpInASNParseErrs counter [RFC1907] is incremented, the security 1499 state information is discarded, the message is discarded without 1500 further processing, and a FAILURE result is returned. SNMPv3 1501 Message Processing is complete. 1503 8) The pduVersion is set to an SNMPv2-PDU. 1505 9) The pduType is determined, in an implementation-dependent manner, 1506 to be: 1508 - a GetRequest-PDU, 1509 - a GetNextRequest-PDU, 1510 - a GetBulkRequest-PDU, 1511 - a SetRequest-PDU, 1512 - an InformRequest-PDU, 1513 - an SNMPv2-Trap-PDU, 1514 - a Response-PDU, or 1515 - a Report-PDU. 1517 10) If the pduType is a Response-PDU or Report-PDU, then 1519 a) The value of the msgID component is used to find the cached 1520 information for a corresponding outstanding Request message. 1521 If no such outstanding Request message is found, then the 1522 security state information is discarded, the message is 1523 discarded without further processing, and a FAILURE result is 1524 returned. SNMPv3 Message Processing is complete. 1526 b) sendPduHandle is retrieved from the cached information. 1528 Otherwise, sendPduHandle is set to , an implementation 1529 defined value. 1531 11) If the pduType is a Report-PDU, then 1533 a) statusInformation is created using the contents of the 1534 Report-PDU, in an implementation-dependent manner. This 1535 statusInformation will be forwarded to the application 1536 associated with the sendPduHandle. 1538 b) Any cached information about the outstanding Request message 1539 message is discarded. 1541 c) The security state information for this incoming message is 1542 discarded. 1544 d) stateReference is set to 1546 e) A SUCCESS result is returned. SNMPv3 Message Processing is 1547 complete. 1549 12) If the pduType is a Response-PDU, then 1551 a) The cached data for the outstanding request, referred to by 1552 stateReference, is retrieved, including 1554 - snmpEngineID 1555 - securityModel 1556 - securityName 1557 - securityLevel 1558 - contextEngineID 1559 - contextName 1561 b) If the values extracted from the incoming message differ from 1562 the cached data, then the security state information is 1563 discarded, any cached information about the outstanding 1564 Request message is discarded, the incoming message is 1565 discarded without further processing, and a FAILURE result is 1566 returned. SNMPv3 Message Processing is complete. 1568 c) Otherwise, any cached information about the outstanding 1569 Request message is discarded, and stateReference is set to 1570 . 1572 d) A SUCCESS result is returned. SNMPv3 Message Processing is 1573 complete. 1575 13) If the pduType is a GetRequest-PDU, GetNextRequest-PDU, 1576 GetBulkRequest-PDU, SetRequest-PDU, or InformRequest-PDU, then 1578 a) If the value of securityEngineID is not equal to the value of 1579 snmpEngineID, then the security state information is 1580 discarded, any cached information about the outstanding 1581 Request message is discarded, the incoming message is 1582 discarded without further processing, and a FAILURE result is 1583 returned. SNMPv3 Message Processing is complete. 1585 b) Information about the message is cached and a stateReference 1586 is created (implementation-specific). Information to be 1587 cached includes the values of: 1589 msgVersion, 1590 msgID, 1591 securityLevel, 1592 msgFlags, 1593 msgMaxSize, 1594 securityModel, 1595 maxSizeResponseScopedPDU, 1596 securityStateReference 1598 c) A SUCCESS result is returned. SNMPv3 Message Processing is 1599 complete. 1601 14) If the pduType is an SNMPv2-Trap-PDU, then A SUCCESS result is 1602 returned. SNMPv3 Message Processing is complete. 1604 8. Intellectual Property 1606 The IETF takes no position regarding the validity or scope of any 1607 intellectual property or other rights that might be claimed to 1608 pertain to the implementation or use of the technology described in 1609 this document or the extent to which any license under such rights 1610 might or might not be available; neither does it represent that it 1611 has made any effort to identify any such rights. Information on the 1612 IETF's procedures with respect to rights in standards-track and 1613 standards-related documentation can be found in BCP-11. Copies of 1614 claims of rights made available for publication and any assurances of 1615 licenses to be made available, or the result of an attempt made to 1616 obtain a general license or permission for the use of such 1617 proprietary rights by implementors or users of this specification can 1618 be obtained from the IETF Secretariat. 1620 The IETF invites any interested party to bring to its attention any 1621 copyrights, patents or patent applications, or other proprietary 1622 rights which may cover technology that may be required to practice 1623 this standard. Please address the information to the IETF Executive 1624 Director. 1626 9. Acknowledgements 1628 This document is the result of the efforts of the SNMPv3 Working 1629 Group. Some special thanks are in order to the following SNMPv3 WG 1630 members: 1632 Dave Battle (SNMP Research, Inc.) 1633 Uri Blumenthal (IBM T.J. Watson Research Center) 1634 Jeff Case (SNMP Research, Inc.) 1635 John Curran (BBN) 1636 T. Max Devlin (Eltrax Systems) 1637 John Flick (Hewlett Packard) 1638 David Harrington (Cabletron Systems Inc.) 1639 N.C. Hien (IBM T.J. Watson Research Center) 1640 Dave Levi (SNMP Research, Inc.) 1641 Louis A. Mamakos (UUNET Technologies Inc.) 1642 Paul Meyer (Secure Computing Corporation) 1643 Keith McCloghrie (Cisco Systems) 1644 Russ Mundy (Trusted Information Systems, Inc.) 1645 Bob Natale (ACE*COMM Corporation) 1646 Mike O'Dell (UUNET Technologies Inc.) 1647 Dave Perkins (DeskTalk) 1648 Peter Polkinghorne (Brunel University) 1649 Randy Presuhn (BMC Software, Inc.) 1650 David Reid (SNMP Research, Inc.) 1651 Aleksey Romanov (Quality Quorum) 1652 Shawn Routhier (Epilogue) 1653 Juergen Schoenwaelder (TU Braunschweig) 1654 Bob Stewart (Cisco Systems) 1655 Bert Wijnen (IBM T.J. Watson Research Center) 1657 The document is based on recommendations of the IETF Security and 1658 Administrative Framework Evolution for SNMP Advisory Team. Members 1659 of that Advisory Team were: 1661 David Harrington (Cabletron Systems Inc.) 1662 Jeff Johnson (Cisco Systems) 1663 David Levi (SNMP Research Inc.) 1664 John Linn (Openvision) 1665 Russ Mundy (Trusted Information Systems) chair 1666 Shawn Routhier (Epilogue) 1667 Glenn Waters (Nortel) 1668 Bert Wijnen (IBM T. J. Watson Research Center) 1670 As recommended by the Advisory Team and the SNMPv3 Working Group 1671 Charter, the design incorporates as much as practical from previous 1672 RFCs and drafts. As a result, special thanks are due to the authors 1673 of previous designs known as SNMPv2u and SNMPv2*: 1675 Jeff Case (SNMP Research, Inc.) 1676 David Harrington (Cabletron Systems Inc.) 1677 David Levi (SNMP Research, Inc.) 1678 Keith McCloghrie (Cisco Systems) 1679 Brian O'Keefe (Hewlett Packard) 1680 Marshall T. Rose (Dover Beach Consulting) 1681 Jon Saperia (BGS Systems Inc.) 1682 Steve Waldbusser (International Network Services) 1683 Glenn W. Waters (Bell-Northern Research Ltd.) 1685 10. Security Considerations 1687 The Dispatcher coordinates the processing of messages to provide a 1688 level of security for management messages and to direct the SNMP PDUs 1689 to the proper SNMP application(s). 1691 A Message Processing Model, and in particular the V3MP defined in 1692 this document, interacts as part of the Message Processing with 1693 Security Models in the Security Subsystem via the abstract service 1694 interface primitives defined in [SNMP-ARCH] and elaborated above. 1696 The level of security actually provided is primarily determined by 1697 the specific Security Model implementation(s) and the specific SNMP 1698 application implementation(s) incorporated into this framework. 1699 Applications have access to data which is not secured. Applications 1700 should take reasonable steps to protect the data from disclosure, and 1701 when they send data across the network, they should obey the 1702 securityLevel and call upon the services of an Access Control Model 1703 as they apply access control. 1705 The values for the msgID element used in communication between SNMP 1706 entities must be chosen to avoid replay attacks. The values do not 1707 need to be unpredictable; it is sufficient that they not repeat. 1709 11. References 1711 [RFC1901] The SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, 1712 M. and S. Waldbusser, "Introduction to Community-based SNMPv2", 1713 RFC 1901, January 1996. 1715 [RFC1902] The SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, 1716 M. and S. Waldbusser, "Structure of Management Information for 1717 Version 2 of the Simple Network Management Protocol (SNMPv2)", 1718 RFC 1902, January 1996. 1720 [RFC1905] The SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, 1721 M. and S. Waldbusser, "Protocol Operations for Version 2 of the 1722 Simple Network Management Protocol (SNMPv2)", RFC 1905, January 1723 1996. 1725 [RFC1906] The SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, 1726 M. and S. Waldbusser, "Transport Mappings for Version 2 of the 1727 Simple Network Management Protocol (SNMPv2)", RFC 1906, January 1728 1996. 1730 [RFC1907] The SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, 1731 M. and S. Waldbusser, "Management Information Base for Version 2 1732 of the Simple Network Management Protocol (SNMPv2)", RFC 1907 1733 January 1996. 1735 [RFC1908] The SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, 1736 M. and S. Waldbusser, "Coexistence between Version 1 and Version 2 1737 of the Internet-standard Network Management Framework", RFC 1908, 1738 January 1996. 1740 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1741 Requirement Levels", RFC 2119, BCP 14, March 1997. 1743 [RFC2028] Hovey, R. and S. Bradner, "The Organizations Involved in 1744 the IETF Standards Process", BCP 11, RFC 2028, October 1996. 1746 [SNMP-ARCH] Harrington, D., Presuhn, R. and B. Wijnen, "An 1747 Architecture for describing SNMP Management Frameworks", , August 1998. 1750 [SNMP-USM] Blumenthal, U. and B. Wijnen, "The User-Based Security 1751 Model for Version 3 of the Simple Network Management Protocol 1752 (SNMPv3)", , August 1998. 1754 [SNMP-ACM] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based 1755 Access Control Model for the Simple Network Management Protocol 1756 (SNMP)", , August 1998. 1758 [SNMP-APPL] Levi, D. B., Meyer, P. and B. Stewart, "SNMPv3 1759 Applications", , November 1997. 1761 [SNMP-INTRO] Case, J., Mundy, R., Partain, D. and B. Stewart, 1762 "Introduction to Version 3 of the Internet-standard Network 1763 Management Framework", draft-ietf-snmpv3-intro-01.txt, August 1764 1998. 1766 12. Editors' Addresses 1768 Jeffrey Case 1769 SNMP Research, Inc. 1770 3001 Kimberlin Heights Road 1771 Knoxville, TN 37920-9716 1772 USA 1774 Phone: +1 423-573-1434 1775 EMail: case@snmp.com 1777 Dave Harrington 1778 Cabletron Systems, Inc 1779 Post Office Box 5005 1780 Mail Stop: Durham 1781 35 Industrial Way 1782 Rochester, NH 03867-5005 1783 USA 1785 Phone: +1 603-337-7357 1786 EMail: dbh@ctron.com 1787 Randy Presuhn 1788 BMC Software, Inc. 1789 965 Stewart Drive 1790 Sunnyvale, CA 94086 1791 USA 1793 Phone: +1 408-616-3100 1794 EMail: randy_presuhn@bmc.com 1796 Bert Wijnen 1797 IBM T. J. Watson Research 1798 Schagen 33 1799 3461 GL Linschoten 1800 Netherlands 1802 Phone: +31 348-432-794 1803 EMail: wijnen@vnet.ibm.com 1805 APPENDIX A 1807 A. Issues 1809 This section will be deleted in the transition from internet-draft to 1810 RFC. 1812 A.1. Open Issues 1814 The following issues have been discussed on the working group mailing 1815 list, and the document editors have not been able to figure out what 1816 changes to make, if any: 1818 - New PDU types can cause different error reactions, e.g. sending 1819 an snmpUnknownPDUHandlers report or just incrementing the ASN.1 1820 parse error counter. To allow smooth deployment, text needs to 1821 be added how to recognize PDU types and a report should be sent 1822 if a received PDU type is unknown. 1824 - The acknowledgement list is in need of update. 1826 A.2. Change Log 1828 The following change log records major changes from the previous 1829 internet draft. 1831 - Updated contact information for editors. 1833 Made parameter identification in prepareResponseMsg() 1834 consistent, both internally and with architecture. 1836 - Made references to processIncomingMsg() consistent, both 1837 internally and with architecture. 1839 - Deleted superfluous expectResponse parameter from 1840 processIncomingMsg(), consistent with architecture. 1842 - Fixed typos. 1844 - Removed sending of a report PDU from step 4 on page 30 on RFC 1845 2272. (Technical change, editor believes there was WG 1846 agreement.) 1848 - The document directly refers to RFC 1905 PDU types which binds 1849 the version 3 message model to RFC 1905. The text should 1850 instead use "PDU classes" so that additional PDU types can be 1851 added over time without having to change the message processing 1852 model. Resolved: the binding of MPD to USM was a conscious 1853 decision. 1855 - Added intro document to references. 1857 - What security name is used for sending reports when the auth 1858 flag is not set but the priv flag is set? (7.2.5, similar 1859 questions for 7.2.6) Resolved by using securityName from 1860 incoming message. 1862 - What action is taken upon receipt of illegal combinations of 1863 the msgFlags bits? What action is taken if the "reserved" bits 1864 are non-zero upon receipt? Resolved by adding text saying 1865 reserved are ignored; text specifies handling of illegal 1866 combination. 1868 - The purpose of Report PDUs (engine-to-engine communications) 1869 might be made clearer. What text (if any) should be added 1870 explaining what actions (if any) are taken upon receipt of a 1871 report PDU? Issue resolved by adding text. 1873 - Various possible points of clarifications, especially the ones 1874 raised by Martin Bjorklund and others on the mailing list. 1876 - The more precise specification of the handling of the 1877 reportableFlag begs the question of what an engine is supposed 1878 to do when it receives a message with an illegal combination of 1879 the reportableFlag and PDU type. Issue resolved; all cases 1880 covered in text. 1882 B. Full Copyright Statement 1884 Copyright (C) The Internet Society (1998). All Rights Reserved. 1886 This document and translations of it may be copied and furnished to 1887 others, and derivative works that comment on or otherwise explain it 1888 or assist in its implementation may be prepared, copied, published 1889 and distributed, in whole or in part, without restriction of any 1890 kind, provided that the above copyright notice and this paragraph are 1891 included on all such copies and derivative works. However, this 1892 document itself may not be modified in any way, such as by removing 1893 the copyright notice or references to the Internet Society or other 1894 Internet organizations, except as needed for the purpose of 1895 developing Internet standards in which case the procedures for 1896 copyrights defined in the Internet Standards process must be 1897 followed, or as required to translate it into languages other than 1898 English. 1900 The limited permissions granted above are perpetual and will not be 1901 revoked by the Internet Society or its successors or assigns. 1903 This document and the information contained herein is provided on an 1904 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1905 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1906 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1907 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1908 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.