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

Good point Dave. We did indeed discuss this quite
extensively a few years back. It is coming back 
into my mind.

Thanks,
Bert 

> -----Original Message-----
> From: Harrington, David [mailto:[email protected]]
> Sent: maandag 24 maart 2003 19:27
> To: Michael Kirkham; [email protected]
> Subject: 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
> > 
> > 
>