idnits 2.17.1 draft-ietf-snmpv3-mpc-00.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. ** 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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- 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 (7 August 1998) is 9391 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 1696, but no explicit reference was found in the text == Unused Reference: 'RFC1908' is defined on line 1716, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 1721, but no explicit reference was found in the text == Unused Reference: 'RFC 2028' is defined on line 1724, but no explicit reference was found in the text == Unused Reference: 'SNMP-USM' is defined on line 1731, but no explicit reference was found in the text == Unused Reference: 'SNMP-ACM' is defined on line 1736, but no explicit reference was found in the text == Unused Reference: 'SNMP-APPL' is defined on line 1741, 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' Summary: 16 errors (**), 0 flaws (~~), 11 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 7 August 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 .......................................... 23 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 ............................................. 24 82 6.8.3. data .................................................... 25 83 7. Elements of Procedure for v3MP .............................. 25 84 7.1. Prepare an Outgoing SNMP Message .......................... 25 85 7.2. Prepare Data Elements from an Incoming SNMP Message ....... 31 86 8. Intellectual Property ....................................... 36 87 9. Acknowledgements ............................................ 37 88 10. Security Considerations .................................... 38 89 11. References ................................................. 39 90 12. Editors' Addresses ......................................... 40 91 13. Issues ..................................................... 41 92 13.1. Open Issues .............................................. 41 93 13.2. Change Log ............................................... 42 94 14. Full Copyright Statement ................................... 42 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. 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 Note that the reportableFlag is a secondary aid in determining 936 whether a Report PDU must be sent. It is only used in cases where 937 the PDU portion of a message cannot be decoded, due to, for example, 938 an incorrect ecryption key. If the PDU can be decoded, the PDU type 939 forms the basis for decisions on sending Report PDUs. 941 The authFlag and privFlag portions of the msgFlags field are set by 942 the sender to indicate the securityLevel that was applied to the 943 message before it was sent on the wire. The receiver of the message 944 must apply the same securityLevel when the message is received and 945 the contents are being processed. 947 There are three securityLevels, namely noAuthNoPriv, which is less 948 than authNoPriv, which is in turn less than authPriv. See the SNMP 949 architecture document [SNMP-ARCH] for details about the 950 securityLevel. 952 a) authFlag 954 If the authFlag is set to one, then the securityModel used by the 955 SNMP engine which sent the message must identify the securityName 956 on whose behalf the SNMP message was generated and must provide, 957 in a securityModel-specific manner, sufficient data for the 958 receiver of the message to be able to authenticate that 959 identification. In general, this authentication will allow the 960 receiver to determine with reasonable certainty that the message 961 was: 963 - sent on behalf of the principal associated with the 964 securityName, 966 - was not redirected, 968 - was not modified in transit, and 970 - was not replayed. 972 If the authFlag is zero, then the securityModel used by the SNMP 973 engine which sent the message must identify the securityName on 974 whose behalf the SNMP message was generated but it does not need 975 to provide sufficient data for the receiver of the message to 976 authenticate the identification, as there is no need to 977 authenticate the message in this case. 979 b) privFlag 981 If the privFlag is set, then the securityModel used by the SNMP 982 engine which sent the message must also protect the scopedPDU in 983 an SNMP message from disclosure, i.e., must encrypt/decrypt the 984 scopedPDU. If the privFlag is zero, then the securityModel in use 985 does not need to protect the data from disclosure. 987 It is an explicit requirement of the SNMP architecture that if 988 privacy is selected, then authentication is also required. That 989 means that if the privFlag is set, then the authFlag must also be 990 set to one. 992 The combination of the authFlag and the privFlag comprises a Level 993 of Security as follows: 994 authFlag zero, privFlag zero -> securityLevel is noAuthNoPriv 995 authFlag zero, privFlag one -> invalid combination 996 authFlag one, privFlag zero -> securityLevel is authNoPriv 997 authFlag one, privFlag one -> securityLevel is authPriv 999 6.5. msgSecurityModel 1001 The v3MP supports the concurrent existence of multiple Security 1002 Models to provide security services for SNMPv3 messages. The 1003 msgSecurityModel field in an SNMPv3 Message identifies which Security 1004 Model was used by the sender to generate the message and therefore 1005 which securityModel must be used by the receiver to perform security 1006 processing for the message. The mapping to the appropriate 1007 securityModel implementation within an SNMP engine is accomplished in 1008 an implementation-dependent manner. 1010 6.6. msgSecurityParameters 1012 The msgSecurityParameters field of the SNMPv3 Message is used for 1013 communication between the Security Model modules in the sending and 1014 receiving SNMP engines. The data in the msgSecurityParameters field 1015 is used exclusively by the Security Model, and the contents and 1016 format of the data is defined by the Security Model. This OCTET 1017 STRING is not interpreted by the v3MP, but is passed to the local 1018 implementation of the Security Model indicated by the 1019 msgSecurityModel field in the message. 1021 6.7. scopedPduData 1023 The scopedPduData field represents either the plain text scopedPDU if 1024 the privFlag in the msgFlags is zero, or it represents an 1025 encryptedPDU (encoded as an OCTET STRING) which must be decrypted by 1026 the securityModel in use to produce a plaintext scopedPDU. 1028 6.8. scopedPDU 1030 The scopedPDU contains information to identify an administratively 1031 unique context and a PDU. The object identifiers in the PDU refer to 1032 managed objects which are (expected to be) accessible within the 1033 specified context. 1035 6.8.1. contextEngineID 1037 The contextEngineID in the SNMPv3 message, uniquely identifies, 1038 within an administrative domain, an SNMP entity that may realize an 1039 instance of a context with a particular contextName. 1041 For incoming messages, the contextEngineID is used to determine to 1042 which application the scopedPDU will be sent for processing. 1044 For outgoing messages, the v3MP sets the contextEngineID to the value 1045 provided by the application in the request for a message to be sent. 1047 6.8.2. contextName 1049 The contextName field in an SNMPv3 message, in conjunction with the 1050 contextEngineID field, identifies the particular context associated 1051 with the management information contained in the PDU portion of the 1052 message. The contextName is unique within the SNMP entity specified 1053 by the contextEngineID, which may realize the managed objects 1054 referenced within the PDU. An application which originates a message 1055 provides the value for the contextName field and this value may be 1056 used during processing by an application at the receiving SNMP 1057 Engine. 1059 6.8.3. data 1061 The data field of the SNMPv3 Message contains the PDU. Among other 1062 things, the PDU contains the PDU type that is used by the v3MP to 1063 determine the type of the incoming SNMP message. The v3MP specifies 1064 that the PDU must be one of those specified in [RFC1905]. 1066 7. Elements of Procedure for v3MP 1068 This section describes the procedures followed by an SNMP engine when 1069 generating and processing SNMP messages according to the SNMPv3 1070 Message Processing Model. 1072 Please note, that for the sake of clarity and to prevent the text 1073 from being even longer and more complicated, some details were 1074 omitted from the steps below. 1076 a) Some steps specify that when some error conditions are 1077 encountered when processing a received message, a message 1078 containing a Report PDU is generated and the received message 1079 is discarded without further processing. However, a Report-PDU 1080 must not be generated unless the reportableFlag is set in the 1081 received message. 1083 b) The elements of procedure do not always explicitly indicate 1084 when state information needs to be released. The general rule 1085 is that if state information is available when a message is to 1086 be "discarded without further processing", then the state 1087 information must also be released at that same time. 1089 7.1. Prepare an Outgoing SNMP Message 1091 This section describes the procedure followed to prepare an SNMPv3 1092 message from the data elements passed by the Message Dispatcher. 1094 1) The Message Dispatcher may request that an SNMPv3 message 1095 containing a GetRequest-PDU, GetNextRequest-PDU, GetBulkRequest- 1096 PDU, SetRequest-PDU, InformRequest-PDU, or SNMPv2-Trap-PDU be 1097 prepared for sending. 1099 a) It makes such a request according to the abstract service 1100 primitive: 1102 statusInformation = -- success or errorIndication 1103 prepareOutgoingMessage( 1104 IN transportDomain -- requested transport domain 1105 IN transportAddress -- requested destination address 1106 IN messageProcessingModel -- typically, SNMP version 1107 IN securityModel -- Security Model to use 1108 IN securityName -- on behalf of this principal 1109 IN securityLevel -- Level of Security requested 1110 IN contextEngineID -- data from/at this entity 1111 IN contextName -- data from/in this context 1112 IN pduVersion -- version of the PDU 1113 IN PDU -- SNMP Protocol Data Unit 1114 IN expectResponse -- TRUE or FALSE 1115 IN sendPduHandle -- the handle for matching 1116 -- incoming responses 1117 OUT destTransportDomain -- destination transport domain 1118 OUT destTransportAddress -- destination transport address 1119 OUT outgoingMessage -- the message to send 1120 OUT outgoingMessageLength -- the length of the message 1121 ) 1123 b) A unique msgID is generated. The number used for msgID should 1124 not have been used recently, and must not be the same as was 1125 used for any outstanding request. 1127 * SNMPv3 does not use the values of expectResponse or 1128 pduVersion. 1130 2) The Message Dispatcher may request that an SNMPv3 message 1131 containing a Response-PDU or Report-PDU be prepared for sending. 1133 a) It makes such a request according to the abstract service 1134 primitive: 1136 result = -- SUCCESS or FAILURE 1137 prepareResponseMessage( 1138 IN messageProcessingModel -- typically, SNMP version 1139 IN securityModel -- same as on incoming request 1140 IN securityName -- same as on incoming request 1141 IN securityLevel -- same as on incoming request 1142 IN contextEngineID -- data from/at this SNMP entity 1143 IN contextName -- data from/in this context 1144 IN pduVersion -- version of the PDU 1145 IN PDU -- SNMP Protocol Data Unit 1146 IN maxSizeResponseScopedPDU -- maximum size of Response PDU 1147 IN stateReference -- reference to state 1148 -- information presented with 1149 -- the request 1150 IN statusInformation -- success or errorIndication 1151 -- error counter OID and value 1152 -- when errorIndication 1153 OUT destTransportDomain -- destination transport domain 1154 OUT destTransportAddress -- destination transport address 1155 OUT outgoingMessage -- the message to send 1156 OUT outgoingMessageLength -- the length of the message 1157 ) 1159 b) The cached information for the original request is retrieved 1160 via the stateReference, including 1162 - msgID, 1163 - contextEngineID, 1164 - contextName, 1165 - securityModel, 1166 - securityName, 1167 - securityLevel, 1168 - securityStateReference, 1169 - reportableFlag, 1170 - transportDomain, and 1171 - transportAddress. 1173 The SNMPv3 Message Processing Model does not allow cached data 1174 to be overridden, except by error indications as detailed in 1175 (3) below. 1177 3) If statusInformation contains values for an OID/value combination 1178 (potentially also containing a securityLevel value, 1179 contextEngineID value, or contextName value), then 1180 a) If reportableFlag is zero, then the original message is 1181 discarded, and no further processing is done. A result of 1182 FAILURE is returned. SNMPv3 Message Processing is complete. 1184 b) If a PDU is provided, it is the PDU from the original request. 1185 If possible, extract the request-id. 1187 c) A Report PDU is prepared: 1189 1) the varBindList is set to contain the OID and value from the 1190 statusInformation 1192 2) error-status is set to 0 1194 3) error-index is set to 0. 1196 4) request-id is set to the value extracted in step b) 1197 Otherwise, request-id is set to 0 1199 d) The errorIndication in statusInformation may be accompanied by 1200 a securityLevel value, a contextEngineID value, or a 1201 contextName value. 1203 1) If statusInformation contains a value for securityLevel, 1204 then securityLevel is set to that value, otherwise it is set 1205 to noAuthNoPriv. 1207 2) If statusInformation contains a value for contextEngineID, 1208 then contextEngineID is set to that value, otherwise it is 1209 set to the value of this entity's snmpEngineID. 1211 3) If statusInformation contains a value for contextName, then 1212 contextName is set to that value, otherwise it is set to the 1213 default context of "" (zero-length string). 1215 e) PDU is set to refer to the new Report-PDU. The old PDU is 1216 discarded. 1218 f) Processing continues with step 6) below. 1220 4) If contextEngineID is not yet determined, then the contextEngineID 1221 is determined, in an implementation-dependent manner, possibly 1222 using the transportDomain and transportAddress. 1224 5) If the contextName is not yet determined, the contextName is set 1225 to the default context. 1227 6) A scopedPDU is prepared from the contextEngineID, contextName, and 1228 PDU. 1230 7) msgGlobalData is constructed as follows 1232 a) The msgVersion field is set to snmpv3(3). 1234 b) msgID is set as determined in step 1 or 2 above. 1236 c) msgMaxSize is set to an implementation-dependent value. 1238 d) msgFlags are set as follows: 1240 - If securityLevel specifies noAuthNoPriv, then authFlag and 1241 privFlag are both set to zero. 1243 - If securityLevel specifies authNoPriv, then authFlag is set 1244 to one and privFlag is set to zero. 1246 - If securityLevel specifies authPriv, then authFlag is set to 1247 one and privFlag is set to one. 1249 - If the PDU is a Response-PDU, Report-PDU or SNMPv2-Trap-PDU, 1250 then the reportableFlag is set to zero. 1252 - If the PDU is a GetRequest-PDU, GetNextRequest-PDU, 1253 GetBulkRequest-PDU, SetRequest-PDU, or InformRequest-PDU 1254 then the reportableFlag is set to one. 1256 - All other msgFlags bits are set to zero. 1258 e) msgSecurityModel is set to the value of securityModel 1260 8) If the PDU is a Response-PDU or Report-PDU, then 1261 a) The specified Security Model is called to generate the message 1262 according to the primitive: 1264 statusInformation = 1265 generateResponseMsg( 1266 IN messageProcessingModel -- SNMPv3 Message Processing 1267 -- Model 1268 IN globalData -- msgGlobalData from step 7 1269 IN maxMessageSize -- from msgMaxSize (step 7c) 1270 IN securityModel -- as determined in step 7e 1271 IN securityEngineID -- the value of snmpEngineID 1272 IN securityName -- on behalf of this principal 1273 IN securityLevel -- for the outgoing message 1274 IN scopedPDU -- as prepared in step 6) 1275 IN securityStateReference -- as determined in step 2 1276 OUT securityParameters -- filled in by Security Module 1277 OUT wholeMsg -- complete generated message 1278 OUT wholeMsgLength -- length of generated message 1279 ) 1281 If, upon return from the Security Model, the statusInformation 1282 includes an errorIndication, then any cached information about 1283 the outstanding request message is discarded, and an 1284 errorIndication is returned, so it can be returned to the 1285 calling application. SNMPv3 Message Processing is complete. 1287 b) A SUCCESS result is returned. SNMPv3 Message Processing is 1288 complete. 1290 9) If the PDU is a GetRequest-PDU, GetNextRequest-PDU, 1291 GetBulkRequest-PDU, SetRequest-PDU, InformRequest-PDU, or 1292 SNMPv2-Trap-PDU, then 1294 a) If the PDU is an SNMPv2-Trap-PDU, then securityEngineID is set 1295 to the value of this entity's snmpEngineID. 1297 Otherwise, the snmpEngineID of the target entity is determined, 1298 in an implementation-dependent manner, possibly using 1299 transportDomain and transportAddress. The value of 1300 securityEngineID is set to the value of the target entity's 1301 snmpEngineID. 1303 b) The specified Security Model is called to generate the message 1304 according to the primitive: 1306 statusInformation = 1307 generateRequestMsg( 1308 IN messageProcessingModel -- SNMPv3 Message Processing Model 1309 IN globalData -- msgGlobalData, from step 7 1310 IN maxMessageSize -- from msgMaxSize in step 7 c) 1311 IN securityModel -- as provided by caller 1312 IN securityEngineID -- authoritative SNMP entity 1313 IN securityName -- as provided by caller 1314 IN securityLevel -- as provided by caller 1315 IN snmpEngineID -- as determined in step 9 a) 1316 IN scopedPDU -- as prepared in step 6 1317 OUT securityParameters -- filled in by Security Module 1318 OUT wholeMsg -- complete generated message 1319 OUT wholeMsgLength -- length of the generated message 1320 ) 1322 If, upon return from the Security Model, the statusInformation 1323 includes an errorIndication, then the message is discarded, and 1324 the errorIndication is returned, so it can be returned to the 1325 calling application, and no further processing is done. 1326 SNMPv3 Message Processing is complete. 1328 c) Information about the outgoing message is cached, and a 1329 stateReference is created (implementation-specific). 1330 Information to be cached includes the values of: 1332 - sendPduHandle 1333 - msgID 1334 - snmpEngineID 1335 - securityModel 1336 - securityName 1337 - securityLevel 1338 - contextEngineID 1339 - contextName 1341 d) A SUCCESS result is returned. SNMPv3 Message Processing is 1342 complete. 1344 7.2. Prepare Data Elements from an Incoming SNMP Message 1346 This section describes the procedure followed to extract data from an 1347 SNMPv3 message, and to prepare the data elements required for further 1348 processing of the message by the Message Dispatcher. 1350 1) The message is passed in from the Message Dispatcher according to 1351 the abstract service primitive: 1353 result = -- SUCCESS or errorIndication 1354 prepareDataElements( 1355 IN transportDomain -- origin transport domain 1356 IN transportAddress -- origin transport address 1357 IN wholeMsg -- as received from the network 1358 IN wholeMsgLength -- as received from the network 1359 OUT messageProcessingModel -- typically, SNMP version 1360 OUT securityModel -- Security Model to use 1361 OUT securityName -- on behalf of this principal 1362 OUT securityLevel -- Level of Security requested 1363 OUT contextEngineID -- data from/at this entity 1364 OUT contextName -- data from/in this context 1365 OUT pduVersion -- version of the PDU 1366 OUT PDU -- SNMP Protocol Data Unit 1367 OUT pduType -- SNMP PDU type 1368 OUT sendPduHandle -- handle for matched request 1369 OUT maxSizeResponseScopedPDU -- maximum size of Response PDU 1370 OUT statusInformation -- success or errorIndication 1371 -- error counter OID and value 1372 -- when errorIndication 1373 OUT stateReference -- reference to state information 1374 -- to be used for a possible 1375 ) -- Response 1377 2) If the received message is not the serialization (according to 1378 the conventions of [RFC1906]) of an SNMPv3Message value, then the 1379 snmpInASNParseErrs counter [RFC1907] is incremented, the message 1380 is discarded without further processing, and a FAILURE result is 1381 returned. SNMPv3 Message Processing is complete. 1383 3) The values for msgVersion, msgID, msgMaxSize, msgFlags, 1384 msgSecurityModel, msgSecurityParameters, and msgData are 1385 extracted from the message. 1387 4) If the value of the msgSecurityModel component does not match a 1388 supported securityModel, then the snmpUnknownSecurityModels 1389 counter is incremented, the message is discarded without further 1390 processing, and a FAILURE result is returned. SNMPv3 Message 1391 Processing is complete. 1393 5) The securityLevel is determined from the authFlag and the 1394 privFlag bits of the msgFlags component as follows: 1396 a) If the authFlag is not set and the privFlag is not set, then 1397 securityLevel is set to noAuthNoPriv. 1399 b) If the authFlag is set and the privFlag is not set, then 1400 securityLevel is set to authNoPriv. 1402 c) If the authFlag is set and the privFlag is set, then 1403 securityLevel is set to authPriv. 1405 d) If the authFlag is not set and privFlag is set, then the 1406 snmpInvalidMsgs counter is incremented, a Report PDU is 1407 generated, the message is discarded without further 1408 processing, and a FAILURE result is returned. SNMPv3 Message 1409 Processing is complete. 1411 6) The security module implementing the Security Model as specified 1412 by the securityModel component is called for authentication and 1413 privacy services. This is done according to the abstract service 1414 primitive: 1416 statusInformation = -- errorIndication or success 1417 -- error counter OID and 1418 -- value if error 1419 processIncomingMsg( 1420 IN messageProcessingModel -- SNMPv3 Message Processing Model 1421 IN maxMessageSize -- of the sending SNMP entity 1422 IN securityParameters -- for the received message 1423 IN securityModel -- for the received message 1424 IN securityLevel -- Level of Security 1425 IN wholeMsg -- as received on the wire 1426 IN wholeMsgLength -- length as received on the wire 1427 OUT securityEngineID -- authoritative SNMP entity 1428 OUT securityName -- identification of the principal 1429 OUT scopedPDU, -- message (plaintext) payload 1430 OUT maxSizeResponseScopedPDU -- maximum size of Response PDU 1431 OUT securityStateReference -- reference to security state 1432 ) -- information, needed for 1433 -- response 1435 If an errorIndication is returned by the security module, then 1437 a) If statusInformation contains values for an OID/value pair, 1438 then a Report PDU is generated. 1440 1) If the scopedPDU has been returned from processIncomingMsg 1441 then determine contextEngineID, contextName, and PDU. 1443 2) Information about the message is cached and a 1444 stateReference is created (implementation-specific). 1445 Information to be cached includes the values of: 1447 msgVersion, 1448 msgID, 1449 securityLevel, 1450 msgFlags, 1451 msgMaxSize, 1452 securityModel, 1453 maxSizeResponseScopedPDU, 1454 securityStateReference 1456 3) Request that a Report-PDU be prepared and sent, according 1457 to the abstract service primitive: 1459 result = -- SUCCESS or FAILURE 1460 returnResponsePdu( 1461 IN messageProcessingModel -- SNMPv3(3) 1462 IN securityModel -- same as on incoming request 1463 IN securityName -- from processIncomingMsg 1464 IN securityLevel -- same as on incoming request 1465 IN contextEngineID -- from step 6 a) 1) 1466 IN contextName -- from step 6 a) 1) 1467 IN pduVersion -- SNMPv2-PDU 1468 IN PDU -- from step 6 a) 1) 1469 IN maxSizeResponseScopedPDU -- from processIncomingMsg 1470 IN stateReference -- from step 6 a) 2) 1471 IN statusInformation -- from processIncomingMsg 1472 ) 1474 b) The incoming message is discarded without further processing, 1475 and a FAILURE result is returned. SNMPv3 Message Processing is 1476 complete. 1478 7) The scopedPDU is parsed to extract the contextEngineID, the 1479 contextName and the PDU. If any parse error occurs, then the 1480 snmpInASNParseErrs counter [RFC1907] is incremented, the security 1481 state information is discarded, the message is discarded without 1482 further processing, and a FAILURE result is returned. SNMPv3 1483 Message Processing is complete. 1485 8) The pduVersion is set to an SNMPv2-PDU. 1487 9) The pduType is determined, in an implementation-dependent manner, 1488 to be: 1490 - a GetRequest-PDU, 1491 - a GetNextRequest-PDU, 1492 - a GetBulkRequest-PDU, 1493 - a SetRequest-PDU, 1494 - an InformRequest-PDU, 1495 - an SNMPv2-Trap-PDU, 1496 - a Response-PDU, or 1497 - a Report-PDU. 1499 10) If the pduType is a Response-PDU or Report-PDU, then 1501 a) The value of the msgID component is used to find the cached 1502 information for a corresponding outstanding Request message. 1503 If no such outstanding Request message is found, then the 1504 security state information is discarded, the message is 1505 discarded without further processing, and a FAILURE result is 1506 returned. SNMPv3 Message Processing is complete. 1508 b) sendPduHandle is retrieved from the cached information. 1510 Otherwise, sendPduHandle is set to , an implementation 1511 defined value. 1513 11) If the pduType is a Report-PDU, then 1515 a) statusInformation is created using the contents of the 1516 Report-PDU, in an implementation-dependent manner. This 1517 statusInformation will be forwarded to the application 1518 associated with the sendPduHandle. 1520 b) Any cached information about the outstanding Request message 1521 message is discarded. 1523 c) The security state information for this incoming message is 1524 discarded. 1526 d) stateReference is set to 1528 e) A SUCCESS result is returned. SNMPv3 Message Processing is 1529 complete. 1531 12) If the pduType is a Response-PDU, then 1533 a) The cached data for the outstanding request, referred to by 1534 stateReference, is retrieved, including 1536 - snmpEngineID 1537 - securityModel 1538 - securityName 1539 - securityLevel 1540 - contextEngineID 1541 - contextName 1543 b) If the values extracted from the incoming message differ from 1544 the cached data, then the security state information is 1545 discarded, any cached information about the outstanding 1546 Request message is discarded, the incoming message is 1547 discarded without further processing, and a FAILURE result is 1548 returned. SNMPv3 Message Processing is complete. 1550 c) Otherwise, any cached information about the outstanding 1551 Request message is discarded, and stateReference is set to 1552 . 1554 d) A SUCCESS result is returned. SNMPv3 Message Processing is 1555 complete. 1557 13) If the pduType is a GetRequest-PDU, GetNextRequest-PDU, 1558 GetBulkRequest-PDU, SetRequest-PDU, or InformRequest-PDU, then 1560 a) If the value of securityEngineID is not equal to the value of 1561 snmpEngineID, then the security state information is 1562 discarded, any cached information about the outstanding 1563 Request message is discarded, the incoming message is 1564 discarded without further processing, and a FAILURE result is 1565 returned. SNMPv3 Message Processing is complete. 1567 b) Information about the message is cached and a stateReference 1568 is created (implementation-specific). Information to be 1569 cached includes the values of: 1571 msgVersion, 1572 msgID, 1573 securityLevel, 1574 msgFlags, 1575 msgMaxSize, 1576 securityModel, 1577 maxSizeResponseScopedPDU, 1578 securityStateReference 1580 c) A SUCCESS result is returned. SNMPv3 Message Processing is 1581 complete. 1583 14) If the pduType is an SNMPv2-Trap-PDU, then A SUCCESS result is 1584 returned. SNMPv3 Message Processing is complete. 1586 8. Intellectual Property 1588 The IETF takes no position regarding the validity or scope of any 1589 intellectual property or other rights that might be claimed to 1590 pertain to the implementation or use of the technology described in 1591 this document or the extent to which any license under such rights 1592 might or might not be available; neither does it represent that it 1593 has made any effort to identify any such rights. Information on the 1594 IETF's procedures with respect to rights in standards-track and 1595 standards-related documentation can be found in BCP-11. Copies of 1596 claims of rights made available for publication and any assurances of 1597 licenses to be made available, or the result of an attempt made to 1598 obtain a general license or permission for the use of such 1599 proprietary rights by implementors or users of this specification can 1600 be obtained from the IETF Secretariat. 1602 The IETF invites any interested party to bring to its attention any 1603 copyrights, patents or patent applications, or other proprietary 1604 rights which may cover technology that may be required to practice 1605 this standard. Please address the information to the IETF Executive 1606 Director. 1608 9. Acknowledgements 1610 This document is the result of the efforts of the SNMPv3 Working 1611 Group. Some special thanks are in order to the following SNMPv3 WG 1612 members: 1614 Dave Battle (SNMP Research, Inc.) 1615 Uri Blumenthal (IBM T.J. Watson Research Center) 1616 Jeff Case (SNMP Research, Inc.) 1617 John Curran (BBN) 1618 T. Max Devlin (Hi-TECH Connections) 1619 John Flick (Hewlett Packard) 1620 David Harrington (Cabletron Systems Inc.) 1621 N.C. Hien (IBM T.J. Watson Research Center) 1622 Dave Levi (SNMP Research, Inc.) 1623 Louis A. Mamakos (UUNET Technologies Inc.) 1624 Paul Meyer (Secure Computing Corporation) 1625 Keith McCloghrie (Cisco Systems) 1626 Russ Mundy (Trusted Information Systems, Inc.) 1627 Bob Natale (ACE*COMM Corporation) 1628 Mike O'Dell (UUNET Technologies Inc.) 1629 Dave Perkins (DeskTalk) 1630 Peter Polkinghorne (Brunel University) 1631 Randy Presuhn (BMC Software, Inc.) 1632 David Reid (SNMP Research, Inc.) 1633 Shawn Routhier (Epilogue) 1634 Juergen Schoenwaelder (TU Braunschweig) 1635 Bob Stewart (Cisco Systems) 1636 Bert Wijnen (IBM T.J. Watson Research Center) 1638 The document is based on recommendations of the IETF Security and 1639 Administrative Framework Evolution for SNMP Advisory Team. Members 1640 of that Advisory Team were: 1642 David Harrington (Cabletron Systems Inc.) 1643 Jeff Johnson (Cisco Systems) 1644 David Levi (SNMP Research Inc.) 1645 John Linn (Openvision) 1646 Russ Mundy (Trusted Information Systems) chair 1647 Shawn Routhier (Epilogue) 1648 Glenn Waters (Nortel) 1649 Bert Wijnen (IBM T. J. Watson Research Center) 1651 As recommended by the Advisory Team and the SNMPv3 Working Group 1652 Charter, the design incorporates as much as practical from previous 1653 RFCs and drafts. As a result, special thanks are due to the authors 1654 of previous designs known as SNMPv2u and SNMPv2*: 1656 Jeff Case (SNMP Research, Inc.) 1657 David Harrington (Cabletron Systems Inc.) 1658 David Levi (SNMP Research, Inc.) 1659 Keith McCloghrie (Cisco Systems) 1660 Brian O'Keefe (Hewlett Packard) 1661 Marshall T. Rose (Dover Beach Consulting) 1662 Jon Saperia (BGS Systems Inc.) 1663 Steve Waldbusser (International Network Services) 1664 Glenn W. Waters (Bell-Northern Research Ltd.) 1666 10. Security Considerations 1668 The Dispatcher coordinates the processing of messages to provide a 1669 level of security for management messages and to direct the SNMP PDUs 1670 to the proper SNMP application(s). 1672 A Message Processing Model, and in particular the V3MP defined in 1673 this document, interacts as part of the Message Processing with 1674 Security Models in the Security Subsystem via the abstract service 1675 interface primitives defined in [SNMP-ARCH] and elaborated above. 1677 The level of security actually provided is primarily determined by 1678 the specific Security Model implementation(s) and the specific SNMP 1679 application implementation(s) incorporated into this framework. 1680 Applications have access to data which is not secured. Applications 1681 should take reasonable steps to protect the data from disclosure, and 1682 when they send data across the network, they should obey the 1683 securityLevel and call upon the services of an Access Control Model 1684 as they apply access control. 1686 The values for the msgID element used in communication between SNMP 1687 entities must be chosen to avoid replay attacks. The values do not 1688 need to be unpredictable; it is sufficient that they not repeat. 1690 11. References 1692 [RFC1901] The SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, 1693 M. and S. Waldbusser, "Introduction to Community-based SNMPv2", 1694 RFC 1901, January 1996. 1696 [RFC1902] The SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, 1697 M. and S. Waldbusser, "Structure of Management Information for 1698 Version 2 of the Simple Network Management Protocol (SNMPv2)", 1699 RFC 1902, January 1996. 1701 [RFC1905] The SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, 1702 M. and S. Waldbusser, "Protocol Operations for Version 2 of the 1703 Simple Network Management Protocol (SNMPv2)", RFC 1905, January 1704 1996. 1706 [RFC1906] The SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, 1707 M. and S. Waldbusser, "Transport Mappings for Version 2 of the 1708 Simple Network Management Protocol (SNMPv2)", RFC 1906, January 1709 1996. 1711 [RFC1907] The SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, 1712 M. and S. Waldbusser, "Management Information Base for Version 2 1713 of the Simple Network Management Protocol (SNMPv2)", RFC 1907 1714 January 1996. 1716 [RFC1908] The SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, 1717 M. and S. Waldbusser, "Coexistence between Version 1 and Version 2 1718 of the Internet-standard Network Management Framework", RFC 1908, 1719 January 1996. 1721 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1722 Requirement Levels", RFC 2119, BCP 14, March 1997. 1724 [RFC 2028] Hovey, R. and S. Bradner, "The Organizations Involved in 1725 the IETF Standards Process", BCP 11, RFC 2028, October 1996. 1727 [SNMP-ARCH] The SNMPv3 Working Group, Harrington, D., Presuhn, R., 1728 and B. Wijnen, "An Architecture for describing SNMP Management 1729 Frameworks", , August 1998. 1731 [SNMP-USM] The SNMPv3 Working Group, Blumenthal, U., and B. Wijnen, 1732 "The User-Based Security Model for Version 3 of the Simple Network 1733 Management Protocol (SNMPv3)", , 1734 August 1998. 1736 [SNMP-ACM] The SNMPv3 Working Group, Wijnen, B., Presuhn, R., and K. 1737 McCloghrie, "View-based Access Control Model for the Simple 1738 Network Management Protocol (SNMP)", 1739 , August 1998. 1741 [SNMP-APPL] The SNMPv3 Working Group, Levi, D. B., Meyer, P., and B. 1742 Stewart, "SNMPv3 Applications", , 1743 November 1997. 1745 12. Editors' Addresses 1747 Jeffrey Case 1748 SNMP Research, Inc. 1749 3001 Kimberlin Heights Road 1750 Knoxville, TN 37920-9716 1751 USA 1753 Phone: +1 423-573-1434 1754 EMail: case@snmp.com 1756 Dave Harrington 1757 Cabletron Systems, Inc 1758 Post Office Box 5005 1759 Mail Stop: Durham 1760 35 Industrial Way 1761 Rochester, NH 03867-5005 1762 USA 1764 Phone: +1 603-337-7357 1765 EMail: dbh@ctron.com 1767 Randy Presuhn 1768 BMC Software, Inc. 1769 1190 Saratoga Avenue 1770 Suite 130 1771 San Jose, CA 95129 1772 USA 1774 Phone: +1 408-616-3100 1775 EMail: rpresuhn@bmc.com 1776 Bert Wijnen 1777 IBM T. J. Watson Research 1778 Schagen 33 1779 3461 GL Linschoten 1780 Netherlands 1782 Phone: +31 348-432-794 1783 EMail: wijnen@vnet.ibm.com 1785 13. Issues 1787 This section will be deleted in the transition from internet-draft to 1788 RFC. 1790 13.1. Open Issues 1792 The following issues have been discussed on the working group mailing 1793 list, and the document editors have not been able to figure out what 1794 changes to make, if any: 1796 - The more precise specification of the handling of the 1797 reportableFlag begs the question of what an engine is supposed 1798 to do when it receives a message with an illegal combination of 1799 the reportableFlag and PDU type. 1801 - The purpose of Report PDUs (engine-to-engine communications) 1802 might be made clearer. What text (if any) should be added 1803 explaining what actions (if any) are taken upon receipt of a 1804 report PDU? 1806 - What action is taken upon receipt of illegal combinations of 1807 the msgFlags bits? What action is taken if the "reserved" bits 1808 are non-zero upon receipt? 1810 - What security name is used for sending reports when the auth 1811 flag is not set but the priv flag is set? (7.2.5, similar 1812 questions for 7.2.6) 1814 - Various possible points of clarifications, especially the ones 1815 raised by Martin Bjorklund and others on the mailing list. 1817 - The argument has been raised that the HeaderData SEQUENCE in 1818 the message header is not needed. This means that we waste 2 1819 bytes in every SNMPv3 message. 1821 - The msgSecurityParameters element is of type OCTET STRING. This 1822 means that the security model specific parameters are always 1823 wrapped in an OCTET STRING value. In case of USM, we have to 1824 first encode a SEQUENCE and afterwards encode the result as an 1825 OCTET STRING. This again wastes 2 bytes and in addition 1826 requires to create a separate BER buffer. This problem can be 1827 avoided by changing msgSecurityParameters to ANY and to require 1828 that every security model must specify the parameters wrapped 1829 in an ASN.1 type. 1831 - The docuement directly refers to RFC 1905 PDU types which binds 1832 the version 3 message model to RFC 1905. The text should 1833 instead use "PDU classes" so that additional PDU types can be 1834 added over time without having to change the message processing 1835 model. 1837 - New PDU types can cause different error reactions, e.g. sending 1838 an snmpUnknownPDUHandlers report or just incrementing the ASN.1 1839 parse error counter. To allow smooth deployment, text needs to 1840 be added how to recognize PDU types and a report should be sent 1841 if a received PDU type is unknown. 1843 13.2. Change Log 1845 The following change log records major changes from the previous 1846 internet draft. 1848 - Updated contact information for editors. 1850 Made parameter identification in prepareResponseMsg() 1851 consistent, both internally and with architecture. 1853 - Made references to processIncomingMsg() consistent, both 1854 internally and with architecture. 1856 - Deleted superfluous expectResponse parameter from 1857 processIncomingMsg(), consistent with architecture. 1859 - Fixed typos. 1861 - Removed sending of a report PDU from step 4 on page 30 on RFC 1862 2272. (Technical change, editor believes there was WG 1863 agreement.) 1865 14. Full Copyright Statement 1867 Copyright (C) The Internet Society (1998). All Rights Reserved. 1869 This document and translations of it may be copied and furnished to 1870 others, and derivative works that comment on or otherwise explain it 1871 or assist in its implementation may be prepared, copied, published 1872 and distributed, in whole or in part, without restriction of any 1873 kind, provided that the above copyright notice and this paragraph are 1874 included on all such copies and derivative works. However, this 1875 document itself may not be modified in any way, such as by removing 1876 the copyright notice or references to the Internet Society or other 1877 Internet organizations, except as needed for the purpose of 1878 developing Internet standards in which case the procedures for 1879 copyrights defined in the Internet Standards process must be 1880 followed, or as required to translate it into languages other than 1881 English. 1883 The limited permissions granted above are perpetual and will not be 1884 revoked by the Internet Society or its successors or assigns. 1886 This document and the information contained herein is provided on an 1887 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1888 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1889 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1890 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1891 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.