[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: IPSec MIB

In message <199704092148.RAA00302@alisan.ibm.net>, Uri Blumenthal writes:
>
>	- a list of SPIs with the parameter values
>	  might be helpful;

Absolutely. Three implementations right now use the kernfs/procfs
interface for this.

>	- a list of the hashes of the keys in use
>	  might assist in debugging;

I'll point out that this allows for exhaustive search.

>	- some counters (number of rekeys, number of
>	  bad auth, garbled crypto, etc.) could be
>	  of some use;

Yes. Two implementations use the netstat mechanism to display such
information.

>Knobs/buttons:
>	- enforce rekey now;
>	- control of various windows and timeouts (make
>	  'em narrower or wider);
>	- enabling/disabling certain algorithms (that
>	  could be then used in the negotiations);
>	- enabling/disabling certain modes (i.e. from now
>	  on only encrypting SA can be negotiated);
>	- set certain parameters (length of something...?);
>	- again, anything else?

I'd argue against *setting* anything. This is best done through the
key management daemon and policy engine. SNMP would complicate matters.

>If this MIB is to be useful and not just a placeholder
>(like too many of the existing MIBs) - please give us
>your input.

This however is a very critical MIB. I'm not sure whether setting
IPsec related SNMP variables makes any sense, since most of the
decisions are taken at a user level process (the KMP).
My $.02 + tax.
-Angelos
References: