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

discussion of IPsec MIB requirements and goals, and my review of IPsec Flow Monitoring MIB



OK, I have finally had a chance to do a thoughtful review of the IPsec Flow
Monitoring MIB.  Took a while until I could take the time away from pressing
deliverables to do so.  Now I can participate in an informed discussion.
(This is a LONG message.)


I should start with how I got involved in the IPsec MIB.  It was a
combination of two things.  One, I was working at Shiva with BBN on a
proprietary IPsec MIB for a product I was then involved with.  Two, I saw
Tim Jenkins' MIB work, and saw that it showed a lot of work, but didn't meet
BBN's criteria (lots of artificial indices), and it really didn't meet David
Perkins' "MIB design rules".  (For those who are designing SNMP MIBs,
"Understanding SNMP MIBs" is a must-read.)

So, I started providing lots of comments to Tim.  I was about the only
person commenting.  So many comments that Tim offered to make me a
co-author, which I accepted.


There were a set of criteria that we developed as we worked on the MIB.  I
think I can put most of them in a list here:

1. Well-formed by Perkins' criteria.
2. Meaningful indices on tables wherever possible, rather than synthetic
indexes (starting at 1).
3. Ability to look things up directly via an index, rather than a table
search, wherever possible.
4. Layered.  Start with IPsec, since that's mandatory.  Then ISAKMP, since
it was a protocol in its own right.  Then IKE on top of ISAKMP.
5. Augment rows wherever possible when going up through the MIB
documents/layers.  Some are full formal AUGMENTS, others are sparse
augmentation, which isn't formally expressable in SMIv2.
6. Extensible without having to change the base MIB.  No assignments of
IPsec magic numbers by the IANA should break or obsolete the MIB.  (The
magic numbers are what I have in the Textual-Conventions MIB, which would be
updated by the IANA after release.)  If you don't do this, the MIBs will
never reach Full Standard, because they will always be tracking new
assignments.  (Consider the frustrating fate of the dot3 MIB, trying to keep
up with the IEEE defining new flavors of Ethernet.)
7. Allow what the IPsec specifications allow, rather than limiting the MIB
to current conventional IPsec useage.
8. Minimize revealing much more than you could learn by sniffing the wire.
While there are parts of the MIB which deserve access controls, there's
nothing SENSITIVE like keys in it.
9. There should be MIBs for the raw IPsec unidirectional security
associations.
10. Allow key negotiations other than IKE to be supported over ISAKMP.
11. Avoid counters that could help a cracker tell if they finally found the
right value in a keyspace search.  (Things like authentication error
counters, etc.)  Even more so with traps.
12. Be careful about the length of OID's, especially large index variables.
13. Try and make all index variables definite-length, to avoid the pain of
having to insert the length sub-identifier and sort by it.
14. Maximize compatibility with management via SNMPv1 with SMIv1.
Basically, be stingy with Counter64, and careful about the Notification
OIDs.


One frustration that we had was the hopeless generality of the IPsec
specifications.  There was little "pruning" of the requirements before
switching to the protocol development stage.  Thus IPsec is everything to
everyone.  

An example of this is identities for Phase 2 key exchanges in IKE.  In the
spec, the number space is the same one used for Phase 1 key exchanges in
ISAKMP.  But many of these make absolutely no sense in Phase 2.  Like what
would "user fully-qualified domain name" mean in this context?  In reality,
only the address-based identities make sense in this context.

