tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search

RFC 3584

 
 
 

Coexistence between Version 1, Version 2, and Version 3 of the Internet-standard Network Management Framework

Part 2 of 2, p. 26 to 51
Prev RFC Part

 


prevText      Top      Up      ToC       Page 26 
5.  Message Processing Models and Security Models

   In order to adapt SNMPv1 (and SNMPv2c) into the SNMP architecture,
   the following Message Processing (MP) models are defined in this
   document:

   -  The SNMPv1 Message Processing Model

   -  The SNMPv1 Community-Based Security Model

   -  The SNMPv2c Message Processing Model

   -  The SNMPv2c Community-Based Security Model

   In most respects, the SNMPv1 Message Processing Model and the SNMPv2c
   Message Processing Model are identical, and so these are not
   discussed independently in this document.  Differences between the
   two models are described as required.

   Similarly, the SNMPv1 Community-Based Security Model and the SNMPv2c
   Community-Based Security Model are nearly identical, and so are not
   discussed independently.  Differences between these two models are
   also described as required.

5.1.  Mappings

   The SNMPv1 (and SNMPv2c) Message Processing Model and Security Model
   require mappings between parameters used in SNMPv1 (and SNMPv2c)
   messages, and the version independent parameters used in the SNMP
   architecture [RFC3411].  The parameters which MUST be mapped consist
   of the SNMPv1 (and SNMPv2c) community name, and the SNMP securityName
   and contextEngineID/contextName pair.  A MIB module (the SNMP-
   COMMUNITY-MIB) is provided in this document in order to perform these
   mappings.  This MIB provides mappings in both directions, that is, a
   community name may be mapped to a securityName, contextEngineID, and
   contextName, or the combination of securityName, contextEngineID, and
   contextName may be mapped to a community name.

5.2.  The SNMPv1 MP Model and SNMPv1 Community-based Security Model

   The SNMPv1 Message Processing Model handles processing of SNMPv1
   messages.  The processing of messages is handled generally in the
   same manner as described in RFC 1157 [RFC1157], with differences and
   clarifications as described in the following sections.  The
   SnmpMessageProcessingModel value for SNMPv1 is 0 (the value for
   SNMPv2c is 1).

Top      Up      ToC       Page 27 
5.2.1.  Processing An Incoming Request

   In RFC 1157 [RFC1157], section 4.1, item (3) for an entity which
   receives a message, states that various parameters are passed to the
   "desired authentication scheme".  The desired authentication scheme
   in this case is the SNMPv1 Community-Based Security Model, which will
   be called using the processIncomingMsg ASI.  The parameters passed to
   this ASI are:

   -  The messageProcessingModel, which will be 0 (or 1 for SNMPv2c).

   -  The maxMessageSize, which should be the maximum size of a message
      that the receiving entity can generate (since there is no such
      value in the received message).

   -  The securityParameters, which consist of the community string and
      the message's source and destination transport domains and
      addresses.

   -  The securityModel, which will be 1 (or 2 for SNMPv2c).

   -  The securityLevel, which will be noAuthNoPriv.

   -  The wholeMsg and wholeMsgLength.

   The Community-Based Security Model will attempt to select a row in
   the snmpCommunityTable.  This is done by performing a search through
   the snmpCommunityTable in lexicographic order.  The first entry for
   which the following matching criteria are satisfied will be selected:

   -  The community string is equal to the snmpCommunityName value.

   -  If the snmpCommunityTransportTag is an empty string, it is ignored
      for the purpose of matching.  If the snmpCommunityTransportTag is
      not an empty string, the transportDomain and transportAddress from
      which the message was received must match one of the entries in
      the snmpTargetAddrTable selected by the snmpCommunityTransportTag
      value.  The snmpTargetAddrTMask object is used as described in
      section 5.3 when checking whether the transportDomain and
      transportAddress matches a entry in the snmpTargetAddrTable.

   If no such entry can be found, an authentication failure occurs as
   described in RFC 1157 [RFC1157], and the snmpInBadCommunityNames
   counter is incremented.

Top      Up      ToC       Page 28 
   The parameters returned from the Community-Based Security Model are:

   -  The securityEngineID, which will always be the local value of
      snmpEngineID.0.

   -  The securityName, which will be the value of
      snmpCommunitySecurityName from the selected row in the
      snmpCommunityTable.

   -  The scopedPDU.  Note that this parameter will actually consist of
      three values, the contextSnmpEngineID (which will be the value of
      snmpCommunityContextEngineID from the selected entry in the
      snmpCommunityTable), the contextName (which will be the value of
      snmpCommunityContextName from the selected entry in the
      snmpCommunityTable), and the PDU.  These must be separate values,
      since the first two do not actually appear in the message.

   -  The maxSizeResponseScopedPDU, which will be derived using the
      minimum of the maxMessageSize above, and the value of
      snmpTargetAddrMMS of the selected row in the snmpTargetAddrTable.
      If no such entry was selected, then this value will be derived
      from the maxMessageSize only.

   -  The securityStateReference, which MUST contain the community
      string from the original request.

   The appropriate SNMP application will then be called (depending on
   the value of the contextEngineID and the request type in the PDU)
   using the processPdu ASI.  The parameters passed to this ASI are:

   -  The messageProcessingModel, which will be 0 (or 1 for SNMPv2c).

   -  The securityModel, which will be 1 (or 2 for SNMPv2c).

   -  The securityName, which was returned from the call to
      processIncomingMsg.

   -  The securityLevel, which is noAuthNoPriv.

   -  The contextEngineID, which was returned as part of the ScopedPDU
      from the call to processIncomingMsg.

   -  The contextName, which was returned as part of the ScopedPDU from
      the call to processIncomingMsg.

   -  The pduVersion, which should indicate an SNMPv1 version PDU (if
      the message version was SNMPv2c, this would be an SNMPv2 version
      PDU).

