Page 116 / 998 Scroll up to view Page 111 - 115
SNMP
ZTC command reference
iMG/RG Software Reference Manual (System Configuration)
1-84
Description
This command changes the value of the
pollingtimeout
, which is the polling time interval
used by the ztcclient when it attempts the first synchronization. After the gateway is syn-
chronized, the ztc client switches to the configtimeout polling time to check if new con-
figurations are available on the ZTC server. The timer is used to force a fast
synchronization without generate high network traffic when the gateway is already con-
figured.
Options
The following table gives the range of values for each option that can be specified with
this command, and a default value (if applicable).
Example
--> ztcclient set pollingtimeout 10
See also
ZTCCLIENT SHOW
1.5.3.1.7 ZTCCLIENT UPDATE
Syntax
ZTCCLIENT UPDATE
Description
This command saves the changes made with ZTCCLIENT SET CONFIGTIMEOUT and
ZTCCLIENT ENABLE DYNAMIC or ZTCCLIENT ENABLE DYNAMIC commands and
turn on the polling timeout.
Example
--> ztcclient update
1.6
SNMP
This chapter introduces the configuration of SNMP module on the gateway.
To describe the SNMP configuration process the following terminology is used:
entity
a network management element that consists of an SNMP engine and one or more applications.
engine
a component of an SNMP entity that consists of a message processing subsystem, a security subsystem, an
access control subsystem (as appropriate), and a dispatcher.
application
Option
Description
Default Value
P
OLLINGTIMEOUT
The polling time (in secs) used by the ztc client
module when it tries to make the first server syn-
chronization.
5
Page 117 / 998
ZTC command reference
SNMP
1-85
iMG/RG Software Reference Manual (System Configuration)
a component of an SNMP entity that determines the function of the entity. Applications include a command
generator, command responder, notification originator, notification receiver, proxy forwarder, etc.
The SNMP entity that is commonly called a
MANAGER
is an engine plus a command generator application and a
notification receiver application.
FIGURE 1-13
A manager Entity
FIGURE 1-14
An agent Entity
The SNMP entity that is commonly called an
AGENT
is an engine plus a command responder and a notification
originator. Other types of entities are possible, because other combinations of engine and applications are via-
ble.
Dispatcher
Message
Processing
Subsystem
Security
Subsystem
SNMP Engine indentified by snmpEngineID
SNMP Entity
Command
Generator
Notification
Receiver
Application(s)
Dispatcher
Message
Processing
Subsystem
Security
Subsystem
Access
Control
Subsystem
SNMP Engine indentified by snmpEngineID
SNMP Entity
Command
Responder
Notification
Originator
Application(s)
Page 118 / 998
SNMP
SNMP configuration within the SNMPv3 adminis-
iMG/RG Software Reference Manual (System Configuration)
1-86
1.6.1
SNMP configuration within the SNMPv3 administration framework
The SNMPv3 Administration Framework is a configuration infrastructure for SNMPv3 users, but it can also be
used to remotely configure and administer SNMPv1 and SNMPv2c community strings.
The SNMPv3 security administration framework provides a strong authentication mechanism, authorization
with fine granularity, complete access control, security level controls which include two authentication algo-
rithms
1
and an optional privacy protocol, and a MIB document for remote configuration.
1.6.1.1 Security
SNMPv3 provides advanced security mechanisms for protecting against threats to management operations.
These security mechanisms are not new: they are taken from the SNMPv2 Draft Standards. The following sec-
tions describe the potential threats and how SNMPv3 protects against these threats.
SNMPv3 addresses in particular the following four threats:
M
ASQUERADE
the masquerade threat is when an unauthorized user attempts to carry out management operations by
assuming the identity of an authorized user. SNMPv3 can verify the identity of the originator of the SNMPv3
message.
M
ODIFICATION
OF
INFORMATION
modification of information is the threat that a user will (by malice or error) alter a message in transit
between the source and the destination, thereby carrying out unauthorized management activity. SNMPv3
can verify that the SNMPv3 message was not altered in transit between the originator and the recipient.
M
ESSAGE
STREAM
MODIFICATION
message stream modification occurs when (by malice or error) management messages are reordered,
replayed, or delayed. SNMPv3 can verify that a received message is timely.
1.6.1.2 Mechanisms used by SNMPv3 security
SNMPv3 security protects against masquerade, modification of information, and message stream modification
by using the Hash-based Message Authentication Code (HMAC) with MD5 Message Digest Algorithm (MD5) in
a symmetric, i.e. private, key mode. MD5, defined in RFC1321, takes “as input a message of arbitrary length and
produces as output a fingerprint or ‘message digest’ of the input.”
Computes an MD5 hash (H)on the concatenation of
The shared secret key (K), which has been
xored
with the hexadecimal value ‘36 ’(ipad),
The SNMP message (text), which contains zero bytes in the digest field, to produce an intermediate
digest, and
Computes an MD5 hash on the concatenation of
1.
Trivial authentication requiring only a correct user names and strong authentication based on an MD5 hash algorithm.
Page 119 / 998
SNMP configuration within the SNMPv3 administration framework
SNMP
1-87
iMG/RG Software Reference Manual (System Configuration)
The shared secret key, which has been xored with the hexadecimal value ‘5C ’(opad),
The intermediate digest to produce the final digest.
The HMAC function is summarized by the following expression:
FIGURE 1-15
hmac expression
HMAC is used in the following manner to protect against threats to management operations:
The sender and intended recipient of the SNMPv3 message share a secret key.
When the sender constructs the outgoing message, the sender’s notion of the SNMP agent’s time is inserted
into the message, and the digest field is padded with zeros. The HMAC function is then used to compute a
digest (“fingerprint”) over the concatenation of the sender‘s notion of the shared secret key and SNMPv3
message.
The digest is then inserted into the message at the position where the padding previously had been.
The message is then sent.
When the recipient receives the message, the digest in the incoming message is saved.
The recipient inserts zeros into the incoming message at the position where the shared secret key previ-
ously had been.
In the same manner as the sender, the recipient uses HMAC to compute a digest of the incoming message
(with padding instead of a digest) and the recipient’s notion of the shared secret key.
The recipient then compares:
The digest computed over the incoming message,
The digest that was saved from the incoming message.
If the shared secret key has not been compromised
2
, and if the two digests above exactly match, then there is a
high degree of confidence
3
that the following statements about the message are true:
The message origin is authentic. That is, the user that claims to have sent the message did in fact send it.
Otherwise, the digests would have been different.
The message contents have not been altered in transit. Otherwise, the digests would have been different.
2.
SNMPv3 cannot protect against the threat of compromised keys. If an unauthorized user knows a shared secret key, then
that user can masquerade as another user, modify messages in transit, and modify the message stream.
3.
It is computationally infeasible to threaten a system by trying all possible keys, especially if the administration policy for
the system includes a periodic changing of the keys which are configured.
Page 120 / 998
SNMP
SNMP configuration within the SNMPv3 adminis-
iMG/RG Software Reference Manual (System Configuration)
1-88
When an SNMP agent receives a message, it verifies that the received message is timely by comparing the time
value inside the packet with the current time. If the time value from the packet is within a “safe”window of the
actual current time, the packet is accepted. If the time value from the packet is not within the specified window,
a Report PDU containing the agent’s notion of current time is transmitted to the sender of the received packet,
and the agent discards the received packet.
If the original message was authentic, then the sender of the original message has the ability to resend the
request. The sender of the original message will update its notion of the SNMP agent’s time using the time value
from the Report PDU. Then, the HMAC calculations will be performed again to obtain the digest for the same
request packet containing an updated time value.
If the original message was the result of message stream modification, and if the shared secret key has not been
compromised, then the sender would not find the time value from the Report PDU to be useful. Without the
secret key, the packet digest cannot be correctly recalculated.
1.6.1.3 Local configuration datastore
SNMP configuration information must be stored locally on the gateway filesystem in a plain ASCII text file
named
snmpd.cnf
.
It's possible upload such file via a ftp session (using the ftp daemon facility available on the Residential Gateway)
or via the
swupdate
feature.
1.6.1.4 Configuration file format
Each line of the configuration file has the format
<TAG> <VALUE>
where
<TAG>
is a keyword and
<VALUE>
is a valid configuration value.
Entries may be continued across multiple lines by using a backslash ( \). White space (tabs, spaces, line-feeds/
carriage-returns) and blank lines in the file are ignored. Values that are strings containing white space must be
delimited with quotation marks (").
1.6.1.5 Configuration for all SNMPv3 entities
1.6.1.5.1 Configuring SNMPv3 users
Configuration for at least one SNMPv3 user must be provided for an SNMP engine to send or receive SNMPv3
messages on behalf of certain SNMP applications.
To configure an SNMPv3 user, add an
usmUserEntry
definition in the
snmpd.cnf
file accordingly the fol-
lowing syntax:
usmUserEntry <usmUserEngineID> <usmUserName> <usmUserAuthProtocol>
<usmUserStorageType> <usmTargetTag> <AuthKey>

Rate

4 / 5 based on 3 votes.

Popular Allied-Telesis Models

Bookmark Our Site

Press Ctrl + D to add this site to your favorites!

Share
Top