Subject: Re: [Isms] achieving market saturation with ISMS (fwd)

From: "David T. Perkins" <[email-masked]>
Date: Thu, 24 Feb 2005 13:05:23 -0800 (PST)

HI,

This is a resend. Sorry if you get it twice, but
it's VERY IMPORTANT.

Regards,
/david t. perkins

---------- Forwarded message ----------
Date: Thu, 24 Feb 2005 12:37:11 -0800 (PST)
From: David T. Perkins <[email-masked]>
To: Juergen Schoenwaelder <[email-masked]>
Cc: Randy Presuhn <[email-masked]>, [email-masked]
Subject: Re: [Isms] achieving market saturation with ISMS

HI,

Juergen is so right. We covered this topic in the BOFs
that lead up to the formation of ISMS.

That is, when a box is set up, work is done to use
other management interfaces. Unfortunately, to deploy
SNMPv3/USM on the box, extra work has to be done. And for
on-going operations, extra work needs to be done to support
SNMPv3/USM. The ABSOLUTELY PRIMARY goal of ISMS is to
ELIMINATE this "extra" work. I believe the EVAL team
didn't GET THIS, and thus, they came out with a fatally
flawed I-D. Again, THEY DIDN'T UNDERSTAND THE PRIMARY
PROBLEM TO BE SOLVED! For example, they believed that
boxes must continue to support USM, so if an authentication
service was not available, there would be a fallback
method to authentication. WRONG!! There is NO NEED for
USM, except for backwards compatibility with the
VERY small number of SNMPv3/USM managers.

The WG will continue to go around in circles and come
up with clever engineering solutions (because the 
EVAL authors and members of the WG are really smart
engineers) until some basic understanding is reached
on the operational problem to be solved.

Please, WG chairs supply some guidance on solving
the appropriate problem. Please ask the EVAL team,
or a new team do the evals specified in section 2.3
of the EVAL I-D, and drop all of the other 
eval considerations that they added.

On Thu, 24 Feb 2005, Juergen Schoenwaelder wrote:

> On Wed, Feb 23, 2005 at 03:49:29PM -0800, Randy Presuhn wrote:
> 
> > Here's what bugs me about local accounts:
> > The effort required to provision and maintain local accounts is arguably
> > even greater than that required to maintain USM users, because at least
> > the USM user maintenance is easily accomplished remotely through a
> > highly standardized interface.  If USM is too much work, then how would
> > making local accounts be an improvement?
> 
> Local accounts are a reality on all boxes that I can think of. You
> telnet, ssh, whatever into local accounts as the default. On some
> installations, you find AAA setups to simplify the maintenance of
> accounts in the normal case (when the core network is running).
> The point is that USM does typically not interface with neither
> these local accounts nor AAA systems. In other words, USM is too
> much work because it is extra work in _addition_ to the management
> of local accounts or AAA accounts. [I am surprised that the core
> of the problem still seems to be not well understood.]
> 
> /js
> 
> -- 
> Juergen Schoenwaelder		    International University Bremen
> <http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany
> 
> _______________________________________________
> Isms mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/isms
> 

_______________________________________________
Isms mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/isms

---

From: Juergen Quittek <[email-masked]>
Date: Fri, 25 Feb 2005 11:48:00 +0100

Hi David,

--On 24.02.2005 22:05 h +0100 David T. Perkins wrote:

> ELIMINATE this "extra" work.

Sorry, to which part of the I-D are you referring?

>                              I believe the EVAL team
> PROBLEM TO BE SOLVED! For example,

Do you have more examples or even the full list?

>                                    they believed that
> method to authentication. WRONG!!

What the I-D states is

      *  Must not preclude the use of USM [RFC3414], particularly if
         network instability could cause problems for the proposed
         solution
      *  ...
      *  Must not break basic device discovery.  (Retaining USM support
         would satisfy this goal.)

I don't see a statement saying "boxes must continue to support USM".

>                                   There is NO NEED for

Is there support for this statement by other WG members?

---

