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

RE: FW: IPSec Monitoring MIB works for IPv4 only?



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


> -----Original Message-----
> From: John Shriver [mailto:jas@shiva.com]
> Sent: Wednesday, November 18, 1998 12:53 PM
> To: tjenkins@TimeStep.com
> Cc: ipsec@tis.com
> Subject: Re: FW: IPSec Monitoring MIB works for IPv4 only?
> 
> 
> I suppose that we are running into the problems that IKE is far more
> generous in what it allows compared to what people expect to do.  What
> do we define the MIB to correspond with: IKE, or expected common
> practice? 
> 

My mandate was to *quickly* produce a usable MIB. The speed issue requires
some simplification. Further, I have only made a few simplifications:
1) Assumption of only 1 IPCOMP service per bundle, 1 ESP service per bundle,
   and 1 AH service per bundle.
2) No method to specify the order of the services per bundle, since the
   normal reasonable order is assumed (see some of the previous email on
   this).
3) Only 1 phase SA between 2 peers at a time.
4) That IPSec is above IP in a stack.

A can't think of any others off the top of my head...

(I know that number 4 above has raised concerns, but it looked like they
 were addressable where implementations needed to do that.)

> There's no question that my proprietary MIB also has "tunnels".  There
> are plenty of useful things there.  But there really ought to also be
> a fast way to find your way into the MIB if the only thing you know is
> the destination IP address and SPI.
> 

This would require the addition of an IP address added to every
'ipsecSaEntry',
causing it to be duplicated, since it's already in the 'ipsecIkeSaTable'.

> I think my customer is looking at the "troubleshooting" part of
> management, and your customer is looking at the "performance
> monitoring" part of management.  Both are valid, and both should be
> represented in the MIB.  (See Perkins' book.)
> 

Sure, but if there's a conflict between the two, which has priority?
You can still do both with this architecture, it's just easier to do
performance monitoring. Which would be done more often by most customers?

Would it help if an 'ipsecIkeSaTable' index was placed into each
'ipsecSaEntry', so that one de-referencing step would be removed?
Is it worth it?

> This brings up another issue.  I think "tunnel" is not the word to use
> here.  In your own response, you flip between "tunnel" and "bundle".
> Since "bundle" is what is used in the IPSec Architecture document, I
> think it would be a better-chosen word to use for what the
> ipsecSaTable contains.  Thus, I'd propose we call it the
> ipsecBundleTable...

I don't flip between tunnel and bundle. I *do* flip between bundle and SA,
since this MIB views a bundle as an SA with more than one service. So, in
this sense, the 'ipsecSaTable' is really an 'ipsecBundleTable' as you
suggest. I considered that name some time ago, but rejected it,
since I didn't want confusion with separately negotiated multiple but
layered SAs and bundles. Further, some of the drafts also refer to
bundles as "security suites"...

I also wanted to strengthen the concept that bundles are SAs with multiple
services, rather than simply layered SAs.

> 
> I will admit that what I want to call the ipsecBundleTable is really
> very hard to index by anything other than an arbitrary index.  It
> really should be indexed by the Desc and SPD rules that lead to using
> that bundle, but that's probably exceedingly unwieldy!
> 
> As for ipsecSaInboutTraffic, what exactly does it count?  Does it
> count the bytes including AH, ESP, and IPCOMP headers?  Well, really
> it has to count exactly what is supposed to be counted against the
> lifetime in kbytes.  (The comment on ipsecSaTrafficLimit in
> IpsecSaEntry is wrong, should be -- 1024 byte units, 0 if none.)
> 

Actually, I was waiting for someone to catch this.

System administrators (in general) want this mean the *user* traffic
carried by the SA. However, there are problems with this if we use your
rule above. The expiration value is based on the amount data the
service is applied to. So, for ESP, this means the user traffic plus
the padding (and next protocol and padding length) bytes. In general,
the numbers will be close.

However, what happens in a bundle? The ESP packet is then applied to AH (if
they are both used), and the data processed by ESP is longer than both
the user data and the data applied to ESP.

For this reason, I think the 'ipsecSaInboundTraffic' should refer to user
data, after all inbound processing. As noted above, this will not
necessarily be the same as the amount counted against an SA's expiration
by traffic limit.

Further comments on this are invited...


> 
> As for IPv6, I think it should be in a seperate MIB.  That is, what
> you are presently working on is really IPSEC-IPV4-MIB.  There will be
> a seperate IPSEC-IPV6-MIB.  This will prevent RFC publication of
> IPSEC-IPV4-MIB from being held up because IPV6-TC isn't published as
> an RFC yet.  (You cannot publish an RFC with a reference to an
> Internet-Draft...)
> 

Okay.

> Further, as conformance statements are developed for IPSEC-IPV4-MIB,
> perhaps they should be carefully constructed so as not to require IPv4
> specific variables unless the IPsec implementation implements IPv4.
> Someday, there may be IPv6-only hosts...
> 

Any one want to do the conformance statements?
Follow-Ups: