Re: Regarding to timeliness checking

Hi,

 Please find answers to the questions below 

1.To enable non-authoritative engines to maintain time
synchronization, each authoritative engine inserts its
current boot and time values, as well as its value of
snmpEngineID, in each outgoing Response, Report, or
Trap message in the fields
msgAuthoritativeEngineBoots,
msgAuthoritativeEngineTime, and
msgAuthoritativeEngineID. If the message is authentic,
and if the message is within the time window, then the
receiving non-authoritative engine updates is local
variables (snmpEngineBoots, snmpEngineTime, and
latestReceived EngineTime) for that remote engine
according to the following rules: 
1. An update occurs if at least one of the two
following conditions is true: 
- (msgAuthoritativeEngineBoots > snmpEngineBoots) or 
- [(msgAuthoritativeEngineBoots = snmpEngineBoots) and

(msgAuthoritativeEngineTime >
latestReceivedEngineTime)] 

The first condition says that an update should occur
if the boot value from the authoritative engine has
increased since the last update. The second condition
says that if the boot value has not increased, then an
update should occur if the incoming engine time is
greater than the latest received engine time. The
incoming engine time will be less than the latest
received engine time if two incoming messages arrive
out of order, which can happen, or if a replay attack
is underway; in either case, the receiving engine will
not perform an update. 

 If an update is called for, then the following
changes are made: 
- set snmpEngineBoots to the value of
msgAuthoritativeEngineBoots 
- set snmpEngineTime to the value of
msgAuthoritativeEngineTime 
- set latestReceivedEngineTime to the value of 
msgAuthoritativeEngineTime 

If we turn the logic around, we see that if
msgAuthoritativeEngineBoots < snmpEngineBoots, then no
update occurs. Such a message is considered not
authentic and must be ignored. If
msgAuthoritativeEngineBoots = snmpEngineBoots but
msgAuthoritativeEngineTime < latestReceivedEngineTime,
then again no update occurs. In this case, the message
may be authentic, but it may be misordered, in which
case an update of snmpEngineTime is not warranted. 
Note that synchronization is only employed if the
authentication service is in use for this message and
the message has been determined to be authentic via
HMAC. This restriction is essential because the scope
of authentication includes msgAuthoritativeEngineID,
msgAuthoritativeEngineBoots, and
msgAuthoritativeEngineTime, thus assuring that these
values are valid. 
SNMPv3 dictates that a message must be received within
a reasonable time window, to avoid delay and replay
attacks. The time window should be chosen to be as
small as possible given the accuracy of the clocks
involved, round-trip communication delays, and the
frequency with which clocks are synchronized. If the
time window is set too small, authentic messages will
be rejected as unauthentic. On the other hand, a large
time window increases the vulnerability to malicious
delays of messages. 
We consider the more important case of an
authoritative receiver; timeliness testing by a
non-authoritative receiver differs slightly. With each
incoming message that has been authenticated and whose
msgAuthoritativeEngineID is the same as the value of
snmpEngineID for this engine, the engine compares the
values of msgAuthoritativeEngineBoots and
msgAuthoritativeEngineTime from the incoming message
with the values of snmpEngineBoots and snmpEngineTime
that this engine maintains for itself. The incoming
message is considered outside the time window if any
one of the following conditions is true: 

snmpEngineBoots = 231 ­ 1 or 
msgAuthoritativeEngineBoots != snmpEngineBoots or 
the value of msgAuthoritativeEngineTime differs from
that of snmpEngineTime by more than ±150 s 
The first condition says that if snmpEngineBoots is
latched at its maximum value, no incoming message can
be considered authentic. The second condition says
that a message must have a boot time equal to the
local engine's boot time; for example, if the local
engine has rebooted and the remote engine has not
synchronized with the local engine since the reboot,
the messages from that remote engine are considered
not authentic. The final condition says that the time
on the incoming message must be greater than the local
time minus 150 s and less than the local time plus 150
s. 
If a message is considered to be outside the time
window, then the message is considered not authentic,
and an error indication (notInTimeWindow) is returned
to the calling module. 



