- If a GetResponse-PDU is received in response to a GetRequest-PDU
(previously generated by the proxy) which contains variable-
bindings of type Counter64 or which contain an SNMPv2 exception
code, and the message would be forwarded using the SNMPv1 message
version, the proxy MUST generate an alternate response PDU
consisting of the request-id and variable bindings from the
original SNMPv1 request, containing a noSuchName error-status
value, and containing an error-index value indicating the position
of the variable-binding containing the Counter64 type or exception
code.
- If a GetResponse-PDU is received in response to a GetNextRequest-
PDU (previously generated by the proxy) which contains variable-
bindings that contain an SNMPv2 exception code, and the message
would be forwarded using the SNMPv1 message version, the proxy
MUST generate an alternate response PDU consisting of the
request-id and variable bindings from the original SNMPv1 request,
containing a noSuchName error-status value, and containing an
error-index value indicating the position of the variable-binding
containing the exception code.
- If a GetResponse-PDU is received in response to a GetNextRequest-
PDU (previously generated by the proxy) which contains variable-
bindings of type Counter64, the proxy MUST re-send the entire
GetNextRequest-PDU, with the following modifications. For any
variable bindings in the received GetResponse which contained
Counter64 types, the proxy substitutes the object names of these
variable bindings for the corresponding object names in the
previously-sent GetNextRequest. The proxy MUST repeat this
process until no Counter64 objects are returned. Note that an
implementation may attempt to optimize this process of skipping
Counter64 objects. One approach to such an optimization would be
to replace the last sub-identifier of the object names of varbinds
containing a Counter64 type with 65535 if that sub-identifier is
less than 65535, or with 4294967295 if that sub-identifier is
greater than 65535. This approach should skip multiple instances
of the same Counter64 object, while maintaining compatibility with
some broken agent implementations (which only use 16-bit integers
for sub-identifiers).
Deployment Hint: The process of repeated GetNext requests used by
a proxy when Counter64 types are returned can be expensive. When
deploying a proxy, this can be avoided by configuring the target
agents to which the proxy forwards requests in a manner such that
any objects of type Counter64 are in fact not-in-view for the
principal that the proxy is using when communicating with these
agents.
- If a GetResponse-PDU is received which contains an SNMPv2 error-
status value of wrongValue, wrongEncoding, wrongType, wrongLength,
inconsistentValue, noAccess, notWritable, noCreation,
inconsistentName, resourceUnavailable, commitFailed, undoFailed,
or authorizationError, the error-status value is modified using
the mappings in section 4.3.
- If an SNMPv2-Trap-PDU is received, and will be forwarded using the
SNMPv1 message version, the proxy SHALL apply the translation
rules described in section 3, and SHALL forward the notification
as a Trap-PDU. Note that if the translation fails due to the
existence of a Counter64 data-type in the received SNMPv2-Trap-
PDU, the trap cannot be forwarded using SNMPv1.
- If an InformRequest-PDU is received, any configuration information
indicating that it would be forwarded using the SNMPv1 message
version SHALL be ignored. An InformRequest-PDU can only be
forwarded using the SNMPv2c or SNMPv3 message version. The
InformRequest-PDU may still be forwarded if there is other
configuration information indicating that it should be forwarded
using SNMPv2c or SNMPv3.
4.3. Error Status Mappings
The following tables shows the mappings of SNMPv1 error-status values
into SNMPv2 error-status values, and the mappings of SNMPv2 error-
status values into SNMPv1 error-status values.
SNMPv1 error-status SNMPv2 error-status
=================== ===================
noError noError
tooBig tooBig
noSuchName noSuchName
badValue badValue
genErr genErr
SNMPv2 error-status SNMPv1 error-status
=================== ===================
noError noError
tooBig tooBig
genErr genErr
wrongValue badValue
wrongEncoding badValue
wrongType badValue
wrongLength badValue
inconsistentValue badValue
noAccess noSuchName
notWritable noSuchName
noCreation noSuchName
inconsistentName noSuchName
resourceUnavailable genErr
commitFailed genErr
undoFailed genErr
authorizationError noSuchName
Whenever the SNMPv2 error-status value of authorizationError is
translated to an SNMPv1 error-status value of noSuchName, the value
of snmpInBadCommunityUses MUST be incremented.
5. Message Processing Models and Security Models
In order to adapt SNMPv1 (and SNMPv2c) into the SNMP architecture,
the following models are defined in this document:
- The SNMPv1 Message Processing Model
- The SNMPv1 Community-Based Security Model
The following models are also described in this document:
- 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 [16]. 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 RFC1157 [2], with differences and
clarifications as described in the following sections. The
SnmpMessageProcessingModel value for SNMPv1 is 0 (the value for
SNMPv2c is 1).
5.2.1. Processing An Incoming Request
In RFC1157 [2], 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 RFC1157 [2], and the snmpInBadCommunityNames counter is
incremented.
The parameters returned from the Community-Based Security Model are:
- The securityEngineID, which will always be the local value of
snmpEngineID.0.
- The securityName.
- The scopedPDU. Note that this parameter will actually consist
of three values, the contextSnmpEngineID, the contextName, and
the PDU. These must be separate values, since the first two do
not actually appear in the message.
- The maxSizeResponseScopedPDU.
- The securityStateReference.
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).
- 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 stateReference
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.
- 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.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
features are accomplished by providing a tag in the
snmpCommunityTable which selects sets of entries in the
snmpTargetAddrTable [18]. 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).
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.
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 "200003060000Z" -- 6 Mar 2000, midnight
ORGANIZATION "SNMPv3 Working Group"
CONTACT-INFO "WG-email: snmpv3@lists.tislabs.com
Subscribe: majordomo@lists.tislabs.com
In msg body: subscribe snmpv3
Chair: Russ Mundy
TIS Labs at Network Associates
Postal: 3060 Washington Rd
Glenwood MD 21738
USA
Email: mundy@tislabs.com
Phone: +1-301-854-6889
Co-editor: Rob Frye
CoSine Communications
Postal: 1200 Bridge Parkway
Redwood City, CA 94065
USA
E-mail: rfrye@cosinecom.com
Phone: +1 703 725 1130
Co-editor: David B. Levi
Nortel Networks
Postal: 3505 Kesterwood Drive
Knoxville, TN 37918
E-mail: dlevi@nortelnetworks.com
Phone: +1 423 686 0432
Co-editor: Shawn A. Routhier
Integrated Systems Inc.
Postal: 333 North Ave 4th Floor
Wakefield, MA 01880
E-mail: sar@epilogue.com
Phone: +1 781 245 0804
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."
REVISION "200003060000Z" -- 6 Mar 2000
DESCRIPTION "This version published as RFC2576."
REVISION "199905130000Z" -- 13 May 1999
DESCRIPTION "The Initial Revision"
::= { 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
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."
::= { 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
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
from which a command responder application will accept
management requests. If a management request containing
this community is received on a transport endpoint other
than the transport endpoints identified by this object,
the request is deemed unauthentic.
The transports identified by this object are specified
in the snmpTargetAddrTable. Entries in that table
whose snmpTargetAddrTagList contains this tag value
are identified.
If the value of this object has zero-length, transport
endpoints are not checked when authenticating messages
containing this community string."
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
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The table of mask and 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
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."
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 }
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."
::= { 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 { snmpCommunityGroup }
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."
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 }
snmpCommunityGroup OBJECT-GROUP
OBJECTS {
snmpCommunityName,
snmpCommunitySecurityName,
snmpCommunityContextEngineID,
snmpCommunityContextName,
snmpCommunityTransportTag,
snmpCommunityStorageType,
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
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.
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 (Cabletron Systems Inc.)
David Levi (SNMP Research, Inc.)
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.
Further, the SNMP-COMMUNITY-MIB 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
the SNMP-COMMUNITY-MIB, and in particular, to make it inaccessible
when using the 'public' community string.
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. Careful configuration of
proxies is required to address such situations. One approach to deal
with such situations might be to use an encrypted tunnel.
9. References
[1] Rose, M. and K. McCloghrie, "Structure and Identification of
Management Information for TCP/IP-based internets", STD 16, RFC
1155, May 1990.
[2] Case, J., Fedor, M., Schoffstall, M. and J. Davin, "Simple
Network Management Protocol", STD 15, RFC1157, May 1990.
[3] McCloghrie, K. and M. Rose, Editors, "Concise MIB Definitions",
STD 16, RFC1212, March 1991.
[4] Rose, M., "A Convention for Defining Traps for use with the
SNMP", RFC1215, March 1991.
[5] McCloghrie, K. and M. Rose, "A Convention for Describing SNMP-
based Agents", RFC1303, February 1992.
[6] Case, J., McCloghrie, K., Rose, M. and S.Waldbusser,
"Introduction to Community-based SNMPv2", RFC1901, January
1996.
[7] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose,
M. and S. Waldbusser, "Structure of Management Information
Version 2 (SMIv2)", STD 58, RFC2578, April 1999.
[8] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose,
M. and S. Waldbusser, "Textual Conventions for SMIv2", STD 58,
RFC2579, April 1999.
[9] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose,
M. and S. Waldbusser, "Conformance Statements for SMIv2", STD
58, RFC2580, April 1999.
[10] Case, J., McCloghrie, K., Rose, M. and S.Waldbusser, "Protocol
Operations for Version 2 of the Simple Network Management
Protocol (SNMPv2)", RFC1905, January 1996.
[11] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Transport
Mappings for Version 2 of the Simple Network Management Protocol
(SNMPv2)", RFC1906, January 1996.
[12] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser,
"Management Information Base for Version 2 of the Simple Network
Management Protocol (SNMPv2)", RFC1907, January 1996.
[13] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser,
"Coexistence between Version 1 and Version 2 of the Internet-
standard Network Management Framework", RFC1908, January 1996.
[14] Levi, D. and B. Wijnen, "Mapping SNMPv2 onto SNMPv1 within a
bi-lingual SNMP agent", RFC2089, January 1997.
[15] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC2119, March 1997.
[16] Harrington, D. and B. Wijnen, "An Architecture for Describing
SNMP Management Frameworks", RFC2571, May 1999.
[17] Case, J., Harrington, D. and B. Wijnen, "Message Processing and
Dispatching for the Simple Network Management Protocol (SNMP)",
RFC2572, May 1999.
[18] Levi, D., Meyer, P. and B. Stewart, "SNMP Applications", RFC
2573, May 1999.
[19] Blumenthal, U. and Wijnen, B., "The User-Based Security Model
for Version 3 of the Simple Network Management Protocol (SNMP)",
RFC2574, May 1999.
[20] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based Access
Control Model for the Simple Network Management Protocol
(SNMP)", RFC2575, May 1999.
10. Editor's Addresses
Rob Frye
CoSine Communications
1200 Bridge Parkway
Redwood City, CA 94065
U.S.A.
Phone: +1 703 725 1130
EMail: rfrye@cosinecom.com
David B. Levi
Nortel Networks
3505 Kesterwood Drive
Knoxville, TN 37918
U.S.A.
Phone: +1 423 686 0432
EMail: dlevi@nortelnetworks.com
Shawn A. Routhier
Integrated Systems Inc.
333 North Ave 4th Floor
Wakefield MA 01880
U.S.A.
Phone: + 1 781 245 0804
EMail: sar@epilogue.com
Bert Wijnen
Lucent Technologies
Schagen 33
3461 GL Linschoten
Netherlands
Phone: +31 348 407-775
EMail: wijnen@lucent.com
A. Changes From RFC1908
- Editorial changes to comply with current RFCrequirements.
- 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
paramaters 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 RFC2089 the SNMPv2 to SNMPv1
mapping within a multi-lingual SNMP Engine.
- Use keywords from RFC2119 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.
Full Copyright Statement
Copyright (C) The Internet Society (2000). 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 assigns.
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 RFCEditor function is currently provided by the
Internet Society.