RE: USM time windows check question

At 1/4/2003:07:30 AM, Wijnen, Bert (Bert) wrote:

Hi Bert,

Please refer to the data at:

   http://www.winsnmp.com/TimeWindow-Debug.htm

Ok...I hope I'm not wasting people's time with this...
and I *really* hope it's not some stupid oversight on my
part :-(...but we have been debugging a customer problem
report for a scenario in which our WinSNMP SNMPv3 stuff
powers a command generator (CG) app interacting with
a v3 command responder (CR) app from another source
and this particular CR has some (known) problems with
its implementation of engineTime and appears to run on
a system whose clock runs slower than the system which 
hosts the CG app.  Due to customer circumstances, we
have to accept these attributes of the problem space
for now.  The known problems with the CR's implementation
of engineTime are blatant but are thought to be not
immediately material to the problem scenario discussed
herein (but might affect other aspects of the problem).

The customer/problem thing is, of course, a matter for
the parties involved and not the IETF community.  However,
this particular problem scenario caused us to review more
closely our relatively very tight implementation of RFC3414
and that review has revealed a *possible* problem with the
spec.  (Also, in doing related research we found secondary
sources and other implementation code that specifically
avoided the "tight" implementation approach wrt RFC3414 3.2.7b).)

So, please look at the data in the (html) spreadsheet URL'd
above.  I've tried to keep the details as simple as possible.
Think of the three "Events" (columns t0, t1, and t2) as as
three separate CG Request messages happening at times t0 = 0,
t1 = t0 + 30 seconds, and t2 = t1 + 300 seconds.  Event t0
includes Report-based engine discovery and initial time sync
with the CR.

Ok...remembering that the CR in this case runs consistently
slower than the CG...it appears that the protocol attribute
values at t2 lead to the CR's response being accepted as
valid (within Time-Window) if 3.2.7b.1} is executed before
3.2.7b.2), whereas the response is considered outside the
Time-Window if 3.2.7b.2) is executed first.  The latter
result looks like the "right" one in this case...?  The
items in red and green font color in column t2 are highlighted
as the suspect problems.

It is also clear from this spreadsheet that the tests in
rows 16 and 17 (from 7b.2) can never fail if the sets in
rows 10 and 11 (from 7b.1) are executed first, leaving
only the case where the local notion of snmpEngineBoots
now equals the latch value where Not-In-Time-Window will
be asserted (in this problem scenario...in which the CR's
clock advances but at a rate consistently behind the CG's
clock).

For ease of reference, I am including the text of RFC3414
3.2.7b after my .sig below.

Perhaps I have mis-interpreted the text?

Perhaps I have erred in translating the text to the
operations/values in rows 6 thru 18 of the spreadsheet...?

Perhaps I have overlooked some other part of the spec that
would nullify the conditions set out for one or both of
columns t1 or t2?

Perhaps I am mis-interpreting my own data?

I feel like it's a lot to ask, but I would appreciate
anyone's assessment re the above.  And despite what I
said at the outset, I really do hope that I end up with
egg on my face here!

Cheers,