Top      Up      ToC       Page 29 
   -  The PDU, which was returned as part of the ScopedPDU from the call
      to processIncomingMsg.

   -  The maxSizeResponseScopedPDU which was returned from the call to
      processIncomingMsg.

   -  The stateReference which was returned from the call to
      processIncomingMsg.

   The SNMP application should process the request as described
   previously in this document.  Note that access control is applied by
   an SNMPv3 command responder application as usual.  The parameters as
   passed to the processPdu ASI will be used in calls to the
   isAccessAllowed ASI.

5.2.2.  Generating An Outgoing Response

   There is no special processing required for generating an outgoing
   response.  However, the community string used in an outgoing response
   must be the same as the community string from the original request.
   The original community string MUST be present in the
   securityStateReference information of the original request.

5.2.3.  Generating An Outgoing Notification

   In a multi-lingual SNMP entity, the parameters used for generating
   notifications will be obtained by examining the SNMP-TARGET-MIB and
   SNMP-NOTIFICATION-MIB.  These parameters will be passed to the SNMPv1
   Message Processing Model using the sendPdu ASI.  The SNMPv1 Message
   Processing Model will attempt to locate an appropriate community
   string in the snmpCommunityTable based on the parameters passed to
   the sendPdu ASI.  This is done by performing a search through the
   snmpCommunityTable in lexicographic order.  The first entry for which
   the following matching criteria are satisfied will be selected:

   -  The securityName must be equal to the snmpCommunitySecurityName
      value.

   -  The contextEngineID must be equal to the
      snmpCommunityContextEngineID value.

   -  The contextName must be equal to the snmpCommunityContextName
      value.

Top      Up      ToC       Page 30 
   -  If the snmpCommunityTransportTag is an empty string, it is ignored
      for the purpose of matching.  If the snmpCommunityTransportTag is
      not an empty string, the transportDomain and transportAddress must
      match one of the entries in the snmpTargetAddrTable selected by
      the snmpCommunityTransportTag value.

   If no such entry can be found, the notification is not sent.
   Otherwise, the community string used in the outgoing notification
   will be the value of the snmpCommunityName column of the selected
   row.

5.2.4.  Proxy Forwarding Of Requests

   In a proxy forwarding application, when a received request is to be
   forwarded using the SNMPv1 Message Processing Model, the parameters
   used for forwarding will be obtained by examining the SNMP-PROXY-MIB
   and the SNMP-TARGET-MIB.  These parameters will be passed to the
   SNMPv1 Message Processing Model using the sendPdu ASI.  The SNMPv1
   Message Processing Model will attempt to locate an appropriate
   community string in the snmpCommunityTable based on the parameters
   passed to the sendPdu ASI.  This is done by performing a search
   through the snmpCommunityTable in lexicographic order.  The first
   entry for which the following matching criteria are satisfied will be
   selected:

   -  The securityName must be equal to the snmpCommunitySecurityName
      value.

   -  The contextEngineID must be equal to the
      snmpCommunityContextEngineID value.

   -  The contextName must be equal to the snmpCommunityContextName
      value.

   If no such entry can be found, the proxy forwarding application
   should follow the procedure described in RFC 3413 [RFC3413], section
   3.5.1.1, item (2).  This procedure states that the snmpProxyDrops
   counter [RFC3418] is incremented, and that a Response-PDU is
   generated by calling the Dispatcher using the returnResponsePdu
   abstract service interface.

5.3.  The SNMP Community MIB Module

   The SNMP-COMMUNITY-MIB contains objects for mapping between community
   strings and version-independent SNMP message parameters.  In
   addition, this MIB provides a mechanism for performing source address
   validation on incoming requests, and for selecting community strings
   based on target addresses for outgoing notifications.  These two

Top      Up      ToC       Page 31 
   features are accomplished by providing a tag in the
   snmpCommunityTable which selects sets of entries in the
   snmpTargetAddrTable [RFC3413].  In addition, the SNMP-COMMUNITY-MIB
   augments the snmpTargetAddrTable with a transport address mask value
   and a maximum message size value.  These values are used only where
   explicitly stated.  In cases where the snmpTargetAddrTable is used
   without mention of these augmenting values, the augmenting values
   should be ignored.

   The mask value, snmpTargetAddrTMask, allows selected entries in the
   snmpTargetAddrTable to specify multiple addresses (rather than just a
   single address per entry).  This would typically be used to specify a
   subnet in an snmpTargetAddrTable rather than just a single address.
   The mask value is used to select which bits of a transport address
   must match bits of the corresponding instance of
   snmpTargetAddrTAddress, in order for the transport address to match a
   particular entry in the snmpTargetAddrTable.  The value of an
   instance of snmpTargetAddrTMask must always be an OCTET STRING whose
   length is either zero or the same as that of the corresponding
   instance of snmpTargetAddrTAddress.

   Note that the snmpTargetAddrTMask object is only used where
   explicitly stated.  In particular, it is not used when generating
   notifications (i.e., when generating notifications, entries in the
   snmpTargetAddrTable only specify individual addresses).  If use of
   the snmpTargetAddrTMask object is not mentioned in text describing
   matching addresses in the snmpTargetAddrTable, then its value MUST be
   ignored.

   When checking whether a transport address matches an entry in the
   snmpTargetAddrTable, if the value of snmpTargetAddrTMask is a zero-
   length OCTET STRING, the mask value is ignored, and the value of
   snmpTargetAddrTAddress must exactly match a transport address.
   Otherwise, each bit of each octet in the snmpTargetAddrTMask value
   corresponds to the same bit of the same octet in the
   snmpTargetAddrTAddress value.  For bits that are set in the
   snmpTargetAddrTMask value (i.e., bits equal to 1), the corresponding
   bits in the snmpTargetAddrTAddress value must match the bits in a
   transport address.  If all such bits match, the transport address is
   matched by that snmpTargetAddrTable entry.  Otherwise, the transport
   address is not matched.

   The maximum message size value, snmpTargetAddrMMS, is used to
   determine the maximum message size acceptable to another SNMP entity
   when the value cannot be determined from the protocol.

