idnits 2.17.1 draft-ietf-snmpv3-mpd-v2-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 9 instances of too long lines in the document, the longest one being 2 characters 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 (3 October 2001) is 8239 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: 'RFC2578' is defined on line 1797, but no explicit reference was found in the text == Unused Reference: 'RFC-COEX' is defined on line 1817, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 1822, but no explicit reference was found in the text == Unused Reference: 'RFC2028' is defined on line 1825, but no explicit reference was found in the text == Unused Reference: 'RFC-USM' is defined on line 1833, but no explicit reference was found in the text == Unused Reference: 'RFC-ACM' is defined on line 1839, but no explicit reference was found in the text == Unused Reference: 'RFC-APPL' is defined on line 1844, but no explicit reference was found in the text == Unused Reference: 'RFC2570' is defined on line 1848, 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' ** Obsolete normative reference: RFC 2574 (ref. 'RFC-USM') (Obsoleted by RFC 3414) -- 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: 10 errors (**), 0 flaws (~~), 11 warnings (==), 9 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 3 October 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 an 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 * One or more models may be present. 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 [RFC-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 [RFC-PROTO]. 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 [RFC-PROTO] elements of procedure and syntax instead 288 of those specified for SNMPv1. 290 3.3. pduType 292 A value of pduType represents a specific type of protocol operation. 293 The values of pduType are specific to the version of the PDU 294 contained in a message. 296 Applications register to support particular pduTypes for particular 297 contextEngineIDs. 299 For incoming messages, pduType is provided to the Dispatcher by a 300 version-specific Message Processing module. It is subsequently used 301 to dispatch the PDU to the application which registered for the 302 pduType for the contextEngineID of the associated scopedPDU. 304 3.4. sendPduHandle 306 This handle is generated for coordinating the processing of requests 307 and responses between the SNMP engine and an application. The handle 308 must be unique across all version-specific Message Processing Models, 309 and is of local significance only. 311 4. Dispatcher Elements of Procedure 313 This section describes the procedures followed by the Dispatcher when 314 generating and processing SNMP messages. 316 4.1. Sending an SNMP Message to the Network 318 This section describes the procedure followed by an SNMP engine 319 whenever it sends an SNMP message. 321 4.1.1. Sending a Request or Notification 323 The following procedures are followed by the Dispatcher when an 324 application wants to send an SNMP PDU to another (remote) 325 application, i.e., to initiate a communication by originating a 326 message, such as one containing a request or a trap. 328 1) The application requests this using the abstract service 329 primitive: 331 statusInformation = -- sendPduHandle if success 332 -- errorIndication if failure 333 sendPdu( 334 IN transportDomain -- transport domain to be used 335 IN transportAddress -- destination network address 336 IN messageProcessingModel -- typically, SNMP version 337 IN securityModel -- Security Model to use 338 IN securityName -- on behalf of this principal 339 IN securityLevel -- Level of Security requested 340 IN contextEngineID -- data from/at this entity 341 IN contextName -- data from/in this context 342 IN pduVersion -- the version of the PDU 343 IN PDU -- SNMP Protocol Data Unit 344 IN expectResponse -- TRUE or FALSE 345 ) 347 2) If the messageProcessingModel value does not represent a Message 348 Processing Model known to the Dispatcher, then an errorIndication 349 (implementation-dependent) is returned to the calling application. 350 No further processing is performed. 352 3) The Dispatcher generates a sendPduHandle to coordinate subsequent 353 processing. 355 4) The Message Dispatcher sends the request to the version-specific 356 Message Processing module identified by messageProcessingModel 357 using the abstract service primitive: 359 statusInformation = - success or error indication 360 prepareOutgoingMessage( 361 IN transportDomain -- as specified by application 362 IN transportAddress -- as specified by application 363 IN messageProcessingModel -- as specified by application 364 IN securityModel -- as specified by application 365 IN securityName -- as specified by application 366 IN securityLevel -- as specified by application 367 IN contextEngineID -- as specified by application 368 IN contextName -- as specified by application 369 IN pduVersion -- as specified by application 370 IN PDU -- as specified by application 371 IN expectResponse -- as specified by application 372 IN sendPduHandle -- as determined in step 3. 373 OUT destTransportDomain -- destination transport domain 374 OUT destTransportAddress -- destination transport address 375 OUT outgoingMessage -- the message to send 376 OUT outgoingMessageLength -- the message length 377 ) 379 5) If the statusInformation indicates an error, the errorIndication 380 is returned to the calling application. No further processing is 381 performed. 383 6) If the statusInformation indicates success, the sendPduHandle is 384 returned to the application, and the outgoingMessage is sent. The 385 transport used to send the outgoingMessage is returned via 386 destTransportDomain, and the address to which it was sent is 387 returned via destTransportAddress. 389 Outgoing Message Processing is complete. 391 4.1.2. Sending a Response to the Network 393 The following procedure is followed when an application wants to 394 return a response back to the originator of an SNMP Request. 396 1) An application can request this using the abstract service 397 primitive: 399 result = 400 returnResponsePdu( 401 IN messageProcessingModel -- typically, SNMP version 402 IN securityModel -- Security Model in use 403 IN securityName -- on behalf of this principal 404 IN securityLevel -- same as on incoming request 405 IN contextEngineID -- data from/at this SNMP entity 406 IN contextName -- data from/in this context 407 IN pduVersion -- the version of the PDU 408 IN PDU -- SNMP Protocol Data Unit 409 IN maxSizeResponseScopedPDU -- maximum size of Response PDU 410 IN stateReference -- reference to state information 411 -- as presented with the request 412 IN statusInformation -- success or errorIndication 413 ) -- (error counter OID and value 414 -- when errorIndication) 416 2) The Message Dispatcher sends the request to the appropriate 417 Message Processing Model indicated by the received value of 418 messageProcessingModel using the abstract service primitive: 420 result = -- SUCCESS or errorIndication 421 prepareResponseMessage( 422 IN messageProcessingModel -- specified by application 423 IN securityModel -- specified by application 424 IN securityName -- specified by application 425 IN securityLevel -- specified by application 426 IN contextEngineID -- specified by application 427 IN contextName -- specified by application 428 IN pduVersion -- specified by application 429 IN PDU -- specified by application 430 IN maxSizeResponseScopedPDU -- specified by application 431 IN stateReference -- specified by application 432 IN statusInformation -- specified by application 433 OUT destTransportDomain -- destination transport domain 434 OUT destTransportAddress -- destination transport address 435 OUT outgoingMessage -- the message to send 436 OUT outgoingMessageLength -- the message length 437 ) 439 3) If the result is an errorIndication, the errorIndication is 440 returned to the calling application. No further processing is 441 performed. 443 4) If the result is success, the outgoingMessage is sent. The 444 transport used to send the outgoingMessage is returned via 445 destTransportDomain, and the address to which it was sent is 446 returned via destTransportAddress. 448 Message Processing is complete. 450 4.2. Receiving an SNMP Message from the Network 452 This section describes the procedure followed by an SNMP engine 453 whenever it receives an SNMP message. 455 Please note, that for the sake of clarity and to prevent the text 456 from being even longer and more complicated, some details were 457 omitted from the steps below. In particular, The elements of 458 procedure do not always explicitly indicate when state information 459 needs to be released. The general rule is that if state information 460 is available when a message is to be "discarded without further 461 processing", then the state information must also be released at that 462 same time. 464 4.2.1. Message Dispatching of received SNMP Messages 466 1) The snmpInPkts counter [RFC-MIB] is incremented. 468 2) The version of the SNMP message is determined in an 469 implementation-dependent manner. If the packet cannot be 470 sufficiently parsed to determine the version of the SNMP message, 471 then the snmpInASNParseErrs [RFC-MIB] counter is incremented, and 472 the message is discarded without further processing. If the 473 version is not supported, then the snmpInBadVersions [RFC-MIB] 474 counter is incremented, and the message is discarded without 475 further processing. 477 3) The origin transportDomain and origin transportAddress are 478 determined. 480 4) The message is passed to the version-specific Message Processing 481 Model which returns the abstract data elements required by the 482 Dispatcher. This is performed using the abstract service 483 primitive: 485 result = -- SUCCESS or errorIndication 486 prepareDataElements( 487 IN transportDomain -- origin as determined in step 3. 488 IN transportAddress -- origin as determined in step 3. 489 IN wholeMsg -- as received from the network 490 IN wholeMsgLength -- as received from the network 491 OUT messageProcessingModel -- typically, SNMP version 492 OUT securityModel -- Security Model specified 493 OUT securityName -- on behalf of this principal 494 OUT securityLevel -- Level of Security specified 495 OUT contextEngineID -- data from/at this entity 496 OUT contextName -- data from/in this context 497 OUT pduVersion -- the version of the PDU 498 OUT PDU -- SNMP Protocol Data Unit 499 OUT pduType -- SNMP PDU type 500 OUT sendPduHandle -- handle for a matched request 501 OUT maxSizeResponseScopedPDU -- maximum size of Response PDU 502 OUT statusInformation -- success or errorIndication 503 -- (error counter OID and value 504 -- when errorIndication) 505 OUT stateReference -- reference to state information 506 -- to be used for a possible 507 ) -- Response 509 5) If the result is a FAILURE errorIndication, the message is 510 discarded without further processing. 512 6) At this point, the abstract data elements have been prepared and 513 processing continues as described in Section 4.2.2, PDU 514 Dispatching for Incoming Messages. 516 4.2.2. PDU Dispatching for Incoming Messages 518 The elements of procedure for the dispatching of PDUs depends on the 519 value of sendPduHandle. If the value of sendPduHandle is , 520 then this is a request or notification and the procedures specified 521 in Section 4.2.2.1 apply. If the value of snmpPduHandle is not 522 , then this is a response and the procedures specified in 523 Section 4.2.2.2 apply. 525 4.2.2.1. Incoming Requests and Notifications 527 The following procedures are followed for the dispatching of PDUs 528 when the value of sendPduHandle is , indicating this is a 529 request or notification. 531 1) The combination of contextEngineID and pduType is used to 532 determine which application has registered for this request or 533 notification. 535 2) If no application has registered for the combination, then 537 a) The snmpUnknownPDUHandlers counter is incremented. 539 b) A Response message is generated using the abstract service 540 primitive: 542 result = -- SUCCESS or FAILURE 543 prepareResponseMessage( 544 IN messageProcessingModel -- as provided by MP module 545 IN securityModel -- as provided by MP module 546 IN securityName -- as provided by MP module 547 IN securityLevel -- as provided by MP module 548 IN contextEngineID -- as provided by MP module 549 IN contextName -- as provided by MP module 550 IN pduVersion -- as provided by MP module 551 IN PDU -- as provided by MP module 552 IN maxSizeResponseScopedPDU -- as provided by MP module 553 IN stateReference -- as provided by MP module 554 IN statusInformation -- errorIndication plus 555 -- snmpUnknownPDUHandlers OID 556 -- value pair. 557 OUT destTransportDomain -- destination transportDomain 558 OUT destTransportAddress -- destination transportAddress 559 OUT outgoingMessage -- the message to send 560 OUT outgoingMessageLength -- its length 561 ) 563 c) If the result is SUCCESS, then the prepared message is sent to 564 the originator of the request as identified by the 565 transportDomain and transportAddress. The transport used to 566 send the outgoingMessage is returned via destTransportDomain, 567 and the address to which it was sent is returned via 568 destTransportAddress. 570 d) The incoming message is discarded without further processing. 571 Message Processing for this message is complete. 573 3) The PDU is dispatched to the application, using the abstract 574 service primitive: 576 processPdu( -- process Request/Notification 577 IN messageProcessingModel -- as provided by MP module 578 IN securityModel -- as provided by MP module 579 IN securityName -- as provided by MP module 580 IN securityLevel -- as provided by MP module 581 IN contextEngineID -- as provided by MP module 582 IN contextName -- as provided by MP module 583 IN pduVersion -- as provided by MP module 584 IN PDU -- as provided by MP module 585 IN maxSizeResponseScopedPDU -- as provided by MP module 586 IN stateReference -- as provided by MP module 587 -- needed when sending response 588 ) 590 Message processing for this message is complete. 592 4.2.2.2. Incoming Responses 594 The following procedures are followed for the dispatching of PDUs 595 when the value of sendPduHandle is not , indicating this is a 596 response. 598 1) The value of sendPduHandle is used to determine, in an 599 implementation-defined manner, which application is waiting for 600 a response associated with this sendPduHandle. 602 2) If no waiting application is found, the message is discarded 603 without further processing, and the stateReference is released. 604 The snmpUnknownPDUHandlers counter is incremented. Message 605 Processing is complete for this message. 607 3) Any cached information, including stateReference, about the 608 message is discarded. 610 4) The response is dispatched to the application using the 611 abstract service primitive: 613 processResponsePdu( -- process Response PDU 614 IN messageProcessingModel -- provided by the MP module 615 IN securityModel -- provided by the MP module 616 IN securityName -- provided by the MP module 617 IN securityLevel -- provided by the MP module 618 IN contextEngineID -- provided by the MP module 619 IN contextName -- provided by the MP module 620 IN pduVersion -- provided by the MP module 621 IN PDU -- provided by the MP module 622 IN statusInformation -- provided by the MP module 623 IN sendPduHandle -- provided by the MP module 624 ) 626 Message Processing is complete for this message. 628 4.3. Application Registration for Handling PDU types 630 Applications that want to process certain PDUs must register with the 631 PDU Dispatcher. Applications specify the combination of 632 contextEngineID and pduType(s) for which they want to take 633 responsibility 635 1) An application registers according to the abstract interface 636 primitive: 638 statusInformation = -- success or errorIndication 639 registerContextEngineID( 640 IN contextEngineID -- take responsibility for this one 641 IN pduType -- the pduType(s) to be registered 642 ) 644 Note: implementations may provide a means of requesting 645 registration for simultaneous multiple contextEngineID values, 646 e.g., all contextEngineID values, and may also provide means for 647 requesting simultaneous registration for multiple values of 648 pduType. 650 2) The parameters may be checked for validity; if they are not, then 651 an errorIndication (invalidParameter) is returned to the 652 application. 654 3) Each combination of contextEngineID and pduType can be registered 655 only once. If another application has already registered for the 656 specified combination, then an errorIndication (alreadyRegistered) 657 is returned to the application. 659 4) Otherwise, the registration is saved so that SNMP PDUs can be 660 dispatched to this application. 662 4.4. Application Unregistration for Handling PDU Types 664 Applications that no longer want to process certain PDUs must 665 unregister with the PDU Dispatcher. 667 1) An application unregisters using the abstract service primitive: 669 unregisterContextEngineID( 670 IN contextEngineID -- give up responsibility for this 671 IN pduType -- the pduType(s) to be unregistered 672 ) 673 Note: implementations may provide means for requesting 674 unregistration for simultaneous multiple contextEngineID values, 675 e.g., all contextEngineID values, and may also provide means for 676 requesting simultaneous unregistration for multiple values of 677 pduType. 679 2) If the contextEngineID and pduType combination has been 680 registered, then the registration is deleted. 682 If no such registration exists, then the request is ignored. 684 5. Definitions 686 5.1. Definitions for SNMP Message Processing and Dispatching 688 SNMP-MPD-MIB DEFINITIONS ::= BEGIN 690 IMPORTS 691 MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF 692 MODULE-IDENTITY, OBJECT-TYPE, 693 snmpModules, Counter32 FROM SNMPv2-SMI; 695 snmpMPDMIB MODULE-IDENTITY 696 LAST-UPDATED "200110040533Z" 697 ORGANIZATION "SNMPv3 Working Group" 698 CONTACT-INFO "WG-EMail: snmpv3@lists.tislabs.com 699 Subscribe: snmpv3-request@lists.tislabs.com 701 Co-Chair: Russ Mundy 702 TIS Labs at Network Associates 703 postal: 3060 Washington Road 704 Glenwood, MD 21738 705 USA 706 EMail: mundy@tislabs.com 707 phone: +1 301-854-6889 708 Co-Chair & 709 Co-editor: David Harrington 710 Enterasys Networks 711 postal: 35 Industrial Way 712 P. O. Box 5005 713 Rochester NH 03866-5005 714 USA 715 EMail: dbh@enterasys.com 716 phone: +1 603-337-2614 718 Co-editor: Jeffrey Case 719 SNMP Research, Inc. 720 postal: 3001 Kimberlin Heights Road 721 Knoxville, TN 37920-9716 722 USA 723 EMail: case@snmp.com 724 phone: +1 423-573-1434 726 Co-editor: Randy Presuhn 727 BMC Software, Inc. 728 postal: 2141 North First Street 729 San Jose, CA 95131 730 USA 731 EMail: randy_presuhn@bmc.com 732 phone: +1 408-546-1006 734 Co-editor: Bert Wijnen 735 Lucent Technologies 736 postal: Schagen 33 737 3461 GL Linschoten 738 Netherlands 739 EMail: bwijnen@lucent.com 740 phone: +31 348-680-485 741 " 742 DESCRIPTION "The MIB for Message Processing and Dispatching" 743 REVISION "200110040533Z" 744 DESCRIPTION "Updated addresses, published as RFC -MPD." 745 REVISION "9905041636Z" -- 4 May 1999 746 DESCRIPTION "Updated addresses, published as RFC 2572." 747 REVISION "9709300000Z" -- 30 September 1997 748 DESCRIPTION "Original version, published as RFC 2272." 749 ::= { snmpModules 11 } 751 -- Administrative assignments *************************************** 753 snmpMPDAdmin OBJECT IDENTIFIER ::= { snmpMPDMIB 1 } 754 snmpMPDMIBObjects OBJECT IDENTIFIER ::= { snmpMPDMIB 2 } 755 snmpMPDMIBConformance OBJECT IDENTIFIER ::= { snmpMPDMIB 3 } 756 -- Statistics for SNMP Messages ************************************* 758 snmpMPDStats OBJECT IDENTIFIER ::= { snmpMPDMIBObjects 1 } 760 snmpUnknownSecurityModels OBJECT-TYPE 761 SYNTAX Counter32 762 MAX-ACCESS read-only 763 STATUS current 764 DESCRIPTION "The total number of packets received by the SNMP 765 engine which were dropped because they referenced a 766 securityModel that was not known to or supported by 767 the SNMP engine. 768 " 769 ::= { snmpMPDStats 1 } 771 snmpInvalidMsgs 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 there were invalid 777 or inconsistent components in the SNMP message. 778 " 779 ::= { snmpMPDStats 2 } 781 snmpUnknownPDUHandlers OBJECT-TYPE 782 SYNTAX Counter32 783 MAX-ACCESS read-only 784 STATUS current 785 DESCRIPTION "The total number of packets received by the SNMP 786 engine which were dropped because the PDU contained 787 in the packet could not be passed to an application 788 responsible for handling the pduType, e.g. no SNMP 789 application had registered for the proper 790 combination of the contextEngineID and the pduType. 791 " 792 ::= { snmpMPDStats 3 } 794 -- Conformance information ****************************************** 796 snmpMPDMIBCompliances OBJECT IDENTIFIER ::= {snmpMPDMIBConformance 1} 797 snmpMPDMIBGroups OBJECT IDENTIFIER ::= {snmpMPDMIBConformance 2} 799 -- Compliance statements 801 snmpMPDCompliance MODULE-COMPLIANCE 802 STATUS current 803 DESCRIPTION "The compliance statement for SNMP entities which 804 implement the SNMP-MPD-MIB. 805 " 806 MODULE -- this module 807 MANDATORY-GROUPS { snmpMPDGroup } 808 ::= { snmpMPDMIBCompliances 1 } 810 snmpMPDGroup OBJECT-GROUP 811 OBJECTS { 812 snmpUnknownSecurityModels, 813 snmpInvalidMsgs, 814 snmpUnknownPDUHandlers 815 } 816 STATUS current 817 DESCRIPTION "A collection of objects providing for remote 818 monitoring of the SNMP Message Processing and 819 Dispatching process. 820 " 821 ::= { snmpMPDMIBGroups 1 } 823 END 825 6. The SNMPv3 Message Format 827 This section defines the SNMPv3 message format and the corresponding 828 SNMP version 3 Message Processing Model (v3MP). 829 SNMPv3MessageSyntax DEFINITIONS IMPLICIT TAGS ::= BEGIN 831 SNMPv3Message ::= SEQUENCE { 832 -- identify the layout of the SNMPv3Message 833 -- this element is in same position as in SNMPv1 834 -- and SNMPv2c, allowing recognition 835 -- the value 3 is used for snmpv3 836 msgVersion INTEGER ( 0 .. 2147483647 ), 837 -- administrative parameters 838 msgGlobalData HeaderData, 839 -- security model-specific parameters 840 -- format defined by Security Model 841 msgSecurityParameters OCTET STRING, 842 msgData ScopedPduData 843 } 845 HeaderData ::= SEQUENCE { 846 msgID INTEGER (0..2147483647), 847 msgMaxSize INTEGER (484..2147483647), 849 msgFlags OCTET STRING (SIZE(1)), 850 -- .... ...1 authFlag 851 -- .... ..1. privFlag 852 -- .... .1.. reportableFlag 853 -- Please observe: 854 -- .... ..00 is OK, means noAuthNoPriv 855 -- .... ..01 is OK, means authNoPriv 856 -- .... ..10 reserved, MUST NOT be used. 857 -- .... ..11 is OK, means authPriv 859 msgSecurityModel INTEGER (1..2147483647) 860 } 862 ScopedPduData ::= CHOICE { 863 plaintext ScopedPDU, 864 encryptedPDU OCTET STRING -- encrypted scopedPDU value 865 } 867 ScopedPDU ::= SEQUENCE { 868 contextEngineID OCTET STRING, 869 contextName OCTET STRING, 870 data ANY -- e.g., PDUs as defined in RFC -PROTO 871 } 872 END 874 6.1. msgVersion 876 The msgVersion field is set to snmpv3(3) and identifies the message 877 as an SNMP version 3 Message. 879 6.2. msgID 881 The msgID is used between two SNMP entities to coordinate request 882 messages and responses, and by the v3MP to coordinate the processing 883 of the message by different subsystem models within the architecture. 885 Values for msgID SHOULD be generated in a manner that avoids re-use 886 of any outstanding values. Doing so provides protection against some 887 replay attacks. One possible implementation strategy would be to use 888 the low-order bits of snmpEngineBoots [RFC-ARCH] as the high-order 889 portion of the msgID value and a monotonically increasing integer for 890 the low-order portion of msgID. 892 Note that the request-id in a PDU may be used by SNMP applications to 893 identify the PDU; the msgID is used by the engine to identify the 894 message which carries a PDU. The engine needs to identify the message 895 even if decryption of the PDU (and request-id) fails. No assumption 896 should be made that the value of the msgID and the value of the 897 request-id are equivalent. 899 The value of the msgID field for a response takes the value of the 900 msgID field from the message to which it is a response. By use of 901 the msgID value, an engine can distinguish the (potentially multiple) 902 outstanding requests, and thereby correlate incoming responses with 903 outstanding requests. In cases where an unreliable datagram service 904 is used, the msgID also provides a simple means of identifying 905 messages duplicated by the network. If a request is retransmitted, a 906 new msgID value SHOULD be used for each retransmission. 908 6.3. msgMaxSize 910 The msgMaxSize field of the message conveys the maximum message size 911 supported by the sender of the message, i.e., the maximum message 912 size that the sender can accept when another SNMP engine sends an 913 SNMP message (be it a response or any other message) to the sender of 914 this message on the transport in use for this message. 916 When an SNMP message is being generated, the msgMaxSize is provided 917 by the SNMP engine which generates the message. At the receiving 918 SNMP engine, the msgMaxSize is used to determine the maximum message 919 size the sender can accommodate. 921 6.4. msgFlags 923 The msgFlags field of the message contains several bit fields which 924 control processing of the message. 926 The reportableFlag is a secondary aid in determining whether a Report 927 PDU MUST be sent. It is only used in cases where the PDU portion of 928 a message cannot be decoded, due to, for example, an incorrect 929 encryption key. If the PDU can be decoded, the PDU type forms the 930 basis for decisions on sending Report PDUs. 932 When the reportableFlag is used, if its value is one, a Report PDU 933 MUST be returned to the sender under those conditions which can cause 934 the generation of Report PDUs. Similarly, when the reportableFlag is 935 used and its value is zero, then a Report PDU MUST NOT be sent. The 936 reportableFlag MUST always be zero when the message contains a PDU 937 from the Unconfirmed Class, such as a Report PDU, a response-type PDU 938 (such as a Response PDU), or an unacknowledged notification-type PDU 939 (such as an SNMPv2-trap PDU). The reportableFlag MUST always be one 940 for a PDU from the Confirmed Class, include request-type PDUs (such 941 as a Get PDU) and an acknowledged notification-type PDUs (such as an 942 Inform PDU). 944 If the reportableFlag is set to one for a message containing a PDU 945 from the Unconfirmed Class, such as a Report PDU, a response-type PDU 946 (such as a Response PDU), or an unacknowledged notification-type PDU 947 (such as an SNMPv2-trap PDU), then the receiver of that message MUST 948 process it as though the reportableFlag had been set to zero. 950 If the reportableFlag is set to zero for a message containing a 951 request-type PDU (such as a Get PDU) or an acknowledged 952 notification-type PDU (such as an Inform PDU), then the receiver of 953 that message MUST process it as though the reportableFlag had been 954 set to one. 956 Report PDUs are generated directly by the SNMPv3 Message Processing 957 Model, and support engine-to-engine communications, but may be passed 958 to applications for processing. 960 An SNMP engine that receives a reportPDU may use it to determine what 961 kind of problem was detected by the remote SNMP engine. It can do so 962 based on the error counter included as the first (and only) varBind 963 of the reportPDU. Based on the detected error, the SNMP engine may 964 try to send a corrected SNMP message. If that is not possible, it 965 may pass an indication of the error to the application on whose 966 behalf the failed SNMP request was issued. 968 The authFlag and privFlag portions of the msgFlags field are set by 969 the sender to indicate the securityLevel that was applied to the 970 message before it was sent on the wire. The receiver of the message 971 MUST apply the same securityLevel when the message is received and 972 the contents are being processed. 974 There are three securityLevels, namely noAuthNoPriv, which is less 975 than authNoPriv, which is in turn less than authPriv. See the SNMP 976 architecture document [RFC-ARCH] for details about the securityLevel. 978 a) authFlag 980 If the authFlag is set to one, then the securityModel used by the 981 SNMP engine which sent the message MUST identify the securityName 982 on whose behalf the SNMP message was generated and MUST provide, 983 in a securityModel-specific manner, sufficient data for the 984 receiver of the message to be able to authenticate that 985 identification. In general, this authentication will allow the 986 receiver to determine with reasonable certainty that the message 987 was: 989 - sent on behalf of the principal associated with the 990 securityName, 992 - was not redirected, 994 - was not modified in transit, and 996 - was not replayed. 998 If the authFlag is zero, then the securityModel used by the SNMP 999 engine which sent the message MUST identify the securityName on 1000 whose behalf the SNMP message was generated but it does not need 1001 to provide sufficient data for the receiver of the message to 1002 authenticate the identification, as there is no need to 1003 authenticate the message in this case. 1005 b) privFlag 1007 If the privFlag is set, then the securityModel used by the SNMP 1008 engine which sent the message MUST also protect the scopedPDU in 1009 an SNMP message from disclosure, i.e., it MUST encrypt/decrypt the 1010 scopedPDU. If the privFlag is zero, then the securityModel in use 1011 does not need to protect the data from disclosure. 1013 It is an explicit requirement of the SNMP architecture that if 1014 privacy is selected, then authentication is also required. That 1015 means that if the privFlag is set, then the authFlag MUST also be 1016 set to one. 1018 The combination of the authFlag and the privFlag comprises a Level 1019 of Security as follows: 1020 authFlag zero, privFlag zero -> securityLevel is noAuthNoPriv 1021 authFlag zero, privFlag one -> invalid combination, see below 1022 authFlag one, privFlag zero -> securityLevel is authNoPriv 1023 authFlag one, privFlag one -> securityLevel is authPriv 1025 The elements of procedure (see below) describe the action to be taken 1026 when the invalid combination of authFlag equal to zero and privFlag 1027 equal to one is encountered. 1029 The remaining bits in msgFlags are reserved, and MUST be set to zero 1030 when sending a message and SHOULD be ignored when receiving a 1031 message. 1033 6.5. msgSecurityModel 1035 The v3MP supports the concurrent existence of multiple Security 1036 Models to provide security services for SNMPv3 messages. The 1037 msgSecurityModel field in an SNMPv3 Message identifies which Security 1038 Model was used by the sender to generate the message and therefore 1039 which securityModel MUST be used by the receiver to perform security 1040 processing for the message. The mapping to the appropriate 1041 securityModel implementation within an SNMP engine is accomplished in 1042 an implementation-dependent manner. 1044 6.6. msgSecurityParameters 1046 The msgSecurityParameters field of the SNMPv3 Message is used for 1047 communication between the Security Model modules in the sending and 1048 receiving SNMP engines. The data in the msgSecurityParameters field 1049 is used exclusively by the Security Model, and the contents and 1050 format of the data is defined by the Security Model. This OCTET 1051 STRING is not interpreted by the v3MP, but is passed to the local 1052 implementation of the Security Model indicated by the 1053 msgSecurityModel field in the message. 1055 6.7. scopedPduData 1057 The scopedPduData field represents either the plain text scopedPDU if 1058 the privFlag in the msgFlags is zero, or it represents an 1059 encryptedPDU (encoded as an OCTET STRING) which MUST be decrypted by 1060 the securityModel in use to produce a plaintext scopedPDU. 1062 6.8. scopedPDU 1064 The scopedPDU contains information to identify an administratively 1065 unique context and a PDU. The object identifiers in the PDU refer to 1066 managed objects which are (expected to be) accessible within the 1067 specified context. 1069 6.8.1. contextEngineID 1071 The contextEngineID in the SNMPv3 message, uniquely identifies, 1072 within an administrative domain, an SNMP entity that may realize an 1073 instance of a context with a particular contextName. 1075 For incoming messages, the contextEngineID is used in conjunction 1076 with pduType to determine to which application the scopedPDU will be 1077 sent for processing. 1079 For outgoing messages, the v3MP sets the contextEngineID to the value 1080 provided by the application in the request for a message to be sent. 1082 6.8.2. contextName 1084 The contextName field in an SNMPv3 message, in conjunction with the 1085 contextEngineID field, identifies the particular context associated 1086 with the management information contained in the PDU portion of the 1087 message. The contextName is unique within the SNMP entity specified 1088 by the contextEngineID, which may realize the managed objects 1089 referenced within the PDU. An application which originates a message 1090 provides the value for the contextName field and this value may be 1091 used during processing by an application at the receiving SNMP 1092 Engine. 1094 6.8.3. data 1096 The data field of the SNMPv3 Message contains the PDU. Among other 1097 things, the PDU contains the PDU type that is used by the v3MP to 1098 determine the type of the incoming SNMP message. The v3MP specifies 1099 that the PDU MUST be one of those specified in [RFC-PROTO]. 1101 7. Elements of Procedure for v3MP 1103 This section describes the procedures followed by an SNMP engine when 1104 generating and processing SNMP messages according to the SNMPv3 1105 Message Processing Model. 1107 Please note, that for the sake of clarity and to prevent the text 1108 from being even longer and more complicated, some details were 1109 omitted from the steps below. 1111 a) Some steps specify that when some error conditions are 1112 encountered when processing a received message, a message 1113 containing a Report PDU is generated and the received message 1114 is discarded without further processing. However, a Report-PDU 1115 MUST NOT be generated unless the PDU causing generation of the 1116 Report PDU can be determined to be a member of the Confirmed 1117 Class, or the reportableFlag is set to one and the PDU class 1118 cannot be determined. 1120 b) The elements of procedure do not always explicitly indicate 1121 when state information needs to be released. The general rule 1122 is that if state information is available when a message is to 1123 be "discarded without further processing", then the state 1124 information should also be released at that same time. 1126 7.1. Prepare an Outgoing SNMP Message 1128 This section describes the procedure followed to prepare an SNMPv3 1129 message from the data elements passed by the Message Dispatcher. 1131 1) The Message Dispatcher may request that an SNMPv3 message 1132 containing a Read Class, Write Class, or Notification Class PDU be 1133 prepared for sending. 1135 a) It makes such a request according to the abstract service 1136 primitive: 1138 statusInformation = -- success or errorIndication 1139 prepareOutgoingMessage( 1140 IN transportDomain -- requested transport domain 1141 IN transportAddress -- requested destination address 1142 IN messageProcessingModel -- typically, SNMP version 1143 IN securityModel -- Security Model to use 1144 IN securityName -- on behalf of this principal 1145 IN securityLevel -- Level of Security requested 1146 IN contextEngineID -- data from/at this entity 1147 IN contextName -- data from/in this context 1148 IN pduVersion -- version of the PDU * 1149 IN PDU -- SNMP Protocol Data Unit 1150 IN expectResponse -- TRUE or FALSE * 1151 IN sendPduHandle -- the handle for matching 1152 -- incoming responses 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 * The SNMPv3 Message Processing Model does not use the values of 1160 expectResponse or pduVersion. 1162 b) A unique msgID is generated. The number used for msgID should 1163 not have been used recently, and MUST NOT be the same as was 1164 used for any outstanding request. 1166 2) The Message Dispatcher may request that an SNMPv3 message 1167 containing a Response Class or Internal Class PDU be prepared for 1168 sending. 1170 a) It makes such a request according to the abstract service 1171 primitive: 1173 result = -- SUCCESS or FAILURE 1174 prepareResponseMessage( 1175 IN messageProcessingModel -- typically, SNMP version 1176 IN securityModel -- same as on incoming request 1177 IN securityName -- same as on incoming request 1178 IN securityLevel -- same as on incoming request 1179 IN contextEngineID -- data from/at this SNMP entity 1180 IN contextName -- data from/in this context 1181 IN pduVersion -- version of the PDU 1182 IN PDU -- SNMP Protocol Data Unit 1183 IN maxSizeResponseScopedPDU -- maximum size sender can accept 1184 IN stateReference -- reference to state 1185 -- information presented with 1186 -- the request 1187 IN statusInformation -- success or errorIndication 1188 -- error counter OID and value 1189 -- when errorIndication 1190 OUT destTransportDomain -- destination transport domain 1191 OUT destTransportAddress -- destination transport address 1192 OUT outgoingMessage -- the message to send 1193 OUT outgoingMessageLength -- the length of the message 1194 ) 1196 b) The cached information for the original request is retrieved 1197 via the stateReference, including 1199 - msgID, 1200 - contextEngineID, 1201 - contextName, 1202 - securityModel, 1203 - securityName, 1204 - securityLevel, 1205 - securityStateReference, 1206 - reportableFlag, 1207 - transportDomain, and 1208 - transportAddress. 1210 The SNMPv3 Message Processing Model does not allow cached data 1211 to be overridden, except by error indications as detailed in 1212 (3) below. 1214 3) If statusInformation contains values for an OID/value combination 1215 (potentially also containing a securityLevel value, 1216 contextEngineID value, or contextName value), then 1218 a) If reportableFlag is zero, then the original message is 1219 discarded, and no further processing is done. A result of 1220 FAILURE is returned. SNMPv3 Message Processing is complete. 1222 b) If a PDU is provided, it is the PDU from the original request. 1223 If possible, extract the request-id. 1225 c) A Report PDU is prepared: 1227 1) the varBindList is set to contain the OID and value from the 1228 statusInformation 1230 2) error-status is set to 0 1232 3) error-index is set to 0. 1234 4) request-id is set to the value extracted in step b) 1235 Otherwise, request-id is set to 0 1237 d) The errorIndication in statusInformation may be accompanied by 1238 a securityLevel value, a contextEngineID value, or a 1239 contextName value. 1241 1) If statusInformation contains a value for securityLevel, 1242 then securityLevel is set to that value, otherwise it is set 1243 to noAuthNoPriv. 1245 2) If statusInformation contains a value for contextEngineID, 1246 then contextEngineID is set to that value, otherwise it is 1247 set to the value of this entity's snmpEngineID. 1249 3) If statusInformation contains a value for contextName, then 1250 contextName is set to that value, otherwise it is set to the 1251 default context of "" (zero-length string). 1253 e) PDU is set to refer to the new Report-PDU. The old PDU is 1254 discarded. 1256 f) Processing continues with step 6) below. 1258 4) If contextEngineID is not yet determined, then the contextEngineID 1259 is determined, in an implementation-dependent manner, possibly 1260 using the transportDomain and transportAddress. 1262 5) If the contextName is not yet determined, the contextName is set 1263 to the default context. 1265 6) A scopedPDU is prepared from the contextEngineID, contextName, and 1266 PDU. 1268 7) msgGlobalData is constructed as follows 1270 a) The msgVersion field is set to snmpv3(3). 1272 b) msgID is set as determined in step 1 or 2 above. 1274 c) msgMaxSize is set to an implementation-dependent value. 1276 d) msgFlags are set as follows: 1278 - If securityLevel specifies noAuthNoPriv, then authFlag and 1279 privFlag are both set to zero. 1281 - If securityLevel specifies authNoPriv, then authFlag is set 1282 to one and privFlag is set to zero. 1284 - If securityLevel specifies authPriv, then authFlag is set to 1285 one and privFlag is set to one. 1287 - If the PDU is from the Unconfirmed Class, then the 1288 reportableFlag is set to zero. 1290 - If the PDU is from the Confirmed Class then the 1291 reportableFlag is set to one. 1293 - All other msgFlags bits are set to zero. 1295 e) msgSecurityModel is set to the value of securityModel 1297 8) If the PDU is from the Response Class or the Internal Class, then 1298 a) The specified Security Model is called to generate the message 1299 according to the primitive: 1301 statusInformation = 1302 generateResponseMsg( 1303 IN messageProcessingModel -- SNMPv3 Message Processing 1304 -- Model 1305 IN globalData -- msgGlobalData from step 7 1306 IN maxMessageSize -- from msgMaxSize (step 7c) 1307 IN securityModel -- as determined in step 7e 1308 IN securityEngineID -- the value of snmpEngineID 1309 IN securityName -- on behalf of this principal 1310 IN securityLevel -- for the outgoing message 1311 IN scopedPDU -- as prepared in step 6) 1312 IN securityStateReference -- as determined in step 2 1313 OUT securityParameters -- filled in by Security Module 1314 OUT wholeMsg -- complete generated message 1315 OUT wholeMsgLength -- length of generated message 1316 ) 1318 If, upon return from the Security Model, the statusInformation 1319 includes an errorIndication, then any cached information about 1320 the outstanding request message is discarded, and an 1321 errorIndication is returned, so it can be returned to the 1322 calling application. SNMPv3 Message Processing is complete. 1324 b) A SUCCESS result is returned. SNMPv3 Message Processing is 1325 complete. 1327 9) If the PDU is from the Confirmed Class or the Notification Class, 1328 then 1330 a) If the PDU is from the Unconfirmed Class, then securityEngineID 1331 is set to the value of this entity's snmpEngineID. 1333 Otherwise, the snmpEngineID of the target entity is determined, 1334 in an implementation-dependent manner, possibly using 1335 transportDomain and transportAddress. The value of 1336 securityEngineID is set to the value of the target entity's 1337 snmpEngineID. 1339 b) The specified Security Model is called to generate the message 1340 according to the primitive: 1342 statusInformation = 1343 generateRequestMsg( 1344 IN messageProcessingModel -- SNMPv3 Message Processing Model 1345 IN globalData -- msgGlobalData, from step 7 1346 IN maxMessageSize -- from msgMaxSize in step 7 c) 1347 IN securityModel -- as provided by caller 1348 IN securityEngineID -- authoritative SNMP entity 1349 -- from step 9 a) 1350 IN securityName -- as provided by caller 1351 IN securityLevel -- as provided by caller 1352 IN scopedPDU -- as prepared in step 6 1353 OUT securityParameters -- filled in by Security Module 1354 OUT wholeMsg -- complete generated message 1355 OUT wholeMsgLength -- length of the generated message 1356 ) 1358 If, upon return from the Security Model, the statusInformation 1359 includes an errorIndication, then the message is discarded, and 1360 the errorIndication is returned, so it can be returned to the 1361 calling application, and no further processing is done. 1362 SNMPv3 Message Processing is complete. 1364 c) If the PDU is from the Confirmed Class, information about the 1365 outgoing message is cached, and an implementation-specific 1366 stateReference is created. Information to be cached includes 1367 the values of: 1369 - sendPduHandle 1370 - msgID 1371 - snmpEngineID 1372 - securityModel 1373 - securityName 1374 - securityLevel 1375 - contextEngineID 1376 - contextName 1378 d) A SUCCESS result is returned. SNMPv3 Message Processing is 1379 complete. 1381 7.2. Prepare Data Elements from an Incoming SNMP Message 1383 This section describes the procedure followed to extract data from an 1384 SNMPv3 message, and to prepare the data elements required for further 1385 processing of the message by the Message Dispatcher. 1387 1) The message is passed in from the Message Dispatcher according to 1388 the abstract service primitive: 1390 result = -- SUCCESS or errorIndication 1391 prepareDataElements( 1392 IN transportDomain -- origin transport domain 1393 IN transportAddress -- origin transport address 1394 IN wholeMsg -- as received from the network 1395 IN wholeMsgLength -- as received from the network 1396 OUT messageProcessingModel -- typically, SNMP version 1397 OUT securityModel -- Security Model to use 1398 OUT securityName -- on behalf of this principal 1399 OUT securityLevel -- Level of Security requested 1400 OUT contextEngineID -- data from/at this entity 1401 OUT contextName -- data from/in this context 1402 OUT pduVersion -- version of the PDU 1403 OUT PDU -- SNMP Protocol Data Unit 1404 OUT pduType -- SNMP PDU type 1405 OUT sendPduHandle -- handle for matched request 1406 OUT maxSizeResponseScopedPDU -- maximum size sender can accept 1407 OUT statusInformation -- success or errorIndication 1408 -- error counter OID and value 1409 -- when errorIndication 1410 OUT stateReference -- reference to state information 1411 -- to be used for a possible 1412 ) -- Response 1414 2) If the received message is not the serialization (according to 1415 the conventions of [RFC-TMM]) of an SNMPv3Message value, then the 1416 snmpInASNParseErrs counter [RFC-MIB] is incremented, the message 1417 is discarded without further processing, and a FAILURE result is 1418 returned. SNMPv3 Message Processing is complete. 1420 3) The values for msgVersion, msgID, msgMaxSize, msgFlags, 1421 msgSecurityModel, msgSecurityParameters, and msgData are 1422 extracted from the message. 1424 4) If the value of the msgSecurityModel component does not match a 1425 supported securityModel, then the snmpUnknownSecurityModels 1426 counter is incremented, the message is discarded without further 1427 processing, and a FAILURE result is returned. SNMPv3 Message 1428 Processing is complete. 1430 5) The securityLevel is determined from the authFlag and the 1431 privFlag bits of the msgFlags component as follows: 1433 a) If the authFlag is not set and the privFlag is not set, then 1434 securityLevel is set to noAuthNoPriv. 1436 b) If the authFlag is set and the privFlag is not set, then 1437 securityLevel is set to authNoPriv. 1439 c) If the authFlag is set and the privFlag is set, then 1440 securityLevel is set to authPriv. 1442 d) If the authFlag is not set and privFlag is set, then the 1443 snmpInvalidMsgs counter is incremented, the message is 1444 discarded without further processing, and a FAILURE result is 1445 returned. SNMPv3 Message Processing is complete. 1447 e) Any other bits in the msgFlags are ignored. 1449 6) The security module implementing the Security Model as specified 1450 by the securityModel component is called for authentication and 1451 privacy services. This is done according to the abstract service 1452 primitive: 1454 statusInformation = -- errorIndication or success 1455 -- error counter OID and 1456 -- value if error 1457 processIncomingMsg( 1458 IN messageProcessingModel -- SNMPv3 Message Processing Model 1459 IN maxMessageSize -- of the sending SNMP entity 1460 IN securityParameters -- for the received message 1461 IN securityModel -- for the received message 1462 IN securityLevel -- Level of Security 1463 IN wholeMsg -- as received on the wire 1464 IN wholeMsgLength -- length as received on the wire 1465 OUT securityEngineID -- authoritative SNMP entity 1466 OUT securityName -- identification of the principal 1467 OUT scopedPDU, -- message (plaintext) payload 1468 OUT maxSizeResponseScopedPDU -- maximum size sender can accept 1469 OUT securityStateReference -- reference to security state 1470 ) -- information, needed for 1471 -- response 1473 If an errorIndication is returned by the security module, then 1475 a) If statusInformation contains values for an OID/value pair, 1476 then generation of a Report PDU is attempted (see step 3 in 1477 section 7.1). 1479 1) If the scopedPDU has been returned from processIncomingMsg 1480 then determine contextEngineID, contextName, and PDU. 1482 2) Information about the message is cached and a 1483 stateReference is created (implementation-specific). 1485 Information to be cached includes the values of: 1487 msgVersion, 1488 msgID, 1489 securityLevel, 1490 msgFlags, 1491 msgMaxSize, 1492 securityModel, 1493 maxSizeResponseScopedPDU, 1494 securityStateReference 1496 3) Request that a Report-PDU be prepared and sent, according 1497 to the abstract service primitive: 1499 result = -- SUCCESS or FAILURE 1500 returnResponsePdu( 1501 IN messageProcessingModel -- SNMPv3(3) 1502 IN securityModel -- same as on incoming request 1503 IN securityName -- from processIncomingMsg 1504 IN securityLevel -- same as on incoming request 1505 IN contextEngineID -- from step 6 a) 1) 1506 IN contextName -- from step 6 a) 1) 1507 IN pduVersion -- SNMPv2-PDU 1508 IN PDU -- from step 6 a) 1) 1509 IN maxSizeResponseScopedPDU -- from processIncomingMsg 1510 IN stateReference -- from step 6 a) 2) 1511 IN statusInformation -- from processIncomingMsg 1512 ) 1514 b) The incoming message is discarded without further processing, 1515 and a FAILURE result is returned. SNMPv3 Message Processing is 1516 complete. 1518 7) The scopedPDU is parsed to extract the contextEngineID, the 1519 contextName and the PDU. If any parse error occurs, then the 1520 snmpInASNParseErrs counter [RFC-MIB] is incremented, the security 1521 state information is discarded, the message is discarded without 1522 further processing, and a FAILURE result is returned. SNMPv3 1523 Message Processing is complete. Treating an unknown PDU type is 1524 treated as a parse error is an implementation option. 1526 8) The pduVersion is determined in an implementation-dependent 1527 manner. For SNMPv3, the pduVersion would be an SNMPv2-PDU. 1529 9) The pduType is determined, in an implementation-dependent manner. 1530 For RFC -PROTO, the pduTypes include: 1532 - GetRequest-PDU, 1533 - GetNextRequest-PDU, 1534 - GetBulkRequest-PDU, 1535 - SetRequest-PDU, 1536 - InformRequest-PDU, 1537 - SNMPv2-Trap-PDU, 1538 - Response-PDU, 1539 - Report-PDU. 1541 10) If the pduType is from the Response Class or the Internal Class, 1542 then 1544 a) The value of the msgID component is used to find the cached 1545 information for a corresponding outstanding Request message. 1546 If no such outstanding Request message is found, then the 1547 security state information is discarded, the message is 1548 discarded without further processing, and a FAILURE result is 1549 returned. SNMPv3 Message Processing is complete. 1551 b) sendPduHandle is retrieved from the cached information. 1553 Otherwise, sendPduHandle is set to , an implementation 1554 defined value. 1556 11) If the pduType is from the Internal Class, then 1558 a) statusInformation is created using the contents of the 1559 Report-PDU, in an implementation-dependent manner. This 1560 statusInformation will be forwarded to the application 1561 associated with the sendPduHandle. 1563 b) The cached data for the outstanding message, referred to by 1564 stateReference, is retrieved. If the securityModel or 1565 securityLevel values differ from the cached ones, it is 1566 important to recognize that Internal Class PDUs delivered at 1567 the security level of noAuthNoPriv open a window of 1568 opportunity for spoofing or replay attacks. If the receiver 1569 of such messages is aware of these risks, the use of such 1570 unauthenticated messages is acceptable and may provide a 1571 useful function for discovering engine IDs or for detecting 1572 misconfiguration at remote nodes. 1574 When the securityModel or securityLevel values differ from 1575 the cached ones, an implementation may retain the cached 1576 information about the outstanding Request message, in 1577 anticipation of the possibility that the Internal Class PDU 1578 received might be illegitimate. Otherwise, any cached 1579 information about the outstanding Request message is 1580 discarded. 1582 c) The security state information for this incoming message is 1583 discarded. 1585 d) stateReference is set to 1587 e) A SUCCESS result is returned. SNMPv3 Message Processing is 1588 complete. 1590 12) If the pduType is from the Response Class, then 1592 a) The cached data for the outstanding request, referred to by 1593 stateReference, is retrieved, including 1595 - snmpEngineID 1596 - securityModel 1597 - securityName 1598 - securityLevel 1599 - contextEngineID 1600 - contextName 1602 b) If the values extracted from the incoming message differ from 1603 the cached data, then any cached information about the 1604 outstanding Request message is discarded, the incoming 1605 message is discarded without further processing, and a 1606 FAILURE result is returned. SNMPv3 Message Processing is 1607 complete. 1609 When the securityModel or securityLevel values differ from 1610 the cached ones, an implementation may retain the cached 1611 information about the outstanding Request message, in 1612 anticipation of the possibility that the Response Class PDU 1613 received might be illegitimate. 1615 c) Otherwise, any cached information about the outstanding 1616 Request message is discarded, and stateReference is set to 1617 . 1619 d) A SUCCESS result is returned. SNMPv3 Message Processing is 1620 complete. 1622 13) If the pduType is from the Confirmed Class, then 1624 a) If the value of securityEngineID is not equal to the value of 1625 snmpEngineID, then the security state information is 1626 discarded, any cached information about this message is 1627 discarded, the incoming message is discarded without further 1628 processing, and a FAILURE result is returned. SNMPv3 Message 1629 Processing is complete. 1631 b) Information about the message is cached and a stateReference 1632 is created (implementation-specific). Information to be 1633 cached includes the values of: 1635 msgVersion, 1636 msgID, 1637 securityLevel, 1638 msgFlags, 1639 msgMaxSize, 1640 securityModel, 1641 maxSizeResponseScopedPDU, 1642 securityStateReference 1644 c) A SUCCESS result is returned. SNMPv3 Message Processing is 1645 complete. 1647 14) If the pduType is from the Unconfirmed Class, then A SUCCESS 1648 result is returned. SNMPv3 Message Processing is complete. 1650 8. Intellectual Property 1652 The IETF takes no position regarding the validity or scope of any 1653 intellectual property or other rights that might be claimed to 1654 pertain to the implementation or use of the technology described in 1655 this document or the extent to which any license under such rights 1656 might or might not be available; neither does it represent that it 1657 has made any effort to identify any such rights. Information on the 1658 IETF's procedures with respect to rights in standards-track and 1659 standards-related documentation can be found in BCP-11. Copies of 1660 claims of rights made available for publication and any assurances of 1661 licenses to be made available, or the result of an attempt made to 1662 obtain a general license or permission for the use of such 1663 proprietary rights by implementors or users of this specification can 1664 be obtained from the IETF Secretariat. 1666 The IETF invites any interested party to bring to its attention any 1667 copyrights, patents or patent applications, or other proprietary 1668 rights which may cover technology that may be required to practice 1669 this standard. Please address the information to the IETF Executive 1670 Director. 1672 9. Acknowledgements 1674 This document is the result of the efforts of the SNMPv3 Working 1675 Group. Some special thanks are in order to the following SNMPv3 WG 1676 members: 1678 Harald Tveit Alvestrand (Maxware) 1679 Dave Battle (SNMP Research, Inc.) 1680 Alan Beard (Disney Worldwide Services) 1681 Paul Berrevoets (SWI Systemware/Halcyon Inc.) 1682 Martin Bjorklund (Ericsson) 1683 Uri Blumenthal (IBM T. J. Watson Research Center) 1684 Jeff Case (SNMP Research, Inc.) 1685 John Curran (BBN) 1686 Mike Daniele (Compaq Computer Corporation) 1687 T. Max Devlin (Eltrax Systems) 1688 John Flick (Hewlett Packard) 1689 Rob Frye (MCI) 1690 Wes Hardaker (U.C.Davis, Information Technology - D.C.A.S.) 1691 David Harrington (Cabletron Systems Inc.) 1692 Lauren Heintz (BMC Software, Inc.) 1693 N.C. Hien (IBM T. J. Watson Research Center) 1694 Michael Kirkham (InterWorking Labs, Inc.) 1695 Dave Levi (SNMP Research, Inc.) 1696 Louis A Mamakos (UUNET Technologies Inc.) 1697 Joe Marzot (Nortel Networks) 1698 Paul Meyer (Secure Computing Corporation) 1699 Keith McCloghrie (Cisco Systems) 1700 Bob Moore (IBM) 1701 Russ Mundy (TIS Labs at Network Associates) 1702 Bob Natale (ACE*COMM Corporation) 1703 Mike O'Dell (UUNET Technologies Inc.) 1704 Dave Perkins (DeskTalk) 1705 Peter Polkinghorne (Brunel University) 1706 Randy Presuhn (BMC Software, Inc.) 1707 David Reeder (TIS Labs at Network Associates) 1708 David Reid (SNMP Research, Inc.) 1709 Aleksey Romanov (Quality Quorum) 1710 Shawn Routhier (Epilogue) 1711 Juergen Schoenwaelder (TU Braunschweig) 1712 Bob Stewart (Cisco Systems) 1713 Mike Thatcher (Independent Consultant) 1714 Bert Wijnen (IBM T. J. Watson Research Center) 1716 The document is based on recommendations of the IETF Security and 1717 Administrative Framework Evolution for SNMP Advisory Team. Members 1718 of that Advisory Team were: 1720 David Harrington (Cabletron Systems Inc.) 1721 Jeff Johnson (Cisco Systems) 1722 David Levi (SNMP Research Inc.) 1723 John Linn (Openvision) 1724 Russ Mundy (Trusted Information Systems) chair 1725 Shawn Routhier (Epilogue) 1726 Glenn Waters (Nortel) 1727 Bert Wijnen (IBM T. J. Watson Research Center) 1729 As recommended by the Advisory Team and the SNMPv3 Working Group 1730 Charter, the design incorporates as much as practical from previous 1731 RFCs and drafts. As a result, special thanks are due to the authors 1732 of previous designs known as SNMPv2u and SNMPv2*: 1734 Jeff Case (SNMP Research, Inc.) 1735 David Harrington (Cabletron Systems Inc.) 1736 David Levi (SNMP Research, Inc.) 1737 Keith McCloghrie (Cisco Systems) 1738 Brian O'Keefe (Hewlett Packard) 1739 Marshall T. Rose (Dover Beach Consulting) 1740 Jon Saperia (BGS Systems Inc.) 1741 Steve Waldbusser (International Network Services) 1742 Glenn W. Waters (Bell-Northern Research Ltd.) 1744 10. Security Considerations 1746 The Dispatcher coordinates the processing of messages to provide a 1747 level of security for management messages and to direct the SNMP PDUs 1748 to the proper SNMP application(s). 1750 A Message Processing Model, and in particular the v3MP defined in 1751 this document, interacts as part of the Message Processing with 1752 Security Models in the Security Subsystem via the abstract service 1753 interface primitives defined in [RFC-ARCH] and elaborated above. 1755 The level of security actually provided is primarily determined by 1756 the specific Security Model implementation(s) and the specific SNMP 1757 application implementation(s) incorporated into this framework. 1758 Applications have access to data which is not secured. Applications 1759 should take reasonable steps to protect the data from disclosure, and 1760 when they send data across the network, they should obey the 1761 securityLevel and call upon the services of an Access Control Model 1762 as they apply access control. 1764 The values for the msgID element used in communication between SNMP 1765 entities MUST be chosen to avoid replay attacks. The values do not 1766 need to be unpredictable; it is sufficient that they not repeat. 1768 When exchanges are carried out over an insecure network, there is an 1769 open opportunity for a third party to spoof or replay messages when 1770 any message of an exchange is given at the security level of 1771 noAuthNoPriv. For most exchanges, all messages exist at the same 1772 security level. In the case where the final message is an Internal 1773 Class PDU, this message may be delivered at a level of noAuthNoPriv 1774 or authNoPriv, independent of the security level of the preceding 1775 messages. Internal Class PDUs delivered at the level of authNoPriv 1776 are not considered to pose a security hazard. Internal Class PDUs 1777 delivered at the security level of noAuthNoPriv open a window of 1778 opportunity for spoofing or replay attacks. If the receiver of such 1779 messages is aware of these risks, the use of such unauthenticated 1780 messages is acceptable and may provide a useful function for 1781 discovering engine IDs or for detecting misconfiguration at remote 1782 nodes. 1784 This document also contains a MIB definition module. None of the 1785 objects defined is writable, and the information they represent is 1786 not deemed to be particularly sensitive. However, if they are deemed 1787 sensitive in a particular environment, access to them should be 1788 restricted through the use of appropriately configured Security and 1789 Access Control models. 1791 11. References 1793 [RFC1901] The SNMPv2 Working Group, Case, J., McCloghrie, K., 1794 Rose, M. and S. Waldbusser, "Introduction to 1795 Community-based SNMPv2", RFC 1901, January 1996. 1797 [RFC2578] McCloghrie, K., Perkins, D. and J. Schoenwaelder, 1798 "Structure of Management Information Version 2 (SMIv2)", 1799 STD 58, RFC 2578, April 1999. 1801 [RFC-PROTO] Presuhn, R., Case, J., McCloghrie, K., Rose, M., and S. 1802 Waldbusser, "Protocol Operations for the Simple Network 1803 Management Protocol", 1804 , October 2001. 1806 [RFC-TMM] Presuhn, R., Case, J., McCloghrie, K., Rose, M., and S. 1807 Waldbusser, "Transport Mappings for the Simple Network 1808 Management Protocol", 1809 , October 1810 2001. 1812 [RFC-MIB] Presuhn, R., Case, J., McCloghrie, K., Rose, M. and S. 1813 Waldbusser, "Management Information Base for the Simple 1814 Network Management Protocol", 1815 , October 2001. 1817 [RFC-COEX] Frye, R., Levi, D., Routhier, S., and B. Wijnen, 1818 "Coexistence between Version 1, Version 2, and Version 3 1819 of the Internet-standard Network Management Framework", 1820 , October 2001. 1822 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1823 Requirement Levels", BCP 14, RFC 2119, March 1997. 1825 [RFC2028] Hovey, R. and S. Bradner, "The Organizations Involved in 1826 the IETF Standards Process", BCP 11, RFC 2028, October 1827 1996. 1829 [RFC-ARCH] Harrington, D., Presuhn, R. and B. Wijnen, "An 1830 Architecture for describing SNMP Management Frameworks", 1831 , October 2001. 1833 [RFC-USM] Blumenthal, U. and B. Wijnen, "The User-Based Security 1834 Model for Version 3 of the Simple Network Management 1835 Protocol (SNMPv3)", 1836 , October 1837 2001. 1839 [RFC-ACM] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based 1840 Access Control Model for the Simple Network Management 1841 Protocol (SNMP)", , 1842 October 2001. 1844 [RFC-APPL] Levi, D., Meyer, P. and B. Stewart, "SNMP 1845 Applications", , 1846 October 2001. 1848 [RFC2570] Case, J., Mundy, R., Partain, D. and B. Stewart, 1849 "Introduction to Version 3 of the Internet-standard 1850 Network Management Framework", RFC 2570, April 1999. 1852 12. Editors' Addresses 1854 Jeffrey Case 1855 SNMP Research, Inc. 1856 3001 Kimberlin Heights Road 1857 Knoxville, TN 37920-9716 1858 USA 1860 Phone: +1 423-573-1434 1861 EMail: case@snmp.com 1862 David Harrington | 1863 Enterasys Networks | 1864 35 Industrial Way | 1865 Post Office Box 5005 | 1866 Rochester, NH 03866-5005 | 1867 USA | 1869 Phone: +1 603-337-2614 | 1870 EMail: dbh@enterasys.com | 1872 Randy Presuhn 1873 BMC Software, Inc. 1874 2141 North First Street 1875 San Jose, CA 95131 1876 USA 1878 Phone: +1 408-546-1006 1879 EMail: randy_presuhn@bmc.com 1881 Bert Wijnen 1882 Lucent Technologies 1883 Schagen 33 1884 3461 GL Linschoten 1885 Netherlands 1887 Phone: +31 348-680-485 1888 EMail: bwijnen@lucent.com 1890 13. Changes From RFC 2572 1892 The following change log records major changes from the previous 1893 version of this document, RFC 2572. 1895 - Added working group co-chair address. 1897 - Updated working group mailing list subscription information. 1899 - Updated editor contact information. 1901 - Updated copyright dates. 1903 14. Full Copyright Statement 1905 Copyright (C) The Internet Society (2001). All Rights Reserved. 1907 This document and translations of it may be copied and furnished to 1908 others, and derivative works that comment on or otherwise explain it 1909 or assist in its implementation may be prepared, copied, published 1910 and distributed, in whole or in part, without restriction of any 1911 kind, provided that the above copyright notice and this paragraph are 1912 included on all such copies and derivative works. However, this 1913 document itself may not be modified in any way, such as by removing 1914 the copyright notice or references to the Internet Society or other 1915 Internet organizations, except as needed for the purpose of 1916 developing Internet standards in which case the procedures for 1917 copyrights defined in the Internet Standards process must be 1918 followed, or as required to translate it into languages other than 1919 English. 1921 The limited permissions granted above are perpetual and will not be 1922 revoked by the Internet Society or its successors or assigns. 1924 This document and the information contained herein is provided on an 1925 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1926 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1927 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1928 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1929 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1931 Acknowledgement 1933 Funding for the RFC Editor function is currently provided by the 1934 Internet Society.