Subject: RE: [Isms] Why SNMPv3? [WG Review: Integrated Security Model for SNMP (isms)]

From: "McDonald, Ira" <[email-masked]>
Date: Thu, 23 Sep 2004 08:18:51 -0700

Hi Pekka,

SNMPv1 read-only still allows anyone INSIDE your network to
monitor and read interesting configuration and event info
from your routers by packet-sniffing.

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.

I'd say secure SNMPv3 has a lot to offer in your network.

Cheers,
- Ira

Ira McDonald (Musician / Software Architect)
Blue Roof Music / High North Inc
PO Box 221  Grand Marais, MI  49839
phone: +1-906-494-2434
email: [email-masked]

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On
Behalf Of Pekka Savola
Sent: Thursday, September 23, 2004 12:51 AM
To: David B Harrington
Cc: [email-masked]; [email-masked]
Subject: RE: [Isms] Why SNMPv3? [WG Review: Integrated Security Model
for SNMP (isms)]

<...snip...>

Let's consider our particular case (a national research network).  I
guess it should be quite common.

 1) we only use SNMP for read-only access.
 2) we only use SNMP to the routers from (about) two network 
management hosts within our own network.
 2.b) there is one external host from a network monitoring 
organization, using separate [direct] connectivity, which has the same 
RO privileges
 3) we restrict the access to the SNMP port [in all the routers] to 
the IP addresses of the network management.
 4) we eliminate IP spoofing of the network management host addresses
(actually all the addresses, but that's beside the point) at the edge.

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

_______________________________________________
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: Pekka Savola <[email-masked]>
Date: Thu, 23 Sep 2004 20:27:05 +0300 (EEST)

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.

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

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