Top      Up      ToC       Page 32 
      SNMP-COMMUNITY-MIB DEFINITIONS ::= BEGIN

      IMPORTS
          IpAddress,
          MODULE-IDENTITY,
          OBJECT-TYPE,
          Integer32,
          snmpModules
              FROM SNMPv2-SMI
          RowStatus,
          StorageType
              FROM SNMPv2-TC
          SnmpAdminString,
          SnmpEngineID
              FROM SNMP-FRAMEWORK-MIB
          SnmpTagValue,
          snmpTargetAddrEntry
              FROM SNMP-TARGET-MIB
          MODULE-COMPLIANCE,
          OBJECT-GROUP
              FROM SNMPv2-CONF;

      snmpCommunityMIB MODULE-IDENTITY
          LAST-UPDATED "200308060000Z"        -- 06 Aug 2003, midnight
    ORGANIZATION "SNMPv3 Working Group"
    CONTACT-INFO "WG-email:   snmpv3@lists.tislabs.com
                  Subscribe:  majordomo@lists.tislabs.com
                              In msg body:  subscribe snmpv3

                  Co-Chair:   Russ Mundy
                              SPARTA, Inc
                  Postal:     7075 Samuel Morse Drive
                              Columbia, MD 21045
                              USA
                  EMail:      mundy@tislabs.com
                  Phone:      +1 410-872-1515

                  Co-Chair:   David Harrington
                              Enterasys Networks
                  Postal:     35 Industrial Way
                              P. O. Box 5005
                              Rochester, New Hampshire 03866-5005
                              USA
                  EMail:      dbh@enterasys.com
                  Phone:      +1 603-337-2614

                  Co-editor:  Rob Frye
                              Vibrant Solutions

