Re: EXTERNAL: Re: 5.7.3 | snmptrap not populating EngineBoots or EngineTime for snmp v3 traps

On Wed, Dec 19, 2018 at 12:39:07AM +0000, Roedersheimer, Drew A. wrote:
> Denis Hainsworth wrote:
> > #2899 - snmptrap bug
> > #2900 - snmptrapd bug
> > 
> > -denis
> 
> Denis,
> 
> Sorry for the delayed response.  I haven't had time to look at this until recently.
>  
> Regarding the snmptrapd bug you created (#2900): I think this is working as expected.
> I compiled and tested v5.7.3 from git source, and snmptrapd is certainly validating the
> msgAuthoritativeEngineBoots value.  Whenever I send a trap with a boot value that is
> the same or greater than the last, the trap is received.  If I send a trap with a
> boot value that is less than a previous trap, I get the following error from snmptrapd:
>  
> usm: USM processing begun...
> usm: match on user testuser
> usm: Verification succeeded.
> usm: Remote boot count invalid.
> 
> 
> As for the msgAuthoritativeEngineTime values, if the delta from the previous trap
> is large enough, the trap is also rejected by snmptrapd.  Here's the message you
> will see (with -Dusm):
> 
> usm: USM processing begun...
> usm: match on user testuser
> usm: Verification succeeded.
> usm: Message too old.
> 
> I haven't dug into the code deep enough to find the threshold, but I suspect it's
> following the RFC.
> 
> The end result is that I think that bug #2900 should be closed as invalid.
> 
> Please let me know your thoughts.

Dug into this some more.  I see whats happening and not sure if its a
bug per se but I do agree that if there is a non-buggy trap sender its
all working properly so will close the bug with some comments.

So per rfc2574 the only requirement is that a trap boots/time be at most
150s behind the last message received.  Plus that boots/time always
starts at 0/0.   So because snmptrap binary we were using was always
setting boots/time to 0/0 that was never less than 150s older so
snmptrapd happily accepts the messages which I though meant it wasnt
checking.   This is namely because Cisco Prime Network snmp trap
receiver throws the "notintimewindow" error for 0/0.  I believe this is
a restriction technically outside the strict reading of the RFC.  I
couldn't find a section that mandated the snmp receiver should error if
boot/time never changes and/or always stays at 0/0.    In this sense i
think snmptrapd is potentially more RFC compliant but less restrictive 
than cisco.   As you noted if I use a functional snmptrap program where
I am able to set the boots/time and advance it to non zero values than I
can see that I get proper errors if I back the time up past 150s prior
to the latest time sent.

So i'll update and close the snmptrapd bug.   nice catch sorry for the
confusion.  

-denis