(unknown)

[192.94.214.100])
	by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i8NHNXd10747
	for <[email protected]>; Thu, 23 Sep 2004 13:23:33 -0400 (EDT)
(V6.0)
	id srcAAADtaa72; Thu, 23 Sep 04 13:24:54 -0400
Date: Thu, 23 Sep 2004 20:27:05 +0300 (EEST)
From: Pekka Savola <[email protected]>
To: "McDonald, Ira" <[email protected]>
cc: David B Harrington <[email protected]>, <[email protected]>,
    <[email protected]>
Subject: RE: [Isms] Why SNMPv3? [WG Review: Integrated Security Model for
  SNMP (isms)]
In-Reply-To: 
<CFEE79A465B35C4385389BA5866BEDF00C78DA@mailsrvnt02.enet.sharplabs.com>
Message-ID: <[email protected]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [email protected]
Precedence: bulk

I agree that this may be a partially useless discussion, but hopefully
it would help in ensuring that the applicability of different SNMP
management techniques remains to be clearly spelled out..

Combining two messages.

On Thu, 23 Sep 2004, McDonald, Ira wrote:
 > SNMPv1 read-only still allows anyone INSIDE your network to
 > monitor and read interesting configuration and event info
 > from your routers by packet-sniffing.

Certainly, but you can do a lot of things if you're able to sniff the
packets (practically requiring a physical man-in-the-middle attack or
the like :), including over 99% of all traffic.  If an attacker is
able to do that, I would be surprised if the read-only information of
the routers was all that interesting in comparison.

 > And your "direct" connection to your outside network manager
 > had better be entirely non-Internet (or completely encrypted)
 > if you want reasonable security and also availability for
 > their network management functionality.

It's, as said, "direct" in the sense that it isn't routed over the
Internet.

 >From David Perkins:
 > Do you use syslog? Are you dissatisfied with it? Do you know it's
 > limitations?
 >
 > If you answsered "yes" to any of the above, then I believe that
 > SNMPv3/SBSM will provide you great benefit.

Yes. Works for 95% but there are some issues.  At least some of them.

The biggest issue is the unreliability of the transport, i.e., when
link goes down, the syslog message may end up being lost.  In future,
it might also be useful to provide more finer-grained manage what
information to send and where.

 > In SNMPv3/USM, the mechanisms for administering notifications
 > was, I believe pretty horrible. However, I believe that using
 > SNMPv3/SBSM with a little work on the MIB modules for notification
 > targets and loggings, then we will have a real winner.
 >
 > And, all of the below I believe, but I also believe that with
 > SNMPv3/SBSM it will be even easier to deploy a new system than
 > what is required for SNMPv1 and SNMPv2c.

Traps/notification is indeed an area of interesting potential.
However, it is still not clear what kind of authentication is required
there, in the case you can filter out bogus traps based on the IP
address.  The greatest advantages seem to be a reliable transport,
better specification of which notifications to send and to where, and
more advanced means of de-multiplexing the notifications to different
watcher processes, but I would be surprised if this wasn't doable
already (compare to e.g. demux capabilities of syslog-ng).

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings