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

Nah, I'm not so much suggesting a change to the STD level document as I am
(1) making a suggestion to implementors for a possibly better way to deal
with such a situation and (2) mentioning it in case there is ever another
revision to the document, then people could be aware of it (in which case
it could be made a suggestion, but not a requirement).

Yes, it's unfortunate I didn't several years ago.  I only noticed when
doing my second engine implementation recently.  Or perhaps I just forgot.
;)

On Sat, 22 Mar 2003, Wijnen, Bert (Bert) wrote:

> Date: Sat, 22 Mar 2003 19:50:55 +0100
> From: "Wijnen, Bert (Bert)" <[email protected]>
> To: Michael Kirkham <[email protected]>, [email protected]
> Subject: 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
> >
>

--
Michael Kirkham
www.muonics.com