Subject: [Isms] Let's move forward now

From: "McDonald, Ira" <[email-masked]>
Date: Tue, 1 Feb 2005 10:07:13 -0800

Hi,

Four months ago, the authors of three ISMS proposals rushed
out their I-Ds in a few weeks.  Since then, nothing productive
has happened.

The ISMS WG is rapidly headed toward failure.  Randy has
noted that the WG is free under IETF rules to ignore the
recommendation of the selection team.  But that's simply
impossible, because the odor of ten years wasted on SNMPv2
and SNMPv3 lingers in the collective memory of the IESG.

So I suggest a radical departure:

The authors of the existing three ISMS proposals (and any
others with good ideas) should begin immediately to revise
and reissue their I-Ds, assuming that they will advance
as individual contributions.

The operator and user communities would be much better served
by this approach than the current 'deer in the headlights'
fatalistic approach.

Cheers,
- Ira

Ira McDonald (Musician / Software Architect)
Blue Roof Music / High North Inc
PO Box 221  Grand Marais, MI  49839
phone: +1-906-494-2434
email: [email-masked]

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

---

From: Juergen Quittek <[email-masked]>
Date: Wed, 02 Feb 2005 17:53:12 +0100

Ira,

I understand that you are getting impatient.

But after waiting four months, why don't you wait for just
12 more days until you see the recommendation of the evaluation
team.

If then you still feel that 'radical departure' is the way to
go, feel free to initiate it.

Thanks,

    Juergen
-- 
Juergen Quittek        [email-masked]       Tel: +49 6221 90511-15
NEC Europe Ltd.,       Network Laboratories        Fax: +49 6221 90511-55
Kurfuersten-Anlage 36, 69115 Heidelberg, Germany   http://www.netlab.nec.de

---

From: Wes Hardaker <[email-masked]>
Date: Wed, 02 Feb 2005 09:44:16 -0800

>>>>> On Wed, 02 Feb 2005 17:53:12 +0100, Juergen Quittek <[email-masked]> said:

Juergen> But after waiting four months, why don't you wait for just 12
Juergen> more days until you see the recommendation of the evaluation
Juergen> team.

Actually, last I heard there was hope it would be done by the end of
January.  Apparently we're now going with the hard deadline in Feb.
At least that one can't slip!  Well, technically it could be we
technically/officially/legally couldn't talk about the results during
the meeting if I remember the whole point behind the cut-off date in
the first place.

-- 
Wes Hardaker
Sparta

---

From: "David B Harrington" <[email-masked]>
Date: Wed, 2 Feb 2005 13:23:31 -0500

Hi,

It seems a real waste of resources and time to ask us all to sit on
our hands and wait, especially since the team has now missed three(?)
deadlines in a row. We have people willing to work on the problems
this WG is meant to address, but they are not being utilized. Let's
utilize the resources we have, while we have them!

I agree with Ira that we should at least keep working while we wait.
I'm uncomfortable with Ira's suggestion because I think it will cause
people to become entrenched in their positions. Could I suggest a
middle path (or a bunch of alternate middle paths)?

Can the evaluation team identify areas in each approach that they felt
needed more work (after three months of analysis, they should be able
to do this even before finishing their full evaluation and report) and
then the authors can start to address the concerns to make the
discussions at the meeting more fruitful. If how to address the
concerns is not clear, the WG can begin to discuss how the concerns
might be addressed.

Of course, this could be a waste of time and resources if the team has
reached agreement that one or more should simply be eliminated from
consideration, and the WG plans to adopt only one (or two) proposals
for further work. This recommendation to eliminate also should be
something that the team could reveal without full details. In that
case, the authors of the (proposed) eliminated proposals could spend
their time reviewing the other proposals to determine how they might
work with the authors of the remaining proposals. [Of course, since
the recommendations of a design/evaluation team are supposed to hold
no more weight than alternative proposals/evaluations, the authors
might want to start preparing defenses of their proposals.]

Or the eval team might have decided that the proposals each had good
points and bad points and should be merged, and the team should be
able to quickly summarize the strengths/weaknesses of each without
details, and the rest of the WG could start to work at analyzing how
the proposals might be merged.

In each of these cases, the WG could be doing something rather than
just waiting. I personally am beginning to question my commitment to
this WG if the chairs are going to allow deadlines to repeatedly slip,
and continually hold back the willing members from doing anything
useful.

Let us do work!

David Harrington
[email-masked]

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Juergen Quittek
> Sent: Wednesday, February 02, 2005 11:53 AM
> To: McDonald, Ira; [email-masked]
> Subject: Re: [Isms] Let's move forward now
> 
> Ira,
>

---

From: Wes Hardaker <[email-masked]>
Date: Wed, 02 Feb 2005 10:49:09 -0800

>>>>> On Wed, 2 Feb 2005 13:23:31 -0500, "David B Harrington" <[email-masked]> said:

David> Of course, this could be a waste of time and resources if the
David> team has reached agreement that one or more should simply be
David> eliminated from consideration, and the WG plans to adopt only
David> one (or two) proposals for further work.

