Subject: [Isms] Architectural issues

From: "David B Harrington" <[email-masked]>
Date: Wed, 24 Aug 2005 15:18:18 -0400

Hi,

I hate playing the heavy here, but as co-chair of the SNMPv3 WG,
co-author of RFC 3411 and RFC 3412, and a member of the SNMPv2 Design
Team whose job was to figure out how to salvage SNMPv2 and whose
proposal was to utilize this modular architecture as the solution, I
am very cognizent of what can happen if we ignore the architectural
boundaries, and cognizant of the intentions of the desigtners of
SNMPv3.

This WG contains many members from the SNMPv3 WG, and might choose to
override the architectural guidelines and applicability statements
provided by the SNMPv3 WG, assuming the area directors permit this,
but I believe that would be folly.

Recognize that I believe 
1) the SNMPv3 WG got the modularity right given the information they
had at the time; 
2) the SNMPv3 WG got the modularity wrong from the standpoint of
integration with how other security frameworks and the IETF AAA
framework would subsequently develop; 
3) the SNMPv3 WG got it right when they grouped authorization and
access control as part of a single subsystem (see RFC 3410) because
access control can be based on different approaches, not just group
membership;
4) the SNMPv3 WG got it wrong from the standpoint of integrating with
the subsequent approach of IETF AAA framework, which tends to group
authentication and authorization together.

I believe the RFC 341x architecture needs to be modified to allow
integration with existing security frameworks and existing
authorization frameworks (and will probably need more adjustments to
accommodate existing accounting frameworks to complete the AAA
picture).

We can make these adjustments in various ways. We can ignore the
existing RFC 3411 architecture and its underlying philosophy and
create dependencies between models in different subsystems; we can
ignore the existing architecture and simply move authorization from
the access control subsystem to the security subsystem and make VACM
the only access control model; we can define architectural extensions
that work to preserve the existing architecture as much as possible,
but work around some of the limitations of that existing architecture;
or we can scrap RFC 3411 and write a new architecture that better fits
our updated set of requirements.

I prefer the third approach, because it will, hopefully, not require
us to modify any existing SNMPv3 documents, and still make it possible
to integarte with existing external infrastructures.

David Harrington
[email-masked]
co-chair IETF SNMPv3 WG, concluded

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

---

From: Sam Hartman <[email-masked]>
Date: Thu, 25 Aug 2005 13:58:14 -0400

>>>>> "David" == David B Harrington <[email-masked]> writes:

    David> Hi, I hate playing the heavy here, but as co-chair of the
    David> SNMPv3 WG, 
As a point of information, is SNMPV3 still open?

    David> We can make these adjustments in various ways. We can
    David> ignore the existing RFC 3411 architecture and its
    David> underlying philosophy and create dependencies between
    David> models in different subsystems; we can ignore the existing
    David> architecture and simply move authorization from the access
    David> control subsystem to the security subsystem and make VACM
    David> the only access control model; we can define architectural
    David> extensions that work to preserve the existing architecture
    David> as much as possible, but work around some of the
    David> limitations of that existing architecture; or we can scrap
    David> RFC 3411 and write a new architecture that better fits our
    David> updated set of requirements.

    David> I prefer the third approach, because it will, hopefully,
    David> not require us to modify any existing SNMPv3 documents, and
    David> still make it possible to integarte with existing external
    David> infrastructures.

Do you see anyone arguing for other than the third approach?

--Sam

---

From: "David B Harrington" <[email-masked]>
Date: Thu, 25 Aug 2005 15:16:15 -0400

Hi Sam,

> As a point of information, is SNMPV3 still open?

The SNMPv3 WG has concluded. 
(Sorry, I usually include that when referencing the co-chair
position.)

> Do you see anyone arguing for other than the third approach?

Yes, I see some (quasi-) proposals that seem to play very loosely with
the architecture.

I would like to see some of the proposals presented in a more
fully-baked fashion, including discussion of how it fits into the
architecture, so we can see more clearly whether they abide by the
existing architecture or not.

David Harrington
[email-masked]