| blob | a20c1d7e052f0fa8a131acb8d4c05d2edc654802 |
7 Network Working Group D. Harrington
8 Request for Comments: 2271 Cabletron Systems, Inc.
9 Obsoletes: 2261 R. Presuhn
10 Category: Standards Track BMC Software, Inc.
11 B. Wijnen
12 IBM T. J. Watson Research
13 January 1998
15 An Architecture for Describing
16 SNMP Management Frameworks
18 Status of this Memo
20 This document specifies an Internet standards track protocol for the
21 Internet community, and requests discussion and suggestions for
22 improvements. Please refer to the current edition of the "Internet
23 Official Protocol Standards" (STD 1) for the standardization state
24 and status of this protocol. Distribution of this memo is unlimited.
26 Copyright Notice
28 Copyright (C) The Internet Society (1998). All Rights Reserved.
30 IANA Note
32 Due to a clerical error in the assignment of the snmpModules in this
33 memo, this RFC provides the corrected number assignment for this
34 protocol. This memo obsoletes RFC 2261.
36 Abstract
38 This document describes an architecture for describing SNMP
39 Management Frameworks. The architecture is designed to be modular to
40 allow the evolution of the SNMP protocol standards over time. The
41 major portions of the architecture are an SNMP engine containing a
42 Message Processing Subsystem, a Security Subsystem and an Access
43 Control Subsystem, and possibly multiple SNMP applications which
44 provide specific functional processing of management data.
46 Table of Contents
48 1. Introduction ................................................ 3
49 1.1. Overview .................................................. 3
50 1.2. SNMP ...................................................... 4
51 1.3. Goals of this Architecture ................................ 5
52 1.4. Security Requirements of this Architecture ................ 6
53 1.5. Design Decisions .......................................... 7
54 2. Documentation Overview ...................................... 8
58 Harrington, et. al. Standards Track [Page 1]
59 \f
60 RFC 2271 SNMPv3 Architecture January 1998
63 2.1. Document Roadmap .......................................... 10
64 2.2. Applicability Statement ................................... 10
65 2.3. Coexistence and Transition ................................ 10
66 2.4. Transport Mappings ........................................ 11
67 2.5. Message Processing ........................................ 11
68 2.6. Security .................................................. 11
69 2.7. Access Control ............................................ 11
70 2.8. Protocol Operations ....................................... 12
71 2.9. Applications .............................................. 12
72 2.10. Structure of Management Information ...................... 12
73 2.11. Textual Conventions ...................................... 13
74 2.12. Conformance Statements ................................... 13
75 2.13. Management Information Base Modules ...................... 13
76 2.13.1. SNMP Instrumentation MIBs .............................. 13
77 2.14. SNMP Framework Documents ................................. 13
78 3. Elements of the Architecture ................................ 14
79 3.1. The Naming of Entities .................................... 14
80 3.1.1. SNMP engine ............................................. 15
81 3.1.1.1. snmpEngineID .......................................... 16
82 3.1.1.2. Dispatcher ............................................ 16
83 3.1.1.3. Message Processing Subsystem .......................... 16
84 3.1.1.3.1. Message Processing Model ............................ 17
85 3.1.1.4. Security Subsystem .................................... 17
86 3.1.1.4.1. Security Model ...................................... 17
87 3.1.1.4.2. Security Protocol ................................... 18
88 3.1.2. Access Control Subsystem ................................ 18
89 3.1.2.1. Access Control Model .................................. 18
90 3.1.3. Applications ............................................ 18
91 3.1.3.1. SNMP Manager .......................................... 19
92 3.1.3.2. SNMP Agent ............................................ 20
93 3.2. The Naming of Identities .................................. 21
94 3.2.1. Principal ............................................... 21
95 3.2.2. securityName ............................................ 21
96 3.2.3. Model-dependent security ID ............................. 22
97 3.3. The Naming of Management Information ...................... 22
98 3.3.1. An SNMP Context ......................................... 23
99 3.3.2. contextEngineID ......................................... 24
100 3.3.3. contextName ............................................. 24
101 3.3.4. scopedPDU ............................................... 25
102 3.4. Other Constructs .......................................... 25
103 3.4.1. maxSizeResponseScopedPDU ................................ 25
104 3.4.2. Local Configuration Datastore ........................... 25
105 3.4.3. securityLevel ........................................... 25
106 4. Abstract Service Interfaces ................................. 26
107 4.1. Dispatcher Primitives ..................................... 26
108 4.1.1. Generate Outgoing Request or Notification ............... 26
109 4.1.2. Process Incoming Request or Notification PDU ............ 26
110 4.1.3. Generate Outgoing Response .............................. 27
114 Harrington, et. al. Standards Track [Page 2]
115 \f
116 RFC 2271 SNMPv3 Architecture January 1998
119 4.1.4. Process Incoming Response PDU ........................... 27
120 4.1.5. Registering Responsibility for Handling SNMP PDUs ....... 28
121 4.2. Message Processing Subsystem Primitives ................... 28
122 4.2.1. Prepare Outgoing SNMP Request or Notification Message ... 28
123 4.2.2. Prepare an Outgoing SNMP Response Message ............... 29
124 4.2.3. Prepare Data Elements from an Incoming SNMP Message ..... 29
125 4.3. Access Control Subsystem Primitives ....................... 30
126 4.4. Security Subsystem Primitives ............................. 30
127 4.4.1. Generate a Request or Notification Message .............. 30
128 4.4.2. Process Incoming Message ................................ 31
129 4.4.3. Generate a Response Message ............................. 31
130 4.5. Common Primitives ......................................... 32
131 4.5.1. Release State Reference Information ..................... 32
132 4.6. Scenario Diagrams ......................................... 32
133 4.6.1. Command Generator or Notification Originator ............ 32
134 4.6.2. Scenario Diagram for a Command Responder Application .... 33
135 5. Managed Object Definitions for SNMP Management Frameworks ... 35
136 6. Intellectual Property ....................................... 44
137 7. Acknowledgements ............................................ 45
138 8. Security Considerations ..................................... 46
139 9. References .................................................. 46
140 10. Editors' Addresses ......................................... 48
141 A. Guidelines for Model Designers .............................. 49
142 A.1. Security Model Design Requirements ........................ 49
143 A.1.1. Threats ................................................. 49
144 A.1.2. Security Processing ..................................... 50
145 A.1.3. Validate the security-stamp in a received message ....... 51
146 A.1.4. Security MIBs ........................................... 51
147 A.1.5. Cached Security Data .................................... 51
148 A.2. Message Processing Model Design Requirements .............. 52
149 A.2.1. Receiving an SNMP Message from the Network .............. 52
150 A.2.2. Sending an SNMP Message to the Network .................. 52
151 A.3. Application Design Requirements ........................... 53
152 A.3.1. Applications that Initiate Messages ..................... 53
153 A.3.2. Applications that Receive Responses ..................... 54
154 A.3.3. Applications that Receive Asynchronous Messages ......... 54
155 A.3.4. Applications that Send Responses ........................ 54
156 A.4. Access Control Model Design Requirements .................. 55
157 B. Full Copyright Statement .................................... 56
159 1. Introduction
161 1.1. Overview
163 This document defines a vocabulary for describing SNMP Management
164 Frameworks, and an architecture for describing the major portions of
165 SNMP Management Frameworks.
170 Harrington, et. al. Standards Track [Page 3]
171 \f
172 RFC 2271 SNMPv3 Architecture January 1998
175 This document does not provide a general introduction to SNMP. Other
176 documents and books can provide a much better introduction to SNMP.
177 Nor does this document provide a history of SNMP. That also can be
178 found in books and other documents.
180 Section 1 describes the purpose, goals, and design decisions of this
181 architecture.
183 Section 2 describes various types of documents which define SNMP
184 Frameworks, and how they fit into this architecture. It also provides
185 a minimal road map to the documents which have previously defined
186 SNMP frameworks.
188 Section 3 details the vocabulary of this architecture and its pieces.
189 This section is important for understanding the remaining sections,
190 and for understanding documents which are written to fit within this
191 architecture.
193 Section 4 describes the primitives used for the abstract service
194 interfaces between the various subsystems, models and applications
195 within this architecture.
197 Section 5 defines a collection of managed objects used to instrument
198 SNMP entities within this architecture.
200 Sections 6, 7, 8, and 9 are administrative in nature.
202 Appendix A contains guidelines for designers of Models which are
203 expected to fit within this architecture.
205 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
206 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
207 document are to be interpreted as described in [RFC2119].
209 1.2. SNMP
211 An SNMP management system contains:
213 - several (potentially many) nodes, each with an SNMP entity
214 containing command responder and notification originator
215 applications, which have access to management instrumentation
216 (traditionally called agents);
218 - at least one SNMP entity containing command generator and/or
219 notification receiver applications (traditionally called a
220 manager) and,
226 Harrington, et. al. Standards Track [Page 4]
227 \f
228 RFC 2271 SNMPv3 Architecture January 1998
231 - a management protocol, used to convey management information
232 between the SNMP entities.
234 SNMP entities executing command generator and notification receiver
235 applications monitor and control managed elements. Managed elements
236 are devices such as hosts, routers, terminal servers, etc., which are
237 monitored and controlled via access to their management information.
239 It is the purpose of this document to define an architecture which
240 can evolve to realize effective management in a variety of
241 configurations and environments. The architecture has been designed
242 to meet the needs of implementations of:
244 - minimal SNMP entities with command responder and/or
245 notification originator applications (traditionally called SNMP
246 agents),
248 - SNMP entities with proxy forwarder applications (traditionally
249 called SNMP proxy agents),
251 - command line driven SNMP entities with command generator and/or
252 notification receiver applications (traditionally called SNMP
253 command line managers),
255 - SNMP entities with command generator and/or notification
256 receiver, plus command responder and/or notification originator
257 applications (traditionally called SNMP mid-level managers or
258 dual-role entities),
260 - SNMP entities with command generator and/or notification
261 receiver and possibly other types of applications for managing
262 a potentially very large number of managed nodes (traditionally
263 called (network) management stations).
265 1.3. Goals of this Architecture
267 This architecture was driven by the following goals:
269 - Use existing materials as much as possible. It is heavily based
270 on previous work, informally known as SNMPv2u and SNMPv2*.
272 - Address the need for secure SET support, which is considered
273 the most important deficiency in SNMPv1 and SNMPv2c.
275 - Make it possible to move portions of the architecture forward
276 in the standards track, even if consensus has not been reached
277 on all pieces.
282 Harrington, et. al. Standards Track [Page 5]
283 \f
284 RFC 2271 SNMPv3 Architecture January 1998
287 - Define an architecture that allows for longevity of the SNMP
288 Frameworks that have been and will be defined.
290 - Keep SNMP as simple as possible.
292 - Make it relatively inexpensive to deploy a minimal conforming
293 implementation.
295 - Make it possible to upgrade portions of SNMP as new approaches
296 become available, without disrupting an entire SNMP framework.
298 - Make it possible to support features required in large
299 networks, but make the expense of supporting a feature directly
300 related to the support of the feature.
302 1.4. Security Requirements of this Architecture
304 Several of the classical threats to network protocols are applicable
305 to the management problem and therefore would be applicable to any
306 Security Model used in an SNMP Management Framework. Other threats
307 are not applicable to the management problem. This section discusses
308 principal threats, secondary threats, and threats which are of lesser
309 importance.
311 The principal threats against which any Security Model used within
312 this architecture SHOULD provide protection are:
314 Modification of Information
315 The modification threat is the danger that some unauthorized SNMP
316 entity may alter in-transit SNMP messages generated on behalf of
317 an authorized principal in such a way as to effect unauthorized
318 management operations, including falsifying the value of an
319 object.
321 Masquerade
322 The masquerade threat is the danger that management operations not
323 authorized for some principal may be attempted by assuming the
324 identity of another principal that has the appropriate
325 authorizations.
327 Message Stream Modification
328 The SNMP protocol is typically based upon a connectionless
329 transport service which may operate over any subnetwork service.
330 The re-ordering, delay or replay of messages can and does occur
331 through the natural operation of many such subnetwork services.
332 The message stream modification threat is the danger that messages
338 Harrington, et. al. Standards Track [Page 6]
339 \f
340 RFC 2271 SNMPv3 Architecture January 1998
343 may be maliciously re-ordered, delayed or replayed to an extent
344 which is greater than can occur through the natural operation of a
345 subnetwork service, in order to effect unauthorized management
346 operations.
348 Disclosure
349 The disclosure threat is the danger of eavesdropping on the
350 exchanges between SNMP engines. Protecting against this threat
351 may be required as a matter of local policy.
353 There are at least two threats against which a Security Model within
354 this architecture need not protect.
356 Denial of Service
357 A Security Model need not attempt to address the broad range of
358 attacks by which service on behalf of authorized users is denied.
359 Indeed, such denial-of-service attacks are in many cases
360 indistinguishable from the type of network failures with which any
361 viable management protocol must cope as a matter of course.
363 Traffic Analysis
364 A Security Model need not attempt to address traffic analysis
365 attacks. Many traffic patterns are predictable - entities may be
366 managed on a regular basis by a relatively small number of
367 management stations - and therefore there is no significant
368 advantage afforded by protecting against traffic analysis.
370 1.5. Design Decisions
372 Various design decisions were made in support of the goals of the
373 architecture and the security requirements:
375 - Architecture
376 An architecture should be defined which identifies the
377 conceptual boundaries between the documents. Subsystems should
378 be defined which describe the abstract services provided by
379 specific portions of an SNMP framework. Abstract service
380 interfaces, as described by service primitives, define the
381 abstract boundaries between documents, and the abstract
382 services that are provided by the conceptual subsystems of an
383 SNMP framework.
385 - Self-contained Documents
386 Elements of procedure plus the MIB objects which are needed for
387 processing for a specific portion of an SNMP framework should
388 be defined in the same document, and as much as possible,
389 should not be referenced in other documents. This allows pieces
390 to be designed and documented as independent and self-contained
394 Harrington, et. al. Standards Track [Page 7]
395 \f
396 RFC 2271 SNMPv3 Architecture January 1998
399 parts, which is consistent with the general SNMP MIB module
400 approach. As portions of SNMP change over time, the documents
401 describing other portions of SNMP are not directly impacted.
402 This modularity allows, for example, Security Models,
403 authentication and privacy mechanisms, and message formats to
404 be upgraded and supplemented as the need arises. The self-
405 contained documents can move along the standards track on
406 different time-lines.
408 - Threats
409 The Security Models in the Security Subsystem SHOULD protect
410 against the principal threats: modification of information,
411 masquerade, message stream modification and disclosure. They
412 do not need to protect against denial of service and traffic
413 analysis.
415 - Remote Configuration
416 The Security and Access Control Subsystems add a whole new set
417 of SNMP configuration parameters. The Security Subsystem also
418 requires frequent changes of secrets at the various SNMP
419 entities. To make this deployable in a large operational
420 environment, these SNMP parameters must be able to be remotely
421 configured.
423 - Controlled Complexity
424 It is recognized that producers of simple managed devices want
425 to keep the resources used by SNMP to a minimum. At the same
426 time, there is a need for more complex configurations which can
427 spend more resources for SNMP and thus provide more
428 functionality. The design tries to keep the competing
429 requirements of these two environments in balance and allows
430 the more complex environments to logically extend the simple
431 environment.
433 2. Documentation Overview
435 The following figure shows the set of documents that fit within the
436 SNMP Architecture.
450 Harrington, et. al. Standards Track [Page 8]
451 \f
452 RFC 2271 SNMPv3 Architecture January 1998
455 +------------------------- Document Set ----------------------------+
456 | |
457 | +------------+ +-----------------+ +----------------+ |
458 | | Document * | | Applicability * | | Coexistence * | |
459 | | Roadmap | | Statement | | & Transition | |
460 | +------------+ +-----------------+ +----------------+ |
461 | |
462 | +---------------------------------------------------------------+ |
463 | | Message Handling | |
464 | | +----------------+ +-----------------+ +-----------------+ | |
465 | | | Transport | | Message | | Security | | |
466 | | | Mappings | | Processing and | | | | |
467 | | | | | Dispatcher | | | | |
468 | | +----------------+ +-----------------+ +-----------------+ | |
469 | +---------------------------------------------------------------+ |
470 | |
471 | +---------------------------------------------------------------+ |
472 | | PDU Handling | |
473 | | +----------------+ +-----------------+ +-----------------+ | |
474 | | | Protocol | | Applications | | Access | | |
475 | | | Operations | | | | Control | | |
476 | | +----------------+ +-----------------+ +-----------------+ | |
477 | +---------------------------------------------------------------+ |
478 | |
479 | +---------------------------------------------------------------+ |
480 | | Information Model | |
481 | | +--------------+ +--------------+ +---------------+ | |
482 | | | Structure of | | Textual | | Conformance | | |
483 | | | Management | | Conventions | | Statements | | |
484 | | | Information | | | | | | |
485 | | +--------------+ +--------------+ +---------------+ | |
486 | +---------------------------------------------------------------+ |
487 | |
488 | +---------------------------------------------------------------+ |
489 | | MIBs | |
490 | | +-------------+ +-------------+ +----------+ +----------+ | |
491 | | | Standard v1 | | Standard v1 | | Historic | | Draft v2 | | |
492 | | | RFC1157 | | RFC1212 | | RFC14XX | | RFC19XX | | |
493 | | | format | | format | | format | | format | | |
494 | | +-------------+ +-------------+ +----------+ +----------+ | |
495 | +---------------------------------------------------------------+ |
496 | |
497 +-------------------------------------------------------------------+
499 Note: RFC14XX means RFCs 1442, 1443, and 1444. RFC19XX means RFCs
500 1902, 1903, and 1904.
506 Harrington, et. al. Standards Track [Page 9]
507 \f
508 RFC 2271 SNMPv3 Architecture January 1998
511 Those marked with an asterisk (*) are expected to be written in the
512 future. Each of these documents may be replaced or supplemented.
513 This Architecture document specifically describes how new documents
514 fit into the set of documents in the area of Message and PDU
515 handling.
517 2.1. Document Roadmap
519 One or more documents may be written to describe how sets of
520 documents taken together form specific Frameworks. The configuration
521 of document sets might change over time, so the "road map" should be
522 maintained in a document separate from the standards documents
523 themselves.
525 2.2. Applicability Statement
527 SNMP is used in networks that vary widely in size and complexity, by
528 organizations that vary widely in their requirements of management.
529 Some models will be designed to address specific problems of
530 management, such as message security.
532 One or more documents may be written to describe the environments to
533 which certain versions of SNMP or models within SNMP would be
534 appropriately applied, and those to which a given model might be
535 inappropriately applied.
537 2.3. Coexistence and Transition
539 The purpose of an evolutionary architecture is to permit new models
540 to replace or supplement existing models. The interactions between
541 models could result in incompatibilities, security "holes", and other
542 undesirable effects.
544 The purpose of Coexistence documents is to detail recognized
545 anomalies and to describe required and recommended behaviors for
546 resolving the interactions between models within the architecture.
548 Coexistence documents may be prepared separately from model
549 definition documents, to describe and resolve interaction anomalies
550 between a model definition and one or more other model definitions.
552 Additionally, recommendations for transitions between models may also
553 be described, either in a coexistence document or in a separate
554 document.
562 Harrington, et. al. Standards Track [Page 10]
563 \f
564 RFC 2271 SNMPv3 Architecture January 1998
567 2.4. Transport Mappings
569 SNMP messages are sent over various transports. It is the purpose of
570 Transport Mapping documents to define how the mapping between SNMP
571 and the transport is done.
573 2.5. Message Processing
575 A Message Processing Model document defines a message format, which
576 is typically identified by a version field in an SNMP message header.
577 The document may also define a MIB module for use in message
578 processing and for instrumentation of version-specific interactions.
580 An SNMP engine includes one or more Message Processing Models, and
581 thus may support sending and receiving multiple versions of SNMP
582 messages.
584 2.6. Security
586 Some environments require secure protocol interactions. Security is
587 normally applied at two different stages:
589 - in the transmission/receipt of messages, and
591 - in the processing of the contents of messages.
593 For purposes of this document, "security" refers to message-level
594 security; "access control" refers to the security applied to protocol
595 operations.
597 Authentication, encryption, and timeliness checking are common
598 functions of message level security.
600 A security document describes a Security Model, the threats against
601 which the model protects, the goals of the Security Model, the
602 protocols which it uses to meet those goals, and it may define a MIB
603 module to describe the data used during processing, and to allow the
604 remote configuration of message-level security parameters, such as
605 passwords.
607 An SNMP engine may support multiple Security Models concurrently.
609 2.7. Access Control
611 During processing, it may be required to control access to managed
612 objects for operations.
618 Harrington, et. al. Standards Track [Page 11]
619 \f
620 RFC 2271 SNMPv3 Architecture January 1998
623 An Access Control Model defines mechanisms to determine whether
624 access to a managed object should be allowed. An Access Control
625 Model may define a MIB module used during processing and to allow the
626 remote configuration of access control policies.
628 2.8. Protocol Operations
630 SNMP messages encapsulate an SNMP Protocol Data Unit (PDU). It is the
631 purpose of a Protocol Operations document to define the operations of
632 the protocol with respect to the processing of the PDUs.
634 An application document defines which Protocol Operations documents
635 are supported by the application.
637 2.9. Applications
639 An SNMP entity normally includes a number of applications.
640 Applications use the services of an SNMP engine to accomplish
641 specific tasks. They coordinate the processing of management
642 information operations, and may use SNMP messages to communicate with
643 other SNMP entities.
645 Applications documents describe the purpose of an application, the
646 services required of the associated SNMP engine, and the protocol
647 operations and informational model that the application uses to
648 perform management operations.
650 An application document defines which set of documents are used to
651 specifically define the structure of management information, textual
652 conventions, conformance requirements, and operations supported by
653 the application.
655 2.10. Structure of Management Information
657 Management information is viewed as a collection of managed objects,
658 residing in a virtual information store, termed the Management
659 Information Base (MIB). Collections of related objects are defined in
660 MIB modules.
662 It is the purpose of a Structure of Management Information document
663 to establish the syntax for defining objects, modules, and other
664 elements of managed information.
674 Harrington, et. al. Standards Track [Page 12]
675 \f
676 RFC 2271 SNMPv3 Architecture January 1998
679 2.11. Textual Conventions
681 When designing a MIB module, it is often useful to define new types
682 similar to those defined in the SMI, but with more precise semantics,
683 or which have special semantics associated with them. These newly
684 defined types are termed textual conventions, and may defined in
685 separate documents, or within a MIB module.
687 2.12. Conformance Statements
689 It may be useful to define the acceptable lower-bounds of
690 implementation, along with the actual level of implementation
691 achieved. It is the purpose of Conformance Statements to define the
692 notation used for these purposes.
694 2.13. Management Information Base Modules
696 MIB documents describe collections of managed objects which
697 instrument some aspect of a managed node.
699 2.13.1. SNMP Instrumentation MIBs
701 An SNMP MIB document may define a collection of managed objects which
702 instrument the SNMP protocol itself. In addition, MIB modules may be
703 defined within the documents which describe portions of the SNMP
704 architecture, such as the documents for Message processing Models,
705 Security Models, etc. for the purpose of instrumenting those Models,
706 and for the purpose of allowing remote configuration of the Model.
708 2.14. SNMP Framework Documents
710 This architecture is designed to allow an orderly evolution of
711 portions of SNMP Frameworks.
713 Throughout the rest of this document, the term "subsystem" refers to
714 an abstract and incomplete specification of a portion of a Framework,
715 that is further refined by a model specification.
717 A "model" describes a specific design of a subsystem, defining
718 additional constraints and rules for conformance to the model. A
719 model is sufficiently detailed to make it possible to implement the
720 specification.
722 An "implementation" is an instantiation of a subsystem, conforming to
723 one or more specific models.
725 SNMP version 1 (SNMPv1), is the original Internet-standard Network
726 Management Framework, as described in RFCs 1155, 1157, and 1212.
730 Harrington, et. al. Standards Track [Page 13]
731 \f
732 RFC 2271 SNMPv3 Architecture January 1998
735 SNMP version 2 (SNMPv2), is the SNMPv2 Framework as derived from the
736 SNMPv1 Framework. It is described in RFCs 1902-1907. SNMPv2 has no
737 message definition.
739 The Community-based SNMP version 2 (SNMPv2c), is an experimental SNMP
740 Framework which supplements the SNMPv2 Framework, as described in
741 RFC1901. It adds the SNMPv2c message format, which is similar to the
743 SNMPv1 message format.
745 SNMP version 3 (SNMPv3), is an extensible SNMP Framework which
746 supplements the SNMPv2 Framework, by supporting the following:
748 - a new SNMP message format,
750 - Security for Messages, and
752 - Access Control.
754 Other SNMP Frameworks, i.e., other configurations of implemented
755 subsystems, are expected to also be consistent with this
756 architecture.
758 3. Elements of the Architecture
760 This section describes the various elements of the architecture and
761 how they are named. There are three kinds of naming:
763 1) the naming of entities,
765 2) the naming of identities, and
767 3) the naming of management information.
769 This architecture also defines some names for other constructs that
770 are used in the documentation.
772 3.1. The Naming of Entities
774 An SNMP entity is an implementation of this architecture. Each such
775 SNMP entity consists of an SNMP engine and one or more associated
776 applications.
778 The following figure shows details about an SNMP entity and the
779 components within it.
786 Harrington, et. al. Standards Track [Page 14]
787 \f
788 RFC 2271 SNMPv3 Architecture January 1998
791 +-------------------------------------------------------------------+
792 | SNMP entity |
793 | |
794 | +-------------------------------------------------------------+ |
795 | | SNMP engine (identified by snmpEngineID) | |
796 | | | |
797 | | +------------+ +------------+ +-----------+ +-----------+ | |
798 | | | | | | | | | | | |
799 | | | Dispatcher | | Message | | Security | | Access | | |
800 | | | | | Processing | | Subsystem | | Control | | |
801 | | | | | Subsystem | | | | Subsystem | | |
802 | | | | | | | | | | | |
803 | | +------------+ +------------+ +-----------+ +-----------+ | |
804 | | | |
805 | +-------------------------------------------------------------+ |
806 | |
807 | +-------------------------------------------------------------+ |
808 | | Application(s) | |
809 | | | |
810 | | +-------------+ +--------------+ +--------------+ | |
811 | | | Command | | Notification | | Proxy | | |
812 | | | Generator | | Receiver | | Forwarder | | |
813 | | +-------------+ +--------------+ +--------------+ | |
814 | | | |
815 | | +-------------+ +--------------+ +--------------+ | |
816 | | | Command | | Notification | | Other | | |
817 | | | Responder | | Originator | | | | |
818 | | +-------------+ +--------------+ +--------------+ | |
819 | | | |
820 | +-------------------------------------------------------------+ |
821 | |
822 +-------------------------------------------------------------------+
824 3.1.1. SNMP engine
826 An SNMP engine provides services for sending and receiving messages,
827 authenticating and encrypting messages, and controlling access to
828 managed objects. There is a one-to-one association between an SNMP
829 engine and the SNMP entity which contains it.
831 The engine contains:
833 1) a Dispatcher,
835 2) a Message Processing Subsystem,
842 Harrington, et. al. Standards Track [Page 15]
843 \f
844 RFC 2271 SNMPv3 Architecture January 1998
847 3) a Security Subsystem, and
849 4) an Access Control Subsystem.
851 3.1.1.1. snmpEngineID
853 Within an administrative domain, an snmpEngineID is the unique and
854 unambiguous identifier of an SNMP engine. Since there is a one-to-one
855 association between SNMP engines and SNMP entities, it also uniquely
856 and unambiguously identifies the SNMP entity.
858 3.1.1.2. Dispatcher
860 There is only one Dispatcher in an SNMP engine. It allows for
861 concurrent support of multiple versions of SNMP messages in the SNMP
862 engine. It does so by:
864 - sending and receiving SNMP messages to/from the network,
866 - determining the version of an SNMP message and interacting with
867 the corresponding Message Processing Model,
869 - providing an abstract interface to SNMP applications for
870 delivery of a PDU to an application.
872 - providing an abstract interface for SNMP applications that
873 allows them to send a PDU to a remote SNMP entity.
875 3.1.1.3. Message Processing Subsystem
877 The Message Processing Subsystem is responsible for preparing
878 messages for sending, and extracting data from received messages.
880 The Message Processing Subsystem potentially contains multiple
881 Message Processing Models as shown in the next figure.
883 * One or more Message Processing Models may be present.
898 Harrington, et. al. Standards Track [Page 16]
899 \f
900 RFC 2271 SNMPv3 Architecture January 1998
903 +------------------------------------------------------------------+
904 | |
905 | Message Processing Subsystem |
906 | |
907 | +------------+ +------------+ +------------+ +------------+ |
908 | | * | | * | | * | | * | |
909 | | SNMPv3 | | SNMPv1 | | SNMPv2c | | Other | |
910 | | Message | | Message | | Message | | Message | |
911 | | Processing | | Processing | | Processing | | Processing | |
912 | | Model | | Model | | Model | | Model | |
913 | | | | | | | | | |
914 | +------------+ +------------+ +------------+ +------------+ |
915 | |
916 +------------------------------------------------------------------+
918 3.1.1.3.1. Message Processing Model
920 Each Message Processing Model defines the format of a particular
921 version of an SNMP message and coordinates the preparation and
922 extraction of each such version-specific message format.
924 3.1.1.4. Security Subsystem
926 The Security Subsystem provides security services such as the
927 authentication and privacy of messages and potentially contains
928 multiple Security Models as shown in the following figure
930 * One or more Security Models may be present.
932 +------------------------------------------------------------------+
933 | |
934 | Security Subsystem |
935 | |
936 | +----------------+ +-----------------+ +-------------------+ |
937 | | * | | * | | * | |
938 | | User-Based | | Other | | Other | |
939 | | Security | | Security | | Security | |
940 | | Model | | Model | | Model | |
941 | | | | | | | |
942 | +----------------+ +-----------------+ +-------------------+ |
943 | |
944 +------------------------------------------------------------------+
946 3.1.1.4.1. Security Model
948 A Security Model defines the threats against which it protects, the
949 goals of its services, and the security protocols used to provide
950 security services such as authentication and privacy.
954 Harrington, et. al. Standards Track [Page 17]
955 \f
956 RFC 2271 SNMPv3 Architecture January 1998
959 3.1.1.4.2. Security Protocol
961 A Security Protocol defines the mechanisms, procedures, and MIB data
962 used to provide a security service such as authentication or privacy.
964 3.1.2. Access Control Subsystem
966 The Access Control Subsystem provides authorization services by means
967 of one or more Access Control Models.
969 +------------------------------------------------------------------+
970 | |
971 | Access Control Subsystem |
972 | |
973 | +---------------+ +-----------------+ +------------------+ |
974 | | * | | * | | * | |
975 | | View-Based | | Other | | Other | |
976 | | Access | | Access | | Access | |
977 | | Control | | Control | | Control | |
978 | | Model | | Model | | Model | |
979 | | | | | | | |
980 | +---------------+ +-----------------+ +------------------+ |
981 | |
982 +------------------------------------------------------------------+
984 3.1.2.1. Access Control Model
986 An Access Control Model defines a particular access decision function
987 in order to support decisions regarding access rights.
989 3.1.3. Applications
991 There are several types of applications, including:
993 - command generators, which monitor and manipulate management
994 data,
996 - command responders, which provide access to management data,
998 - notification originators, which initiate asynchronous messages,
1000 - notification receivers, which process asynchronous messages,
1001 and
1003 - proxy forwarders, which forward messages between entities.
1005 These applications make use of the services provided by the SNMP
1006 engine.
1010 Harrington, et. al. Standards Track [Page 18]
1011 \f
1012 RFC 2271 SNMPv3 Architecture January 1998
1015 3.1.3.1. SNMP Manager
1017 An SNMP entity containing one or more command generator and/or
1018 notification receiver applications (along with their associated SNMP
1019 engine) has traditionally been called an SNMP manager. * One or more
1020 models may be present.
1022 (traditional SNMP manager)
1023 +-------------------------------------------------------------------+
1024 | +--------------+ +--------------+ +--------------+ SNMP entity |
1025 | | NOTIFICATION | | NOTIFICATION | | COMMAND | |
1026 | | ORIGINATOR | | RECEIVER | | GENERATOR | |
1027 | | applications | | applications | | applications | |
1028 | +--------------+ +--------------+ +--------------+ |
1029 | ^ ^ ^ |
1030 | | | | |
1031 | v v v |
1032 | +-------+--------+-----------------+ |
1033 | ^ |
1034 | | +---------------------+ +----------------+ |
1035 | | | Message Processing | | Security | |
1036 | Dispatcher v | Subsystem | | Subsystem | |
1037 | +-------------------+ | +------------+ | | | |
1038 | | PDU Dispatcher | | +->| v1MP * |<--->| +------------+ | |
1039 | | | | | +------------+ | | | Other | | |
1040 | | | | | +------------+ | | | Security | | |
1041 | | | | +->| v2cMP * |<--->| | Model | | |
1042 | | Message | | | +------------+ | | +------------+ | |
1043 | | Dispatcher <--------->+ | | | |
1044 | | | | | +------------+ | | +------------+ | |
1045 | | | | +->| v3MP * |<--->| | User-based | | |
1046 | | Transport | | | +------------+ | | | Security | | |
1047 | | Mapping | | | +------------+ | | | Model | | |
1048 | | (e.g RFC1906) | | +->| otherMP * |<--->| +------------+ | |
1049 | +-------------------+ | +------------+ | | | |
1050 | ^ +---------------------+ +----------------+ |
1051 | | |
1052 | v |
1053 +-------------------------------------------------------------------+
1054 +-----+ +-----+ +-------+
1055 | UDP | | IPX | . . . | other |
1056 +-----+ +-----+ +-------+
1057 ^ ^ ^
1058 | | |
1059 v v v
1060 +------------------------------+
1061 | Network |
1062 +------------------------------+
1066 Harrington, et. al. Standards Track [Page 19]
1067 \f
1068 RFC 2271 SNMPv3 Architecture January 1998
1071 3.1.3.2. SNMP Agent
1073 An SNMP entity containing one or more command responder and/or
1074 notification originator applications (along with their associated
1075 SNMP engine) has traditionally been called an SNMP agent.
1076 +------------------------------+
1077 | Network |
1078 +------------------------------+
1079 ^ ^ ^
1080 | | |
1081 v v v
1082 +-----+ +-----+ +-------+
1083 | UDP | | IPX | . . . | other |
1084 +-----+ +-----+ +-------+ (traditional SNMP agent)
1085 +-------------------------------------------------------------------+
1086 | ^ |
1087 | | +---------------------+ +----------------+ |
1088 | | | Message Processing | | Security | |
1089 | Dispatcher v | Subsystem | | Subsystem | |
1090 | +-------------------+ | +------------+ | | | |
1091 | | Transport | | +->| v1MP * |<--->| +------------+ | |
1092 | | Mapping | | | +------------+ | | | Other | | |
1093 | | (e.g. RFC1906) | | | +------------+ | | | Security | | |
1094 | | | | +->| v2cMP * |<--->| | Model | | |
1095 | | Message | | | +------------+ | | +------------+ | |
1096 | | Dispatcher <--------->| +------------+ | | +------------+ | |
1097 | | | | +->| v3MP * |<--->| | User-based | | |
1098 | | | | | +------------+ | | | Security | | |
1099 | | PDU Dispatcher | | | +------------+ | | | Model | | |
1100 | +-------------------+ | +->| otherMP * |<--->| +------------+ | |
1101 | ^ | +------------+ | | | |
1102 | | +---------------------+ +----------------+ |
1103 | v |
1104 | +-------+-------------------------+---------------+ |
1105 | ^ ^ ^ |
1106 | | | | |
1107 | v v v |
1108 | +-------------+ +---------+ +--------------+ +-------------+ |
1109 | | COMMAND | | ACCESS | | NOTIFICATION | | PROXY * | |
1110 | | RESPONDER |<->| CONTROL |<->| ORIGINATOR | | FORWARDER | |
1111 | | application | | | | applications | | application | |
1112 | +-------------+ +---------+ +--------------+ +-------------+ |
1113 | ^ ^ |
1114 | | | |
1115 | v v |
1116 | +----------------------------------------------+ |
1117 | | MIB instrumentation | SNMP entity |
1118 +-------------------------------------------------------------------+
1122 Harrington, et. al. Standards Track [Page 20]
1123 \f
1124 RFC 2271 SNMPv3 Architecture January 1998
1127 3.2. The Naming of Identities
1129 principal
1130 ^
1131 |
1132 |
1133 +----------------------------|-------------+
1134 | SNMP engine v |
1135 | +--------------+ |
1136 | | | |
1137 | +-----------------| securityName |---+ |
1138 | | Security Model | | | |
1139 | | +--------------+ | |
1140 | | ^ | |
1141 | | | | |
1142 | | v | |
1143 | | +------------------------------+ | |
1144 | | | | | |
1145 | | | Model | | |
1146 | | | Dependent | | |
1147 | | | Security ID | | |
1148 | | | | | |
1149 | | +------------------------------+ | |
1150 | | ^ | |
1151 | | | | |
1152 | +-------------------------|----------+ |
1153 | | |
1154 | | |
1155 +----------------------------|-------------+
1156 |
1157 v
1158 network
1160 3.2.1. Principal
1162 A principal is the "who" on whose behalf services are provided or
1163 processing takes place.
1165 A principal can be, among other things, an individual acting in a
1166 particular role; a set of individuals, with each acting in a
1167 particular role; an application or a set of applications; and
1168 combinations thereof.
1170 3.2.2. securityName
1172 A securityName is a human readable string representing a principal.
1173 It has a model-independent format, and can be used outside a
1174 particular Security Model.
1178 Harrington, et. al. Standards Track [Page 21]
1179 \f
1180 RFC 2271 SNMPv3 Architecture January 1998
1183 3.2.3. Model-dependent security ID
1185 A model-dependent security ID is the model-specific representation of
1186 a securityName within a particular Security Model.
1188 Model-dependent security IDs may or may not be human readable, and
1189 have a model-dependent syntax. Examples include community names, user
1190 names, and parties.
1192 The transformation of model-dependent security IDs into securityNames
1193 and vice versa is the responsibility of the relevant Security Model.
1195 3.3. The Naming of Management Information
1197 Management information resides at an SNMP entity where a Command
1198 Responder Application has local access to potentially multiple
1199 contexts. This application uses a contextEngineID equal to the
1200 snmpEngineID of its associated SNMP engine.
1234 Harrington, et. al. Standards Track [Page 22]
1235 \f
1236 RFC 2271 SNMPv3 Architecture January 1998
1239 +-----------------------------------------------------------------+
1240 | SNMP entity (identified by snmpEngineID, example: abcd) |
1241 | |
1242 | +------------------------------------------------------------+ |
1243 | | SNMP engine (identified by snmpEngineID) | |
1244 | | | |
1245 | | +-------------+ +------------+ +-----------+ +-----------+ | |
1246 | | | | | | | | | | | |
1247 | | | Dispatcher | | Message | | Security | | Access | | |
1248 | | | | | Processing | | Subsystem | | Control | | |
1249 | | | | | Subsystem | | | | Subsystem | | |
1250 | | | | | | | | | | | |
1251 | | +-------------+ +------------+ +-----------+ +-----------+ | |
1252 | | | |
1253 | +------------------------------------------------------------+ |
1254 | |
1255 | +------------------------------------------------------------+ |
1256 | | Command Responder Application | |
1257 | | (contextEngineID, example: abcd) | |
1258 | | | |
1259 | | example contextNames: | |
1260 | | | |
1261 | | "bridge1" "bridge2" "" (default) | |
1262 | | --------- --------- ------------ | |
1263 | | | | | | |
1264 | +------|------------------|-------------------|--------------+ |
1265 | | | | |
1266 | +------|------------------|-------------------|--------------+ |
1267 | | MIB | instrumentation | | | |
1268 | | +---v------------+ +---v------------+ +----v-----------+ | |
1269 | | | context | | context | | context | | |
1270 | | | | | | | | | |
1271 | | | +------------+ | | +------------+ | | +------------+ | | |
1272 | | | | bridge MIB | | | | bridge MIB | | | | other MIB | | | |
1273 | | | +------------+ | | +------------+ | | +------------+ | | |
1274 | | | | | | | | | |
1275 | | | | | | | +------------+ | | |
1276 | | | | | | | | some MIB | | | |
1277 | | | | | | | +------------+ | | |
1278 | | | | | | | | | |
1279 +-----------------------------------------------------------------+
1281 3.3.1. An SNMP Context
1283 An SNMP context, or just "context" for short, is a collection of
1284 management information accessible by an SNMP entity. An item of
1285 management information may exist in more than one context. An SNMP
1286 entity potentially has access to many contexts.
1290 Harrington, et. al. Standards Track [Page 23]
1291 \f
1292 RFC 2271 SNMPv3 Architecture January 1998
1295 Typically, there are many instances of each managed object type
1296 within a management domain. For simplicity, the method for
1297 identifying instances specified by the MIB module does not allow each
1298 instance to be distinguished amongst the set of all instances within
1299 a management domain; rather, it allows each instance to be identified
1300 only within some scope or "context", where there are multiple such
1301 contexts within the management domain. Often, a context is a
1302 physical device, or perhaps, a logical device, although a context can
1303 also encompass multiple devices, or a subset of a single device, or
1304 even a subset of multiple devices, but a context is always defined as
1305 a subset of a single SNMP entity. Thus, in order to identify an
1306 individual item of management information within the management
1307 domain, its contextName and contextEngineID must be identified in
1308 addition to its object type and its instance.
1310 For example, the managed object type ifDescr [RFC1573], is defined as
1311 the description of a network interface. To identify the description
1312 of device-X's first network interface, four pieces of information are
1313 needed: the snmpEngineID of the SNMP entity which provides access to
1314 the management information at device-X, the contextName (device-X),
1315 the managed object type (ifDescr), and the instance ("1").
1317 Each context has (at least) one unique identification within the
1318 management domain. The same item of management information can exist
1319 in multiple contexts. An item of management information may have
1320 multiple unique identifications. This occurs when an item of
1321 management information exists in multiple contexts, and this also
1322 occurs when a context has multiple unique identifications.
1324 The combination of a contextEngineID and a contextName unambiguously
1325 identifies a context within an administrative domain; note that there
1326 may be multiple unique combinations of contextEngineID and
1327 contextName that unambiguously identify the same context.
1329 3.3.2. contextEngineID
1331 Within an administrative domain, a contextEngineID uniquely
1332 identifies an SNMP entity that may realize an instance of a context
1333 with a particular contextName.
1335 3.3.3. contextName
1337 A contextName is used to name a context. Each contextName MUST be
1338 unique within an SNMP entity.
1346 Harrington, et. al. Standards Track [Page 24]
1347 \f
1348 RFC 2271 SNMPv3 Architecture January 1998
1351 3.3.4. scopedPDU
1353 A scopedPDU is a block of data containing a contextEngineID, a
1354 contextName, and a PDU.
1356 The PDU is an SNMP Protocol Data Unit containing information named in
1357 the context which is unambiguously identified within an
1358 administrative domain by the combination of the contextEngineID and
1359 the contextName. See, for example, RFC1905 for more information about
1360 SNMP PDUs.
1362 3.4. Other Constructs
1364 3.4.1. maxSizeResponseScopedPDU
1366 The maxSizeResponseScopedPDU is the maximum size of a scopedPDU to be
1367 included in a response message. Note that the size of a scopedPDU
1368 does not include the size of the SNMP message header.
1370 3.4.2. Local Configuration Datastore
1372 The subsystems, models, and applications within an SNMP entity may
1373 need to retain their own sets of configuration information.
1375 Portions of the configuration information may be accessible as
1376 managed objects.
1378 The collection of these sets of information is referred to as an
1379 entity's Local Configuration Datastore (LCD).
1381 3.4.3. securityLevel
1383 This architecture recognizes three levels of security:
1385 - without authentication and without privacy (noAuthNoPriv)
1387 - with authentication but without privacy (authNoPriv)
1389 - with authentication and with privacy (authPriv)
1391 These three values are ordered such that noAuthNoPriv is less than
1392 authNoPriv and authNoPriv is less than authPriv.
1394 Every message has an associated securityLevel. All Subsystems
1395 (Message Processing, Security, Access Control) and applications are
1396 required to either supply a value of securityLevel or to abide by the
1397 supplied value of securityLevel while processing the message and its
1398 contents.
1402 Harrington, et. al. Standards Track [Page 25]
1403 \f
1404 RFC 2271 SNMPv3 Architecture January 1998
1407 4. Abstract Service Interfaces
1409 Abstract service interfaces have been defined to describe the
1410 conceptual interfaces between the various subsystems within an SNMP
1411 entity.
1413 These abstract service interfaces are defined by a set of primitives
1414 that define the services provided and the abstract data elements that
1415 are to be passed when the services are invoked. This section lists
1416 the primitives that have been defined for the various subsystems.
1418 4.1. Dispatcher Primitives
1420 The Dispatcher typically provides services to the SNMP applications
1421 via its PDU Dispatcher. This section describes the primitives
1422 provided by the PDU Dispatcher.
1424 4.1.1. Generate Outgoing Request or Notification
1426 The PDU Dispatcher provides the following primitive for an
1427 application to send an SNMP Request or Notification to another SNMP
1428 entity:
1430 statusInformation = -- sendPduHandle if success
1431 -- errorIndication if failure
1432 sendPdu(
1433 IN transportDomain -- transport domain to be used
1434 IN transportAddress -- transport address to be used
1435 IN messageProcessingModel -- typically, SNMP version
1436 IN securityModel -- Security Model to use
1437 IN securityName -- on behalf of this principal
1438 IN securityLevel -- Level of Security requested
1439 IN contextEngineID -- data from/at this entity
1440 IN contextName -- data from/in this context
1441 IN pduVersion -- the version of the PDU
1442 IN PDU -- SNMP Protocol Data Unit
1443 IN expectResponse -- TRUE or FALSE
1444 )
1446 4.1.2. Process Incoming Request or Notification PDU
1448 The PDU Dispatcher provides the following primitive to pass an
1449 incoming SNMP PDU to an application:
1451 processPdu( -- process Request/Notification PDU
1452 IN messageProcessingModel -- typically, SNMP version
1453 IN securityModel -- Security Model in use
1454 IN securityName -- on behalf of this principal
1458 Harrington, et. al. Standards Track [Page 26]
1459 \f
1460 RFC 2271 SNMPv3 Architecture January 1998
1463 IN securityLevel -- Level of Security
1464 IN contextEngineID -- data from/at this SNMP entity
1465 IN contextName -- data from/in this context
1466 IN pduVersion -- the version of the PDU
1467 IN PDU -- SNMP Protocol Data Unit
1468 IN maxSizeResponseScopedPDU -- maximum size of the Response PDU
1469 IN stateReference -- reference to state information
1470 ) -- needed when sending a response
1472 4.1.3. Generate Outgoing Response
1474 The PDU Dispatcher provides the following primitive for an
1475 application to return an SNMP Response PDU to the PDU Dispatcher:
1477 returnResponsePdu(
1478 IN messageProcessingModel -- typically, SNMP version
1479 IN securityModel -- Security Model in use
1480 IN securityName -- on behalf of this principal
1481 IN securityLevel -- same as on incoming request
1482 IN contextEngineID -- data from/at this SNMP entity
1483 IN contextName -- data from/in this context
1484 IN pduVersion -- the version of the PDU
1485 IN PDU -- SNMP Protocol Data Unit
1486 IN maxSizeResponseScopedPDU -- maximum size of the Response PDU
1487 IN stateReference -- reference to state information
1488 -- as presented with the request
1489 IN statusInformation -- success or errorIndication
1490 ) -- error counter OID/value if error
1492 4.1.4. Process Incoming Response PDU
1494 The PDU Dispatcher provides the following primitive to pass an
1495 incoming SNMP Response PDU to an application:
1497 processResponsePdu( -- process Response PDU
1498 IN messageProcessingModel -- typically, SNMP version
1499 IN securityModel -- Security Model in use
1500 IN securityName -- on behalf of this principal
1501 IN securityLevel -- Level of Security
1502 IN contextEngineID -- data from/at this SNMP entity
1503 IN contextName -- data from/in this context
1504 IN pduVersion -- the version of the PDU
1505 IN PDU -- SNMP Protocol Data Unit
1506 IN statusInformation -- success or errorIndication
1507 IN sendPduHandle -- handle from sendPdu
1508 )
1514 Harrington, et. al. Standards Track [Page 27]
1515 \f
1516 RFC 2271 SNMPv3 Architecture January 1998
1519 4.1.5. Registering Responsibility for Handling SNMP PDUs
1521 Applications can register/unregister responsibility for a specific
1522 contextEngineID, for specific pduTypes, with the PDU Dispatcher
1523 according to the following primitives. The list of particular
1524 pduTypes that an application can register for is determined by the
1525 Message Processing Model(s) supported by the SNMP entity that
1526 contains the PDU Dispatcher.
1528 statusInformation = -- success or errorIndication
1529 registerContextEngineID(
1530 IN contextEngineID -- take responsibility for this one
1531 IN pduType -- the pduType(s) to be registered
1532 )
1534 unregisterContextEngineID(
1535 IN contextEngineID -- give up responsibility for this one
1536 IN pduType -- the pduType(s) to be unregistered
1537 )
1539 Note that realizations of the registerContextEngineID and
1540 unregisterContextEngineID abstract service interfaces may provide
1541 implementation-specific ways for applications to register/deregister
1542 responsiblity for all possible values of the contextEngineID or
1543 pduType parameters.
1545 4.2. Message Processing Subsystem Primitives
1547 The Dispatcher interacts with a Message Processing Model to process a
1548 specific version of an SNMP Message. This section describes the
1549 primitives provided by the Message Processing Subsystem.
1551 4.2.1. Prepare Outgoing SNMP Request or Notification Message
1553 The Message Processing Subsystem provides this service primitive for
1554 preparing an outgoing SNMP Request or Notification Message:
1556 statusInformation = -- success or errorIndication
1557 prepareOutgoingMessage(
1558 IN transportDomain -- transport domain to be used
1559 IN transportAddress -- transport address to be used
1560 IN messageProcessingModel -- typically, SNMP version
1561 IN securityModel -- Security Model to use
1562 IN securityName -- on behalf of this principal
1563 IN securityLevel -- Level of Security requested
1564 IN contextEngineID -- data from/at this entity
1565 IN contextName -- data from/in this context
1566 IN pduVersion -- the version of the PDU
1570 Harrington, et. al. Standards Track [Page 28]
1571 \f
1572 RFC 2271 SNMPv3 Architecture January 1998
1575 IN PDU -- SNMP Protocol Data Unit
1576 IN expectResponse -- TRUE or FALSE
1577 IN sendPduHandle -- the handle for matching
1578 -- incoming responses
1579 OUT destTransportDomain -- destination transport domain
1580 OUT destTransportAddress -- destination transport address
1581 OUT outgoingMessage -- the message to send
1582 OUT outgoingMessageLength -- its length
1583 )
1585 4.2.2. Prepare an Outgoing SNMP Response Message
1587 The Message Processing Subsystem provides this service primitive for
1588 preparing an outgoing SNMP Response Message:
1590 result = -- SUCCESS or FAILURE
1591 prepareResponseMessage(
1592 IN messageProcessingModel -- typically, SNMP version
1593 IN securityModel -- same as on incoming request
1594 IN securityName -- same as on incoming request
1595 IN securityLevel -- same as on incoming request
1596 IN contextEngineID -- data from/at this SNMP entity
1597 IN contextName -- data from/in this context
1598 IN pduVersion -- the version of the PDU
1599 IN PDU -- SNMP Protocol Data Unit
1600 IN maxSizeResponseScopedPDU -- maximum size of the Response PDU
1601 IN stateReference -- reference to state information
1602 -- as presented with the request
1603 IN statusInformation -- success or errorIndication
1604 -- error counter OID/value if error
1605 OUT destTransportDomain -- destination transport domain
1606 OUT destTransportAddress -- destination transport address
1607 OUT outgoingMessage -- the message to send
1608 OUT outgoingMessageLength -- its length
1609 )
1611 4.2.3. Prepare Data Elements from an Incoming SNMP Message
1613 The Message Processing Subsystem provides this service primitive for
1614 preparing the abstract data elements from an incoming SNMP message:
1616 result = -- SUCCESS or errorIndication
1617 prepareDataElements(
1618 IN transportDomain -- origin transport domain
1619 IN transportAddress -- origin transport address
1620 IN wholeMsg -- as received from the network
1621 IN wholeMsgLength -- as received from the network
1622 OUT messageProcessingModel -- typically, SNMP version
1626 Harrington, et. al. Standards Track [Page 29]
1627 \f
1628 RFC 2271 SNMPv3 Architecture January 1998
1631 OUT securityModel -- Security Model to use
1632 OUT securityName -- on behalf of this principal
1633 OUT securityLevel -- Level of Security requested
1634 OUT contextEngineID -- data from/at this entity
1635 OUT contextName -- data from/in this context
1636 OUT pduVersion -- the version of the PDU
1637 OUT PDU -- SNMP Protocol Data Unit
1638 OUT pduType -- SNMP PDU type
1639 OUT sendPduHandle -- handle for matched request
1640 OUT maxSizeResponseScopedPDU -- maximum size of the Response PDU
1641 OUT statusInformation -- success or errorIndication
1642 -- error counter OID/value if error
1643 OUT stateReference -- reference to state information
1644 -- to be used for possible Response
1645 )
1647 4.3. Access Control Subsystem Primitives
1649 Applications are the typical clients of the service(s) of the Access
1650 Control Subsystem.
1652 The following primitive is provided by the Access Control Subsystem
1653 to check if access is allowed:
1655 statusInformation = -- success or errorIndication
1656 isAccessAllowed(
1657 IN securityModel -- Security Model in use
1658 IN securityName -- principal who wants to access
1659 IN securityLevel -- Level of Security
1660 IN viewType -- read, write, or notify view
1661 IN contextName -- context containing variableName
1662 IN variableName -- OID for the managed object
1663 )
1665 4.4. Security Subsystem Primitives
1667 The Message Processing Subsystem is the typical client of the
1668 services of the Security Subsystem.
1670 4.4.1. Generate a Request or Notification Message
1672 The Security Subsystem provides the following primitive to generate a
1673 Request or Notification message:
1675 statusInformation =
1676 generateRequestMsg(
1677 IN messageProcessingModel -- typically, SNMP version
1678 IN globalData -- message header, admin data
1682 Harrington, et. al. Standards Track [Page 30]
1683 \f
1684 RFC 2271 SNMPv3 Architecture January 1998
1687 IN maxMessageSize -- of the sending SNMP entity
1688 IN securityModel -- for the outgoing message
1689 IN securityEngineID -- authoritative SNMP entity
1690 IN securityName -- on behalf of this principal
1691 IN securityLevel -- Level of Security requested
1692 IN scopedPDU -- message (plaintext) payload
1693 OUT securityParameters -- filled in by Security Module
1694 OUT wholeMsg -- complete generated message
1695 OUT wholeMsgLength -- length of the generated message
1696 )
1698 4.4.2. Process Incoming Message
1700 The Security Subsystem provides the following primitive to process an
1701 incoming message:
1703 statusInformation = -- errorIndication or success
1704 -- error counter OID/value if error
1705 processIncomingMsg(
1706 IN messageProcessingModel -- typically, SNMP version
1707 IN maxMessageSize -- of the sending SNMP entity
1708 IN securityParameters -- for the received message
1709 IN securityModel -- for the received message
1710 IN securityLevel -- Level of Security
1711 IN wholeMsg -- as received on the wire
1712 IN wholeMsgLength -- length as received on the wire
1713 OUT securityEngineID -- identification of the principal
1714 OUT securityName -- identification of the principal
1715 OUT scopedPDU, -- message (plaintext) payload
1716 OUT maxSizeResponseScopedPDU -- maximum size of the Response PDU
1717 OUT securityStateReference -- reference to security state
1718 ) -- information, needed for response
1720 4.4.3. Generate a Response Message
1722 The Security Subsystem provides the following primitive to generate a
1723 Response message:
1725 statusInformation =
1726 generateResponseMsg(
1727 IN messageProcessingModel -- typically, SNMP version
1728 IN globalData -- message header, admin data
1729 IN maxMessageSize -- of the sending SNMP entity
1730 IN securityModel -- for the outgoing message
1731 IN securityEngineID -- authoritative SNMP entity
1732 IN securityName -- on behalf of this principal
1733 IN securityLevel -- for the outgoing message
1734 IN scopedPDU -- message (plaintext) payload
1738 Harrington, et. al. Standards Track [Page 31]
1739 \f
1740 RFC 2271 SNMPv3 Architecture January 1998
1743 IN securityStateReference -- reference to security state
1744 -- information from original request
1745 OUT securityParameters -- filled in by Security Module
1746 OUT wholeMsg -- complete generated message
1747 OUT wholeMsgLength -- length of the generated message
1748 )
1750 4.5. Common Primitives
1752 These primitive(s) are provided by multiple Subsystems.
1754 4.5.1. Release State Reference Information
1756 All Subsystems which pass stateReference information also provide a
1757 primitive to release the memory that holds the referenced state
1758 information:
1760 stateRelease(
1761 IN stateReference -- handle of reference to be released
1762 )
1764 4.6. Scenario Diagrams
1766 4.6.1. Command Generator or Notification Originator
1768 This diagram shows how a Command Generator or Notification Originator
1769 application requests that a PDU be sent, and how the response is
1770 returned (asynchronously) to that application.
1794 Harrington, et. al. Standards Track [Page 32]
1795 \f
1796 RFC 2271 SNMPv3 Architecture January 1998
1799 Command Dispatcher Message Security
1800 Generator | Processing Model
1801 | | Model |
1802 | sendPdu | | |
1803 |------------------->| | |
1804 | | prepareOutgoingMessage | |
1805 : |----------------------->| |
1806 : | | generateRequestMsg |
1807 : | |-------------------->|
1808 : | | |
1809 : | |<--------------------|
1810 : | | |
1811 : |<-----------------------| |
1812 : | | |
1813 : |------------------+ | |
1814 : | Send SNMP | | |
1815 : | Request Message | | |
1816 : | to Network | | |
1817 : | v | |
1818 : : : : :
1819 : : : : :
1820 : : : : :
1821 : | | | |
1822 : | Receive SNMP | | |
1823 : | Response Message | | |
1824 : | from Network | | |
1825 : |<-----------------+ | |
1826 : | | |
1827 : | prepareDataElements | |
1828 : |----------------------->| |
1829 : | | processIncomingMsg |
1830 : | |-------------------->|
1831 : | | |
1832 : | |<--------------------|
1833 : | | |
1834 : |<-----------------------| |
1835 | processResponsePdu | | |
1836 |<-------------------| | |
1837 | | | |
1839 4.6.2. Scenario Diagram for a Command Responder Application
1841 This diagram shows how a Command Responder or Notification Receiver
1842 application registers for handling a pduType, how a PDU is dispatched
1843 to the application after a SNMP message is received, and how the
1844 Response is (asynchronously) send back to the network.
1850 Harrington, et. al. Standards Track [Page 33]
1851 \f
1852 RFC 2271 SNMPv3 Architecture January 1998
1855 Command Dispatcher Message Security
1856 Responder | Processing Model
1857 | | Model |
1858 | | | |
1859 | registerContextEngineID | | |
1860 |------------------------>| | |
1861 |<------------------------| | | |
1862 | | Receive SNMP | | |
1863 : | Message | | |
1864 : | from Network | | |
1865 : |<-------------+ | |
1866 : | | |
1867 : |prepareDataElements | |
1868 : |------------------->| |
1869 : | | processIncomingMsg |
1870 : | |------------------->|
1871 : | | |
1872 : | |<-------------------|
1873 : | | |
1874 : |<-------------------| |
1875 | processPdu | | |
1876 |<------------------------| | |
1877 | | | |
1878 : : : :
1879 : : : :
1880 | returnResponsePdu | | |
1881 |------------------------>| | |
1882 : | prepareResponseMsg | |
1883 : |------------------->| |
1884 : | |generateResponseMsg |
1885 : | |------------------->|
1886 : | | |
1887 : | |<-------------------|
1888 : | | |
1889 : |<-------------------| |
1890 : | | |
1891 : |--------------+ | |
1892 : | Send SNMP | | |
1893 : | Message | | |
1894 : | to Network | | |
1895 : | v | |
1906 Harrington, et. al. Standards Track [Page 34]
1907 \f
1908 RFC 2271 SNMPv3 Architecture January 1998
1911 5. Managed Object Definitions for SNMP Management Frameworks
1913 SNMP-FRAMEWORK-MIB DEFINITIONS ::= BEGIN
1915 IMPORTS
1916 MODULE-IDENTITY, OBJECT-TYPE,
1917 OBJECT-IDENTITY,
1918 snmpModules FROM SNMPv2-SMI
1919 TEXTUAL-CONVENTION FROM SNMPv2-TC
1920 MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF;
1922 snmpFrameworkMIB MODULE-IDENTITY
1923 LAST-UPDATED "9711200000Z" -- 20 November 1997
1924 ORGANIZATION "SNMPv3 Working Group"
1925 CONTACT-INFO "WG-email: snmpv3@tis.com
1926 Subscribe: majordomo@tis.com
1927 In message body: subscribe snmpv3
1929 Chair: Russ Mundy
1930 Trusted Information Systems
1931 postal: 3060 Washington Rd
1932 Glenwood MD 21738
1933 USA
1934 email: mundy@tis.com
1935 phone: +1 301-854-6889
1937 Co-editor Dave Harrington
1938 Cabletron Systems, Inc.
1939 postal: Post Office Box 5005
1940 Mail Stop: Durham
1941 35 Industrial Way
1942 Rochester, NH 03867-5005
1943 USA
1944 email: dbh@ctron.com
1945 phone: +1 603-337-7357
1947 Co-editor Randy Presuhn
1948 BMC Software, Inc.
1949 postal: 1190 Saratoga Avenue
1950 Suite 130
1951 San Jose, CA 95129
1952 USA
1953 email: rpresuhn@bmc.com
1954 phone: +1 408-556-0720
1956 Co-editor: Bert Wijnen
1957 IBM T.J. Watson Research
1958 postal: Schagen 33
1962 Harrington, et. al. Standards Track [Page 35]
1963 \f
1964 RFC 2271 SNMPv3 Architecture January 1998
1967 3461 GL Linschoten
1968 Netherlands
1969 email: wijnen@vnet.ibm.com
1970 phone: +31 348-432-794
1971 "
1972 DESCRIPTION "The SNMP Management Architecture MIB"
1973 ::= { snmpModules 10 }
1975 -- Textual Conventions used in the SNMP Management Architecture ***
1977 SnmpEngineID ::= TEXTUAL-CONVENTION
1978 STATUS current
1979 DESCRIPTION "An SNMP engine's administratively-unique identifier.
1981 The value for this object may not be all zeros or
1982 all 'ff'H or the empty (zero length) string.
1984 The initial value for this object may be configured
1985 via an operator console entry or via an algorithmic
1986 function. In the latter case, the following
1987 example algorithm is recommended.
1989 In cases where there are multiple engines on the
1990 same system, the use of this algorithm is NOT
1991 appropriate, as it would result in all of those
1992 engines ending up with the same ID value.
1994 1) The very first bit is used to indicate how the
1995 rest of the data is composed.
1997 0 - as defined by enterprise using former methods
1998 that existed before SNMPv3. See item 2 below.
2000 1 - as defined by this architecture, see item 3
2001 below.
2003 Note that this allows existing uses of the
2004 engineID (also known as AgentID [RFC1910]) to
2005 co-exist with any new uses.
2007 2) The snmpEngineID has a length of 12 octets.
2009 The first four octets are set to the binary
2010 equivalent of the agent's SNMP management
2011 private enterprise number as assigned by the
2012 Internet Assigned Numbers Authority (IANA).
2013 For example, if Acme Networks has been assigned
2014 { enterprises 696 }, the first four octets would
2018 Harrington, et. al. Standards Track [Page 36]
2019 \f
2020 RFC 2271 SNMPv3 Architecture January 1998
2023 be assigned '000002b8'H.
2025 The remaining eight octets are determined via
2026 one or more enterprise-specific methods. Such
2027 methods must be designed so as to maximize the
2028 possibility that the value of this object will
2029 be unique in the agent's administrative domain.
2030 For example, it may be the IP address of the SNMP
2031 entity, or the MAC address of one of the
2032 interfaces, with each address suitably padded
2033 with random octets. If multiple methods are
2034 defined, then it is recommended that the first
2035 octet indicate the method being used and the
2036 remaining octets be a function of the method.
2038 3) The length of the octet strings varies.
2040 The first four octets are set to the binary
2041 equivalent of the agent's SNMP management
2042 private enterprise number as assigned by the
2043 Internet Assigned Numbers Authority (IANA).
2044 For example, if Acme Networks has been assigned
2045 { enterprises 696 }, the first four octets would
2046 be assigned '000002b8'H.
2048 The very first bit is set to 1. For example, the
2049 above value for Acme Networks now changes to be
2050 '800002b8'H.
2052 The fifth octet indicates how the rest (6th and
2053 following octets) are formatted. The values for
2054 the fifth octet are:
2056 0 - reserved, unused.
2058 1 - IPv4 address (4 octets)
2059 lowest non-special IP address
2061 2 - IPv6 address (16 octets)
2062 lowest non-special IP address
2064 3 - MAC address (6 octets)
2065 lowest IEEE MAC address, canonical
2066 order
2068 4 - Text, administratively assigned
2069 Maximum remaining length 27
2074 Harrington, et. al. Standards Track [Page 37]
2075 \f
2076 RFC 2271 SNMPv3 Architecture January 1998
2079 5 - Octets, administratively assigned
2080 Maximum remaining length 27
2082 6-127 - reserved, unused
2084 127-255 - as defined by the enterprise
2085 Maximum remaining length 27
2086 "
2087 SYNTAX OCTET STRING (SIZE(1..32))
2089 SnmpSecurityModel ::= TEXTUAL-CONVENTION
2090 STATUS current
2091 DESCRIPTION "An identifier that uniquely identifies a
2092 securityModel of the Security Subsystem within the
2093 SNMP Management Architecture.
2095 The values for securityModel are allocated as
2096 follows:
2098 - The zero value is reserved.
2099 - Values between 1 and 255, inclusive, are reserved
2100 for standards-track Security Models and are
2101 managed by the Internet Assigned Numbers Authority
2102 (IANA).
2103 - Values greater than 255 are allocated to
2104 enterprise-specific Security Models. An
2105 enterprise-specific securityModel value is defined
2106 to be:
2108 enterpriseID * 256 + security model within
2109 enterprise
2111 For example, the fourth Security Model defined by
2112 the enterprise whose enterpriseID is 1 would be
2113 260.
2115 This scheme for allocation of securityModel
2116 values allows for a maximum of 255 standards-
2117 based Security Models, and for a maximum of
2118 255 Security Models per enterprise.
2120 It is believed that the assignment of new
2121 securityModel values will be rare in practice
2122 because the larger the number of simultaneously
2123 utilized Security Models, the larger the
2124 chance that interoperability will suffer.
2125 Consequently, it is believed that such a range
2126 will be sufficient. In the unlikely event that
2130 Harrington, et. al. Standards Track [Page 38]
2131 \f
2132 RFC 2271 SNMPv3 Architecture January 1998
2135 the standards committee finds this number to be
2136 insufficient over time, an enterprise number
2137 can be allocated to obtain an additional 255
2138 possible values.
2140 Note that the most significant bit must be zero;
2141 hence, there are 23 bits allocated for various
2142 organizations to design and define non-standard
2143 securityModels. This limits the ability to
2144 define new proprietary implementations of Security
2145 Models to the first 8,388,608 enterprises.
2147 It is worthwhile to note that, in its encoded
2148 form, the securityModel value will normally
2149 require only a single byte since, in practice,
2150 the leftmost bits will be zero for most messages
2151 and sign extension is suppressed by the encoding
2152 rules.
2154 As of this writing, there are several values
2155 of securityModel defined for use with SNMP or
2156 reserved for use with supporting MIB objects.
2157 They are as follows:
2159 0 reserved for 'any'
2160 1 reserved for SNMPv1
2161 2 reserved for SNMPv2c
2162 3 User-Based Security Model (USM)
2163 "
2164 SYNTAX INTEGER(0..2147483647)
2166 SnmpMessageProcessingModel ::= TEXTUAL-CONVENTION
2167 STATUS current
2168 DESCRIPTION "An identifier that uniquely identifies a Message
2169 Processing Model of the Message Processing
2170 Subsystem within a SNMP Management Architecture.
2172 The values for messageProcessingModel are
2173 allocated as follows:
2175 - Values between 0 and 255, inclusive, are
2176 reserved for standards-track Message Processing
2177 Models and are managed by the Internet Assigned
2178 Numbers Authority (IANA).
2179 - Values greater than 255 are allocated to
2180 enterprise-specific Message Processing Models.
2181 An enterprise messageProcessingModel value is
2182 defined to be:
2186 Harrington, et. al. Standards Track [Page 39]
2187 \f
2188 RFC 2271 SNMPv3 Architecture January 1998
2191 enterpriseID * 256 +
2192 messageProcessingModel within enterprise
2194 For example, the fourth Message Processing Model
2195 defined by the enterprise whose enterpriseID
2196 is 1 would be 260.
2198 This scheme for allocation of securityModel
2199 values allows for a maximum of 255 standards-
2200 based Message Processing Models, and for a
2201 maximum of 255 Message Processing Models per
2202 enterprise.
2204 It is believed that the assignment of new
2205 messageProcessingModel values will be rare
2206 in practice because the larger the number of
2207 simultaneously utilized Message Processing Models,
2208 the larger the chance that interoperability
2209 will suffer. It is believed that such a range
2210 will be sufficient. In the unlikely event that
2211 the standards committee finds this number to be
2212 insufficient over time, an enterprise number
2213 can be allocated to obtain an additional 256
2214 possible values.
2216 Note that the most significant bit must be zero;
2217 hence, there are 23 bits allocated for various
2218 organizations to design and define non-standard
2219 messageProcessingModels. This limits the ability
2220 to define new proprietary implementations of
2221 Message Processing Models to the first 8,388,608
2222 enterprises.
2224 It is worthwhile to note that, in its encoded
2225 form, the securityModel value will normally
2226 require only a single byte since, in practice,
2227 the leftmost bits will be zero for most messages
2228 and sign extension is suppressed by the encoding
2229 rules.
2231 As of this writing, there are several values of
2232 messageProcessingModel defined for use with SNMP.
2233 They are as follows:
2235 0 reserved for SNMPv1
2236 1 reserved for SNMPv2c
2237 2 reserved for SNMPv2u and SNMPv2*
2238 3 reserved for SNMPv3
2242 Harrington, et. al. Standards Track [Page 40]
2243 \f
2244 RFC 2271 SNMPv3 Architecture January 1998
2247 "
2248 SYNTAX INTEGER(0..2147483647)
2250 SnmpSecurityLevel ::= TEXTUAL-CONVENTION
2251 STATUS current
2252 DESCRIPTION "A Level of Security at which SNMP messages can be
2253 sent or with which operations are being processed;
2254 in particular, one of:
2256 noAuthNoPriv - without authentication and
2257 without privacy,
2258 authNoPriv - with authentication but
2259 without privacy,
2260 authPriv - with authentication and
2261 with privacy.
2263 These three values are ordered such that
2264 noAuthNoPriv is less than authNoPriv and
2265 authNoPriv is less than authPriv.
2266 "
2267 SYNTAX INTEGER { noAuthNoPriv(1),
2268 authNoPriv(2),
2269 authPriv(3)
2270 }
2272 SnmpAdminString ::= TEXTUAL-CONVENTION
2273 DISPLAY-HINT "255a"
2274 STATUS current
2275 DESCRIPTION "An octet string containing administrative
2276 information, preferably in human-readable form.
2278 To facilitate internationalization, this
2279 information is represented using the ISO/IEC
2280 IS 10646-1 character set, encoded as an octet
2281 string using the UTF-8 transformation format
2282 described in [RFC2044].
2284 Since additional code points are added by
2285 amendments to the 10646 standard from time
2286 to time, implementations must be prepared to
2287 encounter any code point from 0x00000000 to
2288 0x7fffffff.
2290 The use of control codes should be avoided.
2292 When it is necessary to represent a newline,
2293 the control code sequence CR LF should be used.
2298 Harrington, et. al. Standards Track [Page 41]
2299 \f
2300 RFC 2271 SNMPv3 Architecture January 1998
2303 The use of leading or trailing white space should
2304 be avoided.
2306 For code points not directly supported by user
2307 interface hardware or software, an alternative
2308 means of entry and display, such as hexadecimal,
2309 may be provided.
2311 For information encoded in 7-bit US-ASCII,
2312 the UTF-8 encoding is identical to the
2313 US-ASCII encoding.
2315 Note that when this TC is used for an object that
2316 is used or envisioned to be used as an index, then
2317 a SIZE restriction must be specified so that the
2318 number of sub-identifiers for any object instance
2319 does not exceed the limit of 128, as defined by
2320 [RFC1905].
2321 "
2322 SYNTAX OCTET STRING (SIZE (0..255))
2325 -- Administrative assignments ***************************************
2327 snmpFrameworkAdmin
2328 OBJECT IDENTIFIER ::= { snmpFrameworkMIB 1 }
2329 snmpFrameworkMIBObjects
2330 OBJECT IDENTIFIER ::= { snmpFrameworkMIB 2 }
2331 snmpFrameworkMIBConformance
2332 OBJECT IDENTIFIER ::= { snmpFrameworkMIB 3 }
2334 -- the snmpEngine Group ********************************************
2336 snmpEngine OBJECT IDENTIFIER ::= { snmpFrameworkMIBObjects 1 }
2338 snmpEngineID OBJECT-TYPE
2339 SYNTAX SnmpEngineID
2340 MAX-ACCESS read-only
2341 STATUS current
2342 DESCRIPTION "An SNMP engine's administratively-unique identifier.
2343 "
2344 ::= { snmpEngine 1 }
2346 snmpEngineBoots OBJECT-TYPE
2347 SYNTAX INTEGER (1..2147483647)
2348 MAX-ACCESS read-only
2349 STATUS current
2350 DESCRIPTION "The number of times that the SNMP engine has
2354 Harrington, et. al. Standards Track [Page 42]
2355 \f
2356 RFC 2271 SNMPv3 Architecture January 1998
2359 (re-)initialized itself since its initial
2360 configuration.
2361 "
2362 ::= { snmpEngine 2 }
2364 snmpEngineTime OBJECT-TYPE
2365 SYNTAX INTEGER (0..2147483647)
2366 MAX-ACCESS read-only
2367 STATUS current
2368 DESCRIPTION "The number of seconds since the SNMP engine last
2369 incremented the snmpEngineBoots object.
2370 "
2371 ::= { snmpEngine 3 }
2373 snmpEngineMaxMessageSize OBJECT-TYPE
2374 SYNTAX INTEGER (484..2147483647)
2375 MAX-ACCESS read-only
2376 STATUS current
2377 DESCRIPTION "The maximum length in octets of an SNMP message
2378 which this SNMP engine can send or receive and
2379 process, determined as the minimum of the maximum
2380 message size values supported among all of the
2381 transports available to and supported by the engine.
2382 "
2383 ::= { snmpEngine 4 }
2386 -- Registration Points for Authentication and Privacy Protocols **
2388 snmpAuthProtocols OBJECT-IDENTITY
2389 STATUS current
2390 DESCRIPTION "Registration point for standards-track
2391 authentication protocols used in SNMP Management
2392 Frameworks.
2393 "
2394 ::= { snmpFrameworkAdmin 1 }
2396 snmpPrivProtocols OBJECT-IDENTITY
2397 STATUS current
2398 DESCRIPTION "Registration point for standards-track privacy
2399 protocols used in SNMP Management Frameworks.
2400 "
2401 ::= { snmpFrameworkAdmin 2 }
2403 -- Conformance information ******************************************
2405 snmpFrameworkMIBCompliances
2406 OBJECT IDENTIFIER ::= {snmpFrameworkMIBConformance 1}
2410 Harrington, et. al. Standards Track [Page 43]
2411 \f
2412 RFC 2271 SNMPv3 Architecture January 1998
2415 snmpFrameworkMIBGroups
2416 OBJECT IDENTIFIER ::= {snmpFrameworkMIBConformance 2}
2418 -- compliance statements
2420 snmpFrameworkMIBCompliance MODULE-COMPLIANCE
2421 STATUS current
2422 DESCRIPTION "The compliance statement for SNMP engines which
2423 implement the SNMP Management Framework MIB.
2424 "
2425 MODULE -- this module
2426 MANDATORY-GROUPS { snmpEngineGroup }
2428 ::= { snmpFrameworkMIBCompliances 1 }
2430 -- units of conformance
2432 snmpEngineGroup OBJECT-GROUP
2433 OBJECTS {
2434 snmpEngineID,
2435 snmpEngineBoots,
2436 snmpEngineTime,
2437 snmpEngineMaxMessageSize
2438 }
2439 STATUS current
2440 DESCRIPTION "A collection of objects for identifying and
2441 determining the configuration and current timeliness
2442 values of an SNMP engine.
2443 "
2444 ::= { snmpFrameworkMIBGroups 1 }
2446 END
2448 6. Intellectual Property
2450 The IETF takes no position regarding the validity or scope of any
2451 intellectual property or other rights that might be claimed to
2452 pertain to the implementation or use of the technology described in
2453 this document or the extent to which any license under such rights
2454 might or might not be available; neither does it represent that it
2455 has made any effort to identify any such rights. Information on the
2456 IETF's procedures with respect to rights in standards-track and
2457 standards-related documentation can be found in BCP-11. Copies of
2458 claims of rights made available for publication and any assurances of
2459 licenses to be made available, or the result of an attempt made to
2460 obtain a general license or permission for the use of such
2461 proprietary rights by implementors or users of this specification can
2462 be obtained from the IETF Secretariat.
2466 Harrington, et. al. Standards Track [Page 44]
2467 \f
2468 RFC 2271 SNMPv3 Architecture January 1998
2471 The IETF invites any interested party to bring to its attention any
2472 copyrights, patents or patent applications, or other proprietary
2473 rights which may cover technology that may be required to practice
2474 this standard. Please address the information to the IETF Executive
2475 Director.
2477 7. Acknowledgements
2479 This document is the result of the efforts of the SNMPv3 Working
2480 Group. Some special thanks are in order to the following SNMPv3 WG
2481 members:
2483 Dave Battle (SNMP Research, Inc.)
2484 Uri Blumenthal (IBM T.J. Watson Research Center)
2485 Jeff Case (SNMP Research, Inc.)
2486 John Curran (BBN)
2487 T. Max Devlin (Hi-TECH Connections)
2488 John Flick (Hewlett Packard)
2489 David Harrington (Cabletron Systems Inc.)
2490 N.C. Hien (IBM T.J. Watson Research Center)
2491 Dave Levi (SNMP Research, Inc.)
2492 Louis A Mamakos (UUNET Technologies Inc.)
2493 Paul Meyer (Secure Computing Corporation)
2494 Keith McCloghrie (Cisco Systems)
2495 Russ Mundy (Trusted Information Systems, Inc.)
2496 Bob Natale (ACE*COMM Corporation)
2497 Mike O'Dell (UUNET Technologies Inc.)
2498 Dave Perkins (DeskTalk)
2499 Peter Polkinghorne (Brunel University)
2500 Randy Presuhn (BMC Software, Inc.)
2501 David Reid (SNMP Research, Inc.)
2502 Shawn Routhier (Epilogue)
2503 Juergen Schoenwaelder (TU Braunschweig)
2504 Bob Stewart (Cisco Systems)
2505 Bert Wijnen (IBM T.J. Watson Research Center)
2507 The document is based on recommendations of the IETF Security and
2508 Administrative Framework Evolution for SNMP Advisory Team. Members
2509 of that Advisory Team were:
2511 David Harrington (Cabletron Systems Inc.)
2512 Jeff Johnson (Cisco Systems)
2513 David Levi (SNMP Research Inc.)
2514 John Linn (Openvision)
2515 Russ Mundy (Trusted Information Systems) chair
2516 Shawn Routhier (Epilogue)
2517 Glenn Waters (Nortel)
2518 Bert Wijnen (IBM T. J. Watson Research Center)
2522 Harrington, et. al. Standards Track [Page 45]
2523 \f
2524 RFC 2271 SNMPv3 Architecture January 1998
2527 As recommended by the Advisory Team and the SNMPv3 Working Group
2528 Charter, the design incorporates as much as practical from previous
2529 RFCs and drafts. As a result, special thanks are due to the authors
2530 of previous designs known as SNMPv2u and SNMPv2*:
2532 Jeff Case (SNMP Research, Inc.)
2533 David Harrington (Cabletron Systems Inc.)
2534 David Levi (SNMP Research, Inc.)
2535 Keith McCloghrie (Cisco Systems)
2536 Brian O'Keefe (Hewlett Packard)
2537 Marshall T. Rose (Dover Beach Consulting)
2538 Jon Saperia (BGS Systems Inc.)
2539 Steve Waldbusser (International Network Services)
2540 Glenn W. Waters (Bell-Northern Research Ltd.)
2542 8. Security Considerations
2544 This document describes how an implementation can include a Security
2545 Model to protect management messages and an Access Control Model to
2546 control access to management information.
2548 The level of security provided is determined by the specific Security
2549 Model implementation(s) and the specific Access Control Model
2550 implementation(s) used.
2552 Applications have access to data which is not secured. Applications
2553 should take reasonable steps to protect the data from disclosure.
2555 It is the responsibility of the purchaser of an implementation to
2556 ensure that:
2558 1) an implementation complies with the rules defined by this
2559 architecture,
2561 2) the Security and Access Control Models utilized satisfy the
2562 security and access control needs of the organization,
2564 3) the implementations of the Models and Applications comply with
2565 the model and application specifications,
2567 4) and the implementation protects configuration secrets from
2568 inadvertent disclosure.
2570 9. References
2572 [RFC1155] Rose, M. and K. McCloghrie, "Structure and Identification
2573 of Management Information for TCP/IP-based internets", STD 16, RFC
2574 1155, May 1990.
2578 Harrington, et. al. Standards Track [Page 46]
2579 \f
2580 RFC 2271 SNMPv3 Architecture January 1998
2583 [RFC1157] Case, J., Fedor, M., Schoffstall, M. and J. Davin, "The
2584 Simple Network Management Protocol", STD 15, RFC 1157, May 1990.
2586 [RFC1212] Rose, M. and K. McCloghrie, "Concise MIB Definitions", STD
2587 16, RFC 1212, March 1991.
2589 [RFC1901] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser,
2590 "Introduction to Community-based SNMPv2", RFC 1901, January 1996.
2592 [RFC1902] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser,
2593 "Structure of Management Information for Version 2 of the Simple
2594 Network Management Protocol (SNMPv2)", RFC 1902, January 1996.
2596 [RFC1905] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser,
2597 "Protocol Operations for Version 2 of the Simple Network
2598 Management Protocol (SNMPv2)", RFC 1905, January 1996.
2600 [RFC1906] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser,
2601 "Transport Mappings for Version 2 of the Simple Network Management
2602 Protocol (SNMPv2)", RFC 1906, January 1996.
2604 [RFC1907] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser,
2605 "Management Information Base for Version 2 of the Simple Network
2606 Management Protocol (SNMPv2)", RFC 1907 January 1996.
2608 [RFC1908] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser,
2609 "Coexistence between Version 1 and Version 2 of the Internet-
2610 standard Network Management Framework", RFC 1908, January 1996.
2612 [RFC1909] McCloghrie, K., Editor, "An Administrative Infrastructure
2613 for SNMPv2", RFC 1909, February 1996.
2615 [RFC1910] Waters, G., Editor, "User-based Security Model for SNMPv2",
2616 RFC 1910, February 1996.
2618 [RFC2028] Hovey, R. and S. Bradner, "The Organizations Involved in
2619 the IETF Standards Process", BCP 11, RFC 2028, October 1996.
2621 [RFC2044] Yergeau, F., "UTF-8, a transformation format of Unicode and
2622 ISO 10646", RFC 2044, October 1996.
2624 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
2625 Requirement Levels", BCP 14, RFC 2119, March 1997.
2627 [RFC2272] Case, J., Harrington, D., Presuhn, R., and B. Wijnen,
2628 "Message Processing and Dispatching for the Simple Network
2629 Management Protocol (SNMP)", RFC 2272, January 1998.
2634 Harrington, et. al. Standards Track [Page 47]
2635 \f
2636 RFC 2271 SNMPv3 Architecture January 1998
2639 [RFC2274] Blumenthal, U., and B. Wijnen, "The User-Based
2640 Security Model for Version 3 of the Simple Network Management
2641 Protocol (SNMPv3)", RFC 2274, January 1998.
2643 [RFC2275] Wijnen, B., Presuhn, R., and K. McCloghrie,
2644 "View-based Access Control Model for the Simple Network Management
2645 Protocol (SNMP)", RFC 2275, January 1998.
2647 [RFC2273] Levi, D., Meyer, P., and B. Stewart, "SNMPv3
2648 Applications", RFC 2273, January 1998.
2650 10. Editors' Addresses
2652 Bert Wijnen
2653 IBM T.J. Watson Research
2654 Schagen 33
2655 3461 GL Linschoten
2656 Netherlands
2658 Phone: +31 348-432-794
2659 EMail: wijnen@vnet.ibm.com
2662 Dave Harrington
2663 Cabletron Systems, Inc
2664 Post Office Box 5005
2665 Mail Stop: Durham
2666 35 Industrial Way
2667 Rochester, NH 03867-5005
2668 USA
2670 Phone: +1 603-337-7357
2671 EMail: dbh@ctron.com
2674 Randy Presuhn
2675 BMC Software, Inc.
2676 1190 Saratoga Avenue
2677 Suite 130
2678 San Jose, CA 95129
2679 USA
2681 Phone: +1 408-556-0720
2682 EMail: rpresuhn@bmc.com
2690 Harrington, et. al. Standards Track [Page 48]
2691 \f
2692 RFC 2271 SNMPv3 Architecture January 1998
2695 APPENDIX A
2697 A. Guidelines for Model Designers
2699 This appendix describes guidelines for designers of models which are
2700 expected to fit into the architecture defined in this document.
2702 SNMPv1 and SNMPv2c are two SNMP frameworks which use communities to
2703 provide trivial authentication and access control. SNMPv1 and SNMPv2c
2704 Frameworks can coexist with Frameworks designed according to this
2705 architecture, and modified versions of SNMPv1 and SNMPv2c Frameworks
2706 could be designed to meet the requirements of this architecture, but
2707 this document does not provide guidelines for that coexistence.
2709 Within any subsystem model, there should be no reference to any
2710 specific model of another subsystem, or to data defined by a specific
2711 model of another subsystem.
2713 Transfer of data between the subsystems is deliberately described as
2714 a fixed set of abstract data elements and primitive functions which
2715 can be overloaded to satisfy the needs of multiple model definitions.
2717 Documents which define models to be used within this architecture
2718 SHOULD use the standard primitives between subsystems, possibly
2719 defining specific mechanisms for converting the abstract data
2720 elements into model-usable formats. This constraint exists to allow
2721 subsystem and model documents to be written recognizing common
2722 borders of the subsystem and model. Vendors are not constrained to
2723 recognize these borders in their implementations.
2725 The architecture defines certain standard services to be provided
2726 between subsystems, and the architecture defines abstract service
2727 interfaces to request these services.
2729 Each model definition for a subsystem SHOULD support the standard
2730 service interfaces, but whether, or how, or how well, it performs the
2731 service is dependent on the model definition.
2733 A.1. Security Model Design Requirements
2735 A.1.1. Threats
2737 A document describing a Security Model MUST describe how the model
2738 protects against the threats described under "Security Requirements
2739 of this Architecture", section 1.4.
2746 Harrington, et. al. Standards Track [Page 49]
2747 \f
2748 RFC 2271 SNMPv3 Architecture January 1998
2751 A.1.2. Security Processing
2753 Received messages MUST be validated by a Model of the Security
2754 Subsystem. Validation includes authentication and privacy processing
2755 if needed, but it is explicitly allowed to send messages which do not
2756 require authentication or privacy.
2758 A received message contains a specified securityLevel to be used
2759 during processing. All messages requiring privacy MUST also require
2760 authentication.
2762 A Security Model specifies rules by which authentication and privacy
2763 are to be done. A model may define mechanisms to provide additional
2764 security features, but the model definition is constrained to using
2765 (possibly a subset of) the abstract data elements defined in this
2766 document for transferring data between subsystems.
2768 Each Security Model may allow multiple security protocols to be used
2769 concurrently within an implementation of the model. Each Security
2770 Model defines how to determine which protocol to use, given the
2771 securityLevel and the security parameters relevant to the message.
2772 Each Security Model, with its associated protocol(s) defines how the
2773 sending/receiving entities are identified, and how secrets are
2774 configured.
2776 Authentication and Privacy protocols supported by Security Models are
2777 uniquely identified using Object Identifiers. IETF standard protocols
2778 for authentication or privacy should have an identifier defined
2779 within the snmpAuthProtocols or the snmpPrivProtocols subtrees.
2780 Enterprise specific protocol identifiers should be defined within the
2781 enterprise subtree.
2783 For privacy, the Security Model defines what portion of the message
2784 is encrypted.
2786 The persistent data used for security should be SNMP-manageable, but
2787 the Security Model defines whether an instantiation of the MIB is a
2788 conformance requirement.
2790 Security Models are replaceable within the Security Subsystem.
2791 Multiple Security Model implementations may exist concurrently within
2792 an SNMP engine. The number of Security Models defined by the SNMP
2793 community should remain small to promote interoperability.
2802 Harrington, et. al. Standards Track [Page 50]
2803 \f
2804 RFC 2271 SNMPv3 Architecture January 1998
2807 A.1.3. Validate the security-stamp in a received message
2809 A Message Processing Model requests that a Security Model:
2810 - verifies that the message has not been altered,
2811 - authenticates the identification of the principal for whom the
2812 message was generated.
2813 - decrypts the message if it was encrypted.
2815 Additional requirements may be defined by the model, and additional
2816 services may be provided by the model, but the model is constrained
2817 to use the following primitives for transferring data between
2818 subsystems. Implementations are not so constrained.
2820 A Message Processing Model uses the processMsg primitive as described
2821 in section 4.5.
2823 A.1.4. Security MIBs
2825 Each Security Model defines the MIB module(s) required for security
2826 processing, including any MIB module(s) required for the security
2827 protocol(s) supported. The MIB module(s) SHOULD be defined
2828 concurrently with the procedures which use the MIB module(s). The
2829 MIB module(s) are subject to normal access control rules.
2831 The mapping between the model-dependent security ID and the
2832 securityName MUST be able to be determined using SNMP, if the model-
2833 dependent MIB is instantiated and if access control policy allows
2834 access.
2836 A.1.5. Cached Security Data
2838 For each message received, the Security Model caches the state
2839 information such that a Response message can be generated using the
2840 same security information, even if the Local Configuration Datastore
2841 is altered between the time of the incoming request and the outgoing
2842 response.
2844 A Message Processing Model has the responsibility for explicitly
2845 releasing the cached data if such data is no longer needed. To enable
2846 this, an abstract securityStateReference data element is passed from
2847 the Security Model to the Message Processing Model.
2849 The cached security data may be implicitly released via the
2850 generation of a response, or explicitly released by using the
2851 stateRelease primitive, as described in section 4.1.
2858 Harrington, et. al. Standards Track [Page 51]
2859 \f
2860 RFC 2271 SNMPv3 Architecture January 1998
2863 A.2. Message Processing Model Design Requirements
2865 An SNMP engine contains a Message Processing Subsystem which may
2866 contain multiple Message Processing Models.
2868 The Message Processing Model MUST always (conceptually) pass the
2869 complete PDU, i.e., it never forwards less than the complete list of
2870 varBinds.
2872 A.2.1. Receiving an SNMP Message from the Network
2874 Upon receipt of a message from the network, the Dispatcher in the
2875 SNMP engine determines the version of the SNMP message and interacts
2876 with the corresponding Message Processing Model to determine the
2877 abstract data elements.
2879 A Message Processing Model specifies the SNMP Message format it
2880 supports and describes how to determine the values of the abstract
2881 data elements (like msgID, msgMaxSize, msgFlags,
2882 msgSecurityParameters, securityModel, securityLevel etc). A Message
2883 Processing Model interacts with a Security Model to provide security
2884 processing for the message using the processMsg primitive, as
2885 described in section 4.5.
2887 A.2.2. Sending an SNMP Message to the Network
2889 The Dispatcher in the SNMP engine interacts with a Message Processing
2890 Model to prepare an outgoing message. For that it uses the following
2891 primitives:
2893 - for requests and notifications: prepareOutgoingMessage, as
2894 described in section 4.4
2896 - for response messages: prepareResponseMessage, as described in
2897 section 4.4
2899 A Message Processing Model, when preparing an Outgoing SNMP Message,
2900 interacts with a Security Model to secure the message. For that it
2901 uses the following primitives:
2903 - for requests and notifications: generateRequestMsg, as
2904 described in section 4.5.
2906 - for response messages: generateResponseMsg as described in
2907 section 4.5.
2914 Harrington, et. al. Standards Track [Page 52]
2915 \f
2916 RFC 2271 SNMPv3 Architecture January 1998
2919 Once the SNMP message is prepared by a Message Processing Model,
2920 the Dispatcher sends the message to the desired address using the
2921 appropriate transport.
2923 A.3. Application Design Requirements
2925 Within an application, there may be an explicit binding to a specific
2926 SNMP message version, i.e., a specific Message Processing Model, and
2927 to a specific Access Control Model, but there should be no reference
2928 to any data defined by a specific Message Processing Model or Access
2929 Control Model.
2931 Within an application, there should be no reference to any specific
2932 Security Model, or any data defined by a specific Security Model.
2934 An application determines whether explicit or implicit access control
2935 should be applied to the operation, and, if access control is needed,
2936 which Access Control Model should be used.
2938 An application has the responsibility to define any MIB module(s)
2939 used to provide application-specific services.
2941 Applications interact with the SNMP engine to initiate messages,
2942 receive responses, receive asynchronous messages, and send responses.
2944 A.3.1. Applications that Initiate Messages
2946 Applications may request that the SNMP engine send messages
2947 containing SNMP commands or notifications using the sendPdu primitive
2948 as described in section 4.2.
2950 If it is desired that a message be sent to multiple targets, it is
2951 the responsibility of the application to provide the iteration.
2953 The SNMP engine assumes necessary access control has been applied to
2954 the PDU, and provides no access control services.
2956 The SNMP engine looks at the "expectResponse" parameter, and if a
2957 response is expected, then the appropriate information is cached such
2958 that a later response can be associated to this message, and can then
2959 be returned to the application. A sendPduHandle is returned to the
2960 application so it can later correspond the response with this message
2961 as well.
2970 Harrington, et. al. Standards Track [Page 53]
2971 \f
2972 RFC 2271 SNMPv3 Architecture January 1998
2975 A.3.2. Applications that Receive Responses
2977 The SNMP engine matches the incoming response messages to outstanding
2978 messages sent by this SNMP engine, and forwards the response to the
2979 associated application using the processResponsePdu primitive, as
2980 described in section 4.2.
2982 A.3.3. Applications that Receive Asynchronous Messages
2984 When an SNMP engine receives a message that is not the response to a
2985 request from this SNMP engine, it must determine to which application
2986 the message should be given.
2988 An Application that wishes to receive asynchronous messages registers
2989 itself with the engine using the primitive registerContextEngineID as
2990 described in section 4.2.
2992 An Application that wishes to stop receiving asynchronous messages
2993 should unregister itself with the SNMP engine using the primitive
2994 unregisterContextEngineID as described in section 4.2.
2996 Only one registration per combination of PDU type and contextEngineID
2997 is permitted at the same time. Duplicate registrations are ignored.
2998 An errorIndication will be returned to the application that attempts
2999 to duplicate a registration.
3001 All asynchronously received messages containing a registered
3002 combination of PDU type and contextEngineID are sent to the
3003 application which registered to support that combination.
3005 The engine forwards the PDU to the registered application, using the
3006 processPdu primitive, as described in section 4.2.
3008 A.3.4. Applications that Send Responses
3010 Request operations require responses. An application sends a
3011 response via the returnResponsePdu primitive, as described in section
3012 4.2.
3014 The contextEngineID, contextName, securityModel, securityName,
3015 securityLevel, and stateReference parameters are from the initial
3016 processPdu primitive. The PDU and statusInformation are the results
3017 of processing.
3026 Harrington, et. al. Standards Track [Page 54]
3027 \f
3028 RFC 2271 SNMPv3 Architecture January 1998
3031 A.4. Access Control Model Design Requirements
3033 An Access Control Model determines whether the specified securityName
3034 is allowed to perform the requested operation on a specified managed
3035 object. The Access Control Model specifies the rules by which access
3036 control is determined.
3038 The persistent data used for access control should be manageable
3039 using SNMP, but the Access Control Model defines whether an
3040 instantiation of the MIB is a conformance requirement.
3042 The Access Control Model must provide the primitive isAccessAllowed.
3082 Harrington, et. al. Standards Track [Page 55]
3083 \f
3084 RFC 2271 SNMPv3 Architecture January 1998
3087 B. Full Copyright Statement
3089 Copyright (C) The Internet Society (1998). All Rights Reserved.
3091 This document and translations of it may be copied and furnished to
3092 others, and derivative works that comment on or otherwise explain it
3093 or assist in its implementation may be prepared, copied, published
3094 and distributed, in whole or in part, without restriction of any
3095 kind, provided that the above copyright notice and this paragraph are
3096 included on all such copies and derivative works. However, this
3097 document itself may not be modified in any way, such as by removing
3098 the copyright notice or references to the Internet Society or other
3099 Internet organizations, except as needed for the purpose of
3100 developing Internet standards in which case the procedures for
3101 copyrights defined in the Internet Standards process must be
3102 followed, or as required to translate it into languages other than
3103 English.
3105 The limited permissions granted above are perpetual and will not be
3106 revoked by the Internet Society or its successors or assigns.
3108 This document and the information contained herein is provided on an
3109 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
3110 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
3111 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
3112 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
3113 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
3138 Harrington, et. al. Standards Track [Page 56]
3139 \f