When we were trying to add identities to the Phase 2 tables, we queried the
list as to whether we could assume that they would always be one of the
address types?  Someone authoritatively replied "no".  I think it was Dan
Harkins, who at that time did not like the idea of putting any restrictions
on IKE.  (I do think Dan's viewpoint has shifted...)

The same sort of problem came up trying to build a table of ISAKMP Phase 1
associations.  It would be simple to just do it by the two IP addresses.
But, because the ISAKMP/IKE specs do not resolve how to handle collision of
establishment of Phase 1 associations, even whether to consider tearing one
down, one is forced to add the two cookies as indexes, as that is the only
way to uniquely identify the connections.

So, as I note, the rambling generality of IPsec's specifications complicates
MIB writing, if you want to write a MIB to the spec, rather than to what
people just happen to be doing  today.


Now, one of the underlying assumptions I made above is probably
non-functional now.  That is the layering of ISAKMP and IKE into separate
layers.  If I understand the intent of the working group correctly these
days, the intent is to merge them into one specification now, and to remove
ISAKMP's support for any protocol other than IKE.  If this is the case, and
the assignment of ISAKMP magic numbers is being frozen, I can definitely see
that it would be fully appropriate for us to merge our ISAKMP and IKE MIBs,
removing a bunch of obsolete columns from the ISAKMP part.  Since almost all
the tables are augmenting, this will greatly reduce the number of tables.
But, we need strong assurances that this would be the right direction to go
in!


So, now let's wander through the IPsec Flow Monitoring MIB, and consider the
design problems in it.

Consider section 4, bullet 1.  This is about the need to modity
ipSecEndPtTable to support a new identity type, based on SCTP.  This table
corresponds to our selectorTable (IPsec Monitoring MIB).  The difference is
that selectorTable returns the raw data from the IKE negotiation, with a
Ident Type and raw identity data.  No attempt is made at pretty formatting.
Nor did we reduce this to supporting only the identity types that were
meaningful in this context.  The ipSecEndPtTable does make the assumption
that only the address based identity types made any sense.  (I somewhat
agree with that.)  But, then it gets skewered on my design goal 6 above, as
adding a new identity type breaks it.  Neither solution is really pretty,
the raw ID's are a pain to parse, the change tracking is a loser too.
Perhaps it could be like my group table, there is a table for each ID type,
with the correct rows, and the base table has a "pointer" to the right
table/row to describe the identity.

As for section 4, bullet 4, this brings up the need to layer things.  This
MIB should not be changed to support NAT and IPsec over UDP.  These should
be layered MIBs, hopefully done by AUGMENTing existing rows in the final
IPsec MIBs.  We know that the hard part of SNMP instruementation is
generating the table index data structures for efficient GET and GET-NEXT
operations, so that if multiple SNMP table share the same set of indices,
you aren't repeating the "hard" part of the code.

To the MIB text proper.

The IkePeerType TC is very similar to the InetAddressType in RFC 2851,
"Textual Conventions for Internet Network Addresses".  I think we're pretty
much mandated to use that MIB when we are putting IP addresses into other
MIBs.

However, there is one type there which isn't an IP address, which is id_dn
(I presume X.500 Distinguished Name).  However, this is the core a bunch of
serious MIB problems, which are discussed later.

I don't see why TruthValue isn't suitable instead of defining TrapStatus.

The Flow Monitoring MIB's ikaGlobalStats section is very much like our
isakmpNegStats and IkeGlobals.  But, it has a lot of very intersting
counters.  These are very well considered counters, obviously added due to
very real-world issues.  These are a very valuable contribution to the whole
MIB discussion.  Perhaps a little effort is in order making the definitions
of these counters a little more rigorous?

However, I'm a little worried (for security reasons) about
ikeGlobalAuthFails.  Could be too useful to a cracker.

Then, I come to another one of the layering issues.  The Flow Monitoring MIB
appears to include support for the XAUTH and config-mode protocols, starting
at ikeGlobalInXauthFailures.  While I know as much as anyone that these
expired Internet-Drafts are expired, at present they are not on the
standards track.  Each should be implemented in a seperate MIB, which at
present would have to remain proprietary.  I don't think the working group
wants to MIBify protocols which they couldn't reach consensus on.

The Flow Monitoring MIB ikePeerTable runs into a structural problem.  It
can't be validly implemented.  The reason is that when ikePeerLocalType
and/or ikePeerRemoteType is id_dn, ikePeerLocalValue and/or
ikePeerRemoteValue may very readily be so long that the Object Identifier
will exceed the maximum number of sub-identifiers (230 if I remember).
Moreover, having these indexes be indefinite-length strings invokes the
annoying requirement of a sub-identifier of length in the OID/index.

This is why our IKE MIB has the ikeEndpointTable.  This is a table of
endpoints, indexed by an arbitrary indexes (violating our own no-search
rules), containing the endpoint data.  Then we can use this arbitrary index
to index other tables that need to be indexed by endpoint.  It wasn't
something we were very happy with, but for Phase 1 identities, there really
wasn't any other choice for valid SNMP SMIv2.

Another problem with the id-dn identity type is that you haven't documented
the encoding of the related value.  Is it in DER?  If I remember right,
there are some knotty issues about certs with the same name, but coded in
different language, and whether they are the same or different...

Also, the coding of ikePeerLocalType and ikePeerRemoteType is too limited.
While there are real restraints on Phase 2 identity types, there are no
restrictions on Phase 1 identity types.  I don't think that "user FDQN" or
"X.500 GeneralName" or "IP V6 address range" have been deprecated yet.  (See
IpsecDoiIdentType in the DOI Textual Conventions MIB.)

Meanwhile, there's no way short of table search to find an IKE Phase 1 SA by
the IP addresses.  We have that in index of the saTable in the ISAKMP MIB,
and it's sparsely-augmented partner ikeSaTable in the IKE MIB.

There are also bunch of helper tables in our MIBs (some of which could be
made optional), that let you find the Phase 1 SA's created by particular
peers, etc.

As noted before, the ikePeerTable has a bunch of config-mode entries that
need to be bumped up to a separte proprietary MIB.

I do appreciate the purpose of the separation of ikePeerTable and
ikeTunnelTable.  This makes sense, and could be applied to our structure.
But, ikeTunnelTable should be indexed by address types/addresses/cookies.

The variable ikeTunDiffHellmanGrp does not allow for private groups or
as-yet-undefined groups), yet IKE does.  Unless IKE Version 2 plans to
delete this, I think my saOakleyGroupDesc/saOakleyGroup variables meet the
goal of supporting what the spec allows.  It also avoids obsolescence
problems.  Remember that the supporting modpGroupTable, ecpGroupTable and
ec2nGroupTable are only required if you actually choose to support
negotiating new groups.

