RE: USM time windows check question

OK, here is my assessment.

- Strange CG system. In the first 30 secs it lags 5 seconds
  In the next 300 secs it lags 200 secs (I would have expected 50)
  But... it does not matter to the problem at hand. I just noticed.

- I think the behaviour that results from following the steps as
  outlined in 3414 is correct and if you reverse the sequence,
  then you get incorrect behaviour. It allows the CG SNMP engine
  to come back in sync with the (lagging) CR without having to
  go through an elaborate resync process. Remember that the msg
  was authenticated, so no matter what you do, the message does
  contain the correct CR engineTime, and a resync will not change
  that.

I think that the CR should have responded with a Not-In-Time-Window
error. This is according to sect 3.2.7(a), 3rd bullet. The 
received new request is >+150 seconds according to its local
(authoritative) notion of the egineTime.

So that should have caused the CG SNMP engine to re-sync with the 
CR SNMP Engine. 

We can now wonder if the CG SNMP Engine should still accept this 
response (that should never have been send by a compliant CR).
Some considerations:
- is it realistic to assume that the CR lags so badly in time so
  as to lag 2 seconds every 3 seconds of real time?
- the message is authenticated, we have had no other communication
  with the CR and so, the response MUST (by definition) contain
  the authoritate engineTime of the CR.
- If we do reject it because our time runs (correct or faster) then
  we end up rejecting this response, we do the more complicate resync
  hoopla/polka and the end result is that we find out that the
  authortative value is indeed 100. So with that we send another
  request to the agent and now succeed. Sounds like a lot of
  extra work for nothing, no? And that is what you get if you do
  step 3.2.7b.2 first
So I think the behaviour as per 3414 is correct, or at least acceptable,
cause it does not create a problem at the CG end.

Now let us first change your scenario, such that the CR would not
cause a not-in-time-window response. 
- Let us define t2 as t1+150 seconds
- Let us assume that the CR has lagged 
  have passed
- That is, I believe that the response in

Now, w.r.t. to your claim that a message would never be considered
out-of-time window. In fact it will, but that would happen if
some old response comes back. Let us say at t3 (+600 seconds), 
you have another good CG-CR interaction and the B' and C values
get set to 200. Now let us assume that after that response t1 comes
back once more. Then B<C and so it skips step 3.7.2b.1 and runs
into the not-in-time-window. (see also 2nd para on page 30).

Hope this helps... 
Bert 

> -----Original Message-----
> From: Bob Natale [mailto:[email protected]]
> Sent: zaterdag 4 januari 2003 22:29
> To: Wijnen, Bert (Bert)
> Cc: [email protected]
> Subject: 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
>