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

Hi Mike,

I am in a meeting, so don't have access to the documents right now ;-)

I think your approach is not consistent with the high-level design goals
of snmpv3. The reason we have the flags in the header is so the PDU
format can be independent of header processing, i.e. different PDU types
could be used and the header processing doesn't need to know the details
of the PDU format. 

Your approach requires the header processing sections to look into the
PDU and interpret the contents/format to determine the operations type.
That means the header processing must know just which type of PDU is
encapsulated in the message, and that is not desirable for snmpv3.

dbh

> -----Original Message-----
> From: Michael Kirkham [mailto:[email protected]] 
> Sent: Saturday, March 22, 2003 6:07 AM
> 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
> 
>