Subject: Re: [Isms] [OPS-DIR] SNMP notification configuration

From: "David Harrington" <[email-masked]>
Date: Mon, 2 Jun 2008 13:34:33 -0400

> -----Original Message-----
> From: Phil Shafer [mailto:[email-masked]] 
> Sent: Monday, June 02, 2008 11:10 AM
> To: David Harrington
> Cc: [email-masked]; 'OPS Area'
> Subject: Re: [OPS-DIR] SNMP notification configuration 
> 
> "David Harrington" writes:
> >For SNMP notifications, the SNMP agent will need to act as an SSH
> >client, and the SNMP notification receivers will need to act 
> as an SSH
> >server. Will operators find this objectionable?
> 
> This would require a password/passphrase for an account on the
> management station to be included in the device configuration,
> right?  Many operators will find this objectionable, though one can
> make the ssh equivalent on an "anonymous ftp user" will a little
> effort.  Reachability via firewall (and nat) is also an issue.

Yes, we know that NATs can be problematic. Hopefully someday the IETF
will figure out how to make NATs less of a problem.

> 
> >Question #2:
> >Would operators prefer to modify their existing user and key
> >management solutions, such as implementation-dependent CLI 
> scripts, to
> >configure SSH clients on devices where they may not be found now,
or
> >would operators prefer to have the ISMS WG develop a standard MIB
> >module to configure and manage the SSH credentials needed to 
> have SNMP
> >agents act as SSH clients?
> 
> There are few real-world deployment scenarios for MIBs for config
> (unless forced) and the big motivation for using ssh is that the
> infrastructure is already deployed.  So my take is that no one needs
> or will use a writable MIB for ssh credentials.

Remeber that operators will need to configure the SNMP agents to send
notifications, and we have standard MIBs to do that configuration.
Lacking the ability to also configure the SSH client credebtials via
SNMP means thay must use multiple management interfaces to config SNMP
notifications (or not use the SNMPv3 standard MIBs for notifications).
> 
> Another question:  Given that NETCONF includes ssh-as-transport and
> now has a notification mechanism, would snmp-over-netconf work
> better than snmp-over-ssh?  

It doubt snmp-over-netconf would meet most operators' needs for SNMP
notifications. 

SNMP supports asynchronous notifications. The agent initiates the
session when an event occurs. This may occur at any time, and the
manager (or notification-receiver) is expected to be listening (more
or less) all the time. This is like having your phone ring when
somebody calls you.

One benefit of this approach is trap-directed-polling, The agent can
notify the manager that an event has occured, and the manager can then
poll for additional information to determine the nature and importance
of the event. I think this is like using an answering machine to
screen calls - it tells you who is calling, and maybe what they called
about, but you would pick up or call back to get all the details when
you're ready to handle the details.

Netconf uses a subscribe approach. The client (manager) initiates the
session over which the server (agent) will deliver notifications. The
notifications can only be delivered if a manager has subscribed and
the manager asks for a replay of the notifications it missed while not
subscribed, or kept the session open to listen for new notifications.
I think of this as polling-directed-traps. I think this is like
calling your voicemail to see who called while you weren't home, or
calling all your friends to open a long-term phone connection to each
in case they want to talk to you later.

SNMP notifications have traditionally been close-to-real-time and
scalable. I think netconf notifications are great for interactive
configuration work. I don't think the netconf subscribe approach is
scalable to managing large networks. 

dbh

> Thanks,
>  Phil

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

---

From: Phil Shafer <[email-masked]>
Date: Tue, 03 Jun 2008 10:34:22 -0400

>scalable to managing large networks. 

The difference is much smaller, I think.  SNMP sends async notifications
based on content descriptions set in (typically) configuration.
NETCONF sends async notifications based on content descriptions
given in client subscriptions.  Once set, both styles send notifications
when event happen.  The action of the snmp agent and the netconf
agent are completly similar.

