TABLE OF CONTENTS
C.4.1 SNMPv1
The security parameters for SNMPv1 are based on a community name, which is a string of
ASCII characters (i.e. "public"), and an IP address. The TS2000 defines the IP address such that
SNMPv1 packets will be accepted from any IP address which has a valid community name. The
community name in SNMPv1 packets defines the level of access. The TS2000 allows for the
definition of 2 community names, one which is read-only and another which has read-write
privileges. The design of the SNMPv1 section of the agent defines that the view (which section
of the MIB tree) the incoming SNMPv1 packet acts upon must be the same for both the read-
only and the read-write communities. With this in mind, the view of SNMPv1 packets is from
internet (OID 1.3.6.1) down with the modifier that the snmpParties (OID 1.3.6.1.6.3.3.2.1) is
excluded to prevent SNMPv1 packets from modifying the SNMPv2 Party Table. The user
should consult their SNMP manager documentation in order to determine how to create an object
and set the community names. Typically, the information required will be the IP address of the
TS2000 and the community names which were set through the front panel of the TS2000.
C.4.2 SNMPv2
NOTE: The IETF is currently reviewing SNMPv2. There is a very strong possibility that
SNMPv2 will be abandoned before 1996 in favor of a version of SNMP which provides a
higher level of security than SNMPv1 and yet removes much of the complex security
structure of SNMPv2. Datum Inc provides no warranty than SNMPv2 will be supported
in future versions of the TS2000 or other Datum products.
IT IS STRONGLY SUGGESTED THAT YOU USE SNMPv1 TO COMMUNICATE
WITH THE TS2000.
The security mechanism for SNMPv2 is complex and an explanation of how the various parts
interact is beyond the scope of this manual. The following presentation of SNMPv2
configuration to access the TS2000 assumes that the user is knowledgeable about SNMPv2
parties, contexts and views.
C.4.2.1 SNMPv2 PARTIES
The TS2000 SNMPv2 agent has 10 parties in its party table. The entries are arranged in pairs.
The party id follow the standard SNMP format, using initialPartyId.IPaddress.#, where # is a
cardinal number from 1-10. The IP address is read from flash EPROM when the party table is
initialized. Entries 9 & 10 in the party table are "pseudo-parties" or parties which handle the
SNMPv1 requests. Parties 1, 3, 5 & 7 identify the TS2000 while parties 2, 4, 6 & 8 identify the
corresponding remote entities.
Parties 1 & 2 handle the noAuth/noPriv packets. The TAddress field in party 2 is not checked as
it is defined noAuth/noPriv. This means that any SNMPv2 manager may send requests using
party1 as the destination and party2 as the source. If you correlate these parties with the context
and view tables, it becomes apparent that this does not present a security concern as the only
supported operations are get, getnext and getbulk.
TYMSERVE 2000 Manual Datum Inc, Bancomm Div.
xlviii
To Next Page
Loading...
General