idnits 2.17.1 draft-ietf-snmpv3-next-gen-arch-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-24) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 22 longer pages, the longest (page 10) being 585 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 31 pages 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 lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (26 April 1997) is 9860 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) == Unused Reference: 'RFC1902' is defined on line 1211, but no explicit reference was found in the text == Unused Reference: 'RFC1905' is defined on line 1216, but no explicit reference was found in the text == Unused Reference: 'RFC1906' is defined on line 1221, but no explicit reference was found in the text == Unused Reference: 'RFC1907' is defined on line 1226, but no explicit reference was found in the text == Unused Reference: 'RFC1908' is defined on line 1231, but no explicit reference was found in the text == Unused Reference: 'SNMPng-ARCH' is defined on line 1236, but no explicit reference was found in the text == Unused Reference: 'SNMPng-LPM' is defined on line 1241, but no explicit reference was found in the text == Unused Reference: 'SNMPng-USEC' is defined on line 1246, but no explicit reference was found in the text ** Downref: Normative reference to an Historic RFC: RFC 1901 ** Obsolete normative reference: RFC 1905 (ref. 'RFC1902') (Obsoleted by RFC 3416) -- Duplicate reference: RFC1905, mentioned in 'RFC1905', was also mentioned in 'RFC1902'. ** Obsolete normative reference: RFC 1905 (Obsoleted by RFC 3416) ** Obsolete normative reference: RFC 1906 (Obsoleted by RFC 3417) ** Obsolete normative reference: RFC 1907 (Obsoleted by RFC 3418) ** Obsolete normative reference: RFC 1908 (Obsoleted by RFC 2576) == Outdated reference: A later version (-06) exists of draft-ietf-snmpv3-next-gen-arch-00 -- No information found for draft-ietf-snmpng-lpm - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'SNMPng-LPM' -- No information found for draft-ietf-snmpng-usec - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'SNMPng-USEC' Summary: 16 errors (**), 0 flaws (~~), 12 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Architecture for the Next Generation 2 Simple Network Management Protocol (SNMPng) 4 26 April 1997 6 D. Harrington 7 Cabletron Systems, Inc. 8 dbh@cabletron.com 10 B. Wijnen 11 IBM T.J. Watson Research 12 wijnen@vnet.ibm.com 14 16 Status of this Memo 18 This document is an Internet-Draft. Internet-Drafts are working 19 documents of the Internet Engineering Task Force (IETF), its areas, and 20 its working groups. Note that other groups may also distribute working 21 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 material 26 or to cite them other than as ``work in progress.'' 28 To learn the current status of any Internet-Draft, please check the 29 ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow 30 Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), 31 ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). 33 Abstract 35 This document describes an architecture for the Next-Generation of 36 the Simple Network Management Protocol (SNMPng). The architecture 37 is designed to be modular to allow the evolution of the protocol 38 over time. The major portions of the architecture are 1) a message 39 processing and control framework, 2) a security framework, and 40 3) a local processing framework. 42 Harrington/Wijnen Expires October 1977 [Page 1] 43 \ 44 Draft Architectural Model for SNMPng April 1997 46 0. Change Log 48 [version 1.8] 49 1. changed filename to internet-drafts assigned name 50 [version 1.7] 51 1. Truncate lines to 72 (more to be done) 52 2. Prepare for pagination 53 3. Added references section 54 4. Let table of contents be generated 55 [version 1.6] 56 1. added abstract 57 2. davel's comments 58 3. bert's comments 59 4. reverted to QoS since it was less work. 60 5. completed section 8 61 6. Security Considerations, etc 62 7. table of contents 63 [version 1.5] 64 1. add goals/constraints from issues list 65 2. add discussion of proxy as App 66 3. move ngMIB to arch from LPM doc 67 4. define LCD versus SCD 68 5. copy Bert's 2.x that apply to framework 69 6. modify Message definition to better match Bert's ASN.1 70 [version 1.4] 71 1. modified intro 72 2. added section on design principles/goals 73 3. added section on message contents and service interfaces 74 4. defined LP-F versus LP-M 75 5. changed QoS to msgFlags 76 [version 1.3] 77 1. modified title from Security and Framework Evolution to 78 Next Generation 79 2. expanded section 4 - architectural design goals 80 3. replaced all acronyms with the new acronyms 82 Harrington/Wijnen Expires October 1977 [Page 2] 83 \ 84 Draft Architectural Model for SNMPng April 1997 86 1. Introduction 88 A management system contains: several (potentially many) nodes, each 89 with a processing entity, termed an agent, which has access to 90 management instrumentation; at least one management station; and, a 91 management protocol, used to convey management information between the 92 agents and management stations. 94 Management stations execute management applications which monitor and 95 control managed elements. Managed elements are devices such as hosts, 96 routers, terminal servers, etc., which are monitored and controlled via 97 access to their management information. 99 Operations of the protocol are carried out under an administrative 100 framework which defines minimum policies for mechanisms which provide 101 message-level security, access control for managed objects, and 102 interaction between the protocol engine and the applications which use 103 the services of the engine. 105 It is the purpose of this document to define a framework which can 106 evolve to realize effective SNMP network management in a variety of 107 configurations and environments. The framework has been designed to 108 meet the needs of implementors of both minimal agents and full-function 109 network enterprise management stations. 111 1.1. A Note on Terminology 113 For the purpose of exposition, the original Internet-standard Network 114 Management Framework, as described in RFCs 1155, 1157, and 1212, is 115 termed the SNMP version 1 framework (SNMPv1). A partially-updated 116 Internet-standard Network Management framework , as described 117 in RFCs 1902-1908, is termed the SNMP version 2 framework (SNMPv2). 118 The current framework, meant to complement the SNMPv2 framework, 119 is termed the SNMP next generation framework (SNMPng). 121 SNMPng provides a framework for the evolution of multiple 122 (sub-)frameworks. 124 Throughout the rest of this document, the term Framework will 125 refer to an abstract and incomplete specification of a portion of 126 SNMPng, that will be further refined by a Model specification. 128 A Model describes a specific design of a Framework, defining 129 additional constraints and rules for conformance to the model. 130 A model is sufficiently detailed a design to make it possible 131 to implement the specification. 133 A Implementation is an instantiation of a Framework, conforming to a 134 specific Model. 136 Harrington/Wijnen Expires October 1977 [Page 3] 137 \ 138 Draft Architectural Model for SNMPng April 1997 140 2. Overview 142 The architecture presented here emphasizes the use of modularity to 143 allow the evolution of portions of SNMP without requiring a redesign of 144 the general architecture of SNMP. 146 The processing of SNMP messages is procedural - there are specific 147 steps which must be accomplished in specific order of processing. 148 These steps fall into general categories of similar functionality. 149 This document will describe major abstractions of functionality 150 required of an SNMP engine, and the abstract interactions between 151 these major categories. 153 This document will describe how this architecture is meant to allow 154 modules of functionality corresponding to these abstract categories to 155 be designed to allow the evolution of the whole by modifying discrete 156 modules within the architecture. 158 Harrington/Wijnen Expires October 1977 [Page 4] 159 \ 160 Draft Architectural Model for SNMPng April 1997 162 3. An Evolutionary Architecture - Design Goals 164 The goals of the architectural design are to use encapsulation, 165 cohesion, hierarchical rules, and loose coupling to reduce complexity 166 of design and make the evolution of portions of the architecture 167 possible. 169 3.1. Encapsulation 171 Encapsulation describes the practice of hiding the details that are 172 used internal to a process. Some data is required for a given 173 procedure, but isn't needed by any other part of the process. 175 In networking, the concept of a layered stack reflects this approach. 176 The transport layer contains data specific to its processing; the data 177 is not visible to the other layers. In programming this is reflected 178 in language elements such as "file static" variables in C, and 179 "private" in C++, etc. 181 In the SNMPng architecture, all data used for processing only within a 182 functional portion of the architecture should have its visibility 183 restricted to that portion if possible. The data should be accessed 184 only by that functionality defined with the data. No reference to the 185 data should be made from outside the functional portion of the 186 architecture, except through predefined public interfaces. 188 3.2. Cohesion 190 Similar functions can be grouped together and their differences 191 ignored, so they can be dealt with as a single entity. It is important 192 that the functions which are grouped together are actually similar. 193 For instance, authentication and encryption are both security functions 194 which act on the message. Access control, while similar in some ways, 195 is not similar in that it does not work on the message, it works on the 196 contents of the message. The similarity of the data used to perform 197 functions can be a good indicator of the similarity of the functions. 199 Similar functions, especially those that use the same data elements, 200 should be defined together. The security functions which operate at 201 the message level should be defined in a document together with the 202 definitions for those data elements that are used only by those 203 security functions. For example, a MIB with authentication keys is 204 used only by authentication functions; they should be defined together. 206 3.3. Hierarchical Rules 208 Functionality can be grouped into hierarchies where each element in the 209 hierarchy receives general characteristics from its direct superior, 210 and passes on those characteristics to each of its direct subordinates. 212 Harrington/Wijnen Expires October 1977 [Page 5] 213 \ 214 Draft Architectural Model for SNMPng April 1997 216 The SNMPng architecture uses the hierarchical approach by defining 217 frameworks, which specify the general rules of a portion of the system, 218 models which define the specific rules to be followed by an 219 implementation of the portion of the system, and implementations which 220 encode those rules into reality for a portion of the system. 222 It is expected that within portions of the system, hierarchical 223 relationships will be used to compartmentalize, or modularize, the 224 implementation of specific functionality. For example, it is expected 225 that within the security portion of the system, authentication and 226 privacy will probably be contained in separate modules, and that 227 multiple authentication and privacy mechanisms will be supported by 228 allowing supplemental modules that provide protocol-specific 229 authentication and privacy services. 231 3.4. Coupling 233 Coupling describes the amount of interdependence between parts of 234 a system. Loose coupling indicates that two sub-systems are relatively 235 independent of each other; tight coupling indicates a high degree of 236 mutual dependence. 238 To make it possible to evolve the architecture by replacing only part 239 of the system, or by supplementing existing portions with alternate 240 mechanisms for similar functionality, without obsoleting the complete 241 system, it is necessary to limit the coupling of the parts. 243 Encapsulation and cohesion help to reduce coupling by limiting the 244 visibility of those parts that are only needed within portions of a 245 system. Another mechanism is to constrain the nature of interactions 246 between various parts of the system. 248 This can be done by defining fixed, generic, flexible, interfaces 249 between the parts of the system. The concept of plug-and-play hardware 250 components is based on that type of interface between the hardware 251 component and system into which it will be "plugged." 253 SNMPng has chosen this approach so individual portions of the system 254 can be upgraded over time, while keeping the overall system intact. 255 Cross-references between document describing the subsystems should be 256 limited to Framework or Model defined interfaces wherever possible. 258 Loose coupling works well with the IETF standards process. If we 259 separate message-handling from security and from local processing, 260 then the separate portions of the system can move through the standards 261 process with less dependence on the status of the other portions of the 262 standard. Security models may be able to be re-opened for discussion 263 due to patents, new research, export laws, etc., as is clearly expected 264 by the WG, without needing to reopen the documents which detail the 265 message format or the local processing of PDUs. Thus, the standards 266 track status of related, but independent, documents is not affected. 268 Harrington/Wijnen Expires October 1977 [Page 6] 269 \ 270 Draft Architectural Model for SNMPng April 1997 272 4.0. Abstract Functionality 274 The architecture described here is composed of four "major" frameworks, 275 each capable of being defined as different models, and which may be 276 implemented as modules which can be replaced or supplemented as the 277 growing needs of network management require. 279 The major frameworks are a Message Processing and Control Framework, a 280 Security Framework, a Local Processing Framework, and Applications. 281 Interfaces between the major frameworks are deliberately abstract and 282 fixed. An SNMPng engine is comprised of implementations of a 283 Message Processing and Control Framework, a Security Framework, and 284 a Local Processing Framework. Applications are external to the engine. 286 4.1. Message Processing and Control 288 An SNMP engine interacts with the network and with applications through 289 the Message Processing and Control Framework. 291 Messages being sent to, or received from, the network use a format 292 defined by the SNMP protocol. The possible contents, and their 293 format, are also defined by the SNMP protocol. 295 Messages being sent to, or received from, applications use formats 296 which may be protocol-defined or may be implementation-specific. The 297 possible contents, and their format, may be protocol-defined or 298 implementation-specific. 300 The processing of messages must be controlled to ensure that applicable 301 rules are followed during the processing. Some messages, such as an 302 SNMP Get-Request received from the network for objects managed by this 303 engine, can be processed directly by the engine; other messages must be 304 passed to external processes, such as a remote SNMP engine or an 305 application. Some messages require security; others don't. Some engines 306 support multiple versions of SNMP messages and/or PDU formats. 308 The engine must control the order and the combinations of options used 309 in processing and generating messages. 311 4.2. Security 313 Some environments require secure protocol interactions. Security is 314 normally applied at two different stages - in the transmission/receipt 315 of messages, and in the processing of the contents of messages. For 316 purposes of this document, "security" refers to message-level security; 317 "access control" refers to the security applied to protocol operations. 319 Authentication, encryption, and timeliness checking are common 320 functions of message level security. 322 Harrington/Wijnen Expires October 1977 [Page 7] 323 \ 324 Draft Architectural Model for SNMPng April 1997 326 4.3. Local Processing 328 Local Processing deals with the contents of messages. It interacts with 329 the underlying operating system to access the instrumentation which is 330 represented as managed objects in SNMP. 332 During local processing, it may be required to control access to 333 certain instrumentation for certain operations. The enforcement of 334 access rights requires the means to identify the access allowed for 335 the entity on whose behalf a request is generated. 337 4.4. Applications 339 Applications are processes which interact with the SNMP engine using 340 messages that may use formats defined by a protocol, or that may use 341 implementation-specific formats. 343 Applications are developed to achieve certain goals. They use the SNMP 344 engine to achieve their goals, but their purpose is outside the scope 345 of the SNMP protocol definitions. 347 For example, management stations execute applications which monitor 348 and control managed elements. A proxy application may forward a 349 message from one SNMP engine to another (an snmp proxy), or convert 350 a message from one SNMP format to another (also an snmp proxy), or 351 from SNMP to another protocol ( a foreign proxy). The purpose and 352 design of applications are beyond the scope of the SNMPng engine 353 architecture. 355 4.5. Definition of SNMPng acronyms and terms: 357 MPC-F - Message Processing and Control Framework 358 MPC-M - Message Processing and Control Model 359 MPC-I - Message Processing and Control Implementation 361 SF-F - Security Framework 362 SF-M - Security Framework Model 363 SF-I - Security Framework Implementation 365 LP-F - Local Processing Framework 366 LP-M - Local Processing Model 367 LP-I - Local Processing Implementation 369 LCD - Local Configuration Datastore 370 SCD - Security Configuration Datastore 372 Harrington/Wijnen Expires October 1977 [Page 8] 373 \ 374 Draft Architectural Model for SNMPng April 1997 376 5. Elements of the Framework 378 This section contains definitions of terms used in the interfaces 379 between Frameworks 381 5.1. Groups 383 A Group identifies a set of zero or more security entities on whose 384 behalf SNMP messages are being processed. 386 5.2. Quality of Service 388 Messages may require different levels of security. The term used to 389 refer to the level of security required is "Quality of Service" or QoS. 391 SNMPng recognizes three levels of security: 392 - without authentication and without privacy (noAuth/noPriv) 393 - with authentication but without privacy (auth/noPriv) 394 - with authentication and with privacy (auth/Priv) 396 Every message has an associated QoS; all processing (security, access 397 control, applications, message processing and control) is required 398 to abide the specified QoS. 400 5.3. Contexts 402 An SNMP context is a collection of management information 403 accessible by an SNMP agent. An item of management information 404 may exist in more than one context. An SNMP agent potentially 405 has access to many contexts. 407 5.4. Scoped-PDU 409 A scoped-PDU contains a Naming-Scope that unambiguously 410 identifies an SNMP agent and the context, (locally) accessible 411 by that agent, to which the SNMP management information 412 in the SNMP-PDU refers. 414 A Naming-Scope contains a contextID that unambiguously identifies 415 the SNMP agent which has (local) access to the management 416 information referred to by the contextName and the SNMP-PDU. 418 A Naming-Scope contains a contextName which unambiguously identifies 419 an SNMP context accessible by the SNMP agent to which the SNMP-PDU 420 is directed or from which the SNMP-PDU is originated. 422 An implementation of a Message Processing and Control Model 423 must determine if the contextID in the scopedPDU of a received message 424 matches the snmpNgEngineID of the current engine. If so, the scopedPDU 425 should be processed by the Local Processing implementation. 427 Harrington/Wijnen Expires October 1977 [Page 9] 428 \ 429 Draft Architectural Model for SNMPng April 1997 431 5.5. Security Configuration Datastore 433 Each Security Model may need to retain its own set of information about 434 security entities, mechanisms, and policies. This set of information 435 is called the SNMPng entity's Security Configuration Datastore (SCD). 436 In order to allow an SNMPng entity's SCD to be remotely configured, 437 portions may need to be accessible as managed objects. 439 5.6. Local Configuration Datastore 441 Each Local Processing Model may need to retain its own set of 442 information about access control, naming scopes, and policies. 443 This set of information is called the SNMPng entity's Local 444 Processing Configuration Datastore (LCD). 445 In order to allow an SNMPng entity's LCD to be remotely configured, 446 portions may need to be accessible as managed objects. 448 \ 449 6. Model Design Requirements 451 The basic design elements come from SNMPv2u and SNMPv2*, as 452 described in RFCs 1909-1910, and from a set of internet drafts. 453 these are the two most popular de facto "administrative framework" 454 standards that include security and access control for SNMPv2. 456 SNMPv1 and SNMPv2c [RFC1901] are two administrative frameworks based 457 on communities to provide trivial authentication and access control. 458 SNMPng allows implementations to add support for features of SNMPv1 459 and SNMPv2c, and to coexist with SNMPv1 and SNMPv2c engines, but 460 this document does not provide guidelines for that coexistence. 462 6.1. Security Model Design Requirements 464 Received messages must be validated by a model of the Security 465 Framework before being processed by the Local Processing Framework. 466 Validation includes authentication and privacy processing if needed, 467 but it is explicitly allowed to send messages which do not require 468 authentication or privacy. 470 A received message will contain a specified Quality of Service to be 471 used during processing. All messages requiring privacy must also 472 require authentication. 474 A Security Model specifies rules by which authentication and privacy 475 are to be done. A model may define mechanisms to provide additional 476 security features, but is restricted to using the interface, defined in 477 this document, between the Message Processing and Control Framework and 478 the Security Framework. 480 Each Security Model may allow multiple security mechanisms to be used 481 concurrently within an implementation of the model. Each Security Model 482 defines how to determine which protocol to use, given the QoS and the 483 security parameters passed in the message. Each Security Model, with 484 its associated protocol(s) defines how the sending/receiving entities 485 are identified, how secrets are configured, and how security entities 486 map to groups. 488 For privacy, the Security Model defines what portion of the message 489 is encrypted. 491 Security Models are replaceable within the SNMPng Framework. Multiple 492 Security Model Implementations may exist concurrently within an engine. 493 The number of Security Models defined by the SNMP community should 494 remain small to promote interoperability. It is required that an 495 implementation of the User-Based Security Model be used in all 496 engines to ensure at least a minimal level of interoperability. 498 Each Security Model must define a mapping to be used between a unique 499 entity within the model's SCD, and a securityCookie. A securityCookie 501 \ 502 is an implementation-specific handle to identify the unique entity to 503 which it maps. If an implementation supports multiple Security Models, 504 the securityCookie must include a mechanism for determining which 505 Security Model SCD is referenced. The securityCookie, in combination 506 with the engineID of the engine which instantiates the securityCookie, 507 can be used as a globally-unique identifier for a security entity. The 508 type of a securityCookie is an OCTET STRING, but the format of the 509 contents is implementation-specific. It is important to note that 510 since the securityCookie may be accessible outside the engine, the 511 securityCookie must not disclose any sensitive data, such as by 512 including passwords in open text in the securityCookie. 514 Each Security Model defines the MIBs required for security processing, 515 including any MIBs required for the protocol(s) supported. The MIB 516 formats must be defined concurrently with the procedures which use 517 the MIB. The MIBs are subject to normal security and access control 518 rules. 520 The persistent data used for security should be SNMP-manageable, but 521 the Security Model defines whether an instantiation of the MIB is a 522 conformance requirement. The mapping between a securityCookie and the 523 unique security entity within the engine must be able to be determined 524 using SNMP, if the MIB is instantiated and access control policy 525 allows. 527 Protocols should be uniquely identified using Object Identifiers. 528 Enterprise-specific protocols should be defined within the enterprise 529 subtree. A protocolID MIB should be defined for IETF standard 530 protocols for authentication and privacy. 532 Within any Security Model, there should be no reference to any specific 533 Local Processing Model, or to data defined by a Local Processing Model. 535 6.2. Local Processing Model Design Requirements 537 A Local processing Model only processes scopedPDUs which contain a 538 contextID which matches the engineID of the current engine. 540 A Local Processing Model must determine whether the specified group is 541 allowed to perform the requested operation on the managed objects in 542 the PDU. For messages with a QoS specifying authentication, the group 543 used for access control must be the same group provided by the Message 544 Processing and Control Framework. 546 A Local Processing Model specifies the rules by which access control 547 and PDU processing are to be done. A model may define mechanisms to 548 provide additional processing features, but is restricted to using the 549 interface, defined in this document, between the Message Processing 550 and Control Framework and the Local Processing Framework. 552 \ 553 The persistent data used for local processing should be manageable 554 using SNMP, but the Local Processing Model defines whether an 555 instantiation of the MIB is a conformance requirement. 557 Within any Local Processing Model, there should be no reference to 558 any specific Security Model, or any data defined by a Security Model. 560 6.3. Message Processing and Control Requirements 562 The MPC Model must always pass the complete scopedPDU, i.e. it never 563 forwards less than the complete list of varbinds. 565 The MPC Model must determine whether a scopedPDU should be processed 566 by the current engine or by an application. If a received message 567 contains a scopedPDU with a contextID matching the engineID of the 568 current engine, then the scopedPDU should be passed to the Local 569 Processing Model implementation for processing. 571 If the MPC Model determines that the contextID does not match the 572 engineID of the current engine, then the message parts, as specified in 573 the interface section, are passed to a proxy application for 574 processing. 576 6.4. Applications 578 Applications are beyond the scope of this document, but earlier 579 attempts to define an SNMP Framework considered proxy as a possible 580 function of the protocol. SNMPng does not mandate support for proxy 581 in an SNMPng implementation. 583 6.4.1. A Proxy Application 585 The SNMPng Framework explicitly considers proxy to be an external 586 application. There are certain issues that must be clarified regarding 587 the relation and interface between proxy and the engine, however. 589 A proxy application has the responsibility to define any MIBs used 590 to forward message contents, and to determine the address and 591 identity to whom the message should be forwarded. 593 An engine supports at most one interface to proxy applications; if an 594 implementation wishes to support multiple proxy applications, the 595 determination of which type of proxy, and hence which proxy application 596 should handle it, should be handled by the single proxy application to 597 which the engine has an interface. 599 If proxy is supported, the engine passes all scopedPDUs with a 600 contextID that does not match the current engine's snmpNgEngineID to 601 the proxy application. No access control is applied to the message by 602 the engine which passes the request to the proxy application. A 603 scopedPDU passed to a proxy application must be a complete scopedPDU. 605 \ 606 \ 607 7. The SNMPng message format: 609 DEFINITIONS ::=3D BEGIN 611 snmpNgMessage ::=3D 612 SEQUENCE { 613 -- global parameters 614 version 615 INTEGER { snmpng (3) }, 616 msgID 617 INTEGER, 618 MMS 619 INTEGER, 621 QoS 622 OCTET STRING (SIZE(1)), 623 -- .... ..00 noAuth/noPriv 624 -- .... ..01 auth/noPriv 625 -- .... ..1. auth/priv 626 -- .... .1.. reportableFlag 628 securityModel 629 snmpNgSecurityModel, 631 -- security model-specific parameters 632 securityParameters 633 OCTET STRING, -- format defined by Security Model 635 -- local-processing model-specific data 636 data 637 ScopedPduData 638 } 640 ScopedPduData ::=3D 641 CHOICE { 642 plaintext 643 ScopedPDU, 644 encrypted 645 OCTET STRING -- encrypted ScopedPDU 646 } 648 scopedPDU ::=3D 649 SEQUENCE { 650 contextID 651 snmpNgEngineID, 652 contextName 653 snmpNgContextName, 654 data 655 ANY -- e.g. PDUs as defined in RFC1905 656 } 657 END 659 \ 660 7.1. SNMP version 662 The SNMP version identifies the version of the MPC framework in use. 663 For purposes of discouraging, but not preventing, the replacement of 664 the Local Processing Model, the SNMP version also implies the version 665 of the Local Processing Model. 667 7.2. msgID 669 The msgID is used by SNMP engines to coordinate the processing of the 670 message by different portions of the framework. 672 Note that the requestID used during local processing identifies the 673 request, not the message that carried the request, and therefore might 674 not be equal to the msgID. 676 7.3. MMS 678 The maximum message size supported by the sender of the message. 680 7.4. securityModel 682 Multiple security models may exist concurrently in the engine. 683 This model number identifies which security model should be used to 684 provide security processing for the message. The mapping to the 685 appropriate implementation within the agent is done in an 686 implementation-dependent manner. 688 The initial model of the SNMPng Security Framework is the User-Based 689 Security Model of the SNMPng Security Framework. 691 7.5. QoS 693 The QoS field contains flags to control the processing of the message. 695 If the reportableFlag is set, then reportPDUs are allowed to be 696 returned to the sender under those conditions which cause the 697 generation of reportPDUs. If the reportableFlag is zero, then a 698 reportPDU must not be sent. The reportableFlag should always be zero 699 when the message is a reportPDU, a responsePDU, or a trapPDU. 701 If the auth flag is set, then the security implementation is required 702 to identify the entity on whose behalf a request is generated and to 703 authenticate such identification. If the auth flag is zero, 704 authentication of the identification is not required. 706 If the priv flag is set, then the security implementation is required 707 to protect the data within an SNMP operation from disclosure, i.e. to 708 encrypt the data. If the priv flag is zero, then the security 710 \ 711 implementation does not need to protect the data using encryption. 712 It is an explicit requirement of the SNMPng Framework that if privacy 713 is selected, then authentication of the identification is required, 714 i.e. priv flag can only be set if auth flag is also set. 716 7.6. security parameters 718 This octet string is not interpreted by the MPC-F. This data is used 719 exclusively by the security model, and the contents and format of the 720 data is defined by the security model. 722 7.7. scopedPDU 724 The scopedPDU contains a PDU and the scope in which it is to be 725 processed, as defined by the ID of the engine and the context within 726 which the management data is realized on that engine. 728 7.7.1. contextID 730 This is the engineID of the engine which realizes the managed objects 731 referenced in the PDUs. 733 7.7.2. contextName 735 This is the name of the context, on the contextID-specified engine, 736 which realizes the managed objects referenced within the PDUs. 738 7.7.3. data 740 The data contains the PDUs. The Local Processing Model defines the 741 content and format of the PDUs. The initial model of the SNMPng Local 742 Processing Framework supports SNMPv2 PDUs as defined in RFC1905. 744 \ 745 8. The Frameworks and their standard "services" interfaces 747 Each Framework defines certain standard services, accessible 748 through protocol-fixed interfaces. 750 Each Model for a Framework must provide the standard services, 751 but how it performs the service is defined by the model. 753 8.1. Standard Services of Message Processing and Control Models 755 8.1.1. Receive SNMP messages from the network 757 Upon receipt of an SNMPng message from the network, an MPC-M 758 will extract the MMS, and the QoS, and will determine where the 759 block of security parameters start in the message. 761 It will, in an implementation-defined manner, establish a mechanism 762 for coordinating all processing regarding this received message, 763 e.g. it may assign a "handle" to the message. 765 The MPC-M will pass the MMS, the QoS, a pointer to the message, and a 766 pointer to the block of security parameters to the implementation 767 of the Security Model specified in the message header. 769 The Security Model, after completion of its processing, will return to 770 the Message Processing and Control implementation the group, the 771 securityCookie, the scopedPDU-MMS, and the scopedPDU. 773 In the event of an error in security processing, an errorCode may be 774 returned instead. 776 8.1.2. Send SNMP messages to the network 778 The MPC-M will pass a scopedPDU, the securityCookie, and all global 779 data to be included in the message to the Security Model. 781 The Security Model will construct the message, and return the completed 782 message to the MPC-M, will will send the message to the desired 783 address using the appropriate transport. 785 8.1.3. Coordinate the Local Processing of a Received Request Message 787 The MPC will receive the SNMP message according to the process 788 described in 8.1.1. 790 The Message Processing and Control implementation will compare the 791 contextID in the scopedPDU with its snmpNgEngineID. If they match, the 792 MPC will forward the scopedPDU to the Local Processing implementation. 793 The MPC will pass the scopedPDU, the Group, and the scopedPDU-MMS 794 provided by the Security Model implementation, plus the QoS, to the 795 Local Processing implementation. 797 \ 798 It will accept a completed scopedPDU containing the responsePDU 799 from the LP-I, and generate a response message according to the 800 process described in 8.1.2. 802 8.1.4. Forward Received Request Message to a Proxy Application 804 The MPC will receive the SNMP message according to the process 805 described in 8.1.1. 807 The MPC will determine whether a scopedPDU in a received message 808 contains a contextID which differs from its snmpNgEngineID. 809 If it does differ, and if a proxy application is supported by this 810 engine, the MPC will assign an implementation-defined handle to the 811 message. The MPC will determine, from the message header, the SNMP 812 version, the securityModel, the MMS, and the QoS. It will pass to the 813 proxy application the handle, the SNMP version, securityModel, MMS, 814 QoS, plus the securityCookie provided by the Security Model 815 implementation. 817 8.1.5. Generate a Request Message for an Application 819 The MPC will receive a request for the generation of a request message 820 from an application. The application has the responsibility for 821 providing 822 the Destination Address, the SNMP version, the QoS desired, the MMS of 823 the current engine, the SecurityModel to use, the securityCookie to 824 use, a scopedPDU containing the desired operation, and a handle used 825 for matching up an incoming response to the application making the 826 request. 828 The MPC checks the verb in the scopedPDU to determine that it is a 829 request message, and if so, skips local processing of the scopedPDU. 831 The MPC will generate the message according to the process described 832 in 8.1.2. 834 8.1.6. Forward Received Response Message to an Application 836 The MPC will receive the SNMP message according to the process 837 described in 8.1.1. 839 The MPC will determine which application is awaiting a response, using 840 the handle assigned to the transaction in step 8.1.3 842 The MPC will pass to the application the QoS, the MMS, the Security 843 Model, the securityCookie, the scopedPDU-MMS, and the scopedPDU. 845 The Application, using the securityCookie, will determine the end-user 846 on whose behalf the response should be processed. 848 \ 849 8.1.7. Forward Received Notification Message to an Application 851 The MPC will receive the SNMP message according to the process 852 described in 8.1.1. 854 The MPC will determine to which application traps should be forwarded. 856 The MPC will pass to the application the QoS, the MMS, the Security 857 Model, the securityCookie, the scopedPDU-MMS, and the scopedPDU. 859 The Application, using the securityCookie, will determine the end-user 860 on whose behalf the notification should be processed. 862 8.1.8. Generate a Trap Message 864 The MPC accepts from the LP-I a Destination Address, the QoS, the 865 SecurityModel, the Group, and the scopedPDU. 867 The MPC uses the group and QoS to request a list of securityCookies 868 from the Security Model for security entities contained in the group. 869 For each securityCookie in the list, the MPC generates an SNMP message 870 according to the process described in 8.1.2. 872 8.1.9. Send a Response Message from a Proxy Application 874 The MPC will send the SNMP message according to the process 875 described in 8.1.1. 877 The MPC will determine which application is awaiting a response, using 878 the handle assigned to the transaction in step 8.1.3 880 The MPC will pass to the application the QoS, the MMS, the Security 881 Model, the securityCookie, the scopedPDU-MMS, and the scopedPDU. 883 The Application, using the securityCookie, will determine the end-user 884 on whose behalf the response should be processed. 886 8.2. Standard Services Required of Security Models 888 8.2.1. validate the security-stamp in a received message 890 given a message, the MMS, QoS, and the security parameters from that 891 message, verify the message has not been altered, and authenticate 892 the identification of the security entity for whom the message was 893 generated. 895 If encrypted, decrypt the message 897 additional requirements may be defined by the model, but they 898 cannot require changes to the framework interface 900 \ 901 return a securityCookie identifying the entity for whom the message 902 was generated and return the portions of the message needed for 903 further processing: 904 a scopedPDU - a PDU enclosed by a header which contains 905 an snmpID and a contextName 906 QoS - the quality of service specified for security 907 validation. The same quality of service must also 908 be used during application of access control. 909 MMS - the maximum size of a message able to be generated 910 by this engine for the destination agent. 911 scopedPDU-MMS - the maximum size of a scopedPDU to be 912 included in a response message, given the amount of 913 reserved space in the message for the anticipated 914 security parameters. 915 acGroup - the acGroup to be applied for access control for 916 the entity for whom the request was generated. 918 8.2.2. security-stamp a message 920 Given a scopedPDU, QoS, MMS, and a securityCookie, the Security Model 921 must determine the security parameters for the message, the contents 922 and format of which are defined by the model. 924 The Security Model will return a message including the appropriate 925 security parameters, encrypted if required. 927 8.2.3. Provide mappings between security entities and securityCookies 929 Given model-specific parameters to identify a security entity, 930 an SF-M must return a securityCookie 932 Given a securityCookie generated by this SF-M, the SF-M must return 933 model-specific data identifying the corresponding security entity. 935 8.2.4. Provide mapping between group and securityCookies 937 Given a group, the SF-M must return an array of securityCookies 938 identifying the entities which are members of the specified group. 940 8.3. Standard Services of a Local-Processing Model 942 8.3.1. Process a request 944 Given a ScopedPDU, Group, QoS, and ScopedPDU-MMS, an LP-M must return 945 a scopedPDU processed according to the protocol rules of the LP-M 947 8.3.2. Generate a Trap 949 When an event occurs that requires the generation of a trap, the LP-M 950 must pass to the MPC a Destination Address, QoS, MMS, SecurityModel, a 951 Group, and a scopedPDU, according to the protocol rules of the LP-M. 953 \ 954 \ 955 9. Definitions 957 9.1. Definitions for the Architectural Model for SNMPng 959 snmpNg-MIB DEFINITIONS ::=3D BEGIN 961 IMPORTS 962 MODULE-IDENTITY, OBJECT-TYPE, snmpModules FROM SNMPv2-SMI 963 TEXTUAL-CONVENTION, TestAndIncr, 964 RowStatus, AutonomousType, StorageType, 965 TDomain, TAddress FROM SNMPv2-TC 966 MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF; 968 snmpNgMIB MODULE-IDENTITY 969 LAST-UPDATED "9703260000Z" -- 26 Mar 1997, midnight 970 ORGANIZATION "SNMPv3 Working Group" 971 CONTACT-INFO "WG-email: snmpv3@tis.com 972 Subscribe: majordomo@tis.com 973 In message body: subscribe snmpv3 975 Chair: Russ Mundy 976 Trusted Information Systems 977 postal: 3060 Washington Rd 978 Glenwood MD 21738 979 email: mundy@tis.com 980 phone: 301-854-6889 982 Co-editor: Bert Wijnen 983 IBM T.J. Watson Research 984 postal: Schagen 33 985 3461 GL Linschoten 986 Netherlands 987 email: wijnen@vnet.ibm.com 988 phone: +31-348-412-498 990 Co-editor Dave Harrington 991 Cabletron Systems, Inc 992 postal: Post Office Box 5005 993 MailStop: Durham 994 35 Industrial Way 995 Rochester NH 03867-5005 996 email: dbh@cabletron.com 997 phone: 603-337-7357 998 " 999 DESCRIPTION "The snmpNg engine MIB" 1000 ::=3D { snmpModules xx } 1002 -- Administrative assignments 1004 snmpNgMIBObjects OBJECT IDENTIFIER ::=3D { snmpNgMIB 1 } 1006 \ 1007 snmpNgMIBConformance OBJECT IDENTIFIER ::=3D { snmpNgMIB 2 } 1009 -- Textual Conventions used throughout the SNMPng Framework 1011 snmpNgGroupName ::=3D TEXTUAL-CONVENTION 1012 STATUS current 1013 DESCRIPTION "An octet string representing the name of a group 1014 for use in accordance with the SNMPng Architectural 1015 Framework. 1016 " 1017 SYNTAX OCTET STRING (SIZE(1..16)) 1019 snmpNgContextName ::=3D TEXTUAL-CONVENTION 1020 STATUS current 1021 DESCRIPTION "An SNMPng context name which unambiguously 1022 identifies a set of management information 1023 directly accessible by the Local Processing Module 1024 (implementation or LP-I) of an SNMPng engine. 1025 " 1026 SYNTAX OCTET STRING (SIZE (0..32)) 1028 snmpNgQoS ::=3D TEXTUAL-CONVENTION 1029 STATUS current 1030 DESCRIPTION "A level of security at which SNMPng messages can be 1031 sent; in particular, one of: 1032 noAuth - without authentication and without privacy, 1033 auth - with authentication but without privacy, 1034 priv - with authentication and with privacy. 1035 " 1036 SYNTAX INTEGER { noAuth(1), auth(2), priv(3) } 1038 snmpNgEngineID ::=3D TEXTUAL-CONVENTION 1039 STATUS current 1040 DESCRIPTION "An SNMPng entity's administratively-unique identifier. 1042 The value for this object may not be all zeros or 1043 all 'ff'H. 1045 The initial value for this object may be configured 1046 via an operator console entry or via an algorithmic 1047 function. In the later case, the following 1048 guidelines are recommended: 1050 1) The first four octets are set to the binary 1051 equivalent of the agent's SNMP network management 1052 private enterprise number as assigned by the 1053 Internet Assigned Numbers Authority (IANA). 1054 For example, if Acme Networks has been assigned 1055 { enterprises 696 }, the first four octets would 1056 be assigned '000002b8'H. 1058 \ 1060 2) The remaining eight octets are the cookie whose 1061 contents are determined via one or more 1062 enterprise specific methods. Such methods must 1063 be designed so as to maximize the possibility 1064 that the value of this object will be unique in 1065 the agent's administrative domain. For example, 1066 the cookie may be the IP address of the agent, 1067 or the MAC address of one of the interfaces, 1068 with each address suitably padded with random 1069 octets. If multiple methods are defined, then 1070 it is recommended that the cookie be further 1071 divided into one octet that indicates the 1072 method being used and seven octets which are 1073 a function of the method. 1074 " 1075 SYNTAX OCTET STRING (SIZE (12)) 1077 snmpNgSecurityModel ::=3D TEXTUAL-CONVENTION 1078 STATUS current 1079 DESCRIPTION "An identifier that uniquely identifies an SNMPng 1080 Security Model within the SNMPng Framework. 1081 " 1082 SYNTAX INTEGER 1084 -- SNMPng MIB objects implemented by the SNMPng MPC ****************** 1086 snmpNgEngineID OBJECT-TYPE 1087 SYNTAX snmpNgEngineID 1088 MAX-ACCESS read-only 1089 STATUS current 1090 DESCRIPTION "The SNMPng entity's administratively-unique 1091 SNMP-Engine identifier. 1092 " 1093 ::=3D { snmpNgMIBObjects 1 } 1095 snmpNgEngineMms OBJECT-TYPE 1096 SYNTAX INTEGER 1097 MAX-ACCESS read-only 1098 STATUS current 1099 DESCRIPTION "The maximum length in octets of an SNMPng message 1100 which this SNMPng entity will accept using any 1101 transport mapping. 1102 " 1103 ::=3D { snmpNgMIBObjects 2 } 1105 -- Conformance information 1107 snmpNgMIBCompliances OBJECT IDENTIFIER ::=3D { snmpNgMIBConformance 1 } 1108 snmpNgMIBGroups OBJECT IDENTIFIER ::=3D { snmpNgMIBConformance 2 } 1110 \ 1111 -- Compliance statements 1113 snmpNgMIBCompliance MODULE-COMPLIANCE 1114 STATUS current 1115 DESCRIPTION 1116 "The compliance statement for SNMPng entities which 1117 implement the SNMPng (MPC) remote configuration MIB. 1118 " 1120 MODULE -- this module 1121 MANDATORY-GROUPS { snmpNgBasicGroup } 1123 ::=3D { snmpNgMIBCompliances 1 } 1125 snmpNgBasicGroup OBJECT-GROUP 1126 OBJECTS { snmpNgEngineID, 1127 snmpNgEngineMms 1128 } 1129 STATUS current 1130 DESCRIPTION 1131 "A collection of objects providing for remote configuration 1132 of an SNMPng entity which implements the SNMPng MPC-Model. 1133 " 1134 ::=3D { snmpNgMIBGroups 1 } 1136 END 1138 \ 1139 10. Agent Installation Parameters 1141 During installation, an SNMPng entity acting in an agent role is 1142 configured with several parameters. These include: 1144 (1) a security posture 1146 The choice of security posture determines the extent of the view 1147 configured for unauthenticated access. One of three possible 1148 choices is selected: 1150 minimum-secure, 1151 semi-secure, or 1152 very-secure. 1154 (2) one or more transport service addresses 1156 These parameters may be specified explicitly, or they may be 1157 specified implicitly as the same set of network-layer addresses 1158 configured for other uses by the device together with the well- 1159 known transport-layer "port" information for the appropriate 1160 transport domain 13. The agent listens on each of these 1161 transport service addresses for messages. 1163 \ 1165 11. Security Consideration 1167 This document describes how the SNMPng uses a Security Model and a 1168 Local processing Model to achieve a level of security for network 1169 management messages and controlled access to data. 1171 The level of security actually provided is primarily determined by 1172 the specific Security Model implementation(s) and the specific Local 1173 Processing Model implementation(s) incorporated into this framework. 1174 Applications have access to data which is not secured. Applications 1175 should take reasonable steps to protect the data from disclosure. 1177 It is the responsibility of the purchaser of an SNMPng engine to 1178 ensure that: 1179 1) an implementation of this framework is fully compliant with 1180 the rules laid down by this framework, 1181 2) the implementation of the Security Model complies with the 1182 rules of the Security Model, 1183 3) the implementation of the Local Processing Model complies 1184 with the rules of the Local Processing Model, 1185 4) the implementation of associated applications comply 1186 with the rules of this framework relative to applications, 1187 5) the Security Model of the implementation(s) incorporated into 1188 this framework satisfy the security needs of the organization 1189 using the SNMPng engine, 1190 6) the Local Processing Model of the implementation(s) incorporated 1191 into this framework satisfy the access control policies of the 1192 organization using the SNMPng engine, 1193 7) the implementation of the Security Model protects against 1194 inadvertently revealing security secrets in its design of 1195 implementation-specific data structures, 1196 8) the implementation of the Local Processing Model protects against 1197 inadvertently revealing configuration secrets in its design of 1198 implementation-specific data structures, 1199 9) and the applications associated with this engine should take 1200 reasonable steps to protect the security and access control 1201 configuration secrets from disclosure. 1203 \ 1205 12. References 1207 [RFC1901] The SNMPv2 Working Group, Case, J., McCloghrie, K., 1208 Rose, M., and S., Waldbusser, "Introduction to 1209 Community-based SNMPv2", RFC 1901, January 1996. 1211 [RFC1902] The SNMPv2 Working Group, Case, J., McCloghrie, K., 1212 Rose, M., and S., Waldbusser, "Structure of Management 1213 Information for Version 2 of the Simple Network Management 1214 Protocol (SNMPv2)", RFC 1905, January 1996. 1216 [RFC1905] The SNMPv2 Working Group, Case, J., McCloghrie, K., 1217 Rose, M., and S., Waldbusser, "Protocol Operations for 1218 Version 2 of the Simple Network Management Protocol (SNMPv2)", 1219 RFC 1905, January 1996. 1221 [RFC1906] The SNMPv2 Working Group, Case, J., McCloghrie, K., 1222 Rose, M., and S. Waldbusser, "Transport Mappings for 1223 Version 2 of the Simple Network Management Protocol (SNMPv2)", 1224 RFC 1906, January 1996. 1226 [RFC1907] The SNMPv2 Working Group, Case, J., McCloghrie, K., 1227 Rose, M., and S. Waldbusser, "Management Information Base for 1228 Version 2 of the Simple Network Management Protocol (SNMPv2)", 1229 RFC 1907 January 1996. 1231 [RFC1908] The SNMPv2 Working Group, Case, J., McCloghrie, K., 1232 Rose, M., and S. Waldbusser, "Coexistence between Version 1 1233 and Version 2 of the Internet-standard Network Management 1234 Framework", RFC 1908, January 1996. 1236 [SNMPng-ARCH] The SNMPng Working Group, Harrington, D., Wijnen, B., 1237 "Architecture for the Next Generation Simple Network Management 1238 Protocol (SNMPng)", draft-ietf-snmpv3-next-gen-arch-00.txt, 1239 April 1997. 1241 [SNMPng-LPM] The SNMPng Working Group, Wijnen, B., Harrington, D., 1242 "Local Processing Model for the Next Generation Simple Network 1243 Management Protocol (SNMPng)", draft-ietf-snmpng-lpm-00.txt, 1244 April 1997. 1246 [SNMPng-USEC] To be written 1247 The SNMPng Working Group, Editors...Names, 1248 "The User-Based Security Model for the Next Generation Simple 1249 Network Management Protocol (SNMPng)", 1250 draft-ietf-snmpng-usec-00.txt, April 1997. 1252 \ 1254 13. Editor's Addresses 1256 Co-editor: Bert Wijnen 1257 IBM T.J. Watson Research 1258 postal: Schagen 33 1259 3461 GL Linschoten 1260 Netherlands 1261 email: wijnen@vnet.ibm.com 1262 phone: +31-348-412-498 1264 Co-editor Dave Harrington 1265 Cabletron Systems, Inc 1266 postal: Post Office Box 5005 1267 MailStop: Durham 1268 35 Industrial Way 1269 Rochester NH 03867-5005 1270 email: dbh@cabletron.com 1271 phone: 603-337-7357 1273 14. Acknowledgements 1275 This document describes the work of the SNMP Security and Administrative 1276 Framework Evolution team, comprised of 1278 David Harrington (Cabletron Systems Inc.) 1279 Jeff Johnson (Cisco) 1280 David Levi (SNMP Research Inc.) 1281 John Linn (Openvision) 1282 Russ Mundy (Trusted Information Systems) chair 1283 Shawn Routhier (Epilogue) 1284 Glenn Waters (Nortel) 1285 Bert Wijnen (IBM T.J. Watson Research) 1287 \ 1289 Table of Contents 1291 0. Change Log 2 1292 1. Introduction 3 1293 1.1. A Note on Terminology 3 1294 2. Overview 4 1295 3. An Evolutionary Architecture - Design Goals 5 1296 3.1. Encapsulation 5 1297 3.2. Cohesion 5 1298 3.3. Hierarchical Rules 5 1299 3.4. Coupling 6 1300 4.0. Abstract Functionality 7 1301 4.1. Message Processing and Control 7 1302 4.2. Security 7 1303 4.3. Local Processing 8 1304 4.4. Applications 8 1305 4.5. Definition of SNMPng acronyms and terms: 8 1306 5. Elements of the Framework 9 1307 5.1. Groups 9 1308 5.2. Quality of Service 9 1309 5.3. Contexts 9 1310 5.4. Scoped-PDU 9 1311 5.5. Security Configuration Datastore 10 1312 5.6. Local Configuration Datastore 10 1313 6. Model Design Requirements 11 1314 6.1. Security Model Design Requirements 11 1315 6.2. Local Processing Model Design Requirements 12 1316 6.3. Message Processing and Control Requirements 13 1317 6.4. Applications 13 1318 6.4.1. A Proxy Application 13 1319 7. The SNMPng message format: 15 1320 7.1. SNMP version 16 1321 7.2. msgID 16 1322 7.3. MMS 16 1323 7.4. securityModel 16 1324 7.5. QoS 16 1325 7.6. security parameters 17 1326 7.7. scopedPDU 17 1327 7.7.1. contextID 17 1328 7.7.2. contextName 17 1329 7.7.3. data 17 1330 8. The Frameworks and their standard "services" interfaces 18 1331 8.1. Standard Services of Message Processing and Control Models 18 1332 8.1.1. Receive SNMP messages from the network 18 1333 8.1.2. Send SNMP messages to the network 18 1334 8.1.3. Coordinate the Local Processing of a Received Request Message 18 1335 8.1.4. Forward Received Request Message to a Proxy Application 19 1336 8.1.5. Generate a Request Message for an Application 19 1337 8.1.6. Forward Received Response Message to an Application 19 1338 8.1.7. Forward Received Notification Message to an Application 20 1339 8.1.8. Generate a Trap Message 20 1340 8.1.9. Send a Response Message from a Proxy Application 20 1341 8.2. Standard Services Required of Security Models 20 1342 8.2.1. validate the security-stamp in a received message 20 1343 8.2.2. security-stamp a message 21 1344 8.2.3. Provide mappings between security entities and securityCookies 21 1345 8.2.4. Provide mapping between group and securityCookies 21 1346 8.3. Standard Services of a Local-Processing Model 21 1347 8.3.1. Process a request 21 1348 8.3.2. Generate a Trap 21 1349 9. Definitions 23 1350 9.1. Definitions for the Architectural Model for SNMPng 23 1351 10. Agent Installation Parameters 27 1352 11. Security Consideration 28 1353 12. References 29 1354 13. Editor's Addresses 30 1355 14. Acknowledgements 30