From: "David T. Perkins" <[email-masked]>
Date: Fri, 25 Feb 2005 08:51:41 -0800 (PST)

HI,

The WG is the guide, not the EVAL I-D.

The EVAL I-D is fatally flawed because,
 1) It used eval aspects not included in the WG charter
    or that had rough concensus on the WG charter.
 2) It specified eval criteria in section 2.3 (operational
    scenarios), but did not include the result of
    these operational scenarios in the EVAL I-D.
 3) It mischaracterized the features of the proposals.
 4) It based it's recomendations on facts the authors
    didn't know and ignored facts authors should know
    (or that could be determined).

Does this help with your questions below?

On USM support, why don't you ask the EVAL authors
instead of trying to interpret their double talk.

That is, EVAL authors,
1) Can a new security model replace USM so that there
   would be no need for its deployment. That is,
   after the new security model is available for
   deployment, will there be any need for USM
   except where it is already deployed?

Regards,
/david t. perkins

---

From: "Randy Presuhn" <[email-masked]>
Date: Fri, 25 Feb 2005 17:00:44 -0800

Hi -

> From: "David T. Perkins" <[email-masked]>
> To: "Juergen Quittek" <[email-masked]>
> Cc: <[email-masked]>
> Sent: Friday, February 25, 2005 8:51 AM
> Subject: Re: [Isms] achieving market saturation with ISMS (fwd)
>

>     or that had rough concensus on the WG charter.

Please forgive us for attempting to include points raised in
discussion on the working group mailing list, like those from
Eric Fleischman's wish list, that appeared to not be contentious,
as well as any other criteria that we may have used in trying to
identify a clear "winner" from among the proposals.

>     these operational scenarios in the EVAL I-D.

Please forgive us for submitting a -00- draft that is not perfect.
I guess we erred by trying to produce something helpful in time for
the i-d cutoff, rather than waiting for something that was complete
in all respects.

>  3) It mischaracterized the features of the proposals.

Please forgive us for not getting everything right.  Please
send text, and we'll happily correct errors where we've
misunderstood the proposals.

>     (or that could be determined).

Please forgive our lack of omniscience.  We'll happily
incorporate text that will improve the document, particularly
if it would enable a more clear-cut decision by the WG.
However, the WG should, I think, be focusing on moving
ahead.  As much as we would have like to be able to pick
one of the proposals and say "this is perfect and we should
procede from here", things, at least as we saw them, were
not so clear-cut.

> instead of trying to interpret their double talk.

I'm not sure what you're calling "double talk."   The requirement
"Must not preclude the use of USM [RFC3414], particularly if
network instability could cause problems for the proposed
solution" has not previously been disputed, as far as I know.

>    except where it is already deployed?

I think any model that potentially relies on external AAA needs
some kind of self-sufficient fallback.  USM fuflfills that requirement.
It's probably possible to define a new security model with comparable
fallback capabilities, like the local accounts in SBSM, but that begs the
question of how these are managed.  So yes, to the extent that a new
model re-impliments some key USM features,and doesn't break
other key needs, like device discovery, it could replace USM.
Whether doing so would actually be desirable is not clear.

> > > PROBLEM TO BE SOLVED! For example,

The "extra" work, setting the keys for the "initial" user, isn't addressed
by any of the proposals.  In some respects they compound the problem
by requiring provisioning of AAA keys.  This has been discussed on this
mailing list at some length.  What other parts of the problem don't we get?

> > Do you have more examples or even the full list?

These would be appreciated; we're trying to be useful.

> > > method to authentication. WRONG!!

So if there is no authentication service available, things should
simply not work?  If the fallback is to local accounts, we're back
to the problem of specifying how they're managed, unless you
accept the argument that it's simply someone else's problem.

> > I don't see a statement saying "boxes must continue to support USM".
...

Indeed, we did not say boxes must continue to support USM.
The requirement is that this solution must not preclude supporting USM.

> > > on the operational problem to be solved.
...

Which operational problem(s) do you believe are the ones to
be solved, if not the ones in our charter?

Randy