[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
My IPSec MIB structuring motivations
One thing I realize I didn't put much text into was some of the
motivations for my layering of the IPSec MIB.
Sure, one possible consideration was for people using ISAKMP with
something other than IKE. But, those people (presently) are so in the
"black" that they probably have no intention of ever having a MIB,
it's too much of a security issue for them! Certainly, they're not
going to offer us much design assistance (much less admit who they
work for).
But, the IPSec community could wind up implementing a replacement for
IKE, if some tragic security flaw were to be found. It would be nice
if we didn't have to design a whole new set of MIBs when that happens,
but instead could just define a limited set of new tables for "Son of
IKE".
Also, I wanted a MIB that still made some sense in an environment
where there are non-IKE Security associations. Let's remember that
dynamic keying is still nominally an optional part of the IPSec
stack.
Some of the complexity is also due to the motivation of defining a
group of TEXTUAL-CONVENTIONS for all the DOI1 and IKE magic numbers.
Moreover, the values of these MIB enumerations would be exactly the
same as their on-the-wire encoding, to simplify implementation.
(These TC's would be managed by the IANA as they assign more of those
magic numbers.) Thus, any variable using one of those textual
conventions must be in a DOI1-specific place in a MIB.
If we want to establish our own number space for all these magic
numbers, with different values than on the DOI's, then we don't have
to make the per-DOI tables for all the ISAKMP stuff. But I think that
makes continuing management of the number space a much bigger pain in
the behind...
Then there's the whole nuisance of supporting IPv6. One side of me
would like seperate v4 and v6 tables, with the v4 tables having the
canonical encoding (IpAddress) of IPV4 addresses. But that would
result in massive duplicate tables. But, we've no pretty solution,
since the SNMP SMI doesn't have CHOICE OF from real ASN.1.
I suppose a really strange approach would be to have seperate IPv4 and
IPv6 address fields in each table. Only one would be non-zero in a
given row. If the table needs to be indexed by the address, you just
index it by BOTH of them. One all zeros in every row. But at least
you can make the IPv4 one be SYNTAX IpAddress.
The current scheme has the annoying feature that IPv[46]Address
indexes will have to be instantiated with a length octet or 4 or 16 in
front of them. I suppose this is one reason Tim avoided indexing by
IP address.