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

Re: IPSEC-POLICY-MIB - Negotiation actions

Casey Carr wrote:
> I'm concerned about the apparent deviation from the IPSec Policy model that
> the IPSEC-POLICY-MIB has taken with regards to SANegotiatedActions.
> The NegotiationAction table contains the sanIKEActionName and
> sanIPsecActionName.  It appears to me that the MIB intends for these names
> to be used to look-up an associated IKEAction and an associated IPSecAction
> for the NegotiatedAction.  This implies a Has-A relationship where the model
> calls for an Is-A relationship.  

	That was not what we intended, but your interpretation of what we did 
(inspite of what we inteded) is entirely reasonable. We do need to
change to remove the ambiguity. We intended that sanIKEActionName and
sanIPsecActionName should be mutually exclusive in the
SaNegotiationActionEntry and each should be matched with either a
pgIKERuleName or pgIPsecRuleName respectively. We certianly needed to
include text stating that requirement in the descriptions, our bad.

	But I am thinking that I like your proposal anyway ( that is... get rid
of saNegotiaitonAction and just have IPsecActions and IKEActions (and
move the common parameters into both of those tables. After another
review of draft-ietf-ipsp-config-policy-model-02.txt, I note that is

   the class SANegotiationAction serves as the base class for IKE and 
   IPsec actions that result in a IKE negotiation.  Although the class 
   is concrete, is MUST not be instantiated.
 (section 6.9)

	Hmmm... MUST not be instantiated, that is exactly what we did in the
MIB and it led very directly to confusion. I'm almost willing to start
modifying the text of the MIB, but I'd just like to survey for other
opinions first. What to others feel like here?

> It appears to me that it not only breaks
> the model but requires that the both the IPSecAction and the IKEAction use
> the same values for the following attributes:
> sanMinimumLifetimeSeconds,  sanMinimumLifetimeKB,
> sanRefreshThresholdSeconds, sanRefreshThresholdKB, sanIdleDurrationSeconds.
> Isn't this a bad idea?  Wouldn't the end user want to be able to define
> these values much differently for the Phase 1 and Phase 2 SAs?

	Yes, users will certianly want that adminstrative capability. Both the
model and our mib allow for it. Its just that our MIB was highly
ambigious in this area.... A problem that needs fixing.

> I believe that it is necessary to change these table definitions based on
> the requirement of matching the IPSec Policy Model.  I propose that the
> saNegotiationActionTable be removed and the appropriate parameters be copied
> into each of the IPSecAction and IKEAction tables.   Another possible
> solution would be to have both the IPSecAction and the IKEAction tables
> AUGMENT the NegotationAction ( of course removing the IPSec and IKE action
> name objects).  I'm not a big fan of augmented tables so I would vote for
> the first proposal.

	Although, wouldn't augmenting be a truer representation of an
uninstantiated base class with two differing intantiated and inheriting
classes? Maybe not... just wondering.
  Ricky Charlet   : Redcreek Communications   : usa (510) 795-6903