RE: A slight flaw in the order of operations in USM

[speaking as a technical contributor]
So... you seem to be saying we should go "out of our way"
to try and deal with an SnmpEngine that basically has
incorrectly encoded the message?

It seems to me that ervything works great for messages that
are correctly encoded, and one that is incorrectly encoded
might get an error (that potentially could have passed
if we had done the sequence differently).

I don't think we want to make such a change to a STD level
document. Had this been brought up at the PS level...
we could have considered it.


Thanks,
Bert 

> -----Original Message-----
> From: Michael Kirkham [mailto:[email protected]]
> Sent: zaterdag 22 maart 2003 14:07
> To: [email protected]
> Subject: A slight flaw in the order of operations in USM
> 
> 
> 
> Well, "slight flaw" may be too strong of a wording, but it's 
> a tiny thorn
> that would be simple enough to fix in the future, with little negative
> consequence:
> 
> I would suggest that step 3.2(7) (timeliness checking) of RFC 
> 3414 ought
> to come after step 3.2(8) (decryption) -- at least the part where the
> out-of-time-window error is returned to the calling module.  
> The reason
> being that RFC 3412 requires the PDU type, if it can be determined, to
> override the settings of the 'reportable' flag.  If an implementation
> follows this order to the letter, and receives an authPriv 
> request from
> another implementation that erroneously neglects to set the reportable
> flag, then time synchronization will fail, where it would otherwise
> succeed had the PDU simply been decrypted first, because the 
> PDU type will
> be unknown.
> 
> The only negative consequence that I can think of for 
> decrypting prior to
> timeliness checking is some additional CPU load/processing time for
> out-of-time-window messages, which would probably only matter 
> in the case
> of a DOS attack via replay flood.
> 
> Alternately, the notInTimeWindows report should always be 
> sent, regardless
> of the state of the reportable flag, if the message indicates that the
> processing engine is authoritative by way of the 
> msgAuthoritativeEngineID
> parameter.
> 
> Like I said, it's only a slight flaw -- only one that would affect a
> non-authoritative engine with a bug in its flag settings -- 
> but I thought
> it worth noting, if only because it might cause a new implementor to
> scratch their head for a while if they find that time synchronization
> works with authNoPriv but not with authPriv.
> 
> --
> Michael Kirkham
> www.muonics.com
>