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

RE: FW: IPSec Monitoring MIB works for IPv4 only?

> > -----Original Message-----
> > From: Tero Kivinen [mailto:kivinen@ssh.fi]
> > > In any case if we end up having (or just want to support them)
> > multiple ISAKMP SAs how are we going to represent them in the MIB?
> 
> You describe a problem that is not the MIB's problem: how to deal with
> multiple phase 1 SAs. It's only the MIB's problem if we must support
> multiple phase 1 SAs.
> 
> Can anyone tell me why we need to support multiple phase 1 SAs?
> Obviously, there will be transient times when there are multiple
> SAs during re-keying of a phase 1 SA. However, I don't see a need
> for this condition to persist.

The MIB lets you examine the state of the system.  If the system can
be in this state, the MIB has to be able to deal with that.

Arguably it should be a transient state, but even if it is transient
it isn't necessarily so short that it won't be visible some time, and
it certainly may be visible for unexpectedly long times if something
unexpected happened.

If I have two SAs at time T and the MIB says it handles only one, and
someone asks for "the" SA, what am I supposed to do?  Crash?  Return
one of them chosen at random?  Stall until one of them goes away?


> > Why is the ipsecIkeSaTrafficLimit limited to Gauge32? Note that the
> > current IKE draft doesn't limit the size of the life duration
> > attribute (it may be variable length, although I assume all of the
> > implementations will fail, if someone tries to send 64-bit number to
> > them...).
> 
> It's actually an Integer (misprint in -02). Anyway, at 32 bits,
> I figured 4,294,967,295 1024 byte blocks would be a reasonable upper
> limit for expressing this.

That's Unsigned integer, right?
> > Why are the *Packets counters Counter32, instead of Counter64? We may
> > end up using more than 2^32 packets also... It takes for 100 MB
> > ethernet with small packets only less than an half a day to do it.
> > 
> 
> That's fine. And what will it be over the Internet? Even over a T3
> with normal traffic, it's still likely more than a day.

32 bit counters have been a really bad idea for many years now.
Please, let's not perpetuate this mistake in new MIBs.


> > "ipsecIkeSaEncAlg - Encryption Algorithm" defines DES40-CBC 65001,
> > which is not defined by the DOI (and should not be defined by the DOI,
> > because is it from the private range).
> 
> As I stated in the appendix, they are not part of the MIB. They
> are reproduced for information only.
> 
> The values for DES40 come from a Cisco document, and were used at
> the last interoperability workshop by both Microsoft and TimeStep.

There's a DES40 draft, and the authors have defined an OID for DES40,
but haven't yet produced an algorithm code for it (I asked a month or
two ago).

> ...<snip further comments about DES40>
> > It seems to be odd that group 5 is missing, even when it is much more
> > widely supported than DES40 :-)
> 
> At release time of -02 of the MIB, there was a document for DES40. I
> had not seen the Group 5 document at that time.

I haven't either, though it was mentioned at the last interop
session.  Would whoever has this please post it?

	paul
Follow-Ups: References: