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

RE: Status of ID: IPsec Flow Monitoring MIB

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.

> 
> 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?

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.)

> 
> 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.

> 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.

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.

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