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

From: Sam Hartman <[email-masked]>
Date: Tue, 12 Apr 2005 16:22:24 -0400

>>>>> "Robert" == Robert Story <[email-masked]> writes:

    Robert> On Fri, 18 Mar 2005 17:26:22 -0800 (PST) David wrote:
    DTP> On Fri, 18 Mar 2005, Ken Hornstein wrote: > - "Encapsulation
    DTP> keying"
    DTP> > 
    DTP> > This is the approach taken by TLSM.  An encapsulation
    DTP> protocol (such > as TLS) is used to "wrap" SNMP payloads.

    DTP> 2) Setting up sessions for delivering notifications.

    Robert> Speaking of notifications, isn't there an issue with the
    Robert> transport approach and notifications? Doesn't net-conf
    Robert> suffer from this issue? Specifically, sending a
    Robert> notification when the notification destination doesn't
    Robert> have an existing open session with the notification
    Robert> generator.

Why is this true?  If all engines have credentials they can use, why can't you open a session if you need one?

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

---

From: Eliot Lear <[email-masked]>
Date: Wed, 13 Apr 2005 09:06:08 +0200

Notification destinations are configured in advance, and so a TCP or 
SCTP connection in advance doesn't seem like a large price to pay.  In 
fact, you probably want to do this so that you can detect configuration 
errors BEFORE the notification is necessary.

Eliot

---

From: Robert Story <[email-masked]>
Date: Wed, 13 Apr 2005 07:52:26 -0400

On Wed, 13 Apr 2005 09:06:08 +0200 Eliot wrote:
EL> Notification destinations are configured in advance, and so a TCP or 
EL> SCTP connection in advance doesn't seem like a large price to pay.

It does if you are monitoring 100,000 devices. That's a lot of open connections
so that some (probably) relatively small number of devices can send
notifications.

EL> In fact, you probably want to do this so that you can detect configuration
EL> errors BEFORE the notification is necessary.

Setting up a temporary session to establish that a manager is there is a nice
optional feature that vendors could provide, but it certainly shouldn't be
required.

---

From: Robert Story <[email-masked]>
Date: Wed, 13 Apr 2005 08:14:21 -0400

On Tue, 12 Apr 2005 16:22:24 -0400 Sam wrote:
SH> Why is this true?  If all engines have credentials they can use, why can't
SH> you open a session if you need one?

My concern was was with regards to fitting into an existing infrastructure
where unsolicited communication was not the norm. I use ssh as an example,
because I am not familiar with TLS. While a ssh session does establish a key
for the peer host, additional configuration would be needed to allow that peer
to autonomously establish connections back to the originator's host.

With one of the goals of ISMS being re-use of existing infrastructure, I was
just thinking that for some infrastructures (eg ssh), get and set would easily
fit, but notifications would require more thinking.

---

From: "David B Harrington" <[email-masked]>
Date: Wed, 13 Apr 2005 09:40:31 -0400

A GET-request is an unsolicited communication; only the response is
solicited. 

Netconf chose a model akin to SNMPv1's architecure, where one entity
is always the manager and the other is always the agent. The manager
is always allowed to initiate unsolicited communications to the agent.
It complicates the paradigm when it is necessary for the agent to send
an unsolicited message to the manager. 

The SNMPv3 architecture has been designed as an environment of peer
entities that happen to provide certain types of services. Both sides
of a relationship should be able to send unsolicited messages, e.g.
informs, if the two sides support the corresponding services. SNMPv3
allows a single entity to support  services to a)generate and
b)receive and c)respond to unsolicited communications. 

I think TLS fits the peer-to-peer approach. I agree that the SSH
architecture might be slightly more problematic establishing a two-way
relationship between peers.

David Harrington
[email-masked]

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Robert Story
> Sent: Wednesday, April 13, 2005 8:14 AM
> To: Sam Hartman
> Cc: [email-masked]
> Subject: Re: [Isms] Discussion: Architecture direction for ISMS
>

---

From: Eliot Lear <[email-masked]>
Date: Wed, 13 Apr 2005 16:18:30 +0200

> so that some (probably) relatively small number of devices can send

In the configuration you discuss, sure.  Would I in general advise such 
a configuration?  No.  For one thing, what if the trigger for the event 
is network-wide?  In that case you better be able to handle 100,000 
events on very short order.  Want to do that one one device?  YMMV.  I 
don't, however, want to engineer for an extreme corner case.

> optional feature that vendors could provide, but it certainly shouldn't be

Nothing stopping you from establishing a connection on demand.  Also 
nothing stopping someone from using existing UDP mechanisms.  It's not 
as if they're going away.

Eliot

---

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

HI,

I disagree with your characterization of SNMPv3. SNMP engines
do not have authenticated identifies. 

I'll explain further in another message.

/david t. perkins

---

From: "David B Harrington" <[email-masked]>
Date: Wed, 13 Apr 2005 16:19:52 -0400

Hi David,

When you decide to post your explanation, please indictae where in my
message you think I characterized SNMPv3 as having engines with
authenticated identities. I have read and reread what I said, and I
don't see that I ever said that.