The major difference is that NETCONF requires the manager establish
a connection beforehand, where SNMP sends notifications without
regard to the manager.  The real cost is that a manager needs to
have connections up and running to each managed device.  The cost
for the agent is a connection (one per manager) which is negligible.

Thanks,
 Phil

---

From: "David Harrington" <[email-masked]>
Date: Tue, 3 Jun 2008 11:59:31 -0400

Hi, 

comments inline, and a request for additional feedback from operators.

> Sent: Tuesday, June 03, 2008 10:34 AM
> To: David Harrington
> Cc: [email-masked]; 'OPS Area'; [email-masked]
> regard to the manager.  

SNMP can send notifications when an event happens, without having to
wait for a manager to initiate a connection first. This distinction
can be important, especially during startup. As SNMP moves from a UDP
transport to an SSH transport, an entity-to-entity connection will
need to be initiated before the notification can be sent, so the fact
that a connection must be instantiated first might become less
important. The distinction of WHO must initiates the connection first
might become more important because of NATs.

> The real cost is that a manager needs to

These costs probably are similar between netconf/SSH and SNMP/SSH.

So, in ISMS terms, would operators find it acceptable if SNMP adopted
a "manager must subscribe to get notifications (with replay
capability)" similar to the netconf notification protocol approach,
when using SNMP over a secure transport layer like SSH or TLS? 

Using a manager-must-subscribe mechanism would eliminate the need for
having the agent establish the SSH connection.

The ISMS WG could consider using the same notification protocol design
as netconf. This could be done by 
1) using a MIB extension to the TARGET-MIB, EVENT-MIB, et. al.,
requiring a manager to use SNMP SETs to create subscriptions similar
to that of the netconf notification protocol. Notifications would be
buffered, possibly using the NOTIFICATION-LOG-MIB, just as with
netconf notifications. or 
2) not sending SNMP notifications over secure transports, but rather
requiring support for the netconf notification protocol in all SNMP
agents and managers that support SNMP/secure-transport, so managers
would need to use netconf to get the notifications. SNMP would
presumably continue to support its existing notification model,
requiring no subscription (but still requring pre-configuration), when
used over UDP. or
3) we could define a new SNMP operation to create a subscription
comparable to the netconf notification protocol.

The second and third approaches seem to be totally out of scope of the
ISMS WG charter, but if they would be better solutions, we could
presumably re-charter. 

(Once we get some operator feedback, we can take this discussion off
the OPS lists and return to detailed engineering discussions in the
ISMS WG. ;-)

David Harrington
[email-masked]
[email-masked]
[email-masked]

---

From: "David Harrington" <[email-masked]>
Date: Tue, 3 Jun 2008 12:40:06 -0400

As an SNMP "old dog", I have been indoctrinated with many assumptions
that were true in the 80s, but might be less true now. Startup keeps
getting smaller as a percentage of overall uptime; notifications may
not be as desirable during startup as they once were; UDP may not be
any more reliable than TCP for getting through broken networks, and so
on.

The ISMS WG is trying to make sure we don't change the basic
assumptions of how SNMP works, but we occasionally need to question
whether certain old assumptions are still valid.

dbh

> Sent: Tuesday, June 03, 2008 12:20 PM
> To: David Harrington
> >can be important, especially during startup.
> 
> Sure, but in practice, startup is a painful time to send 
> notifications,
> since the delays of interface bringup and learning routes may mean
> your manager is unreachable.  Waiting for a connection turns out
> to be more useful than firing off packets into nowhere.
> 
> Thanks,
>  Phil
>

---

From: "Randy Presuhn" <[email-masked]>
Date: Tue, 3 Jun 2008 11:40:52 -0700

Hi -

> From: "David Harrington" <[email-masked]>
> To: "'Phil Shafer'" <[email-masked]>
> Cc: <[email-masked]>; <[email-masked]>; "'OPS Area'" <[email-masked]>
> Sent: Tuesday, June 03, 2008 8:59 AM
> Subject: Re: [Isms] [OPS-DIR] SNMP notification configuration
...
> netconf notifications. or 

