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

From: "Sharon Chisholm" <[email-masked]>
Date: Tue, 12 Apr 2005 10:14:45 -0400

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

---

From: "David T. Perkins" <[email-masked]>
Date: Tue, 12 Apr 2005 13:31:47 -0700 (PDT)

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....
> 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