2.Once the non-auth engine got the snmpEngineboot and
snmpEnginetime form the auth-engine by the discovery
process, it should maintain the local notion of these
values. it should increment the snmpenginetime value
once per second  so that the time values at local and
remote are close to in sync. The values of
snmpengineboot and snmpenginetime  are placed in
msgAuthoratativeEngineboots and
msgAuthoratativeEngineTime in the request message and
sent across to the agent.


3. snmpEngineID, snmpEngineBoots, and snmpEngineTime
of the authoritative engine be placed in the
msgSecurityParameters. This requires the
non-authoritative engine (i.e. manager) to know these
values for the authoritative engine (i.e. agent)
before a GET, NEXT, or SET operation can be completed.


This is achieved by a discovery process. There are two
discovery transactions that occur. The first is to
discover the snmpEngineID of the agent. The second is
to discover the snmpEngineBoots and snmpEngineTime.
The second transaction is only needed if the manager
wants to use a security level of authNoPriv or
authPriv. This is because the
msgAuthoritativeEngineBoots and
msgAuthoritativeEngineTime are used by the timeliness
module which is part of the authentication process. 

The first discovery transaction is initiated by the
manager sending an SNMPv3 packet with the
msgAuthoritativeEngineID containing a bogus value.
When the agent receives a packet where the
msgAuthoritativeEngineID is different than its own,
the packet is discarded and a discovery packet is
returned to the manager. The returned discovery packet
contains the correct snmpEngineID which must be used
by the manager. 

The second discovery transaction requires an
authenticated packet be sent to the agent. This means
that the authentication flag is set in the msgFlags,
and the msgAuthenticationParameters contains the
computed message digest for the packet. The secret key
used for authenticating the packet is from the user
specified in msgUserName. What makes this a discovery
packet is that the msgAuthoritativeEngineBoots and
msgAuthoritativeEngineTime contain bogus values. When
the agent receives this packet, it is first
authenticated. Once the authentication is completed,
the msgAuthoritativeEngineBoots and
msgAuthoritativeEngineTime values are checked. Since
the values are bogus, the packet is discarded and a
second discovery packet is returned to the manager.
The returned discovery packet is authenticated, using
the same user, and contains the correct values of the
snmpEngineBoots and snmpEngineTime which must be used
by the manager. 


4. There is no need for any configuration or settings
to make the timeliness checking successful

------------------------------------------------------
Newsgroup [email protected] 
Subject Regarding to timeliness checking 
Time Thu 21 Jul 2005 07:35 PM GMT +0800 
Sender shufen zhang 


Hi All,  
 
My snmpv3 authNoPrive and authPrive request got error:
not in time windows.  
Can anyone please explain a bit:  
 
1.   How timeliness checking is performed internally
by the application?  
 
2.   How snmpengine Boot and snmpEngineBoot Time are
packed in the request  
message?  
 
3.   How does the SNMP acquire the snmpEningeBoot and
Time?  
 
4.  Do we need to do any configuration or settings to
make the timeliness  
checking successful?  
 
Thanks very much!  
 
SF  
 
 
 
 
-------------------------------------------------------
 
SF.Net email is sponsored by: Discover Easy Linux
Migration Strategies  
from IBM. Find simple to follow Roadmaps,
straightforward articles,  
informative Webcasts and more! Get everything you need
to get up to  
speed, fast.
http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
 
_______________________________________________  
Net-snmp-users mailing list  
E-mail Protected  
Please see the following page to unsubscribe or change
other options:  
https://lists.sourceforge.net/lists/listinfo/net-snmp-users
 

Related Messages 
  
  A question about configure Jordi Martin Tirado (1k) 

    Regarding to timeliness checking shufen zhang (1k)
 
    Re: A question about configure Robert Story (1k)  

openSubscriber is not affiliated with the authors of
this message nor responsible for its content.
 
  
Search for messages...
    
 [email protected]     entire site 
 
 
  
© 2005 openSubscriber.com
All rights reserved.  



		
__________________________________________________________ 
Yahoo! India Matrimony: Find your partner now. Go to http://yahoo.shaadi.com


-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.
Get Certified Today * Register for a JBoss Training Course
Free Certification Exam for All Training Attendees Through End of 2005
Visit http://www.jboss.com/services/certification for more information
_______________________________________________
Net-snmp-users mailing list
[email protected]
Please see the following page to unsubscribe or change other options:
https://lists.sourceforge.net/lists/listinfo/net-snmp-users