So another thought would be why don't we request feedback from the WG
now about which proposals they think should go forward and see if we
can eliminate some now?

Options:
  1) vote for 1
  2) vote for up to 2
  3) vote for up to 3

I actually think #2 is useful, but probably #1 will produce better
direction assuming there is no dead-even split.

We've certainly had enough banter about them all so in theory we
should be informed enough about them to make a choice (even if the
there is disagreement about their analysis of the costs and benefits
of each one).

Anyone else feel this would be worthwhile?

-- 
Wes Hardaker
Sparta

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 2 Feb 2005 20:47:32 +0100

> now about which proposals they think should go forward and see if we

The IETF generally does not vote and I think there are some good 
reasons for this.

What I personally would find useful is information how the various
people speaking up here rank the proposals and the rationale behind
their ranking. The point would be to gather opinions as just that -
opinions. We should not try to argue why we have different results.
I would just be interested to understand what others are thinking
and why. For this to work, people would have to send their opinion
statement to some trusted party who will collect them and post them
together after a week or so. This would help to get unbiased and
original opinions.

Not sure whether the result will really help - but it would at least 
an interesting approach to gather opinions and lines of reasoning while
we continue to wait to hear something from the evaluation team.

/js

-- 
Juergen Schoenwaelder		    International University Bremen
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany

---

From: Wes Hardaker <[email-masked]>
Date: Wed, 02 Feb 2005 11:56:15 -0800

>>>>> On Wed, 2 Feb 2005 20:47:32 +0100, Juergen Schoenwaelder <[email-masked]> said:

Juergen> The IETF generally does not vote and I think there are some good 
Juergen> reasons for this.

Vote was a poor choice of words, I agree.  My point was to figure out
if one or more of the proposals could be discarded due to consensus
not to head that direction.  As is, I have heard from a number of
people making arguments but I'm uncertain where the general consensus
lies because we've been arguing more for fundamental concepts and less
for a particular solution.  Given that we have to pick a solution, it
would seem worthwhile to select which of the options best incorporates
these features that are needed by the peopling doing the arguing.

-- 
Wes Hardaker
Sparta

---

From: Ken Hornstein <[email-masked]>
Date: Wed, 02 Feb 2005 15:27:42 -0500

>not to head that direction.

Okay, well, in the interest of moving forward .... I suggest that we
eliminate the TLS proposal from consideration.  Comments?

--Ken

---

From: "David B Harrington" <[email-masked]>
Date: Tue, 8 Feb 2005 18:08:12 -0500

Hi,

I made the suggestion to drop the TLS proposal at the last meeting.

I do have hesitations about discarding this proposal however. Here are
my thoughts.

Security is only as strong as its weakest link, and for device
management, there are multiple links - interactive CLI, CLI scripting,
web-based management (html/http), the emerging netconf, snmpv1,
snmpv2c, and snmpv3. To build one of these management interfaces to be
dramatically more secure than the others, without being able to fully
retire the others, simply makes that choice not the weakest link; it
doesn't help to balance the security across all the management
interfaces.

CLI and CLI scripting are frequently secured with SSH, and netconf
plans to utilize SSH as the preferred "application transport", so TLS
will be used to secure these interfaces. Web-based mgmt utilizes
HTTP/SSL (or TLS 1.0). Each of these approaches "outsources" the
message security to the transport layer, and supplements that with a
session-based user-authentication (for access control) at a higher
layer.

For the best integration of SNMP security with the security used for
other management interfaces, it would seem to make sense to also
"outsource" the message security to the transport layer, and then
supplement that with session-based user-authentication for access
control. Either EUSM or SBSM could be used to provide the
session-based user authentication for access control.

One of the charter goals is to "maximize useability in operational
environments to achieve high deployment success and at the same time
minimize implementation and deployment costs to minimize the time
until deployment is possible."

Utilizing the same security approaches for SNMP as are used for CLI,
CLI scripting, netconf, and web-based mgmt certainly eases the
operational and deployment costs, and given that the operators
indicated SSH as the preferred mechanism for netconf, I expect they
would also support deploying it for SNMP.

Utilizing the same security mechanisms that are already in the devices
in support of secure CLI, CLI scripting, and web-based mgmt helps to
minimize the implementation costs for vendors, and could minimize time
to deployment.

Of course, to utilize the same security mechanisms will require
supporting a TCP transport for SNMP, something already specified in
RFC 3430, or adding support for something similar to DTLS. To utilize
SSH user-authentication (both centralized and local) would require
adding an SNMP security model to leverage those. Again either EUSM or
SBSM might be able to be adapted to provide this.

I believe the long-term benefits of differentiating transport security
and access control security, and balancing the security across
management interfaces, would justify keeping the TLS approach on the
table.

David Harrington
[email-masked] 

> [mailto:[email-masked]] On Behalf Of Ken Hornstein
> Sent: Wednesday, February 02, 2005 3:28 PM
> To: [email-masked]