I'm no operator, but...

For this solution, *no* extensions are needed.  The log mib is already
designed for this scenario.  Yes, the manager would need to query the
MIB to gather the notification payloads.  However, I think this may be
a feature rather than a bug.  If we're going to start talking about replaying
those notifications, we'd then need to limit that replay to transports with
appropriate congestion avoidance built in.  I think it's simpler to just use
the existing MIBs to do what they were designed to do.

Randy

---

From: Phil Shafer <[email-masked]>
Date: Tue, 03 Jun 2008 12:19:38 -0400

>can be important, especially during startup.

Sure, but in practice, startup is a painful time to send notifications,
since the delays of interface bringup and learning routes may mean
your manager is unreachable.  Waiting for a connection turns out
to be more useful than firing off packets into nowhere.

Thanks,
 Phil

---

From: Phil Shafer <[email-masked]>
Date: Tue, 03 Jun 2008 13:34:54 -0400

>whether certain old assumptions are still valid.

Sure, and I'm not out to make trouble, just wondering
about cost/benefit tradeoffs.

Thanks,
 Phil

---

From: Pekka Savola <[email-masked]>
Date: Thu, 5 Jun 2008 22:05:28 +0300 (EEST)

> to be more useful than firing off packets into nowhere.

FWIW my take on this is:

We (our network) are happy enough with SNMP traps over UDP from the 
security (confidentiality etc.) perspective.  I realize that some 
other operators, especially if their borders are not easily definable 
or have equipment all over the globe without virtual management 
interfaces (through tunnels etc.) may have a different perspective.

The main problem with SNMP traps, syslog, etc. is that when a system 
reboots or a line goes down, they get lost.  If the amount of loss is 
infrequent (every event does not cause loss), you can live with it as 
long as you can verify the correct operations using other, reliable 
means.  On the other hand, if every event caused significant loss of 
information, the manual procedures would become more burdensome and 
you would need to use a different management model (e.g. almost 
exclusively polling based) to get the job done.

This is to say that traps/notifications over TCP is not to _us_ very 
interesting if it doesn't also do something else -- i.e. make 
practically certain that all traps/notifications will in fact be 
delivered.

If we examine how unreliable syslog can be made to work we may learn 
something for other protocols.

Mostly unreliable syslog is fine.  Some implementations AFAIK buffer 
syslog data and don't send it if there is no route to the destination. 
That helps a bit but not much if you're using default routes your 
network.  But because syslog is also stored locally, you can either 1) 
go check the local syslog manually if in doubt, or 2) configure 
scripts to pull in devices' local syslog automatically after certain 
kinds of events to ensure that the syslog data you have should be 
complete.

That makes me think that (unless this is already being done) an SNMP 
agent should also store traps/notifications locally at least for the 
duration of O(days), and that a management system could poll them 
after the fact to synchronize notification "state".

-- 
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://www.ietf.org/mailman/listinfo/isms

---

From: "David Harrington" <[email-masked]>
Date: Fri, 6 Jun 2008 12:01:54 -0400

Hi,

RFC3014 "Notification Log MIB" provides a pollable log of SNMP traps,
and statistics that could be checked to see if the manager and agent
are in sync.

The Notification Log MIB also allows for aggregators, so all
trap-generation devices do not need to keep historical logs; the
Notification Log MIB can be implemented in a node that has greater
storage capacity.

If ISMS adopts a subscription-style approach, we could recommend or
require the Notification Log MIB be used as the buffering and replay
mechanism using a polling approach.

dbh

> From: Pekka Savola [mailto:[email-masked]] 
> Sent: Thursday, June 05, 2008 3:05 PM
> To: Phil Shafer
> Cc: David Harrington; [email-masked]; [email-masked]; 'OPS Area'