Top      Up      ToC       Page 33 
                  Postal:     2711 Prosperity Ave
                              Fairfax, Virginia 22031
                              USA
                  E-mail:     rfrye@vibrant-1.com
                  Phone:      +1-703-270-2000

                  Co-editor:  David B. Levi
                              Nortel Networks
                  Postal:     3505 Kesterwood Drive
                              Knoxville, Tennessee 37918
                  E-mail:     dlevi@nortelnetworks.com
                  Phone:      +1 865 686 0432

                  Co-editor:  Shawn A. Routhier
                              Wind River Systems, Inc.
                  Postal:     500 Wind River Way
                              Alameda, CA 94501
                  E-mail:     sar@epilogue.com
                  Phone:      +1 510 749 2095

                  Co-editor:  Bert Wijnen
                              Lucent Technologies
                  Postal:     Schagen 33
                              3461 GL Linschoten
                              Netherlands
                  Email:      bwijnen@lucent.com
                  Phone:      +31-348-407-775
                 "

        DESCRIPTION
            "This MIB module defines objects to help support
             coexistence between SNMPv1, SNMPv2c, and SNMPv3.

             Copyright (C) The Internet Society (2003) This
             version of this MIB module is part of RFC 3584;
             see the RFC itself for full legal notices."

        REVISION "200308060000Z" -- 06 Aug 2003
        DESCRIPTION
            "Updated the LAST-UPDATED, CONTACT-INFO, and REVISION
             clauses and added a copyright notice to the
             DESCRIPTION clause of the MIB module's
             MODULE-IDENTITY invocation.

             Updated the description of snmpCommunityTransportTag
             to make it consistent with the rest of the document.

             Updated the description of `snmpTargetAddrMMS' to

Top      Up      ToC       Page 34 
             clarify that a value of 0 means that the maximum
             message size is unknown.

             Changed the name of 'snmpCommunityGroup' to
             snmpCommunityTableGroup to avoid a name conflict
             with the SNMPv2-MIB.

             Updated DESCRIPTION of snmpCommunityName.

             Updated DESCRIPTION of snmpTrapCommunity.

             Added snmpCommunityMIBFullCompliance.

             This version published as RFC 3584."

        REVISION "200003060000Z" -- 6 Mar 2000
        DESCRIPTION "This version published as RFC 2576."

    ::= { snmpModules 18 }

-- Administrative assignments ************************************

snmpCommunityMIBObjects
        OBJECT IDENTIFIER ::= { snmpCommunityMIB 1 }

snmpCommunityMIBConformance
        OBJECT IDENTIFIER ::= { snmpCommunityMIB 2 }

--
-- The snmpCommunityTable contains a database of community
-- strings.  This table provides mappings between community
-- strings, and the parameters required for View-based Access
-- Control.
--

snmpCommunityTable OBJECT-TYPE
    SYNTAX       SEQUENCE OF SnmpCommunityEntry
    MAX-ACCESS   not-accessible
    STATUS       current
    DESCRIPTION
        "The table of community strings configured in the SNMP
         engine's Local Configuration Datastore (LCD)."
    ::= { snmpCommunityMIBObjects 1 }

snmpCommunityEntry OBJECT-TYPE
    SYNTAX       SnmpCommunityEntry
    MAX-ACCESS   not-accessible
    STATUS       current

Top      Up      ToC       Page 35 
    DESCRIPTION
        "Information about a particular community string."
    INDEX       { IMPLIED snmpCommunityIndex }
    ::= { snmpCommunityTable 1 }

SnmpCommunityEntry ::= SEQUENCE {
    snmpCommunityIndex               SnmpAdminString,
    snmpCommunityName                OCTET STRING,
    snmpCommunitySecurityName        SnmpAdminString,
    snmpCommunityContextEngineID     SnmpEngineID,
    snmpCommunityContextName         SnmpAdminString,
    snmpCommunityTransportTag        SnmpTagValue,
    snmpCommunityStorageType         StorageType,
    snmpCommunityStatus              RowStatus
}

snmpCommunityIndex OBJECT-TYPE
    SYNTAX      SnmpAdminString (SIZE(1..32))
    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION
        "The unique index value of a row in this table."
    ::= { snmpCommunityEntry 1 }

snmpCommunityName OBJECT-TYPE
    SYNTAX       OCTET STRING
    MAX-ACCESS   read-create
    STATUS       current
    DESCRIPTION
        "The community string for which a row in this table
         represents a configuration.  There is no SIZE constraint
         specified for this object because RFC 1157 does not
         impose any explicit limitation on the length of community
         strings (their size is constrained indirectly by the
         SNMP message size)."
    ::= { snmpCommunityEntry 2 }

snmpCommunitySecurityName OBJECT-TYPE
    SYNTAX       SnmpAdminString (SIZE(1..32))
    MAX-ACCESS   read-create
    STATUS       current
    DESCRIPTION
        "A human readable string representing the corresponding
         value of snmpCommunityName in a Security Model
         independent format."
    ::= { snmpCommunityEntry 3 }

snmpCommunityContextEngineID OBJECT-TYPE

Top      Up      ToC       Page 36 
    SYNTAX       SnmpEngineID
    MAX-ACCESS   read-create
    STATUS       current
    DESCRIPTION
        "The contextEngineID indicating the location of the
         context in which management information is accessed
         when using the community string specified by the
         corresponding instance of snmpCommunityName.

         The default value is the snmpEngineID of the entity in
         which this object is instantiated."
    ::= { snmpCommunityEntry 4 }

snmpCommunityContextName OBJECT-TYPE
    SYNTAX       SnmpAdminString (SIZE(0..32))
    MAX-ACCESS   read-create
    STATUS       current
    DESCRIPTION
        "The context in which management information is accessed
         when using the community string specified by the
         corresponding instance of snmpCommunityName."
    DEFVAL      { ''H }   -- the empty string
    ::= { snmpCommunityEntry 5 }

snmpCommunityTransportTag OBJECT-TYPE
    SYNTAX       SnmpTagValue
    MAX-ACCESS   read-create
    STATUS       current
    DESCRIPTION
        "This object specifies a set of transport endpoints
         which are used in two ways:
            - to specify the transport endpoints from which an
              SNMP entity will accept management requests, and
            - to specify the transport endpoints to which a
              notification may be sent using the community
              string matching the corresponding instance of
              snmpCommunityName.
         In either case, if the value of this object has
         zero-length, transport endpoints are not checked when
         either authenticating messages containing this community
         string, nor when generating notifications.

         The transports identified by this object are specified
         in the snmpTargetAddrTable.  Entries in that table
         whose snmpTargetAddrTagList contains this tag value
         are identified.

         If a management request containing a community string

Top      Up      ToC       Page 37 
         that matches the corresponding instance of
         snmpCommunityName is received on a transport endpoint
         other than the transport endpoints identified by this
         object the request is deemed unauthentic.

         When a notification is to be sent using an entry in
         this table, if the destination transport endpoint of
         the notification does not match one of the transport
         endpoints selected by this object, the notification
         is not sent."
    DEFVAL      { ''H }   -- the empty string
    ::= { snmpCommunityEntry 6 }

snmpCommunityStorageType OBJECT-TYPE
    SYNTAX       StorageType
    MAX-ACCESS   read-create
    STATUS       current
    DESCRIPTION
        "The storage type for this conceptual row in the
         snmpCommunityTable.  Conceptual rows having the value
         'permanent' need not allow write-access to any
         columnar object in the row."
    ::= { snmpCommunityEntry 7 }

snmpCommunityStatus OBJECT-TYPE
    SYNTAX       RowStatus
    MAX-ACCESS   read-create
    STATUS       current
    DESCRIPTION
        "The status of this conceptual row in the
         snmpCommunityTable.

         An entry in this table is not qualified for activation
         until instances of all corresponding columns have been
         initialized, either through default values, or through
         Set operations.  The snmpCommunityName and
         snmpCommunitySecurityName objects must be explicitly set.

         There is no restriction on setting columns in this table
         when the value of snmpCommunityStatus is active(1)."
    ::= { snmpCommunityEntry 8 }

--
-- The snmpTargetAddrExtTable
--

snmpTargetAddrExtTable OBJECT-TYPE
    SYNTAX       SEQUENCE OF SnmpTargetAddrExtEntry

Top      Up      ToC       Page 38 
    MAX-ACCESS   not-accessible
    STATUS       current
    DESCRIPTION
        "The table of mask and maximum message size (mms) values
         associated with the snmpTargetAddrTable.

         The snmpTargetAddrExtTable augments the
         snmpTargetAddrTable with a transport address mask value
         and a maximum message size value.  The transport address
         mask allows entries in the snmpTargetAddrTable to define
         a set of addresses instead of just a single address.
         The maximum message size value allows the maximum
         message size of another SNMP entity to be configured for
         use in SNMPv1 (and SNMPv2c) transactions, where the
         message format does not specify a maximum message size."
    ::= { snmpCommunityMIBObjects 2 }

snmpTargetAddrExtEntry OBJECT-TYPE
    SYNTAX       SnmpTargetAddrExtEntry
    MAX-ACCESS   not-accessible
    STATUS       current
    DESCRIPTION
        "Information about a particular mask and mms value."
    AUGMENTS       { snmpTargetAddrEntry }
    ::= { snmpTargetAddrExtTable 1 }

SnmpTargetAddrExtEntry ::= SEQUENCE {
    snmpTargetAddrTMask              OCTET STRING,
    snmpTargetAddrMMS                Integer32
}

snmpTargetAddrTMask OBJECT-TYPE
    SYNTAX      OCTET STRING (SIZE (0..255))
    MAX-ACCESS  read-create
    STATUS      current
    DESCRIPTION
        "The mask value associated with an entry in the
         snmpTargetAddrTable.  The value of this object must
         have the same length as the corresponding instance of
         snmpTargetAddrTAddress, or must have length 0.  An
         attempt to set it to any other value will result in
         an inconsistentValue error.

         The value of this object allows an entry in the
         snmpTargetAddrTable to specify multiple addresses.
         The mask value is used to select which bits of
         a transport address must match bits of the corresponding
         instance of snmpTargetAddrTAddress, in order for the

Top      Up      ToC       Page 39 
         transport address to match a particular entry in the
         snmpTargetAddrTable.  Bits which are 1 in the mask
         value indicate bits in the transport address which
         must match bits in the snmpTargetAddrTAddress value.
         Bits which are 0 in the mask indicate bits in the
         transport address which need not match.  If the
         length of the mask is 0, the mask should be treated
         as if all its bits were 1 and its length were equal
         to the length of the corresponding value of
         snmpTargetAddrTable.

         This object may not be modified while the value of the
         corresponding instance of snmpTargetAddrRowStatus is
         active(1).  An attempt to set this object in this case
         will result in an inconsistentValue error."
    DEFVAL { ''H }
    ::= { snmpTargetAddrExtEntry 1 }

snmpTargetAddrMMS OBJECT-TYPE
    SYNTAX      Integer32 (0|484..2147483647)
    MAX-ACCESS  read-create
    STATUS      current
    DESCRIPTION
        "The maximum message size value associated with an entry
         in the snmpTargetAddrTable.  Note that a value of 0 means
         that the maximum message size is unknown."
    DEFVAL { 484 }
    ::= { snmpTargetAddrExtEntry 2 }

--
-- The snmpTrapAddress and snmpTrapCommunity objects are included
-- in notifications that are forwarded by a proxy, which were
-- originally received as SNMPv1 Trap messages.
--

snmpTrapAddress OBJECT-TYPE
    SYNTAX      IpAddress
    MAX-ACCESS  accessible-for-notify
    STATUS      current
    DESCRIPTION
        "The value of the agent-addr field of a Trap PDU which
         is forwarded by a proxy forwarder application using
         an SNMP version other than SNMPv1.  The value of this
         object SHOULD contain the value of the agent-addr field
         from the original Trap PDU as generated by an SNMPv1
         agent."
    ::= { snmpCommunityMIBObjects 3 }

Top      Up      ToC       Page 40 
snmpTrapCommunity OBJECT-TYPE
    SYNTAX      OCTET STRING
    MAX-ACCESS  accessible-for-notify
    STATUS      current
    DESCRIPTION
        "The value of the community string field of an SNMPv1
         message containing a Trap PDU which is forwarded by a
         a proxy forwarder application using an SNMP version
         other than SNMPv1.  The value of this object SHOULD
         contain the value of the community string field from
         the original SNMPv1 message containing a Trap PDU as
         generated by an SNMPv1 agent.  There is no SIZE
         constraint specified for this object because RFC 1157
         does not impose any explicit limitation on the length
         of community strings (their size is constrained
         indirectly by the SNMP message size)."
    ::= { snmpCommunityMIBObjects 4 }

-- Conformance Information **************************************

snmpCommunityMIBCompliances OBJECT IDENTIFIER
                            ::= { snmpCommunityMIBConformance 1 }
snmpCommunityMIBGroups      OBJECT IDENTIFIER
                            ::= { snmpCommunityMIBConformance 2 }

-- Compliance statements

snmpCommunityMIBCompliance MODULE-COMPLIANCE
    STATUS       current
    DESCRIPTION
        "The compliance statement for SNMP engines which
         implement the SNMP-COMMUNITY-MIB."

    MODULE       -- this module
        MANDATORY-GROUPS { snmpCommunityTableGroup }

        OBJECT           snmpCommunityName
        MIN-ACCESS       read-only
        DESCRIPTION     "Write access is not required."

        OBJECT           snmpCommunitySecurityName
        MIN-ACCESS       read-only
        DESCRIPTION     "Write access is not required."

        OBJECT           snmpCommunityContextEngineID
        MIN-ACCESS       read-only
        DESCRIPTION     "Write access is not required."

Top      Up      ToC       Page 41 
        OBJECT           snmpCommunityContextName
        MIN-ACCESS       read-only
        DESCRIPTION     "Write access is not required."

        OBJECT           snmpCommunityTransportTag
        MIN-ACCESS       read-only
        DESCRIPTION     "Write access is not required."

        OBJECT           snmpCommunityStorageType
        MIN-ACCESS       read-only
        DESCRIPTION     "Write access is not required."

        OBJECT           snmpCommunityStatus
        MIN-ACCESS       read-only
        DESCRIPTION     "Write access is not required."

    ::= { snmpCommunityMIBCompliances 1 }

snmpProxyTrapForwardCompliance MODULE-COMPLIANCE
    STATUS       current
    DESCRIPTION
        "The compliance statement for SNMP engines which
         contain a proxy forwarding application which is
         capable of forwarding SNMPv1 traps using SNMPv2c
         or SNMPv3."
    MODULE       -- this module
        MANDATORY-GROUPS { snmpProxyTrapForwardGroup }
    ::= { snmpCommunityMIBCompliances 2 }

snmpCommunityMIBFullCompliance MODULE-COMPLIANCE
    STATUS       current
    DESCRIPTION
        "The compliance statement for SNMP engines which
         implement the SNMP-COMMUNITY-MIB with full read-create
         access."

    MODULE       -- this module
        MANDATORY-GROUPS { snmpCommunityTableGroup }
    ::= { snmpCommunityMIBCompliances 3 }

snmpCommunityTableGroup OBJECT-GROUP
    OBJECTS {
        snmpCommunityName,
        snmpCommunitySecurityName,
        snmpCommunityContextEngineID,
        snmpCommunityContextName,
        snmpCommunityTransportTag,
        snmpCommunityStorageType,

Top      Up      ToC       Page 42 
        snmpCommunityStatus,
        snmpTargetAddrTMask,
        snmpTargetAddrMMS
    }
    STATUS       current
    DESCRIPTION
        "A collection of objects providing for configuration
         of community strings for SNMPv1 (and SNMPv2c) usage."
    ::= { snmpCommunityMIBGroups 1 }

snmpProxyTrapForwardGroup OBJECT-GROUP
    OBJECTS {
        snmpTrapAddress,
        snmpTrapCommunity
    }
    STATUS       current
    DESCRIPTION
        "Objects which are used by proxy forwarding applications
         when translating traps between SNMP versions.  These are
         used to preserve SNMPv1-specific information when
         translating to SNMPv2c or SNMPv3."
    ::= { snmpCommunityMIBGroups 3 }

END

6.  Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   intellectual property or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; neither does it represent that it
   has made any effort to identify any such rights.  Information on the
   IETF's procedures with respect to rights in standards-track and
   standards-related documentation can be found in BCP-11.  Copies of
   claims of rights made available for publication and any assurances of
   licenses to be made available, or the result of an attempt made to
   obtain a general license or permission for the use of such
   proprietary rights by implementors or users of this specification can
   be obtained from the IETF Secretariat.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights which may cover technology that may be required to practice
   this standard.  Please address the information to the IETF Executive
   Director.

Top      Up      ToC       Page 43 
7.  Acknowledgments

   This document is the result of the efforts of the SNMPv3 Working
   Group.  The design of the SNMP-COMMUNITY-MIB incorporates work done
   by the authors of SNMPv2*:

      Jeff Case (SNMP Research, Inc.)
      David Harrington (Enterasys Networks)
      David Levi (Nortel Networks)
      Brian O'Keefe (Hewlett Packard)
      Jon Saperia (IronBridge Networks, Inc.)
      Steve Waldbusser (International Network Services)

8.  Security Considerations

   Although SNMPv1 and SNMPv2 do not provide any security, allowing
   community names to be mapped into securityName/contextName provides
   the ability to use view-based access control to limit the access of
   unsecured SNMPv1 and SNMPv2 operations.  In fact, it is important for
   network administrators to make use of this capability in order to
   avoid unauthorized access to MIB data that would otherwise be secure.

   When a proxy implementation translates messages between SNMPv1 (or
   SNMPv2c) and SNMPv3, there may be a loss of security.  For example,
   an SNMPv3 message received using authentication and privacy which is
   subsequently forwarded using SNMPv1 will lose the security benefits
   of using authentication and privacy (also known as confidentiality).
   Careful configuration of proxies is required to address such
   situations.  One approach to deal with such situations might be to
   use an encrypted tunnel.

   There are a number of management objects defined in this MIB module
   with a MAX-ACCESS clause of read-write and/or read-create.  Such
   objects may be considered sensitive or vulnerable in some network
   environments.  The support for SET operations in a non-secure
   environment without proper protection can have a negative effect on
   network operations.  These are the tables and objects and their
   sensitivity/vulnerability:

   -  The snmpCommunityTable allows creation and deletion of community
      strings, which is potentially a serious security hole.  Access to
      this table should be greatly restricted, preferably by only
      allowing write access using SNMPv3 VACM and USM, with
      authentication and privacy.

   -  The snmpTargetAddrExtTable contains write-able objects which may
      also be considered sensitive, and so access to it should be
      restricted as well.

Top      Up      ToC       Page 44 
   Some of the readable objects in this MIB module (i.e., objects with a
   MAX-ACCESS other than not-accessible) may be considered sensitive or
   vulnerable in some network environments.  It is thus important to
   control even GET and/or NOTIFY access to these objects and possibly
   to even encrypt the values of these objects when sending them over
   the network via SNMP.  These are the tables and objects and their
   sensitivity/vulnerability:

   -  The snmpCommunityTable has the potential to expose community
      strings which provide access to more information than that which
      is available using the usual 'public' community string.  For this
      reason, a security administrator may wish to limit accessibility
      to objects in the snmpCommunityTable, and in particular, to make
      it inaccessible when using the 'public' community string.

   SNMP versions prior to SNMPv3 did not include adequate security.
   Even if the network itself is secure (for example by using IPSec),
   even then, there is no control as to who on the secure network is
   allowed to access and GET/SET (read/change/create/delete) the objects
   in this MIB module.

   It is RECOMMENDED that implementers consider the security features as
   provided by the SNMPv3 framework (see [RFC3410], section 8),
   including full support for the SNMPv3 cryptographic mechanisms (for
   authentication and privacy).

   Further, deployment of SNMP versions prior to SNMPv3 is NOT
   RECOMMENDED.  Instead, it is RECOMMENDED to deploy SNMPv3 and to
   enable cryptographic security.  It is then a customer/operator
   responsibility to ensure that the SNMP entity giving access to an
   instance of this MIB module is properly configured to give access to
   the objects only to those principals (users) that have legitimate
   rights to indeed GET or SET (change/create/delete) them.

9.  References

9.1.  Normative References

   [RFC1155]   Rose, M. and K. McCloghrie, "Structure and Identification
               of Management Information for TCP/IP-based internets",
               STD 16, RFC 1155, May 1990.

   [RFC1157]   Case, J., Fedor, M., Schoffstall, M. and C. Davin,
               "Simple Network Management Protocol (SNMP)", STD 15, RFC
               1157, May 1990.

   [RFC1212]   Rose, M. and K. McCloghrie, Eds., "Concise MIB
               Definitions", STD 16, RFC 1212, March 1991.

Top      Up      ToC       Page 45 
   [RFC1215]   Rose, M., "A Convention for Defining Traps for use with
               the SNMP", RFC 1215, March 1991.

   [RFC1303]   McCloghrie, K. and M. Rose, "A Convention for Describing
               SNMP-based Agents", RFC 1303, February 1992.

   [RFC1901]   Case, J., McCloghrie, K., Rose, M. and S. Waldbusser,
               "Introduction to Community-based SNMPv2", RFC 1901,
               January 1996.

   [RFC2119]   Bradner, S., "Key words for use in RFCs to Indicate
               Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2578]   McCloghrie, K., Perkins, D. and J. Schoenwaelder,
               "Structure of Management Information Version 2 (SMIv2)",
               RFC 2578, STD 58, April 1999.

   [RFC2579]   McCloghrie, K., Perkins, D. and J. Schoenwaelder,
               "Textual Conventions for SMIv2", STD 58, RFC 2579, April
               1999.

   [RFC2580]   McCloghrie, K., Perkins, D. and J. Schoenwaelder,
               "Conformance Statements for SMIv2", STD 58, RFC 2580,
               April 1999.

   [RFC3411]   Harrington, D., Presuhn, R. and B. Wijnen, "An
               Architecture for Describing Simple Network Management
               Protocol (SNMP) Management Frameworks", STD 62, RFC 3411,
               December 2002.

   [RFC3412]   Case, J., Harrington, D., Presuhn, R. and B. Wijnen,
               "Message Processing and Dispatching for the Simple
               Network Management Protocol (SNMP)", STD 62, RFC 3412,
               December 2002.

   [RFC3413]   Levi, D., Meyer, P. and B. Stewart, "Simple Network
               Management Protocol (SNMP) Applications", STD 62, RFC
               3413, December 2002.

   [RFC3414]   Blumenthal, U. and B. Wijnen, "The User-Based Security
               Model (USM) for Version 3 of the Simple Network
               Management Protocol (SNMP)", STD 62, RFC 3414, December
               2002.

   [RFC3415]   Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based
               Access Control Model (VACM) for the Simple Network
               Management Protocol (SNMP)", STD 62, RFC 3415, December
               2002.

Top      Up      ToC       Page 46 
   [RFC3416]   Presuhn, R., Ed., "Version 2 of the Protocol Operations
               for the Simple Network Management Protocol (SNMPv2)", STD
               62, RFC 3416, December 2002.

   [RFC3417]   Presuhn, R., Ed., "Transport Mappings for Version 2 of
               the Simple Network Management Protocol (SNMPv2)", STD 62,
               RFC 3417, December 2002.

   [RFC3418]   Presuhn, R., Ed., "Management Information Base (MIB) for
               Version 2 of the Simple Network Management Protocol
               (SNMP)", STD 62, RFC 3418, December 2002.

   [ASN1]      Information processing systems - Open Systems
               Interconnection - Specification of Abstract Syntax
               Notation One (ASN.1), International Organization for
               Standardization.  International Standard 8824, (December,
               1987).

9.2.  Informative References

   [RFC1908]   Case, J., McCloghrie, K., Rose, M. and S. Waldbusser,
               "Coexistence between Version 1 and Version 2 of the
               Internet-standard Network Management Framework", RFC
               1908, January 1996.

   [RFC2089]   Levi, D. and B. Wijnen, "Mapping SNMPv2 onto SNMPv1
               within a bilingual SNMP agent", RFC 2089, January 1997.

   [RFC2576]   Frye, R., Levi, D., Routhier, S. and B. Wijnen,
               "Coexistence between Version 1, Version 2, and Version 3
               of the Internet-standard Network Management Framework",
               RFC 2576, March 2000.

   [RFC3410]   Case, J., Mundy, R., Partain, D. and B. Stewart,
               "Introduction and Applicability Statements for Internet-
               Standard Management Framework", RFC 3410, December 2002.

Top      Up      ToC       Page 47 
Appendix A.  Change Log

A.1.  Changes From RFC 2576

   Section numbers below refer to the old section numbers from RFC 2576.
   Some section numbers have changed since RFC 2576.

   -  Added text to abstract about conversion of MIBs from SMIv1 to
      SMIv2.

   -  Added note at end of section 1.3 that all discussion of SNMPv2 PDU
      types and protocol operations applies to both SNMPv2c and SNMPv3.

   -  Added text at end of section 1.4 to clarify that there is no such
      thing as 'SNMPv3 access to MIB data', as SNMPv3 just uses SNMPv2
      PDU types and protocol operations.

   -  Moved section 1.4 to the beginning of section 4.

   -  Changed "MUST" to "SHOULD" in item (3) of the first list in
      Section 2.1.1 to since unconstrained INTEGER is not actually
      illegal in SMIv2.

   -  Changed "SHOULD" to "MUST" in item (13) of the first list in
      Section 2.1.1 to clarify that collecting related objects into
      groups is required when translating a MIB module from SMIv1 to
      SMIv2.

   -  Re-organized bullets in section 2.1.1 to improve clarity.

   -  Changed "SHOULD" to "MUST" in items (1) and (2) of Section 2.3
      since those updates are indeed required when translating a
      capabilities statement from the language defined by RFC 1303 into
      SMIv2.

   -  In the second bullet of the last part of Section 3 listing the
      SNMPv2 notification parameters, clarified that the snmpTrapOID
      parameter refers to the value portion (not the name portion) of
      the second variable-binding, and changed the wording in the text
      under bullet (1) of Section 3.2 from "the snmpTrapOID" to "the
      snmpTrapOID value" to emphasize this point.

   -  In bullet (6) of Section 3.2 emphasized that the SNMPv2 variable-
      bindings do not include sysUpTime.0 an snmpTrapOID.0.

   -  In Section 4.2 clarified that the 'Upstream Version' refers to the
      version used between the command generator or notification
      receiver and the proxy, and the 'Downstream Version' refers to the

Top      Up      ToC       Page 48 
      version used between the proxy and the command responder or
      notification originator.  RFC 2576 neglected to mention the
      notification receiver and notification originator.

   -  In Section 4.1.2 added text noting that SNMPv1 access to MIB data
      SHOULD NOT be used when processing SNMPv2c or SNMPv3 messages and
      re-worded final paragraph to note that the sub-sections that
      follow are concerned solely with command responders that use
      SNMPv2 access to MIB data while processing an SNMPv1 request.

   -  Re-worded first bullet, section 4.2.1, to make it more readable.

   -  In Section 4.2.1 clarified that the error-index field must be set
      to zero in a translated GetResponse-PDU with an error-status of
      'tooBig' and made explicit the rationale for retrying a
      GetBulkRequest-PDU only once.

   -  Added text to the Deployment Hint in Section 4.2.2 to clarify that
      different principals should be used for SNMPv1 requests and
      SNMPv2/v3c requests if for SNMPv1 requests a principal for which
      Counter64 objects are not-in-view is used.

   -  In Section 5.2.1 clarified that the securityName value and the
      scopedPDU's contextSnmpEngineID and contextName values come from
      the selected entry in the snmpCommunityTable.  Also clarified how
      maxSizeResponseScopedPDU is determined and that
      securityStateReference must contain the community string of the
      original request.

   -  Added Section 5.2.4 on Proxy Forwarding Of Requests.

   -  In Section 5.3 clarified that snmpTargetAddrTMask is to be ignored
      whenever its use is not explicitly called for.

   -  Updated the LAST-UPDATED, CONTACT-INFO, and REVISION clauses and
      added a copyright notice to the DESCRIPTION clause of the MIB
      module's MODULE-IDENTITY invocation.

   -  Added text to DESCRIPTION of snmpCommunityName and
      snmpTrapCommunity to clarify why the object has no size
      restriction.

   -  Updated the description of snmpCommunityTransportTag to make it
      consistent with the rest of the document.

   -  Updated the description of 'snmpTargetAddrMMS' to clarify that a
      value of 0 means that the maximum message size is unknown.

Top      Up      ToC       Page 49 
   -  Changed the name of 'snmpCommunityGroup' to
      'snmpCommunityTableGroup' in order to resolve a name conflict with
      the SNMPv2-MIB.

   -  Added compliance statement to SNMP-COMMUNITY-MIB for full read-
      create compliance.

   -  Divided references into Normative References and Informative
      Reference and updated them to point to current documents.

   -  Inserted current year into all copyright notices.

   -  Corrected various typographical and grammatical errors.

A.2.  Changes Between RFC 1908 and RFC 2576

   -  Editorial changes to comply with current RFC requirements.

   -  Added/updated copyright statements.

   -  Added Intellectual Property section.

   -  Replaced old introduction with complete new introduction/overview.

   -  Added content for the Security Considerations Section.

   -  Updated References to current documents.

   -  Updated text to use current SNMP terminology.

   -  Added coexistence for/with SNMPv3.

   -  Added description for SNMPv1 and SNMPv2c Message Processing Models
      and SNMPv1 and SNMPv2c Community-based Security Models.

   -  Added snmpCommunityMIB so that SNMPv1 and SNMPv2 community strings
      can be mapped into the SNMP Version Independent parameters which
      can then be used for access control using the standard SNMPv3
      View-based Access Control Model and the snmpVacmMIB.

   -  Added two MIB objects such that when an SNMPv1 notification (trap)
      must be converted into an SNMPv2 notification we add those two
      objects in order to preserve information about the address and
      community of the originating SNMPv1 agent.

   -  Included (and extended) from RFC 2089 the SNMPv2 to SNMPv1 mapping
      within a multi-lingual SNMP Engine.

Top      Up      ToC       Page 50 
   -  Use keywords from RFC 2119 to describe requirements for
      compliance.

   -  Changed/added some rules for converting a MIB module from SMIv1 to
      SMIv2.

   -  Extended and improved the description of Proxy Forwarder behaviour
      when multiple SNMP versions are involved.

Editors' Addresses

   Rob Frye
   Vibrant Solutions
   2711 Prosperity Ave
   Fairfax, Virginia 22031
   U.S.A.

   Phone: +1 703 270 2000
   EMail: rfrye@vibrant-1.com

   David B. Levi
   Nortel Networks
   3505 Kesterwood Drive
   Knoxville, TN 37918
   U.S.A.

   Phone: +1 865 686 0432
   EMail: dlevi@nortelnetworks.com

   Shawn A. Routhier
   Wind River Systems, Inc.
   500 Wind River Way
   Alameda, CA 94501
   U.S.A.

   Phone: + 1 510 749 2095
   EMail: sar@epilogue.com

   Bert Wijnen
   Lucent Technologies
   Schagen 33
   3461 GL Linschoten
   Netherlands

   Phone: +31 348 407 775
   EMail: bwijnen@lucent.com

Top      Up      ToC       Page 51 
Full Copyright Statement

   Copyright (C) The Internet Society (2003).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assignees.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.