Re: status and future of the isms working group

----- Original Message -----
From: "Wes Hardaker" <[email protected]>
To: "t.petch" <[email protected]>
Cc: "Romascanu, Dan (Dan)" <[email protected]>; "David Harrington"
<[email protected]>; <[email protected]>; "Ron Bonica" <[email protected]>;
<[email protected]>
Sent: Monday, September 20, 2010 8:43 PM
> >>>>> On Mon, 20 Sep 2010 09:28:49 +0200, "t.petch" <[email protected]>
said:
>
> tp> RFC3411 was a great piece of work, but turned out to be fatally
> tp> flawed.  The first time it was put to the test, introducing a new
> tp> security model, it proved unusable.
>
> Well, I'm not sure that's an entirely fair characterization.  The
> problem wasn't that the model was flawed, it was that it wrapped *only*
> around its own notion of the SNMP protocol.
>
> When ISMS came along and the decision was to outsource the security to
> something in a lower layer, then yes the original model had issues with
> that because it didn't take that possibility into account.  5590 simply
> fixed that.  Interestingly enough by providing some extra transmission
> lines to the model and extra information to the data passed via the
> ASIs.

Well, yes and no.  In isms, we retained the idea of 'no sessions', and I was
interested to see in the most recent I-D ....  vacmAaaSessionID OBJECT-TYPE

I always thought that SNMP had sessions, just that some of them were rather
short, and I that that is another disconnect that took quite a lot of time to
sort out in the isms work; it would have been easier if RFC3411 or RFC5590 had
had sessions in the architecture.

And yes, I am making my point quite strongly, because I think that an 'RFC6411'
would be a poor use of IETF resources.

Tom Petch

> However, the ISMS solutions were the first "standardized" ones.  More
> documents and code have been written to provide other security models
> that were either implemented or partially implemented and worked just
> fine without changing the underlying 3411 model: KSM (which is now being
> brought forward again) and SBSM (which is how the ISMS working group got
> started but went the SSH-underneath route instead of an
> in-SNMPv3-protocol integrated model).
> --
> Wes Hardaker
> Cobham Analytic Solutions