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