dbh

> From: David T. Perkins [mailto:[email-masked]] 
> Sent: Wednesday, April 13, 2005 3:09 PM
> To: David B Harrington
> Cc: 'Robert Story'; 'Sam Hartman'; [email-masked]
> Subject: RE: [Isms] Discussion: Architecture direction for ISMS
> 
> HI,
>

---

From: Sam Hartman <[email-masked]>
Date: Wed, 13 Apr 2005 20:52:03 -0400

>>>>> "Robert" == Robert Story <[email-masked]> writes:

    Robert> On Tue, 12 Apr 2005 16:22:24 -0400 Sam wrote:
    SH> Why is this true?  If all engines have credentials they can
    SH> use, why can't you open a session if you need one?

    Robert> My concern was was with regards to fitting into an
    Robert> existing infrastructure where unsolicited communication
    Robert> was not the norm. I use ssh as an example, because I am
    Robert> not familiar with TLS. While a ssh session does establish
    Robert> a key for the peer host, additional configuration would be
    Robert> needed to allow that peer to autonomously establish
    Robert> connections back to the originator's host.

Why do you need to use the same key.  SNMP is symmetric; have two
sessions one from a to be and one from b to a.  The only requirement
is that both a and b have credentials.

That's often true for ssh if you have both a server and client
implementation available.

---

From: Sam Hartman <[email-masked]>
Date: Wed, 13 Apr 2005 20:57:26 -0400

>>>>> "David" == David T Perkins <[email-masked]> writes:

    David> HI, I disagree with your characterization of SNMPv3. SNMP
    David> engines do not have authenticated identifies.

    David> I'll explain further in another message.

As I understand it, I think we're trying to allow SNMP engines to
communicate securely using existing credentials in an existing
infrastructure.  Please correct me if this understanding is wrong; it
is fairly fundamental to my thinking in this WG.

As such, by the time we're done, it seems reasonable to expect that
SNMP engines using ISMS w will clearly know what set of credentials
they are using.  Associated with all the IETF security credentials I'm
familiar with is an authenticated identity.  Sometimes this identity
is implicit or tautological (for example the identity of a raw public
key is often that key), but it does exist.

--Sam

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 13 Apr 2005 18:12:42 -0700

Hi -

> From: "Sam Hartman" <[email-masked]>
> To: "David T. Perkins" <[email-masked]>
> Cc: <[email-masked]>
> Sent: Wednesday, April 13, 2005 5:57 PM
...
> is fairly fundamental to my thinking in this WG.

The communication is between SNMP applications on behalf of users.
The SNMP engine is just the machine that does the work on their behalf.

> key is often that key), but it does exist.

Those credentials are (at least in USM) those of the users, not of the
engines per se.

Randy

---

From: "David T. Perkins" <[email-masked]>
Date: Thu, 14 Apr 2005 09:37:27 -0700 (PDT)

HI Sam,

The theoretical properties and the actual deployment properties
are different. I believe, that most people are not getting this is
the fundamental cause for the major disagreements in this WG.

First, it is difficult to make sweeping statements about all
usage of SNMP technology. Dedicated purpose (and closed) network
infrastructure devices such as routers and switches are
quite different from workstations. Even routers vary
quite a bit from those that cost around $100 to ones
that are in the $1000s to those in the $10,000s.

What Wes and I have done is look at each major class of device
to determine what type of security mechanisms are used.
Likewise, we have looked at systems that run management
applications such as generic programs (MIB browsers), 
task specific programs (has builtin semantic knowledge of
the management info), and notification receivers to
determine what security mechanisms are in use.

So, one can say that in theory, for example, that both
ends of an SNMP communication path will be using X.509
certs, but in practice, this scenario would be rare.

Switching topics...
The introduction to the architecture using SNMP engines
was done to make SNMP easier to understand. I don't believe
that this was the case. Again, SNMP engines themselves
don't have an authenticated identity. SNMP engines
are like a library for SNMP applications, which have
an associated security principle. 

I'm sorry that I cannot finish this now, some unplanned
events have occured that I must take care of.

I do hope that this short message has helped.

> key is often that key), but it does exist.
Regards,
/david t. perkins

---

From: Wes Hardaker <[email-masked]>
Date: Thu, 14 Apr 2005 09:49:17 -0700

>>>>> On Wed, 13 Apr 2005 20:57:26 -0400, Sam Hartman <[email-masked]> said:

Sam> As I understand it, I think we're trying to allow SNMP engines to
Sam> communicate securely using existing credentials in an existing
Sam> infrastructure.  Please correct me if this understanding is wrong; it
Sam> is fairly fundamental to my thinking in this WG.

Yes, that's exactly what we're supposed to be doing.  You've obviously
read the charter because you nicely summarized most of it.  People
keep getting distracted by other topics which are, in fact, important
and even related.

In the end, and David P. has said this well many times, the goal
should be to reduce to as near-zero as possible the amount of work and
knowledge that an operator needs to make SNMP work for them.

-- 
Wes Hardaker
Sparta, Inc.