[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: IPSEC monitor MIB
Thanks for the information Tim, I look forward to seeing the new offerings.
I have a few responses:
SPD - I would still like to push the point the IPSEC architecture does have
the concept of SPDs and these SPDs can be applied to really interfaces if
desired (I think this makes very good sense when a router/security gateway
has a single/limited non-trusted interfaces). I would like to suggest that
and SPD table be considered (just name and reference to an ifEntry) to live
above the IKE Phase-1. The ifEntry may not actually point to an Interface
entry, but it could. The interface that IKE packets are sent over could
also be different from the interface referenced in the SPD table entry; the
only implication is that a packet that is sent/received on a given interface
may have an SPD associated with it in the same way that a set of packet
filters are applied to an interface. This is similar to firewall events
that reference an interface if it is appropriate. Allowing SA to be grouped
under SPD allows for the possibility of having duplicate policy applied to
multiple interfaces, or the same policies applied to all interfaces.
Monitoring MIB - to me all MIBs are monitoring MIBs :) . Just because a MIB
does not allow you to completely configure a feature does not mean it can't
have a few SETs - in my book.
Keep-Alive poll - I'm keen to see what this is. It would be a shame if this
is IPSEC-specific since tunnels without IPSEC protection need similar help
(IP-IP, GRE).
IPCOMP-Only - this is not something that has been tested at bake-offs. Does
anyone intend to implement this? Our approach currently would be to just
use an IP-IP tunnel with LZS 'on' as a static configuration, rather than
hijack IKE to become a generic tunnel negotiation protocol.
Regards, Steve.
-----Original Message-----
From: Tim Jenkins [mailto:tjenkins@TimeStep.com]
Sent: Monday, April 12, 1999 8:38 PM
To: Waters, Stephen;
Subject: 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