On 2018/02/07 11:23, Martin Pieuchot wrote:
> On 07/02/18(Wed) 01:37, Reyk Floeter wrote:
> > 
> > >> Am 02.01.2018 um 15:23 schrieb Martin Pieuchot <m...@openbsd.org>:
> > >> 
> > >>> On 19/12/17(Tue) 18:06, Marco Pfatschbacher wrote:
> > >>> On Tue, Dec 19, 2017 at 12:43:48PM +0100, Martin Pieuchot wrote:
> > >>> I'd like to see some information about my tunnels in my NMS.
> > >> 
> > >> Nice. I would find that very useful :)
> > >> 
> > >>> The problem is that there's not standard MIB for this and most vendor
> > >>> MIBs are huge and are not easy to implement.
> > >> 
> > >> What about https://tools.ietf.org/html/rfc4807 ?
> > > 
> > > This MIB is about the "Policy Database Configuration" which, as far as I
> > > understand, would be useful to export the content of isakmpd.policy(5).
> > 
> > The Security Policy Database has nothing to do with isakmpd.policy or 
> > keynote.
> 
> You forgot the word "Configuration".  Here's what the RFC abstract says:
> 
>   "This document defines a Structure of Management Information Version 2
>    (SMIv2) Management Information Base (MIB) module for configuring the
>    security policy database of a device implementing the IPsec protocol."
> 
> > SPD is the standard term for what we call, for historic reasons, flows. In 
> > other words: an IPsec flow in OpenBSD is an IPsec policy in other operating 
> > systems.
> > 
> > So RFC 4807 might be the right thing after all.
> 
> I doubt it is, but I'm might have read the RFC differently than you did.
> 

I haven't dug into the extensions mentioned
("
   This MIB is structured to allow for reuse through the future creation
   of extension tables that provide additional filters and/or actions.
   In fact, the companion documents to this one ([IPsec-ACTION] and
   [IKE-ACTION]) do just that and define IPsec- and IKE-specific actions
   to be used within this SPD configuration MIB. 
")
but from what I've read of 4807 it really looks more like something
intended for people using SNMP to set and display configuration (which
I think the world has _mostly_ moved on from now in favour of simpler
mechanisms..), rather than using it to monitor current activity.
And the actual parts included directly in 4807 itself look more like
firewall rule setting (drop, accept) than anything which looks like
our flows or keynote.

It's not uncommon with SNMP for the committee-specified MIBs to be
quite overcomplicated and a poor match to any particular implementation
(they often seem to try to please everyone and not really managing
to please anyone) so it's not really a surprise that outside a few
of the older areas, pretty much everyone just makes up their own.
An example of this from a different area. You'd imagine it would be
pretty straightforward to report sensor temperatures. The standard
temperature/sensor mib (ENTITY-SENSOR-MIB) depends on ENTITY-MIB
which needs fairly deep knowledge of the hardware platform and is
all very complicated. So in the real world this is what we have:

$ grep -Rli temperature /var/www/librenms/mibs | wc -l
     331

Of course it's worth investigating to see if some standard can be
used. But it's often not the case. For practical use unless there's
something which is a pretty close fit already, the only useful
options are to emulate a popular vendor (-> more likely to be
handled by NMS), or DIY (will need work to handle, but at least
you get sane data without having to squeeze it into a different
shaped box)..

Reply via email to