idnits 2.17.1 draft-ietf-snmpv3-mpd-v2-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: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. ** The abstract seems to contain references ([RFC-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 (23 February 2001) is 8456 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 229, but not defined == Unused Reference: 'RFC2578' is defined on line 1790, but no explicit reference was found in the text == Unused Reference: 'RFC-COEX' is defined on line 1810, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 1815, but no explicit reference was found in the text == Unused Reference: 'RFC2028' is defined on line 1818, but no explicit reference was found in the text == Unused Reference: 'RFC-USM' is defined on line 1826, but no explicit reference was found in the text == Unused Reference: 'RFC-ACM' is defined on line 1831, but no explicit reference was found in the text == Unused Reference: 'RFC-APPL' is defined on line 1836, but no explicit reference was found in the text == Unused Reference: 'RFC2570' is defined on line 1840, but no explicit reference was found in the text ** Downref: Normative reference to an Historic RFC: RFC 1901 -- Possible downref: Non-RFC (?) normative reference: ref. 'RFC-PROTO' -- Possible downref: Non-RFC (?) normative reference: ref. 'RFC-TMM' -- Possible downref: Non-RFC (?) normative reference: ref. 'RFC-MIB' -- Possible downref: Non-RFC (?) normative reference: ref. 'RFC-COEX' ** Obsolete normative reference: RFC 2028 (Obsoleted by RFC 9281) -- Possible downref: Non-RFC (?) normative reference: ref. 'RFC-ARCH' -- Possible downref: Non-RFC (?) normative reference: ref. 'RFC-USM' -- Possible downref: Non-RFC (?) normative reference: ref. 'RFC-ACM' -- Possible downref: Non-RFC (?) normative reference: ref. 'RFC-APPL' ** Obsolete normative reference: RFC 2570 (Obsoleted by RFC 3410) Summary: 9 errors (**), 0 flaws (~~), 11 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT J. Case 2 Will Obsolete: 2572 SNMP Research, Inc. 3 D. Harrington 4 Enterasys Networks 5 R. Presuhn 6 BMC Software, Inc. 7 B. Wijnen 8 Lucent Technologies 9 23 February 2001 11 Message Processing and Dispatching for the 12 Simple Network Management Protocol (SNMP) 13 15 Status of this Memo 17 This document is an Internet-Draft and is in full conformance with 18 all provisions of Section 10 of RFC2026. Internet-Drafts are working 19 documents of the Internet Engineering Task Force (IETF), its areas, 20 and its working groups. Note that other groups may also distribute 21 working documents as Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html 34 Copyright Notice 36 Copyright (C) The Internet Society (2001). All Rights Reserved. 38 Abstract 40 This document describes the Message Processing and Dispatching for 41 SNMP messages within the SNMP architecture [RFC-ARCH]. It defines 42 the procedures for dispatching potentially multiple versions of SNMP 43 messages to the proper SNMP Message Processing Models, and for 44 dispatching PDUs to SNMP applications. This document also describes 45 one Message Processing Model - the SNMPv3 Message Processing Model. 47 Table of Contents 49 1. Introduction ................................................ 3 50 2. Overview .................................................... 3 51 2.1. The Dispatcher ............................................ 5 52 2.2. Message Processing Subsystem .............................. 5 53 3. Elements of Message Processing and Dispatching .............. 5 54 3.1. messageProcessingModel .................................... 6 55 3.2. pduVersion ................................................ 6 56 3.3. pduType ................................................... 7 57 3.4. sendPduHandle ............................................. 7 58 4. Dispatcher Elements of Procedure ............................ 8 59 4.1. Sending an SNMP Message to the Network .................... 8 60 4.1.1. Sending a Request or Notification ....................... 8 61 4.1.2. Sending a Response to the Network ....................... 9 62 4.2. Receiving an SNMP Message from the Network ................ 11 63 4.2.1. Message Dispatching of received SNMP Messages ........... 11 64 4.2.2. PDU Dispatching for Incoming Messages ................... 12 65 4.2.2.1. Incoming Requests and Notifications ................... 12 66 4.2.2.2. Incoming Responses .................................... 14 67 4.3. Application Registration for Handling PDU types ........... 15 68 4.4. Application Unregistration for Handling PDU Types ......... 16 69 5. Definitions ................................................. 16 70 5.1. Definitions for SNMP Message Processing and Dispatching ... 16 71 6. The SNMPv3 Message Format ................................... 20 72 6.1. msgVersion ................................................ 21 73 6.2. msgID ..................................................... 21 74 6.3. msgMaxSize ................................................ 21 75 6.4. msgFlags .................................................. 22 76 6.5. msgSecurityModel .......................................... 24 77 6.6. msgSecurityParameters ..................................... 24 78 6.7. scopedPduData ............................................. 24 79 6.8. scopedPDU ................................................. 24 80 6.8.1. contextEngineID ......................................... 25 81 6.8.2. contextName ............................................. 25 82 6.8.3. data .................................................... 25 83 7. Elements of Procedure for v3MP .............................. 25 84 7.1. Prepare an Outgoing SNMP Message .......................... 26 85 7.2. Prepare Data Elements from an Incoming SNMP Message ....... 31 86 8. Intellectual Property ....................................... 37 87 9. Acknowledgements ............................................ 37 88 10. Security Considerations .................................... 39 89 11. References ................................................. 40 90 12. Editors' Addresses ......................................... 41 91 13. Changes From RFC 2572 ...................................... 42 92 14. Full Copyright Statement ................................... 42 94 1. Introduction 96 The Architecture for describing Internet Management Frameworks [RFC- 97 ARCH] describes that an SNMP engine is composed of: 99 1) a Dispatcher 100 2) a Message Processing Subsystem, 101 3) a Security Subsystem, and 102 4) an Access Control Subsystem. 104 Applications make use of the services of these subsystems. 106 It is important to understand the SNMP architecture and its 107 terminology to understand where the Message Processing Subsystem and 108 Dispatcher described in this document fit into the architecture and 109 interact with other subsystems within the architecture. The reader 110 is expected to have read and understood the description of the SNMP 111 architecture, defined in [RFC-ARCH]. 113 The Dispatcher in the SNMP engine sends and receives SNMP messages. 114 It also dispatches SNMP PDUs to SNMP applications. When an SNMP 115 message needs to be prepared or when data needs to be extracted from 116 an SNMP message, the Dispatcher delegates these tasks to a message 117 version-specific Message Processing Model within the Message 118 Processing Subsystem. 120 A Message Processing Model is responsible for processing a SNMP 121 version-specific message and for coordinating the interaction with 122 the Security Subsystem to ensure proper security is applied to the 123 SNMP message being handled. 125 Interactions between the Dispatcher, the Message Processing 126 Subsystem, and applications are modeled using abstract data elements 127 and abstract service interface primitives defined by the SNMP 128 architecture. 130 Similarly, interactions between the Message Processing Subsystem and 131 the Security Subsystem are modeled using abstract data elements and 132 abstract service interface primitives as defined by the SNMP 133 architecture. 135 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 136 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 137 document are to be interpreted as described in RFC 2119. 139 2. Overview 141 The following illustration depicts the Message Processing in relation 142 to SNMP applications, the Security Subsystem and Transport Mappings. 144 +-------------------------------------------------------------------+ 145 | SNMP Entity | 146 | | 147 | +---------------------------------------------------------------+ | 148 | | Applications | | 149 | | +-----------+ +--------------+ | | 150 | | | Command | | Notification | | | 151 | | | Generator | | Originator | +-----------+ +--------------+| | 152 | | +-----------+ +--------------+ | Proxy | | Other | | 153 | | +-----------+ +--------------+ | Forwarder | |Application(s)|| | 154 | | | Command | | Notification | +-----------+ +--------------+| | 155 | | | Responder | | Receiver | | | 156 | | +-----------+ +--------------+ | | 157 | +---------------------------------------------------------------+ | 158 | ^ ^ ^ ^ | 159 | | | | | | 160 | v v v v | 161 | +--------+-------+---------------+-----------+ | 162 | ^ | 163 | | +---------------------+ +-----------------+ | 164 | | | Message Processing | | Security | | 165 | Dispatcher v | Subsystem | | Subsystem | | 166 | +------------------+ | +------------+ | | | | 167 | | PDU Dispatcher | | +->| v1MP * |<--->| +-------------+ | | 168 | | | | | +------------+ | | | Other | | | 169 | | | | | +------------+ | | | Security | | | 170 | | | | +->| v2cMP * |<--->| | Model | | | 171 | | Message | | | +------------+ | | +-------------+ | | 172 | | Dispatcher <-------->+ | | | | 173 | | | | | +------------+ | | +-------------+ | | 174 | | | | +->| v3MP * |<--->| | User-based | | | 175 | | Transport | | | +------------+ | | | Security | | | 176 | | Mapping | | | +------------+ | | | Model | | | 177 | | (e.g RFC 1906) | | +->| otherMP * |<--->| +-------------+ | | 178 | +------------------+ | +------------+ | | | | 179 | ^ +---------------------+ +-----------------+ | 180 | | | 181 +----------|--------------------------------------------------------+ 182 v 183 +------------------+ 184 | Network | 185 +------------------+ 187 2.1. The Dispatcher 189 The Dispatcher is a key piece of an SNMP engine. There is only one in 190 an SNMP engine, and its job is to dispatch tasks to the multiple 191 version-specific Message Processing Models, and to dispatch PDUs to 192 various applications. 194 For outgoing messages, an application provides a PDU to be sent, plus 195 the data needed to prepare and send the message, and the application 196 specifies which version-specific Message Processing Model will be 197 used to prepare the message with the desired security processing. 198 Once the message is prepared, the Dispatcher sends the message. 200 For incoming messages, the Dispatcher determines the SNMP version of 201 the incoming message and passes the message to the version-specific 202 Message Processing Model to extract the components of the message and 203 to coordinate the processing of security services for the message. 204 After version-specific processing, the PDU Dispatcher determines 205 which application, if any, should receive the PDU for processing and 206 forwards it accordingly. 208 The Dispatcher, while sending and receiving SNMP messages, collects 209 statistics about SNMP messages and the behavior of the SNMP engine in 210 managed objects to make them accessible to remote SNMP entities. 211 This document defines these managed objects, the MIB module which 212 contains them, and how these managed objects might be used to provide 213 useful management. 215 2.2. Message Processing Subsystem 217 The SNMP Message Processing Subsystem is the part of an SNMP engine 218 which interacts with the Dispatcher to handle the version-specific 219 SNMP messages. It contains one or more Message Processing Models. 221 This document describes one Message Processing Model, the SNMPv3 222 Message Processing Model, in Section 6. The SNMPv3 Message Processing 223 Model is defined in a separate section to show that multiple 224 (independent) Message Processing Models can exist at the same time 225 and that such Models can be described in different documents. The 226 SNMPv3 Message Processing Model can be replaced or supplemented with 227 other Message Processing Models in the future. Two Message Processing 228 Models which are expected to be developed in the future are the 229 SNMPv1 message format [RFC1157] and the SNMPv2c message format 230 [RFC1901]. Others may be developed as needed. 232 3. Elements of Message Processing and Dispatching 234 See [RFC-ARCH] for the definitions of 235 contextEngineID 236 contextName 237 scopedPDU 238 maxSizeResponseScopedPDU 239 securityModel 240 securityName 241 securityLevel 242 messageProcessingModel 244 For incoming messages, a version-specific message processing module 245 provides these values to the Dispatcher. For outgoing messages, an 246 application provides these values to the Dispatcher. 248 For some version-specific processing, the values may be extracted 249 from received messages; for other versions, the values may be 250 determined by algorithm, or by an implementation-defined mechanism. 251 The mechanism by which the value is determined is irrelevant to the 252 Dispatcher. 254 The following additional or expanded definitions are for use within 255 the Dispatcher. 257 3.1. messageProcessingModel 259 The value of messageProcessingModel identifies a Message Processing 260 Model. A Message Processing Model describes the version-specific 261 procedures for extracting data from messages, generating messages, 262 calling upon a securityModel to apply its security services to 263 messages, for converting data from a version-specific message format 264 into a generic format usable by the Dispatcher, and for converting 265 data from Dispatcher format into a version-specific message format. 267 3.2. pduVersion 269 The value of pduVersion represents a specific version of protocol 270 operation and its associated PDU formats, such as SNMPv1 or SNMPv2 271 [RFC-PROTO]. The values of pduVersion are specific to the version of 272 the PDU contained in a message, and the PDUs processed by 273 applications. The Dispatcher does not use the value of pduVersion 274 directly. 276 An application specifies the pduVersion when it requests the PDU 277 Dispatcher to send a PDU to another SNMP engine. The Dispatcher 278 passes the pduVersion to a Message Processing Model, so it knows how 279 to handle the PDU properly. 281 For incoming messages, pduVersion is provided to the Dispatcher by a 282 version-specific Message Processing module. The PDU Dispatcher passes 283 the pduVersion to the application so it knows how to handle the PDU 284 properly. For example, a command responder application needs to know 285 whether to use [RFC-PROTO] elements of procedure and syntax instead 286 of those specified for SNMPv1. 288 3.3. pduType 290 A value of pduType represents a specific type of protocol operation. 291 The values of pduType are specific to the version of the PDU 292 contained in a message. 294 Applications register to support particular pduTypes for particular 295 contextEngineIDs. 297 For incoming messages, pduType is provided to the Dispatcher by a 298 version-specific Message Processing module. It is subsequently used 299 to dispatch the PDU to the application which registered for the 300 pduType for the contextEngineID of the associated scopedPDU. 302 3.4. sendPduHandle 304 This handle is generated for coordinating the processing of requests 305 and responses between the SNMP engine and an application. The handle 306 must be unique across all version-specific Message Processing Models, 307 and is of local significance only. 309 4. Dispatcher Elements of Procedure 311 This section describes the procedures followed by the Dispatcher when 312 generating and processing SNMP messages. 314 4.1. Sending an SNMP Message to the Network 316 This section describes the procedure followed by an SNMP engine 317 whenever it sends an SNMP message. 319 4.1.1. Sending a Request or Notification 321 The following procedures are followed by the Dispatcher when an 322 application wants to send an SNMP PDU to another (remote) 323 application, i.e., to initiate a communication by originating a 324 message, such as one containing a request or a trap. 326 1) The application requests this using the abstract service 327 primitive: 329 statusInformation = -- sendPduHandle if success 330 -- errorIndication if failure 331 sendPdu( 332 IN transportDomain -- transport domain to be used 333 IN transportAddress -- destination network address 334 IN messageProcessingModel -- typically, SNMP version 335 IN securityModel -- Security Model to use 336 IN securityName -- on behalf of this principal 337 IN securityLevel -- Level of Security requested 338 IN contextEngineID -- data from/at this entity 339 IN contextName -- data from/in this context 340 IN pduVersion -- the version of the PDU 341 IN PDU -- SNMP Protocol Data Unit 342 IN expectResponse -- TRUE or FALSE 343 ) 345 2) If the messageProcessingModel value does not represent a Message 346 Processing Model known to the Dispatcher, then an errorIndication 347 (implementation-dependent) is returned to the calling application. 348 No further processing is performed. 350 3) The Dispatcher generates a sendPduHandle to coordinate subsequent 351 processing. 353 4) The Message Dispatcher sends the request to the version-specific 354 Message Processing module identified by messageProcessingModel 355 using the abstract service primitive: 357 statusInformation = - success or error indication 358 prepareOutgoingMessage( 359 IN transportDomain -- as specified by application 360 IN transportAddress -- as specified by application 361 IN messageProcessingModel -- as specified by application 362 IN securityModel -- as specified by application 363 IN securityName -- as specified by application 364 IN securityLevel -- as specified by application 365 IN contextEngineID -- as specified by application 366 IN contextName -- as specified by application 367 IN pduVersion -- as specified by application 368 IN PDU -- as specified by application 369 IN expectResponse -- as specified by application 370 IN sendPduHandle -- as determined in step 3. 371 OUT destTransportDomain -- destination transport domain 372 OUT destTransportAddress -- destination transport address 373 OUT outgoingMessage -- the message to send 374 OUT outgoingMessageLength -- the message length 375 ) 377 5) If the statusInformation indicates an error, the errorIndication 378 is returned to the calling application. No further processing is 379 performed. 381 6) If the statusInformation indicates success, the sendPduHandle is 382 returned to the application, and the outgoingMessage is sent via 383 the transport specified by the transportDomain to the address 384 specified by the transportAddress. 386 Outgoing Message Processing is complete. 388 4.1.2. Sending a Response to the Network 390 The following procedure is followed when an application wants to 391 return a response back to the originator of an SNMP Request. 393 1) An application can request this using the abstract service 394 primitive: 396 result = 397 returnResponsePdu( 398 IN messageProcessingModel -- typically, SNMP version 399 IN securityModel -- Security Model in use 400 IN securityName -- on behalf of this principal 401 IN securityLevel -- same as on incoming request 402 IN contextEngineID -- data from/at this SNMP entity 403 IN contextName -- data from/in this context 404 IN pduVersion -- the version of the PDU 405 IN PDU -- SNMP Protocol Data Unit 406 IN maxSizeResponseScopedPDU -- maximum size of Response PDU 407 IN stateReference -- reference to state information 408 -- as presented with the request 409 IN statusInformation -- success or errorIndication 410 ) -- (error counter OID and value 411 -- when errorIndication) 413 2) The Message Dispatcher sends the request to the appropriate 414 Message Processing Model indicated by the received value of 415 messageProcessingModel using the abstract service primitive: 417 result = -- SUCCESS or errorIndication 418 prepareResponseMessage( 419 IN messageProcessingModel -- specified by application 420 IN securityModel -- specified by application 421 IN securityName -- specified by application 422 IN securityLevel -- specified by application 423 IN contextEngineID -- specified by application 424 IN contextName -- specified by application 425 IN pduVersion -- specified by application 426 IN PDU -- specified by application 427 IN maxSizeResponseScopedPDU -- specified by application 428 IN stateReference -- specified by application 429 IN statusInformation -- specified by application 430 OUT destTransportDomain -- destination transport domain 431 OUT destTransportAddress -- destination transport address 432 OUT outgoingMessage -- the message to send 433 OUT outgoingMessageLength -- the message length 434 ) 436 3) If the result is an errorIndication, the errorIndication is 437 returned to the calling application. No further processing is 438 performed. 440 4) If the result is success, the outgoingMessage is sent over the 441 transport specified by the transportDomain to the address 442 specified by the transportAddress. 444 Message Processing is complete. 446 4.2. Receiving an SNMP Message from the Network 448 This section describes the procedure followed by an SNMP engine 449 whenever it receives an SNMP message. 451 Please note, that for the sake of clarity and to prevent the text 452 from being even longer and more complicated, some details were 453 omitted from the steps below. In particular, The elements of 454 procedure do not always explicitly indicate when state information 455 needs to be released. The general rule is that if state information 456 is available when a message is to be "discarded without further 457 processing", then the state information must also be released at that 458 same time. 460 4.2.1. Message Dispatching of received SNMP Messages 462 1) The snmpInPkts counter [RFC-MIB] is incremented. 464 2) The version of the SNMP message is determined in an 465 implementation-dependent manner. If the packet cannot be 466 sufficiently parsed to determine the version of the SNMP message, 467 then the snmpInASNParseErrs [RFC-MIB] counter is incremented, and 468 the message is discarded without further processing. If the 469 version is not supported, then the snmpInBadVersions [RFC-MIB] 470 counter is incremented, and the message is discarded without 471 further processing. 473 3) The origin transportDomain and origin transportAddress are 474 determined. 476 4) The message is passed to the version-specific Message Processing 477 Model which returns the abstract data elements required by the 478 Dispatcher. This is performed using the abstract service 479 primitive: 481 result = -- SUCCESS or errorIndication 482 prepareDataElements( 483 IN transportDomain -- origin as determined in step 3. 484 IN transportAddress -- origin as determined in step 3. 485 IN wholeMsg -- as received from the network 486 IN wholeMsgLength -- as received from the network 487 OUT messageProcessingModel -- typically, SNMP version 488 OUT securityModel -- Security Model specified 489 OUT securityName -- on behalf of this principal 490 OUT securityLevel -- Level of Security specified 491 OUT contextEngineID -- data from/at this entity 492 OUT contextName -- data from/in this context 493 OUT pduVersion -- the version of the PDU 494 OUT PDU -- SNMP Protocol Data Unit 495 OUT pduType -- SNMP PDU type 496 OUT sendPduHandle -- handle for a matched request 497 OUT maxSizeResponseScopedPDU -- maximum size of Response PDU 498 OUT statusInformation -- success or errorIndication 499 -- (error counter OID and value 500 -- when errorIndication) 501 OUT stateReference -- reference to state information 502 -- to be used for a possible 503 ) -- Response 505 5) If the result is a FAILURE errorIndication, the message is 506 discarded without further processing. 508 6) At this point, the abstract data elements have been prepared and 509 processing continues as described in Section 4.2.2, PDU 510 Dispatching for Incoming Messages. 512 4.2.2. PDU Dispatching for Incoming Messages 514 The elements of procedure for the dispatching of PDUs depends on the 515 value of sendPduHandle. If the value of sendPduHandle is , 516 then this is a request or notification and the procedures specified 517 in Section 4.2.2.1 apply. If the value of snmpPduHandle is not 518 , then this is a response and the procedures specified in 519 Section 4.2.2.2 apply. 521 4.2.2.1. Incoming Requests and Notifications 523 The following procedures are followed for the dispatching of PDUs 524 when the value of sendPduHandle is , indicating this is a 525 request or notification. 527 1) The combination of contextEngineID and pduType is used to 528 determine which application has registered for this request or 529 notification. 531 2) If no application has registered for the combination, then 533 a) The snmpUnknownPDUHandlers counter is incremented. 535 b) A Response message is generated using the abstract service 536 primitive: 538 result = -- SUCCESS or FAILURE 539 prepareResponseMessage( 540 IN messageProcessingModel -- as provided by MP module 541 IN securityModel -- as provided by MP module 542 IN securityName -- as provided by MP module 543 IN securityLevel -- as provided by MP module 544 IN contextEngineID -- as provided by MP module 545 IN contextName -- as provided by MP module 546 IN pduVersion -- as provided by MP module 547 IN PDU -- as provided by MP module 548 IN maxSizeResponseScopedPDU -- as provided by MP module 549 IN stateReference -- as provided by MP module 550 IN statusInformation -- errorIndication plus 551 -- snmpUnknownPDUHandlers OID 552 -- value pair. 553 OUT destTransportDomain -- destination transportDomain 554 OUT destTransportAddress -- destination transportAddress 555 OUT outgoingMessage -- the message to send 556 OUT outgoingMessageLength -- its length 557 ) 559 c) If the result is SUCCESS, then the prepared message is sent to 560 the originator of the request as identified by the 561 transportDomain and transportAddress. 563 d) The incoming message is discarded without further processing. 564 Message Processing for this message is complete. 566 3) The PDU is dispatched to the application, using the abstract 567 service primitive: 569 processPdu( -- process Request/Notification 570 IN messageProcessingModel -- as provided by MP module 571 IN securityModel -- as provided by MP module 572 IN securityName -- as provided by MP module 573 IN securityLevel -- as provided by MP module 574 IN contextEngineID -- as provided by MP module 575 IN contextName -- as provided by MP module 576 IN pduVersion -- as provided by MP module 577 IN PDU -- as provided by MP module 578 IN maxSizeResponseScopedPDU -- as provided by MP module 579 IN stateReference -- as provided by MP module 580 -- needed when sending response 581 ) 583 Message processing for this message is complete. 585 4.2.2.2. Incoming Responses 587 The following procedures are followed for the dispatching of PDUs 588 when the value of sendPduHandle is not , indicating this is a 589 response. 591 1) The value of sendPduHandle is used to determine, in an 592 implementation-defined manner, which application is waiting for 593 a response associated with this sendPduHandle. 595 2) If no waiting application is found, the message is discarded 596 without further processing, and the stateReference is released. 597 The snmpUnknownPDUHandlers counter is incremented. Message 598 Processing is complete for this message. 600 3) Any cached information, including stateReference, about the 601 message is discarded. 603 4) The response is dispatched to the application using the 604 abstract service primitive: 606 processResponsePdu( -- process Response PDU 607 IN messageProcessingModel -- provided by the MP module 608 IN securityModel -- provided by the MP module 609 IN securityName -- provided by the MP module 610 IN securityLevel -- provided by the MP module 611 IN contextEngineID -- provided by the MP module 612 IN contextName -- provided by the MP module 613 IN pduVersion -- provided by the MP module 614 IN PDU -- provided by the MP module 615 IN statusInformation -- provided by the MP module 616 IN sendPduHandle -- provided by the MP module 617 ) 619 Message Processing is complete for this message. 621 4.3. Application Registration for Handling PDU types 623 Applications that want to process certain PDUs must register with the 624 PDU Dispatcher. Applications specify the combination of 625 contextEngineID and pduType(s) for which they want to take 626 responsibility 628 1) An application registers according to the abstract interface 629 primitive: 631 statusInformation = -- success or errorIndication 632 registerContextEngineID( 633 IN contextEngineID -- take responsibility for this one 634 IN pduType -- the pduType(s) to be registered 635 ) 637 Note: implementations may provide a means of requesting 638 registration for simultaneous multiple contextEngineID values, 639 e.g., all contextEngineID values, and may also provide means for 640 requesting simultaneous registration for multiple values of 641 pduType. 643 2) The parameters may be checked for validity; if they are not, then 644 an errorIndication (invalidParameter) is returned to the 645 application. 647 3) Each combination of contextEngineID and pduType can be registered 648 only once. If another application has already registered for the 649 specified combination, then an errorIndication (alreadyRegistered) 650 is returned to the application. 652 4) Otherwise, the registration is saved so that SNMP PDUs can be 653 dispatched to this application. 655 4.4. Application Unregistration for Handling PDU Types 657 Applications that no longer want to process certain PDUs must 658 unregister with the PDU Dispatcher. 660 1) An application unregisters using the abstract service primitive: 662 unregisterContextEngineID( 663 IN contextEngineID -- give up responsibility for this 664 IN pduType -- the pduType(s) to be unregistered 665 ) 666 Note: implementations may provide means for requesting 667 unregistration for simultaneous multiple contextEngineID values, 668 e.g., all contextEngineID values, and may also provide means for 669 requesting simultaneous unregistration for multiple values of 670 pduType. 672 2) If the contextEngineID and pduType combination has been 673 registered, then the registration is deleted. 675 If no such registration exists, then the request is ignored. 677 5. Definitions 679 5.1. Definitions for SNMP Message Processing and Dispatching 681 SNMP-MPD-MIB DEFINITIONS ::= BEGIN 683 IMPORTS 684 MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF 685 MODULE-IDENTITY, OBJECT-TYPE, 686 snmpModules, Counter32 FROM SNMPv2-SMI; 688 snmpMPDMIB MODULE-IDENTITY 689 LAST-UPDATED "200102232146Z" 690 ORGANIZATION "SNMPv3 Working Group" 691 CONTACT-INFO "WG-EMail: snmpv3@lists.tislabs.com 692 Subscribe: snmpv3-request@lists.tislabs.com 694 Co-Chair: Russ Mundy 695 TIS Labs at Network Associates 696 postal: 3060 Washington Road 697 Glenwood, MD 21738 698 USA 699 EMail: mundy@tislabs.com 700 phone: +1 301-854-6889 701 Co-Chair & 702 Co-editor: David Harrington 703 Enterasys Networks 704 postal: 35 Industrial Way 705 P. O. Box 5005 706 Rochester NH 03866-5005 707 USA 708 EMail: dbh@enterasys.com 709 phone: +1 603-337-2614 711 Co-editor: Jeffrey Case 712 SNMP Research, Inc. 713 postal: 3001 Kimberlin Heights Road 714 Knoxville, TN 37920-9716 715 USA 716 EMail: case@snmp.com 717 phone: +1 423-573-1434 719 Co-editor: Randy Presuhn 720 BMC Software, Inc. 721 postal: 2141 North First Street 722 San Jose, CA 95131 723 USA 724 EMail: randy_presuhn@bmc.com 725 phone: +1 408-546-1006 727 Co-editor: Bert Wijnen 728 Lucent Technologies 729 postal: Schagen 33 730 3461 GL Linschoten 731 Netherlands 732 EMail: bwijnen@lucent.com 733 phone: +31 348-680-485 734 " 735 DESCRIPTION "The MIB for Message Processing and Dispatching" 736 REVISION "200102232146Z" 737 DESCRPTION "Updated addresses, published as RFC -MPD." 738 REVISION "9905041636Z" -- 4 May 1999 739 DESCRIPTION "Updated addresses, published as RFC 2572." 740 REVISION "9709300000Z" -- 30 September 1997 741 DESCRIPTION "Original version, published as RFC 2272." 742 ::= { snmpModules 11 } 744 -- Administrative assignments *************************************** 746 snmpMPDAdmin OBJECT IDENTIFIER ::= { snmpMPDMIB 1 } 747 snmpMPDMIBObjects OBJECT IDENTIFIER ::= { snmpMPDMIB 2 } 748 snmpMPDMIBConformance OBJECT IDENTIFIER ::= { snmpMPDMIB 3 } 749 -- Statistics for SNMP Messages ************************************* 751 snmpMPDStats OBJECT IDENTIFIER ::= { snmpMPDMIBObjects 1 } 753 snmpUnknownSecurityModels OBJECT-TYPE 754 SYNTAX Counter32 755 MAX-ACCESS read-only 756 STATUS current 757 DESCRIPTION "The total number of packets received by the SNMP 758 engine which were dropped because they referenced a 759 securityModel that was not known to or supported by 760 the SNMP engine. 761 " 762 ::= { snmpMPDStats 1 } 764 snmpInvalidMsgs OBJECT-TYPE 765 SYNTAX Counter32 766 MAX-ACCESS read-only 767 STATUS current 768 DESCRIPTION "The total number of packets received by the SNMP 769 engine which were dropped because there were invalid 770 or inconsistent components in the SNMP message. 771 " 772 ::= { snmpMPDStats 2 } 774 snmpUnknownPDUHandlers OBJECT-TYPE 775 SYNTAX Counter32 776 MAX-ACCESS read-only 777 STATUS current 778 DESCRIPTION "The total number of packets received by the SNMP 779 engine which were dropped because the PDU contained 780 in the packet could not be passed to an application 781 responsible for handling the pduType, e.g. no SNMP 782 application had registered for the proper 783 combination of the contextEngineID and the pduType. 784 " 785 ::= { snmpMPDStats 3 } 787 -- Conformance information ****************************************** 789 snmpMPDMIBCompliances OBJECT IDENTIFIER ::= {snmpMPDMIBConformance 1} 790 snmpMPDMIBGroups OBJECT IDENTIFIER ::= {snmpMPDMIBConformance 2} 792 -- Compliance statements 794 snmpMPDCompliance MODULE-COMPLIANCE 795 STATUS current 796 DESCRIPTION "The compliance statement for SNMP entities which 797 implement the SNMP-MPD-MIB. 798 " 799 MODULE -- this module 800 MANDATORY-GROUPS { snmpMPDGroup } 801 ::= { snmpMPDMIBCompliances 1 } 803 snmpMPDGroup OBJECT-GROUP 804 OBJECTS { 805 snmpUnknownSecurityModels, 806 snmpInvalidMsgs, 807 snmpUnknownPDUHandlers 808 } 809 STATUS current 810 DESCRIPTION "A collection of objects providing for remote 811 monitoring of the SNMP Message Processing and 812 Dispatching process. 813 " 814 ::= { snmpMPDMIBGroups 1 } 816 END 818 6. The SNMPv3 Message Format 820 This section defines the SNMPv3 message format and the corresponding 821 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 -- the value 3 is used for snmpv3 829 msgVersion INTEGER ( 0 .. 2147483647 ), 830 -- administrative parameters 831 msgGlobalData HeaderData, 832 -- security model-specific parameters 833 -- format defined by Security Model 834 msgSecurityParameters OCTET STRING, 835 msgData ScopedPduData 836 } 838 HeaderData ::= SEQUENCE { 839 msgID INTEGER (0..2147483647), 840 msgMaxSize INTEGER (484..2147483647), 842 msgFlags OCTET STRING (SIZE(1)), 843 -- .... ...1 authFlag 844 -- .... ..1. privFlag 845 -- .... .1.. reportableFlag 846 -- Please observe: 847 -- .... ..00 is OK, means noAuthNoPriv 848 -- .... ..01 is OK, means authNoPriv 849 -- .... ..10 reserved, must NOT be used. 850 -- .... ..11 is OK, means authPriv 852 msgSecurityModel INTEGER (1..2147483647) 853 } 855 ScopedPduData ::= CHOICE { 856 plaintext ScopedPDU, 857 encryptedPDU OCTET STRING -- encrypted scopedPDU value 858 } 860 ScopedPDU ::= SEQUENCE { 861 contextEngineID OCTET STRING, 862 contextName OCTET STRING, 863 data ANY -- e.g., PDUs as defined in RFC -PROTO 864 } 865 END 867 6.1. msgVersion 869 The msgVersion field is set to snmpv3(3) and identifies the message 870 as an SNMP version 3 Message. 872 6.2. msgID 874 The msgID is used between two SNMP entities to coordinate request 875 messages and responses, and by the v3MP to coordinate the processing 876 of the message by different subsystem models within the architecture. 878 Values for msgID SHOULD be generated in a manner that avoids re-use 879 of any outstanding values. Doing so provides protection against some 880 replay attacks. One possible implementation strategy would be to use 881 the low-order bits of snmpEngineBoots [RFC-ARCH] as the high-order 882 portion of the msgID value and a monotonically increasing integer for 883 the low-order portion of msgID. 885 Note that the request-id in a PDU may be used by SNMP applications to 886 identify the PDU; the msgID is used by the engine to identify the 887 message which carries a PDU. The engine needs to identify the message 888 even if decryption of the PDU (and request-id) fails. No assumption 889 should be made that the value of the msgID and the value of the 890 request-id are equivalent. 892 The value of the msgID field for a response takes the value of the 893 msgID field from the message to which it is a response. By use of 894 the msgID value, an engine can distinguish the (potentially multiple) 895 outstanding requests, and thereby correlate incoming responses with 896 outstanding requests. In cases where an unreliable datagram service 897 is used, the msgID also provides a simple means of identifying 898 messages duplicated by the network. If a request is retransmitted, a 899 new msgID value SHOULD be used for each retransmission. 901 6.3. msgMaxSize 903 The msgMaxSize field of the message conveys the maximum message size 904 supported by the sender of the message, i.e., the maximum message 905 size that the sender can accept when another SNMP engine sends an 906 SNMP message (be it a response or any other message) to the sender of 907 this message on the transport in use for this message. 909 When an SNMP message is being generated, the msgMaxSize is provided 910 by the SNMP engine which generates the message. At the receiving 911 SNMP engine, the msgMaxSize is used to determine the maximum message 912 size the sender can accommodate. 914 6.4. msgFlags 916 The msgFlags field of the message contains several bit fields which 917 control processing of the message. 919 The reportableFlag is a secondary aid in determining whether a Report 920 PDU must be sent. It is only used in cases where the PDU portion of 921 a message cannot be decoded, due to, for example, an incorrect 922 encryption key. If the PDU can be decoded, the PDU type forms the 923 basis for decisions on sending Report PDUs. 925 When the reportableFlag is used, if its value is one, a Report PDU 926 MUST be returned to the sender under those conditions which can cause 927 the generation of Report PDUs. Similarly, when the reportableFlag is 928 used and its value is zero, then a Report PDU MUST NOT be sent. The 929 reportableFlag MUST always be zero when the message contains a PDU 930 from the Unconfirmed Class, such as a Report PDU, a response-type PDU 931 (such as a Response PDU), or an unacknowledged notification-type PDU 932 (such as an SNMPv2-trap PDU). The reportableFlag MUST always be one 933 for a PDU from the Confirmed Class, include request-type PDUs (such 934 as a Get PDU) and an acknowledged notification-type PDUs (such as an 935 Inform PDU). 937 If the reportableFlag is set to one for a message containing a PDU 938 from the Unconfirmed Class, such as a Report PDU, a response-type PDU 939 (such as a Response PDU), or an unacknowledged notification-type PDU 940 (such as an SNMPv2-trap PDU), then the receiver of that message MUST 941 process it as though the reportableFlag had been set to zero. 943 If the reportableFlag is set to zero for a message containing a 944 request-type PDU (such as a Get PDU) or an acknowledged 945 notification-type PDU (such as an Inform PDU), then the receiver of 946 that message must process it as though the reportableFlag had been 947 set to one. 949 Report PDUs are generated directly by the SNMPv3 Message Processing 950 Model, and support engine-to-engine communications, but may be passed 951 to applications for processing. 953 An SNMP engine that receives a reportPDU may use it to determine what 954 kind of problem was detected by the remote SNMP engine. It can do so 955 based on the error counter included as the first (and only) varBind 956 of the reportPDU. Based on the detected error, the SNMP engine may 957 try to send a corrected SNMP message. If that is not possible, it 958 may pass an indication of the error to the application on whose 959 behalf the failed SNMP request was issued. 961 The authFlag and privFlag portions of the msgFlags field are set by 962 the sender to indicate the securityLevel that was applied to the 963 message before it was sent on the wire. The receiver of the message 964 MUST apply the same securityLevel when the message is received and 965 the contents are being processed. 967 There are three securityLevels, namely noAuthNoPriv, which is less 968 than authNoPriv, which is in turn less than authPriv. See the SNMP 969 architecture document [RFC-ARCH] for details about the securityLevel. 971 a) authFlag 973 If the authFlag is set to one, then the securityModel used by the 974 SNMP engine which sent the message MUST identify the securityName 975 on whose behalf the SNMP message was generated and MUST provide, 976 in a securityModel-specific manner, sufficient data for the 977 receiver of the message to be able to authenticate that 978 identification. In general, this authentication will allow the 979 receiver to determine with reasonable certainty that the message 980 was: 982 - sent on behalf of the principal associated with the 983 securityName, 985 - was not redirected, 987 - was not modified in transit, and 989 - was not replayed. 991 If the authFlag is zero, then the securityModel used by the SNMP 992 engine which sent the message must identify the securityName on 993 whose behalf the SNMP message was generated but it does not need 994 to provide sufficient data for the receiver of the message to 995 authenticate the identification, as there is no need to 996 authenticate the message in this case. 998 b) privFlag 1000 If the privFlag is set, then the securityModel used by the SNMP 1001 engine which sent the message MUST also protect the scopedPDU in 1002 an SNMP message from disclosure, i.e., it MUST encrypt/decrypt the 1003 scopedPDU. If the privFlag is zero, then the securityModel in use 1004 does not need to protect the data from disclosure. 1006 It is an explicit requirement of the SNMP architecture that if 1007 privacy is selected, then authentication is also required. That 1008 means that if the privFlag is set, then the authFlag MUST also be 1009 set to one. 1011 The combination of the authFlag and the privFlag comprises a Level 1012 of Security as follows: 1013 authFlag zero, privFlag zero -> securityLevel is noAuthNoPriv 1014 authFlag zero, privFlag one -> invalid combination, see below 1015 authFlag one, privFlag zero -> securityLevel is authNoPriv 1016 authFlag one, privFlag one -> securityLevel is authPriv 1018 The elements of procedure (see below) describe the action to be taken 1019 when the invalid combination of authFlag equal to zero and privFlag 1020 equal to one is encountered. 1022 The remaining bits in msgFlags are reserved, and MUST be set to zero 1023 when sending a message and SHOULD be ignored when receiving a 1024 message. 1026 6.5. msgSecurityModel 1028 The v3MP supports the concurrent existence of multiple Security 1029 Models to provide security services for SNMPv3 messages. The 1030 msgSecurityModel field in an SNMPv3 Message identifies which Security 1031 Model was used by the sender to generate the message and therefore 1032 which securityModel must be used by the receiver to perform security 1033 processing for the message. The mapping to the appropriate 1034 securityModel implementation within an SNMP engine is accomplished in 1035 an implementation-dependent manner. 1037 6.6. msgSecurityParameters 1039 The msgSecurityParameters field of the SNMPv3 Message is used for 1040 communication between the Security Model modules in the sending and 1041 receiving SNMP engines. The data in the msgSecurityParameters field 1042 is used exclusively by the Security Model, and the contents and 1043 format of the data is defined by the Security Model. This OCTET 1044 STRING is not interpreted by the v3MP, but is passed to the local 1045 implementation of the Security Model indicated by the 1046 msgSecurityModel field in the message. 1048 6.7. scopedPduData 1050 The scopedPduData field represents either the plain text scopedPDU if 1051 the privFlag in the msgFlags is zero, or it represents an 1052 encryptedPDU (encoded as an OCTET STRING) which must be decrypted by 1053 the securityModel in use to produce a plaintext scopedPDU. 1055 6.8. scopedPDU 1057 The scopedPDU contains information to identify an administratively 1058 unique context and a PDU. The object identifiers in the PDU refer to 1059 managed objects which are (expected to be) accessible within the 1060 specified context. 1062 6.8.1. contextEngineID 1064 The contextEngineID in the SNMPv3 message, uniquely identifies, 1065 within an administrative domain, an SNMP entity that may realize an 1066 instance of a context with a particular contextName. 1068 For incoming messages, the contextEngineID is used in conjunction 1069 with pduType to determine to which application the scopedPDU will be 1070 sent for processing. 1072 For outgoing messages, the v3MP sets the contextEngineID to the value 1073 provided by the application in the request for a message to be sent. 1075 6.8.2. contextName 1077 The contextName field in an SNMPv3 message, in conjunction with the 1078 contextEngineID field, identifies the particular context associated 1079 with the management information contained in the PDU portion of the 1080 message. The contextName is unique within the SNMP entity specified 1081 by the contextEngineID, which may realize the managed objects 1082 referenced within the PDU. An application which originates a message 1083 provides the value for the contextName field and this value may be 1084 used during processing by an application at the receiving SNMP 1085 Engine. 1087 6.8.3. data 1089 The data field of the SNMPv3 Message contains the PDU. Among other 1090 things, the PDU contains the PDU type that is used by the v3MP to 1091 determine the type of the incoming SNMP message. The v3MP specifies 1092 that the PDU must be one of those specified in [RFC-PROTO]. 1094 7. Elements of Procedure for v3MP 1096 This section describes the procedures followed by an SNMP engine when 1097 generating and processing SNMP messages according to the SNMPv3 1098 Message Processing Model. 1100 Please note, that for the sake of clarity and to prevent the text 1101 from being even longer and more complicated, some details were 1102 omitted from the steps below. 1104 a) Some steps specify that when some error conditions are 1105 encountered when processing a received message, a message 1106 containing a Report PDU is generated and the received message 1107 is discarded without further processing. However, a Report-PDU 1108 must not be generated unless the PDU causing generation of the 1109 Report PDU can be determine to be a member of the Confirmed 1110 Class, or the reportableFlag is set to one and the PDU class 1111 cannot be determined. 1113 b) The elements of procedure do not always explicitly indicate 1114 when state information needs to be released. The general rule 1115 is that if state information is available when a message is to 1116 be "discarded without further processing", then the state 1117 information should also be released at that same time. 1119 7.1. Prepare an Outgoing SNMP Message 1121 This section describes the procedure followed to prepare an SNMPv3 1122 message from the data elements passed by the Message Dispatcher. 1124 1) The Message Dispatcher may request that an SNMPv3 message 1125 containing a Read Class, Write Class, or Notification Class PDU be 1126 prepared for sending. 1128 a) It makes such a request according to the abstract service 1129 primitive: 1131 statusInformation = -- success or errorIndication 1132 prepareOutgoingMessage( 1133 IN transportDomain -- requested transport domain 1134 IN transportAddress -- requested destination address 1135 IN messageProcessingModel -- typically, SNMP version 1136 IN securityModel -- Security Model to use 1137 IN securityName -- on behalf of this principal 1138 IN securityLevel -- Level of Security requested 1139 IN contextEngineID -- data from/at this entity 1140 IN contextName -- data from/in this context 1141 IN pduVersion -- version of the PDU 1142 IN PDU -- SNMP Protocol Data Unit 1143 IN expectResponse -- TRUE or FALSE * 1144 IN sendPduHandle -- the handle for matching 1145 -- incoming responses 1146 OUT destTransportDomain -- destination transport domain 1147 OUT destTransportAddress -- destination transport address 1148 OUT outgoingMessage -- the message to send 1149 OUT outgoingMessageLength -- the length of the message 1150 ) 1152 * The SNMPv3 Message Processing Model does not use the values of 1153 expectResponse or pduVersion. 1155 b) A unique msgID is generated. The number used for msgID should 1156 not have been used recently, and must not be the same as was 1157 used for any outstanding request. 1159 2) The Message Dispatcher may request that an SNMPv3 message 1160 containing a Response Class or Internal Class PDU be prepared for 1161 sending. 1163 a) It makes such a request according to the abstract service 1164 primitive: 1166 result = -- SUCCESS or FAILURE 1167 prepareResponseMessage( 1168 IN messageProcessingModel -- typically, SNMP version 1169 IN securityModel -- same as on incoming request 1170 IN securityName -- same as on incoming request 1171 IN securityLevel -- same as on incoming request 1172 IN contextEngineID -- data from/at this SNMP entity 1173 IN contextName -- data from/in this context 1174 IN pduVersion -- version of the PDU 1175 IN PDU -- SNMP Protocol Data Unit 1176 IN maxSizeResponseScopedPDU -- maximum size sender can accept 1177 IN stateReference -- reference to state 1178 -- information presented with 1179 -- the request 1180 IN statusInformation -- success or errorIndication 1181 -- error counter OID and value 1182 -- when errorIndication 1183 OUT destTransportDomain -- destination transport domain 1184 OUT destTransportAddress -- destination transport address 1185 OUT outgoingMessage -- the message to send 1186 OUT outgoingMessageLength -- the length of the message 1187 ) 1189 b) The cached information for the original request is retrieved 1190 via the stateReference, including 1192 - msgID, 1193 - contextEngineID, 1194 - contextName, 1195 - securityModel, 1196 - securityName, 1197 - securityLevel, 1198 - securityStateReference, 1199 - reportableFlag, 1200 - transportDomain, and 1201 - transportAddress. 1203 The SNMPv3 Message Processing Model does not allow cached data 1204 to be overridden, except by error indications as detailed in 1205 (3) below. 1207 3) If statusInformation contains values for an OID/value combination 1208 (potentially also containing a securityLevel value, 1209 contextEngineID value, or contextName value), then 1211 a) If reportableFlag is zero, then the original message is 1212 discarded, and no further processing is done. A result of 1213 FAILURE is returned. SNMPv3 Message Processing is complete. 1215 b) If a PDU is provided, it is the PDU from the original request. 1216 If possible, extract the request-id. 1218 c) A Report PDU is prepared: 1220 1) the varBindList is set to contain the OID and value from the 1221 statusInformation 1223 2) error-status is set to 0 1225 3) error-index is set to 0. 1227 4) request-id is set to the value extracted in step b) 1228 Otherwise, request-id is set to 0 1230 d) The errorIndication in statusInformation may be accompanied by 1231 a securityLevel value, a contextEngineID value, or a 1232 contextName value. 1234 1) If statusInformation contains a value for securityLevel, 1235 then securityLevel is set to that value, otherwise it is set 1236 to noAuthNoPriv. 1238 2) If statusInformation contains a value for contextEngineID, 1239 then contextEngineID is set to that value, otherwise it is 1240 set to the value of this entity's snmpEngineID. 1242 3) If statusInformation contains a value for contextName, then 1243 contextName is set to that value, otherwise it is set to the 1244 default context of "" (zero-length string). 1246 e) PDU is set to refer to the new Report-PDU. The old PDU is 1247 discarded. 1249 f) Processing continues with step 6) below. 1251 4) If contextEngineID is not yet determined, then the contextEngineID 1252 is determined, in an implementation-dependent manner, possibly 1253 using the transportDomain and transportAddress. 1255 5) If the contextName is not yet determined, the contextName is set 1256 to the default context. 1258 6) A scopedPDU is prepared from the contextEngineID, contextName, and 1259 PDU. 1261 7) msgGlobalData is constructed as follows 1263 a) The msgVersion field is set to snmpv3(3). 1265 b) msgID is set as determined in step 1 or 2 above. 1267 c) msgMaxSize is set to an implementation-dependent value. 1269 d) msgFlags are set as follows: 1271 - If securityLevel specifies noAuthNoPriv, then authFlag and 1272 privFlag are both set to zero. 1274 - If securityLevel specifies authNoPriv, then authFlag is set 1275 to one and privFlag is set to zero. 1277 - If securityLevel specifies authPriv, then authFlag is set to 1278 one and privFlag is set to one. 1280 - If the PDU is from the Unconfirmed Class, then the 1281 reportableFlag is set to zero. 1283 - If the PDU is from the Confirmed Class then the 1284 reportableFlag is set to one. 1286 - All other msgFlags bits are set to zero. 1288 e) msgSecurityModel is set to the value of securityModel 1290 8) If the PDU is from the Response Class or the Internal Class, then 1291 a) The specified Security Model is called to generate the message 1292 according to the primitive: 1294 statusInformation = 1295 generateResponseMsg( 1296 IN messageProcessingModel -- SNMPv3 Message Processing 1297 -- Model 1298 IN globalData -- msgGlobalData from step 7 1299 IN maxMessageSize -- from msgMaxSize (step 7c) 1300 IN securityModel -- as determined in step 7e 1301 IN securityEngineID -- the value of snmpEngineID 1302 IN securityName -- on behalf of this principal 1303 IN securityLevel -- for the outgoing message 1304 IN scopedPDU -- as prepared in step 6) 1305 IN securityStateReference -- as determined in step 2 1306 OUT securityParameters -- filled in by Security Module 1307 OUT wholeMsg -- complete generated message 1308 OUT wholeMsgLength -- length of generated message 1309 ) 1311 If, upon return from the Security Model, the statusInformation 1312 includes an errorIndication, then any cached information about 1313 the outstanding request message is discarded, and an 1314 errorIndication is returned, so it can be returned to the 1315 calling application. SNMPv3 Message Processing is complete. 1317 b) A SUCCESS result is returned. SNMPv3 Message Processing is 1318 complete. 1320 9) If the PDU is from the Confirmed Class or the Notification Class, 1321 then 1323 a) If the PDU is from the Unconfirmed Class, then securityEngineID 1324 is set to the value of this entity's snmpEngineID. 1326 Otherwise, the snmpEngineID of the target entity is determined, 1327 in an implementation-dependent manner, possibly using 1328 transportDomain and transportAddress. The value of 1329 securityEngineID is set to the value of the target entity's 1330 snmpEngineID. 1332 b) The specified Security Model is called to generate the message 1333 according to the primitive: 1335 statusInformation = 1336 generateRequestMsg( 1337 IN messageProcessingModel -- SNMPv3 Message Processing Model 1338 IN globalData -- msgGlobalData, from step 7 1339 IN maxMessageSize -- from msgMaxSize in step 7 c) 1340 IN securityModel -- as provided by caller 1341 IN securityEngineID -- authoritative SNMP entity 1342 -- from step 9 a) 1343 IN securityName -- as provided by caller 1344 IN securityLevel -- as provided by caller 1345 IN scopedPDU -- as prepared in step 6 1346 OUT securityParameters -- filled in by Security Module 1347 OUT wholeMsg -- complete generated message 1348 OUT wholeMsgLength -- length of the generated message 1349 ) 1351 If, upon return from the Security Model, the statusInformation 1352 includes an errorIndication, then the message is discarded, and 1353 the errorIndication is returned, so it can be returned to the 1354 calling application, and no further processing is done. 1355 SNMPv3 Message Processing is complete. 1357 c) If the PDU is from the Confirmed Class, information about the 1358 outgoing message is cached, and a (implementation-specific) 1359 stateReference is created. Information to be cached includes 1360 the values of: 1362 - sendPduHandle 1363 - msgID 1364 - snmpEngineID 1365 - securityModel 1366 - securityName 1367 - securityLevel 1368 - contextEngineID 1369 - contextName 1371 d) A SUCCESS result is returned. SNMPv3 Message Processing is 1372 complete. 1374 7.2. Prepare Data Elements from an Incoming SNMP Message 1376 This section describes the procedure followed to extract data from an 1377 SNMPv3 message, and to prepare the data elements required for further 1378 processing of the message by the Message Dispatcher. 1380 1) The message is passed in from the Message Dispatcher according to 1381 the abstract service primitive: 1383 result = -- SUCCESS or errorIndication 1384 prepareDataElements( 1385 IN transportDomain -- origin transport domain 1386 IN transportAddress -- origin transport address 1387 IN wholeMsg -- as received from the network 1388 IN wholeMsgLength -- as received from the network 1389 OUT messageProcessingModel -- typically, SNMP version 1390 OUT securityModel -- Security Model to use 1391 OUT securityName -- on behalf of this principal 1392 OUT securityLevel -- Level of Security requested 1393 OUT contextEngineID -- data from/at this entity 1394 OUT contextName -- data from/in this context 1395 OUT pduVersion -- version of the PDU 1396 OUT PDU -- SNMP Protocol Data Unit 1397 OUT pduType -- SNMP PDU type 1398 OUT sendPduHandle -- handle for matched request 1399 OUT maxSizeResponseScopedPDU -- maximum size sender can accept 1400 OUT statusInformation -- success or errorIndication 1401 -- error counter OID and value 1402 -- when errorIndication 1403 OUT stateReference -- reference to state information 1404 -- to be used for a possible 1405 ) -- Response 1407 2) If the received message is not the serialization (according to 1408 the conventions of [RFC-TMM]) of an SNMPv3Message value, then the 1409 snmpInASNParseErrs counter [RFC-MIB] is incremented, the message 1410 is discarded without further processing, and a FAILURE result is 1411 returned. SNMPv3 Message Processing is complete. 1413 3) The values for msgVersion, msgID, msgMaxSize, msgFlags, 1414 msgSecurityModel, msgSecurityParameters, and msgData are 1415 extracted from the message. 1417 4) If the value of the msgSecurityModel component does not match a 1418 supported securityModel, then the snmpUnknownSecurityModels 1419 counter is incremented, the message is discarded without further 1420 processing, and a FAILURE result is returned. SNMPv3 Message 1421 Processing is complete. 1423 5) The securityLevel is determined from the authFlag and the 1424 privFlag bits of the msgFlags component as follows: 1426 a) If the authFlag is not set and the privFlag is not set, then 1427 securityLevel is set to noAuthNoPriv. 1429 b) If the authFlag is set and the privFlag is not set, then 1430 securityLevel is set to authNoPriv. 1432 c) If the authFlag is set and the privFlag is set, then 1433 securityLevel is set to authPriv. 1435 d) If the authFlag is not set and privFlag is set, then the 1436 snmpInvalidMsgs counter is incremented, the message is 1437 discarded without further processing, and a FAILURE result is 1438 returned. SNMPv3 Message Processing is complete. 1440 e) Any other bits in the msgFlags are ignored. 1442 6) The security module implementing the Security Model as specified 1443 by the securityModel component is called for authentication and 1444 privacy services. This is done according to the abstract service 1445 primitive: 1447 statusInformation = -- errorIndication or success 1448 -- error counter OID and 1449 -- value if error 1450 processIncomingMsg( 1451 IN messageProcessingModel -- SNMPv3 Message Processing Model 1452 IN maxMessageSize -- of the sending SNMP entity 1453 IN securityParameters -- for the received message 1454 IN securityModel -- for the received message 1455 IN securityLevel -- Level of Security 1456 IN wholeMsg -- as received on the wire 1457 IN wholeMsgLength -- length as received on the wire 1458 OUT securityEngineID -- authoritative SNMP entity 1459 OUT securityName -- identification of the principal 1460 OUT scopedPDU, -- message (plaintext) payload 1461 OUT maxSizeResponseScopedPDU -- maximum size sender can accept 1462 OUT securityStateReference -- reference to security state 1463 ) -- information, needed for 1464 -- response 1466 If an errorIndication is returned by the security module, then 1468 a) If statusInformation contains values for an OID/value pair, 1469 then generation of a Report PDU is attempted (see step 3 in 1470 section 7.1). 1472 1) If the scopedPDU has been returned from processIncomingMsg 1473 then determine contextEngineID, contextName, and PDU. 1475 2) Information about the message is cached and a 1476 stateReference is created (implementation-specific). 1478 Information to be cached includes the values of: 1480 msgVersion, 1481 msgID, 1482 securityLevel, 1483 msgFlags, 1484 msgMaxSize, 1485 securityModel, 1486 maxSizeResponseScopedPDU, 1487 securityStateReference 1489 3) Request that a Report-PDU be prepared and sent, according 1490 to the abstract service primitive: 1492 result = -- SUCCESS or FAILURE 1493 returnResponsePdu( 1494 IN messageProcessingModel -- SNMPv3(3) 1495 IN securityModel -- same as on incoming request 1496 IN securityName -- from processIncomingMsg 1497 IN securityLevel -- same as on incoming request 1498 IN contextEngineID -- from step 6 a) 1) 1499 IN contextName -- from step 6 a) 1) 1500 IN pduVersion -- SNMPv2-PDU 1501 IN PDU -- from step 6 a) 1) 1502 IN maxSizeResponseScopedPDU -- from processIncomingMsg 1503 IN stateReference -- from step 6 a) 2) 1504 IN statusInformation -- from processIncomingMsg 1505 ) 1507 b) The incoming message is discarded without further processing, 1508 and a FAILURE result is returned. SNMPv3 Message Processing is 1509 complete. 1511 7) The scopedPDU is parsed to extract the contextEngineID, the 1512 contextName and the PDU. If any parse error occurs, then the 1513 snmpInASNParseErrs counter [RFC-MIB] is incremented, the security 1514 state information is discarded, the message is discarded without 1515 further processing, and a FAILURE result is returned. SNMPv3 1516 Message Processing is complete. Treating an unknown PDU type is 1517 treated as a parse error is an implementation option. 1519 8) The pduVersion is determined in an implementation-dependent 1520 manner. For SNMPv3, the pduVersion would be an SNMPv2-PDU. 1522 9) The pduType is determined, in an implementation-dependent manner. 1523 For RFC -PROTO, the pduTypes include: 1525 - GetRequest-PDU, 1526 - GetNextRequest-PDU, 1527 - GetBulkRequest-PDU, 1528 - SetRequest-PDU, 1529 - InformRequest-PDU, 1530 - SNMPv2-Trap-PDU, 1531 - Response-PDU, 1532 - Report-PDU. 1534 10) If the pduType is from the Response Class or the Internal Class, 1535 then 1537 a) The value of the msgID component is used to find the cached 1538 information for a corresponding outstanding Request message. 1539 If no such outstanding Request message is found, then the 1540 security state information is discarded, the message is 1541 discarded without further processing, and a FAILURE result is 1542 returned. SNMPv3 Message Processing is complete. 1544 b) sendPduHandle is retrieved from the cached information. 1546 Otherwise, sendPduHandle is set to , an implementation 1547 defined value. 1549 11) If the pduType is from the Internal Class, then 1551 a) statusInformation is created using the contents of the 1552 Report-PDU, in an implementation-dependent manner. This 1553 statusInformation will be forwarded to the application 1554 associated with the sendPduHandle. 1556 b) The cached data for the outstanding message, referred to by 1557 stateReference, is retrieved. If the securityModel or 1558 securityLevel values differ from the cached ones, it is 1559 important to recognize that Internal Class PDUs delivered at 1560 the security level of noAuthNoPriv open a window of 1561 opportunity for spoofing or replay attacks. If the receiver 1562 of such messages is aware of these risks, the use of such 1563 unauthenticated messages is acceptable and may provide a 1564 useful function for discovering engine IDs or for detecting 1565 misconfiguration at remote nodes. 1567 When the securityModel or securityLevel values differ from 1568 the cached ones, an implementation may retain the cached 1569 information about the outstanding Request message, in 1570 anticipation of the possibility that the Internal Class PDU 1571 received might be illegitimate. Otherwise, any cached 1572 information about the outstanding Request message message is 1573 discarded. 1575 c) The security state information for this incoming message is 1576 discarded. 1578 d) stateReference is set to 1580 e) A SUCCESS result is returned. SNMPv3 Message Processing is 1581 complete. 1583 12) If the pduType is from the Response Class, then 1585 a) The cached data for the outstanding request, referred to by 1586 stateReference, is retrieved, including 1588 - snmpEngineID 1589 - securityModel 1590 - securityName 1591 - securityLevel 1592 - contextEngineID 1593 - contextName 1595 b) If the values extracted from the incoming message differ from 1596 the cached data, then any cached information about the 1597 outstanding Request message is discarded, the incoming 1598 message is discarded without further processing, and a 1599 FAILURE result is returned. SNMPv3 Message Processing is 1600 complete. 1602 When the securityModel or securityLevel values differ from 1603 the cached ones, an implementation may retain the cached 1604 information about the outstanding Request message, in 1605 anticipation of the possibility that the Response Class PDU 1606 received might be illegitimate. 1608 c) Otherwise, any cached information about the outstanding 1609 Request message is discarded, and stateReference is set to 1610 . 1612 d) A SUCCESS result is returned. SNMPv3 Message Processing is 1613 complete. 1615 13) If the pduType is from the Confirmed Class, then 1617 a) If the value of securityEngineID is not equal to the value of 1618 snmpEngineID, then the security state information is 1619 discarded, any cached information about this message is 1620 discarded, the incoming message is discarded without further 1621 processing, and a FAILURE result is returned. SNMPv3 Message 1622 Processing is complete. 1624 b) Information about the message is cached and a stateReference 1625 is created (implementation-specific). Information to be 1626 cached includes the values of: 1628 msgVersion, 1629 msgID, 1630 securityLevel, 1631 msgFlags, 1632 msgMaxSize, 1633 securityModel, 1634 maxSizeResponseScopedPDU, 1635 securityStateReference 1637 c) A SUCCESS result is returned. SNMPv3 Message Processing is 1638 complete. 1640 14) If the pduType is from the Unconfirmed Class, then A SUCCESS 1641 result is returned. SNMPv3 Message Processing is complete. 1643 8. Intellectual Property 1645 The IETF takes no position regarding the validity or scope of any 1646 intellectual property or other rights that might be claimed to 1647 pertain to the implementation or use of the technology described in 1648 this document or the extent to which any license under such rights 1649 might or might not be available; neither does it represent that it 1650 has made any effort to identify any such rights. Information on the 1651 IETF's procedures with respect to rights in standards-track and 1652 standards-related documentation can be found in BCP-11. Copies of 1653 claims of rights made available for publication and any assurances of 1654 licenses to be made available, or the result of an attempt made to 1655 obtain a general license or permission for the use of such 1656 proprietary rights by implementors or users of this specification can 1657 be obtained from the IETF Secretariat. 1659 The IETF invites any interested party to bring to its attention any 1660 copyrights, patents or patent applications, or other proprietary 1661 rights which may cover technology that may be required to practice 1662 this standard. Please address the information to the IETF Executive 1663 Director. 1665 9. Acknowledgements 1667 This document is the result of the efforts of the SNMPv3 Working 1668 Group. Some special thanks are in order to the following SNMPv3 WG 1669 members: 1671 Harald Tveit Alvestrand (Maxware) 1672 Dave Battle (SNMP Research, Inc.) 1673 Alan Beard (Disney Worldwide Services) 1674 Paul Berrevoets (SWI Systemware/Halcyon Inc.) 1675 Martin Bjorklund (Ericsson) 1676 Uri Blumenthal (IBM T. J. Watson Research Center) 1677 Jeff Case (SNMP Research, Inc.) 1678 John Curran (BBN) 1679 Mike Daniele (Compaq Computer Corporation) 1680 T. Max Devlin (Eltrax Systems) 1681 John Flick (Hewlett Packard) 1682 Rob Frye (MCI) 1683 Wes Hardaker (U.C.Davis, Information Technology - D.C.A.S.) 1684 David Harrington (Cabletron Systems Inc.) 1685 Lauren Heintz (BMC Software, Inc.) 1686 N.C. Hien (IBM T. J. Watson Research Center) 1687 Michael Kirkham (InterWorking Labs, Inc.) 1688 Dave Levi (SNMP Research, Inc.) 1689 Louis A Mamakos (UUNET Technologies Inc.) 1690 Joe Marzot (Nortel Networks) 1691 Paul Meyer (Secure Computing Corporation) 1692 Keith McCloghrie (Cisco Systems) 1693 Bob Moore (IBM) 1694 Russ Mundy (TIS Labs at Network Associates) 1695 Bob Natale (ACE*COMM Corporation) 1696 Mike O'Dell (UUNET Technologies Inc.) 1697 Dave Perkins (DeskTalk) 1698 Peter Polkinghorne (Brunel University) 1699 Randy Presuhn (BMC Software, Inc.) 1700 David Reeder (TIS Labs at Network Associates) 1701 David Reid (SNMP Research, Inc.) 1702 Aleksey Romanov (Quality Quorum) 1703 Shawn Routhier (Epilogue) 1704 Juergen Schoenwaelder (TU Braunschweig) 1705 Bob Stewart (Cisco Systems) 1706 Mike Thatcher (Independent Consultant) 1707 Bert Wijnen (IBM T. J. Watson Research Center) 1709 The document is based on recommendations of the IETF Security and 1710 Administrative Framework Evolution for SNMP Advisory Team. Members 1711 of that Advisory Team were: 1713 David Harrington (Cabletron Systems Inc.) 1714 Jeff Johnson (Cisco Systems) 1715 David Levi (SNMP Research Inc.) 1716 John Linn (Openvision) 1717 Russ Mundy (Trusted Information Systems) chair 1718 Shawn Routhier (Epilogue) 1719 Glenn Waters (Nortel) 1720 Bert Wijnen (IBM T. J. Watson Research Center) 1722 As recommended by the Advisory Team and the SNMPv3 Working Group 1723 Charter, the design incorporates as much as practical from previous 1724 RFCs and drafts. As a result, special thanks are due to the authors 1725 of previous designs known as SNMPv2u and SNMPv2*: 1727 Jeff Case (SNMP Research, Inc.) 1728 David Harrington (Cabletron Systems Inc.) 1729 David Levi (SNMP Research, Inc.) 1730 Keith McCloghrie (Cisco Systems) 1731 Brian O'Keefe (Hewlett Packard) 1732 Marshall T. Rose (Dover Beach Consulting) 1733 Jon Saperia (BGS Systems Inc.) 1734 Steve Waldbusser (International Network Services) 1735 Glenn W. Waters (Bell-Northern Research Ltd.) 1737 10. Security Considerations 1739 The Dispatcher coordinates the processing of messages to provide a 1740 level of security for management messages and to direct the SNMP PDUs 1741 to the proper SNMP application(s). 1743 A Message Processing Model, and in particular the V3MP defined in 1744 this document, interacts as part of the Message Processing with 1745 Security Models in the Security Subsystem via the abstract service 1746 interface primitives defined in [RFC-ARCH] and elaborated above. 1748 The level of security actually provided is primarily determined by 1749 the specific Security Model implementation(s) and the specific SNMP 1750 application implementation(s) incorporated into this framework. 1751 Applications have access to data which is not secured. Applications 1752 should take reasonable steps to protect the data from disclosure, and 1753 when they send data across the network, they should obey the 1754 securityLevel and call upon the services of an Access Control Model 1755 as they apply access control. 1757 The values for the msgID element used in communication between SNMP 1758 entities must be chosen to avoid replay attacks. The values do not 1759 need to be unpredictable; it is sufficient that they not repeat. 1761 When exchanges are carried out over an insecure network, there is an 1762 open opportunity for a third party to spoof or replay messages when 1763 any message of an exchange is given at the security level of 1764 noAuthNoPriv. For most exchanges, all messages exist at the same 1765 security level. In the case where the final message is an Internal 1766 Class PDU, this message may be delivered at a level of noAuthNoPriv 1767 or authNoPriv, independent of the security level of the preceding 1768 messages. Internal Class PDUs delivered at the level of authNoPriv 1769 are not considered to pose a security hazard. Internal Class PDUs 1770 delivered at the security level of noAuthNoPriv open a window of 1771 opportunity for spoofing or replay attacks. If the receiver of such 1772 messages is aware of these risks, the use of such unauthenticated 1773 messages is acceptable and may provide a useful function for 1774 discovering engine IDs or for detecting misconfiguration at remote 1775 nodes. 1777 This document also contains a MIB definition module. None of the 1778 objects defined is writable, and the information they represent is 1779 not deemed to be particularly sensitive. However, if they are deemed 1780 sensitive in a particular environment, access to them should be 1781 restricted through the use of appropriately configured Security and 1782 Access Control models. 1784 11. References 1786 [RFC1901] The SNMPv2 Working Group, Case, J., McCloghrie, K., 1787 Rose, M. and S. Waldbusser, "Introduction to 1788 Community-based SNMPv2", RFC 1901, January 1996. 1790 [RFC2578] McCloghrie, K., Perkins, D. and J. Schoenwaelder, 1791 "Structure of Management Information Version 2 (SMIv2)", 1792 STD 58, RFC 2578, April 1999. 1794 [RFC-PROTO] Presuhn, R., Case, J., McCloghrie, K., Rose, M., and S. 1795 Waldbusser, "Protocol Operations for the Simple Network 1796 Management Protocol", 1797 , February 2001. 1799 [RFC-TMM] Presuhn, R., Case, J., McCloghrie, K., Rose, M., and S. 1800 Waldbusser, "Transport Mappings for the Simple Network 1801 Management Protocol", 1802 , February 1803 2001. 1805 [RFC-MIB] Presuhn, R., Case, J., McCloghrie, K., Rose, M. and S. 1806 Waldbusser, "Management Information Base for the Simple 1807 Network Management Protocol", 1808 , February 2001. 1810 [RFC-COEX] Frye, R., Levi, D., Routhier, S., and B. Wijnen, 1811 "Coexistence between Version 1, Version 2, and Version 3 1812 of the Internet-standard Network Management Framework", 1813 , February 2001. 1815 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1816 Requirement Levels", BCP 14, RFC 2119, March 1997. 1818 [RFC2028] Hovey, R. and S. Bradner, "The Organizations Involved in 1819 the IETF Standards Process", BCP 11, RFC 2028, October 1820 1996. 1822 [RFC-ARCH] Harrington, D., Presuhn, R. and B. Wijnen, "An 1823 Architecture for describing SNMP Management Frameworks", 1824 , February 2001. 1826 [RFC-USM] Blumenthal, U. and B. Wijnen, "The User-Based Security 1827 Model for Version 3 of the Simple Network Management 1828 Protocol (SNMPv3)", , 1829 February 2001. 1831 [RFC-ACM] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based 1832 Access Control Model for the Simple Network Management 1833 Protocol (SNMP)", , 1834 February 2001. 1836 [RFC-APPL] Levi, D., Meyer, P. and B. Stewart, "SNMP 1837 Applications", , 1838 February 2001. 1840 [RFC2570] Case, J., Mundy, R., Partain, D. and B. Stewart, 1841 "Introduction to Version 3 of the Internet-standard 1842 Network Management Framework", RFC 2570, April 1999. 1844 12. Editors' Addresses 1846 Jeffrey Case 1847 SNMP Research, Inc. 1848 3001 Kimberlin Heights Road 1849 Knoxville, TN 37920-9716 1850 USA 1852 Phone: +1 423-573-1434 1853 EMail: case@snmp.com 1854 David Harrington 1855 Enterasys Networks 1856 35 Industrial Way 1857 Post Office Box 5005 1858 Rochester, NH 03866-5005 1859 USA 1861 Phone: +1 603-337-2614 1862 EMail: dbh@enterasys.com 1864 Randy Presuhn 1865 BMC Software, Inc. 1866 2141 North First Street 1867 San Jose, CA 95131 1868 USA 1870 Phone: +1 408-546-1006 1871 EMail: randy_presuhn@bmc.com 1873 Bert Wijnen 1874 Lucent Technologies 1875 Schagen 33 1876 3461 GL Linschoten 1877 Netherlands 1879 Phone: +31 348-680-485 1880 EMail: bwijnen@lucent.com 1882 13. Changes From RFC 2572 1884 The following change log records major changes from the previous 1885 version of this document, RFC 2572. 1887 - Added working group co-chair address. 1889 - Updated working group mailing list subscription information. 1891 - Updated editor contact information. 1893 - Updated copyright dates. 1895 14. Full Copyright Statement 1897 Copyright (C) The Internet Society (2001). All Rights Reserved. 1899 This document and translations of it may be copied and furnished to 1900 others, and derivative works that comment on or otherwise explain it 1901 or assist in its implementation may be prepared, copied, published 1902 and distributed, in whole or in part, without restriction of any 1903 kind, provided that the above copyright notice and this paragraph are 1904 included on all such copies and derivative works. However, this 1905 document itself may not be modified in any way, such as by removing 1906 the copyright notice or references to the Internet Society or other 1907 Internet organizations, except as needed for the purpose of 1908 developing Internet standards in which case the procedures for 1909 copyrights defined in the Internet Standards process must be 1910 followed, or as required to translate it into languages other than 1911 English. 1913 The limited permissions granted above are perpetual and will not be 1914 revoked by the Internet Society or its successors or assigns. 1916 This document and the information contained herein is provided on an 1917 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1918 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1919 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1920 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1921 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1923 Acknowledgement 1925 Funding for the RFC Editor function is currently provided by the 1926 Internet Society.