I wonder why ikeTunStatus has a syntax of TunnelStatus, it could also have a
restricted version of RowStatus instead, which might let management stations
present it better.

The counters of exchange types at the end of this table, starting with
ikeTunInNewGrpRequests, and proceeding into more config-mode counter
variables, again shows why I did the exchangeTable.  Here, new exchange
types just instantiate new index values, and no MIB changes are needed when
you do things like add Config-Mode.

ikePeerCorrTable has the same problem as before of supporting X.500
DistinguishedName strings as indices.  Otherwise, it is the same concept as
our suiteByCreatorsTable, but with different indices.

I do like the various "Wraps" counters, such as ipSecGlobalInOctWraps,
that's a nice way to provide SNMPv1 compatability.

I do not view IPCOMP as part of IPsec, I would propose that the IPCOMP
variables, such as ipSecGlobalInDecompOctets belongs in a IPCOMP MIB.

The ipsecTunnelTable is essentially equivalent to our suiteTable.  Both have
an arbitrary index, as a proper index is just ridiculously long and
complicated.  The major difference is that suiteTable has references to rows
in the IPsec MIB, for each of the raw SA's that make up a tunnel/suite.  The
Flow Monitoring MIB has flattened this out. 

I will admit that it is a perfectly valid topic to discuss whether there
should be a MIB like the IPsec Monitoring MIB.  Perhaps at current
network/crypto bandwidths, these rows would be created and destroyed so fast
that (1) they would vanish before you chased a reference to them and (2) it
would be a computational burden updating the table indices all the time.
Perhaps flattening the most essential elements into a higher level MIB is a
better solution.

On the other hand, how does one monitor a static-SA/static-key only
IPsec/IPv4 implementation, which is perfectly valid?  (Of course, it also
makes for a rather useless product...)

Also, I think that ipSecTunelTable assumes that only the canonical three
transformations are used, in the canonical order.  (Is this a restriction
that Son-of-IKE will impose?)

The ipSecEndPtTable was discussed earlier, how it cannot be stable with the
introduction of new Phase 2 ID types.

The ipSecSaTable is similar to our phase2SaTable, but folds in a bit of the
IPsec Monitoring MIB.  I presume that the intent here is to allow listing
the raw SAs in the order that they are applied?


I really don't have any issues with the history tables.  They are a most
interesting idea.  They also could be in a MIB by themselves.  They could be
resource-intensive...


I haven't looked at the notifications yet.  Hopefully none can be used by
key-crackers on a "traffic analysis" basis.


I think by the time one changes the indices on the tables that have
"structural problems", and allow more extensibility, the tables start to
look a lot like the ones Tim and I have been working on for a few years.  I
think if we prune some things, maybe merge ISAKMP/IKE, and decide if we want
an IPsec proper MIB, we can merge the excellent counters with the basic
table strategy that has been evolving over two years.

The claim that there are "major differences" doesn't ring completely true to
me.  There are many key similarities, often hidden by different terminology.