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

Re: IPSec MIB

Angelos D. Keromytis says:
> >	- a list of the hashes of the keys in use
> >	  might assist in debugging;
> 
> I'll point out that this allows for exhaustive search.

It just *helps* an exhaustive search, making it slightly easier
than a known-plaintext-exhaustive-search attack.

An access to these particular objects should be restricted in
any case, or these objects may not exist at all. The question
here is whether the usefulness of these objects justifies
their existence (and so we should devise a way to remove
or minimize the exposure), or the benefit is too small
to bother.

When trying to figure out how come that the two boxes refuse
to talk to each other, observing that:
	- the counter of "rejected 'cause of bad auth" is
	  increasing rapidly;
	- the hashes of the key presumably used are different,

one can make a pretty good guess what is happening. This
assumes that there is an "authorized" NetAdmin whose job
is to get the things working on his whole admin domain.

As I said earlier, I'm not really sure what info is absolutely
necessary to quickly determine the cause of the problem,   nor
whether the existing (plus those being designed now) protection
methods of SNMP are deemed adequate. That is one of the reasons
I'm asking all these questions.

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

Good. Let's have it solidified, what counters could be of use. 
Obviously the ones I mentioned. Anything else?

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

Possibly. I tend to prefer to "concentrate" my control (i.e.
both "watching" and "tweaking") in the same spot/tool...
Anybody else cares to comment on this?

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

This is a very good point. I didn't think about it.

Of course KMP can be instrumented too...  Should it be...?
-- 
Regards,
Uri		uri@watson.ibm.com
-=-=-=-=-=-=-
<Disclaimer>