Subject: RE: [Isms] Discussion: Architecture direction for ISMS

From: "Martin Soukup" <[email-masked]>
Date: Tue, 12 Apr 2005 23:11:27 -0400

We would need to work through the effort involved in each implementation to
judge which is more easily implementable, but I'm not sure that's possible
at the abstract level of "should we use OOBK, IBK, or EBK". Are there any
arguments that show there is a significant difference in implementation of
these architectures that we can all agree on? I doubt it, since I think OOBK
is the cheapest to implement and others on the list obviously differ in
opinion. Would it be useful to break down what the major elements of
implementation would be for each approach and lay them out for comparison?

Martin.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of David T. Perkins
> Sent: April 12, 2005 4:32 PM
> To: Chisholm, Sharon [CAR:5K50:EXCH]
> Cc: [email-masked]
> Subject: RE: [Isms] Discussion: Architecture direction for ISMS
> 
> HI,
> 
> Working code is a tradition in the IETF.
> 
> You haven't provided any costs and benefits
> with using one architecture approach over
> another.
> 
> What I'm suggesting is a validation of the
> consequences of each approach. How would
> you do this? I'm open to any approach that
> addresses the problem of driving the
> deployment (initial installation and
> ongoing operational cost) of a secure
> SNMP to a low enough number so that
> it will be cost effective to use.
> 
> Please provide an actionable approach
> that will provide some insights with
> a reasonable amount of certainty.
> 
> Again....
> > I've been doing some serious work on SNMPv3 for the last
> > few months, and have had many meetings with the developers
> > from the network management group, and with the security developers.
> > SNMPv3 USM is quite difficult to understand, and email doesn't
> > provide an effective medium for communication. Packet dumps,
> > working code, multiple screens with the RFCs are tools that
> > are needed to make progress.
> 
> Regards,
> /david t. perkins
> 
> On Tue, 12 Apr 2005, Sharon Chisholm wrote:
> > hi
> >
> > Somehow using a code inspection to determine the correct architecture
> seems
> > very wrong to me.
> >
> > Sharon
> >
> > -----Original Message-----
> > From: David T. Perkins [mailto:[email-masked]]
> > Sent: Tuesday, April 05, 2005 3:49 PM
> > To: Chisholm, Sharon [CAR:5K50:EXCH]
> > Cc: [email-masked]
> > Subject: RE: [Isms] Discussion: Architecture direction for ISMS
> >
> >
> > HI,
> >
> > Lets set up a conference call to talk this through.
> >
> > Wes knows the internals of NET-SNMP. I've been going through the SNMP
> > Research code. Hopefully we can get some other developers with knowledge
> of
> > other SNMP stacks together to work this out.
> >
> > And if any developers that are using the SNMP Research stack want to
> talk to
> > me about details, I'm open to setting up a private conversation. Send me
> > email. (I cannot talk in detail about the code, since it is covered by a
> > non-disclosure agreement, unless the other person is also covered by the
> > non-disclosure agreement.)
> >
> > I would certainly appreciate talking with the SNMP developers at Nortel.
> Let
> > me know a time and a place, and I'll try to come visit for a day or two.
> > Likewise, if anyone else wants to have a developer to developer talk,
> please
> > contact me.
> >
> > I've been doing some serious work on SNMPv3 for the last
> > few months, and have had many meetings with the developers
> > from the network management group, and with the security developers.
> SNMPv3
> > USM is quite difficult to understand, and email doesn't provide an
> effective
> > medium for communication. Packet dumps, working code, multiple screens
> with
> > the RFCs are tools that are needed to make progress.
> >
> > On Tue, 5 Apr 2005, Sharon Chisholm wrote:
> > > <Wes>
> > >
> > > As do I.  Specifically, I think Robert's ordering of requirements
> > > matches mine.  In-band first, and encapsulated being a second choice.
> > > As I've mentioned in multiple other messages, there are a large number
> > > of issues with out-of-band keying that makes implementation difficult.
> > > I suspect Sharon must not agree with any of those other points? </Wes>
> > >
> > > No, not really. After our discussion in Minneapolis where you
> > > mentioned the fact that you felt separate key management would be
> > > impossible to implement in net-snmp, I went back and talked to some
> > > more SNMPv3 implementers to get their view of implementing eUSM and
> > > although they observed there were some missing elements of procedure,
> > > they saw nothing that they felt would cause implementation problems.
> > >
> > > I'm a big fan of modular architectures. It allows you to add
> > > functionality as you need it and to ensures a good return in
> > > investment when looking to add new features. Yes, there are points
> > > where having too many separate modules to worry about starts to cost
> > > more than it saves and then you look at combining things together to
> > > get some improvements. I don't think we are there in this particular
> > > case.
> > >
> > > Sharon
> >
> > Regards,
> > /david t. perkins
> >
> >
> >
> > _______________________________________________
> > Isms mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/isms
> >
> 
> 
> _______________________________________________
> 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: "Randy Presuhn" <[email-masked]>
Date: Tue, 12 Apr 2005 20:25:18 -0700

Hi -

> From: "Martin Soukup" <[email-masked]>
> To: "'David T. Perkins'" <[email-masked]>; "Sharon Chisholm" <[email-masked]>
> Cc: <[email-masked]>
> Sent: Tuesday, April 12, 2005 8:11 PM

> at the abstract level of "should we use OOBK, IBK, or EBK". Are there any
...

I would think that using existing USM keying (whether you think of it as
OOBK or IBK) is the most easily implementable, since the infrastructure is
already in place at both ends.  The question is how to provide a mechanism
for key expiry on termination of a session.  One obvious solutions are an update
to the usm user entry using SNMPv3, the other is to AUGMENT the usm user
table with an expiration date / timer.  Alternatively one could use RFC 2786,
again augmenting the usm user table with a key expiry mechanism in order to
avoid changing the protocol by adding an explicit session termination.

Randy

---

From: "David T. Perkins" <[email-masked]>
Date: Wed, 13 Apr 2005 10:26:59 -0700 (PDT)

HI,

The word "implement" has different meanings. I can't tell
whether you mean the cost of designing, coding, testing, etc
to get the technology into products, or do you mean the cost
to deploy (initial install and on-going operations) products
containing the technology.

Would you clarify.

Thanks,
/david t. perkins

---

From: "David T. Perkins" <[email-masked]>
Date: Wed, 13 Apr 2005 10:34:44 -0700 (PDT)

HI,

My observation, and assumption is that the SNMP MIB objects
defined in the 3rd SNMP framework for configuration (especially
for user identity) are not being used. Thus, I see little
motivation to "save" them. 

In the systems that I recently reviewed, and the system that
I'm finishing up for delivery, NONE of the SNMP administrative
MIB objects for configuration are being made available.
There are many reasons.

This may be a world changing view. Ultimately the markets will
decide. And so far, there have little call by the markets
for SNMPv3 administration via SNMPv3.

Regards,
/david t. perkins