[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: discussion of IPsec MIB requirements and goals, and my reviewof IPsec Flow Monitoring MIB
Hi -
Thanks for outlining the goals of your MIB design
and your very useful critique of the Flow MIB.
The Flow MIB, which has been in design for a few
years now, had two primary goals:
G1) to provide manageability to the protocol arrived
at by the IPsec WG (and not merely "MIBify" the protocol
definition)
G2) to provide abstractions to aid NMS applications
involved in managing IPsec based networks.
G3) to reduce the cost of polling the tables from the NMS
While (G1) and (G3) were critical, (G2) was our overarching goal.
The initial draft (defined by the IBM Nways group a few
years ago) has been costantly revised based on the
evolution of the protocol as well as updated use cases
from the field.
From: "Shriver, John" <john.shriver@intel.com>
Date: Thu, 8 Nov 2001 14:10:10 -0800
Message-ID: <C703B434E680D511BDFD0002A507069602978E43@hdsmsx101.hd.intel.com>
>The claim that there are "major differences" doesn't ring
>completely true to me. There are many key similarities, often
>hidden by different terminology.
The Flow MIB is fundamentally different from the IPsec Monitoring
MIB. A MIB is essentially a model or an abstraction set forth
using rules of SMI. The basic abstraction defined by the Flow
MIB is a "tunnel" or a "traffic flow". A "tunnel" is the set of
SAs created by successive QMs that share the same Phase 2 ID and
hence go to sustain a specified traffic flow. This is illustrated
in the figures accompanying Section 2. This abstraction is the
central to the MIB; all counters and tables are centered around it.
Practically, such the "flow" abstraction is essential to monitoring
the state and performance of IPsec sessions. It is on flows
that SLAs can be meaningfully defined and evaluated.
To see a similarity between the SA-level MIB and the Flow MIB
would be to miss this central idea. The superficial similarities
you note arise because the two MIBs are, after all, instrumenting
the same protocol. The counters defined by the Flow MIB correspond
to an aggregated traffic flow while those defined by the IPsec
Monitoring MIB are too level to be made use of by performance
monitoring applications.
Now, to your objections about the "structural" problems in the
Flow MIB:
1. Phase 2 proxy ID types restricted in EndPt table
===================================================
One of our design goals was to minimize the SNMP traffic
required to complete a query. Hence, we chose not to normalize
tables even where it would have seemed theoretically elegant.
The restriction on the identity types in the End Point table
is a consequence of of this goal as well the feeling that
only address based identities make sense in this context.
>The addition of a new identity type breaks it.
It is to be expected that a MIB that instruments a protocol must
be revised with any significant revision to the protocol. Addition
of a new Phase 2 identity type is a significant revision to
the protocol and in practice, a rare occurrence.
The only way to avoid such revisions would be make the MIB
a look up table of raw values: a MIB as a lookup table is not
very appealing and seems to add very little value.
Another disadvantage of the IPsec Monitoring MIB (and similarly
the IKE MIB) is that the amount of polling required to complete
a query would be high, due to the number of cross-table correlations.
More on this later.
The points (2), (3) and (4) are quite valid and my responses below.
2. ikePeerLocalValue size cannot accomodate arbitrarily large values
=================================================================
>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).
It is true that a very large Phase I identity string cannot be
accomodated in the ikePeerTable. A large identity string will be
truncated: but this causes no ambiguity in indexes due to the
disambiguating internal index in the table.
However, in practice how often is likely to see such large
identity strings?
>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.
This solution may fit the bill in theory; in practice, as I said earlier,
traversal of your tables will lead to costly SNMP polls.
3. No way to pinpoint a peer address other than by searching
==================================================================
>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.
This is a valid point; but we felt that keying based on
Phase I IDs would compensate for this.
4. IKE has been made mandatory keying protocol
==============================================
This probelm arises merely because IKE groups have been
made mandatory in the module compliance. This needs to be
fixed and defining a brand new MIB is I think an overkill.
5. No way to identify new or negotiated DH grps
===============================================
>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.
The MIB was not designed to reveal every nut and bolt
of the SAs. I am not sure if the WG expects a MIB that
faithfully models every bit of the protocol. Identitifying
that a new group has been negotiated for a specific SA is
useful (using a new textual convention element "private").
You consider the following elements either obsolete or
extraneous to this MIB definition.
6. XAUTH and mode-config should be separated out
7. IPsec over UDP should not be a part of this MIB
Deleting obsoleted elements is trivial, if the corresponding
drafts are indeed dead. With regards to layering: traversing
normalized tables can cause a lot of SNMP traffic. With goal (G3)
in mind, we have included metrics closely related to IKE/IPsec
tunnels in this MIB even if it appeared that they could be
layered out.
In addition you have listed a number of cosmetic problems
such as those pertaining to the type of TrapStatus,
making descriptions more rigorous and documentation of
encoding types if certain ID types. I will take these up
in a separate mail.
>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.
This statement is entirely incorrect: the approach of the two MIBs
is entirely different. You have attempted to faithfully reflect every
aspect of the WG's output in the protocol and hence you instrument
the protocol at the SA level. For this reason alone, your MIBs provide
a low level view of the managed network. The second concern I have
about your draft is that in monitoring large networks, traversing
tables in your MIBs will result in quite a lot of SNMP polling.
The Flow MIB, on the other hand, was designed considering
numerous use-cases from the field. It defines an important
abstraction, defines counters and tables around this view
and provides limited archives to capture trends of traffic
and failures.
Its time to merge the best aspects of the two MIBs. That will
be my next step. Thanks for your thorough review.
---
S Ramakrishnan, Cisco SYstems Inc., San Jose, Ca