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

Re: Status of ID: IPsec Flow Monitoring MIB



"Shriver, John" wrote:
> 
> Comments inline...
> 
> > -----Original Message-----
> > From: rks@cisco.com [mailto:rks@cisco.com]
> > Sent: Friday, October 26, 2001 2:23 PM
> > To: Theodore Tso
> > Cc: Tim Jenkins; bbruins@cisco.com; bret_harrison@tivoli.com; Barbara
> > Fraser; cmadson@cisco.com; ipsec@lists.tislabs.com; leot@cisco.com;
> > pcn@cisco.com
> > Subject: Re: Status of ID: IPsec Flow Monitoring MIB
> >
> >
> > Hi -
> >
> >     From: Theodore Tso <tytso@mit.edu>
> >     Date: On Fri, 26 Oct 2001 14:23:03 -0400
> >
> >     >Which leads us to the next question... assuming that there
> >     >is only one attempt to implement the I-D's, what is the
> >     >working group's feeling about advancing the documents?
> >
> >
> > I have looked through the IKE and IPsec monitoring MIBs
> > and I am a bit confused about the purpose of these "low level" MIBs.
> > Why were these defined and what problem are they meant to solve?
> > MIBs that dish out bits of the protocol merely because the bits
> > happen to be there, serve very little purpose (let's call
> > such MIBs "protocol MIBs").
> 
> Well, there are IETF rules about protocols, progress along the standards
> path, and SNMP MIBs.  No MIB, no Full Standard status.  That's what got me
> initially interested.

So let's forward a useful MIB for the protocol.

> 
> >
> > Why would an administrator use them instead of the command
> > line interface (I am not sure there is a device out there
> > that supports SNMP protocol but not management through
> > telnet)?
> 
> Two reasons:
> 
> Because you are using the MIB because you cannot establish an IPsec session
> with the managed system.  If you can't establish an IPsec session, how are
> you going to establish a Telnet session that is secure enough to be allowed
> access to the CLI?

In contrast...  Using the current "low level" MIBs , the problem event would 
be so short that the MIB entry would gone before a query could be done.
  
> 
> Because you need to automate troubleshooting, and you're not going to do
> that with a CLI management interface.  These MIBs were designed according to
> criteria set out by people at BBN when we were courting them as a customer,
> to be able to troubleshoot a particular IPsec "session" WITHOUT having to do
> any table searching.  That is what makes the indexing complicated.  (BBN is
> famous for knowing how to manage a network.)

The Flow Monitor MIB has this capability.  The "low level" MIBs do NOT.

> 
> >
> > One answer to my last question could be the following:
> > Monitoring and troubleshooting are done in the context of
> > an application of IPsec (such as VPNs). Hence, if a problem
> > with the application is traced down to the underlying protocol
> > (IPsec), the ensuing troubleshooting would require the nuts and bolts
> > of the protocol. Hence, I'd argue that without a MIB that provides
> > abstractions on top of the protocol view (an "application MIB"),
> > the protocol MIB serves little purpose.
> 
> I fully agree that application oriented MIBs on top of these MIBs are fully
> appropriate.

And should replace the "low level" MIBs which no one other than
an IPsec developer could understand.

> 
> > There has not been any discussion on these MIBs, leave alone
> > a debate contrasting the two approaches (the Jenkins drafts and
> > the IPsec Flow Monitoring MIB, proposed by us).
> 
> They have been presented at the IETF meeting, and few issues were raised.
> Those issues were addressed in revisions.

Really?   I have tried to find the latest drafts of the "low level"
MIBs and only find references with "dead" links.  

> 
> We've had a lot of good review comments from various reviewers.  I started
> as a reviewer, and progressed into co-authorship.
> 
> There are admittedly some curious issues of managing a strong secure
> protocol like IPsec with the much more modestly secure protocol SNMPv3.
> 
> I will admit that the drafts now have a bunch of redundant layering, since
> there may someday be a revision of IKE that "flattens out" the
> specifications.  But we have put a lot of work into making them
> "well-formed" MIBs.


Right.  Redundant is another word for "not useful".

> 
> >
> > Hence, how can it be appropriate to take these drafts to the
> > final call?
> >
> > Rk
> > x77309
> >
> > ---
> > S Ramakrishnan, Cisco Systems Inc., San Jose, Ca
> >
References: