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

RE: IPSEC monitor MIB



> -----Original Message-----
> From: Waters, Stephen [mailto:Stephen.Waters@cabletron.com]
> Sent: April 12, 1999 2:53 PM
> To: ipsec@lists.tislabs.com
> Subject: IPSEC monitor MIB
> 
> > I have a few thoughts having read draft 3 of the IPSEC 
> Monitoring MIB:

That series has been abandoned; there is another that is draft 00 which
is not representative either, but is closer; a new architecture was
presented in Minneapolis.

(I need to get the first series pulled off the WG page...)

The current proposal (and we hope to release new documents very soon)
consists of three separate MIBs. A rough description of them is:

-a DOI-independent ISAKMP MIB
-an IPSec SA MIB (raw SAs, independent of how created)
-an IKE MIB, that links phase 1 and phase 2

Concepts like channels and tunnels as introduced in the original]
series of MIBs are gone; they will have to added in as application
specific MIBs on top of the above three MIBs.

So, having said that...


> > 
> > 
> > 1) I feel there is room for an 'SPD' table entry to sit 
> 'above' the IKE
> > Control Channel table. The IPSEC architecture describes 
> interface-specific
> > SPD (I seem to remember) and in this case, the same IDs 
> used to make the
> > IPSEC MIB entries unique could occur many time, for 
> example, if I want to
> > define the security on a number of 'public' interfaces to 'protect
> > everything' in a LAN-LAN case, then I may have multiple 
> occurrences of the
> > same simple selectors. The IPSEC MIB could then be used as 
> an extension of
> > the Interface MIB.

Control channels are gone; they were the logical phase 1 tunnel.

I think you mean to associate the phase 2 tunnel with the
Interface MIB. The relationships to the interface MIB of tunnel
identifiers was discussed and I believe determined to be an
implementation specific issue. This was then to be handled
outside the scope of the IPSec MIBs.

> > 
> > 2) As part of an attempt to recycle resources in a security 
> gateway, would
> > it be possible to add an 'idle timer' that is used a bit 
> like LifeTime,
> > but allow user inactivity to be identified and acted on in some way
> > (delete the SAs)?

This is a monitoring MIB only. While the addition of the idle
timer might be a good idea, the ability to delete the SA via
SNMP is not within the scope of this MIB.

I'm really concerned that the addition of the ability to write
will open up real problems in handling security issues; I've
added writeable objects to control traps in the new MIBs, but
I'm concerned about even those.

> > 
> > 3) While thinking about how to identify when a tunnel was 
> broken, has
> > anyone proposed a way to actively monitor IP tunnels? I thinking of
> > something like an ICMP message poller to operate a bit like 
> a PPP Echo
> > poll which can be used to declare the tunnel 'down'.

There is talk of a 'keep-alive' notification; others will
probably comment on that.

> > 
> > 4) There is a lot of text in this draft that suggests that 
> IKE can be used
> > to negotiate a 'protection suite' of just IPCOMP. Have I 
> missed something?
> > Does anyone support this?  This option would seem to be 
> better placed as
> > an addition to IP-IP Tunnels/MIBs.

There is nothing that precludes IKE negotiating just IPCOMP.
Whether it is supported or not is an implementation issue.

In any case, the new MIB proposal treats individual SAs
completely separately; the IPCOMP SAs are in their own
tables.

> > 
> > 5) The IPSEC Tunnel table - given that it can contain 
> TRANSPORT and TUNNEL
> > mode types, should we use a name other than tunnel in the 
> table name?  How
> > about IPSEC Connection - to go with the IKE Connection table?

The words 'transport' and 'tunnel' are encapsulation modes.
The 'tunnel' concept is just as valid since the original data
(not including the IP header anymore) is still wrapped in
another header and opaque to the rest of the world when
wrapped.

In any case, it's gone from the current proposals for the MIB.

> > 
> > 6) Accounting.  I guess I was going to use SA 
> initiation/termination as a
> > handle to do IPSEC Accounting. If TRAPs are not intended 
> for transient SA
> > initiation/termination, how could this be done?  I suppose 
> it could be
> > done on a timer basis that simple logs deltas on IPSEC Tunnel table
> > entries.

The concepts of transient and permanent tunnels are gone, since
tunnels are gone. However, when the application specific overlay
MIBs are added, your concerns should be applied to them.

> > 
> > 7) Under certain circumstances, I'd like to be able to use 
> SETs to do some
> > rough management.  I understand there are security worries 
> with this, but
> > the SNMP flow could itself be protected with IPSEC...   I'm 
> looking to add
> > things such as turning IPSEC on/off, deleting IKE-SA or IPSEC-SA.

Again, this is a monitoring MIB only. I'd like to see how we
can deal with the security issues before we add this kind of thing.

> > 
> > 8) What counts the Phase-2 IKE traffic?  It isn't clear to 
> me what exactly
> > the IKE Control and IKE SA entries count as 'traffic'.

The bytes that go across the wire. It's a measure of the 'overhead'
used to manage the IPSec SAs themselves. At least, that's the intent;
however this makes it different from the amount of traffic applied
to the security transforms.

---
Tim Jenkins                       TimeStep Corporation
tjenkins@timestep.com          http://www.timestep.com
(613) 599-3610 x4304               Fax: (613) 599-3617