BobN
----- From RFC3414 -----
   7)  If the securityLevel indicates an authenticated message, then the
       local values of snmpEngineBoots, snmpEngineTime and
       latestReceivedEngineTime corresponding to the value of the
       msgAuthoritativeEngineID field are extracted from the Local
       Configuration Datastore.

       a) If the extracted value of msgAuthoritativeEngineID is the same
          as the value of snmpEngineID of the processing SNMP engine
          (meaning this is the authoritative SNMP engine), then if any
          of the following conditions is true, then the message is
          considered to be outside of the Time Window:

          - the local value of snmpEngineBoots is 2147483647;

          - the value of the msgAuthoritativeEngineBoots field differs
            from the local value of snmpEngineBoots; or,

          - the value of the msgAuthoritativeEngineTime field differs
            from the local notion of snmpEngineTime by more than +/- 150
            seconds.

          If the message is considered to be outside of the Time Window
          then the usmStatsNotInTimeWindows counter is incremented and
          an error indication (notInTimeWindow) together with the OID,
          the value of the incremented counter, and an indication that
          the error must be reported with a securityLevel of authNoPriv,
          is returned to the calling module

       b) If the extracted value of msgAuthoritativeEngineID is not the
          same as the value snmpEngineID of the processing SNMP engine
          (meaning this is not the authoritative SNMP engine), then:

          1) if at least one of the following conditions is true:

             - the extracted value of the msgAuthoritativeEngineBoots
               field is greater than the local notion of the value of
               snmpEngineBoots; or,

             - the extracted value of the msgAuthoritativeEngineBoots
               field is equal to the local notion of the value of
               snmpEngineBoots, and the extracted value of
               msgAuthoritativeEngineTime field is greater than the
               value of latestReceivedEngineTime,

             then the LCD entry corresponding to the extracted value of
             the msgAuthoritativeEngineID field is updated, by setting:

             - the local notion of the value of snmpEngineBoots to the
               value of the msgAuthoritativeEngineBoots field,

             - the local notion of the value of snmpEngineTime to the
               value of the msgAuthoritativeEngineTime field, and

             - the latestReceivedEngineTime to the value of the value of
               the msgAuthoritativeEngineTime field.

          2) if any of the following conditions is true, then the
             message is considered to be outside of the Time Window:

             - the local notion of the value of snmpEngineBoots is
               2147483647;

             - the value of the msgAuthoritativeEngineBoots field is
               less than the local notion of the value of
               snmpEngineBoots; or,

             - the value of the msgAuthoritativeEngineBoots field is
               equal to the local notion of the value of snmpEngineBoots
               and the value of the msgAuthoritativeEngineTime field is
               more than 150 seconds less than the local notion of the
               value of snmpEngineTime.

             If the message is considered to be outside of the Time
             Window then an error indication (notInTimeWindow) is
             returned to the calling module.

             Note that this means that a too old (possibly replayed)
             message has been detected and is deemed unauthentic.

             Note that this procedure allows for the value of
             msgAuthoritativeEngineBoots in the message to be greater
             than the local notion of the value of snmpEngineBoots to
             allow for received messages to be accepted as authentic
             when received from an authoritative SNMP engine that has
             re-booted since the receiving SNMP engine last
             (re-)synchronized.
----- End of excerpt from RFC3414 -----
>Inline
>
>> -----Original Message-----
>> From: Bob Natale [mailto:[email protected]]
>> Sent: zaterdag 4 januari 2003 9:38
>> 
>> Hi,
>> 
>> In considering RFC3414 Sec 3.2.7b, I am curious
>> as to whether the ordering of the sub-sections
>> 1) and 2) has any significance...?  That is,
>> is that ordering supposed to indicate that the
>> tests and actions in 1) should be performed
>> first and then the tests and actions in 2) should
>> be performed...?
>> 
>I think so, as I think all the steps are to be executed 
>in the sequence as documented. It is maybe possible that 
>other sequences are valid too... but we have all been 
>evaluating this sequence and we have done interoeprability
>testing using this sequence.
>
>> Common-sense would suggest that the ordering
>> means something (generally we do step 1 before
>> step 2), but there are some reasons for thinking
>> that might not apply here.  :-)
>
>I'd like to understand the reasons why you think it may 
>not apply in this case.
>
>> First, there is no "then" or "else" prefixed to
>> 2)...suggesting that the two sets of tests and
>> actions are performed independently.
>
>Well, none (or very few) of our numbered sequenced 
>statemens start with "then"... so why would we do it
>in this case?
>
>> Second, as it
>> turns out, however, the two sets of "if" conditions
>> are not mutually exclusive and for certain values
>> of the subject variables, performing 1) before 2)
>> can lead to invalid, but unavoidable, results.
>> (It's late here now, so I'm going to skip laying
>> out a detailed example...but if anyone thinks it's
>> necessary, I'll add it in a follow-up.)
>> 
>Pls post an example where you think we come to 
>invalid results. I am not saying this is not true, 
>but I believe we have gone through this a number of 
>times in the past, and I think we came to the 
>conclusion that this is what needs to be done.
>We still may have overlooked a specific case, so
>I'd love to hear it.
>
>> The bottom line is that I think the tests and
>> actions described in 2) need to be performed
>> before those in 1) and that this ordering and
>> the specific dependency need to be spelled out
>> in any future revision of the spec.  That is,
>> the time window check should be done before
>> checks that might lead to updating the local
>> record of the authEngine's timeliness variables.
>> Doing them in reverse order (i.e., as currently
>> ordered in the spec) can lead to situations in
>> which otherwise out of time window messages
>> morph into valid messages or, at the very least,
>> inappropriately lead to "updates" of the local
>> record of the authEngine's timeliness variables.
>> 
>Pls do realize, that at this point (3.2.7b) we are
>dealing with an authenticated message. So this MUST 
>be the real value that the AUTHORITATIVE engine
>tells us about, no? So what is wrong with using that
>value to update our local notion at the 
>non-AUTHORITATIVE side of the communication?
>
>Bert
>> I will appreciate any and all feedback on this
>> topic.
>> 
>> Cheers,
>> 
>> BobN