Subject: IPSEC-POLICY-MIB - Negotiation actions

From: "Casey Carr" <[email-masked]>
Date: Wed, 9 May 2001 11:05:53 -0400

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

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.

Casey

---

From: Ricky Charlet <[email-masked]>
Date: Wed, 09 May 2001 10:26:25 -0600

Thanks
	pondering....

Ricky Charlet

-- 
  Ricky Charlet   : Redcreek Communications   : usa (510) 795-6903

---

From: Ricky Charlet <[email-masked]>
Date: Wed, 09 May 2001 10:59:02 -0600

Casey Carr wrote:
> 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
says:

   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

	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.

> name objects).  I'm not a big fan of augmented tables so I would vote for

	Although, wouldn't augmenting be a truer representation of an
uninstantiated base class with two differing intantiated and inheriting
classes? Maybe not... just wondering.

---

From: "Casey Carr" <[email-masked]>
Date: Wed, 9 May 2001 14:07:00 -0400

See my comments at the end.

Casey

-----Original Message-----
From: Ricky Charlet [mailto:[email-masked]]
Sent: Wednesday, May 09, 2001 12:59 PM
To: [email-masked]
Cc: IPSec Policy WG; Ricky Charlet
Subject: Re: IPSEC-POLICY-MIB - Negotiation actions

> calls for an Is-A relationship.

        That was not what we intended, but your interpretation of what we
did

        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
says:

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

        Although, wouldn't augmenting be a truer representation of an
uninstantiated base class with two differing intantiated and inheriting
classes? Maybe not... just wondering.
Yes it would be more accurate.  I'm not an SMI expert, but does it support
designing a table definition that has to be AUGMENTed in order to have an
instantiated row?  I.E. Does can SMI support the concept of an abstract base
class?  If SMI supports it, maybe you could omit a RowStatus in the base
table and but have one in each of the tables that AUGMENT it.

---

From: Wes Hardaker <[email-masked]>
Date: 09 May 2001 13:30:00 -0700

>>>>> On Wed, 9 May 2001 14:07:00 -0400, "Casey Carr" <[email-masked]> said:

Casey> Although, wouldn't augmenting be a truer representation of an
Casey> uninstantiated base class with two differing intantiated and
Casey> inheriting classes? Maybe not... just wondering.  Yes it would
Casey> be more accurate.  I'm not an SMI expert, but does it support
Casey> designing a table definition that has to be AUGMENTed in order
Casey> to have an instantiated row?  I.E. Does can SMI support the
Casey> concept of an abstract base class?  If SMI supports it, maybe
Casey> you could omit a RowStatus in the base table and but have one
Casey> in each of the tables that AUGMENT it.

Part of the problem here is that Mike and I came up with the initial
table breakdown, but Ricky and Cliff wrote the tables in question so
what Mike and I were thinking didn't get exactly mapped into reality.
I have many minor "corrections" I'll propose (when I get the time,
hopefully later this month, sigh) in this regard.

The problem is basically one of reuse.  The idea was the notification
parameters that were common to both action sets should be defined in a
single table such that reuse of the definition would be possible.
IE, the table in question should have been "pointed to" by the other
two action tables such that it would be a reference saying "see here
for common parameters".

Now, it doesn't make sense for all instances and this is what we need
to determine.  However, I'm admittedly opposed (from an admittedly
idealistic standpoint) to taking the exact same set of paramaters and
making them identical column sets in two other tables.  Instead, we
should use a pointer of some kind (whether that's via a string index
(I think what was originally intended), or via a RowPointer, or via an
AUGMENTS (IE, MIB-specific) style of inheritance.

Make sense?
-- 
Wes Hardaker
NAI Labs
Network Associates

---

From: Ricky Charlet <[email-masked]>
Date: Wed, 09 May 2001 14:54:56 -0600

> AUGMENTS (IE, MIB-specific) style of inheritance.

	But as the tables stand today, the SANegotiationAction entries are not
re-usable by several ike or ipsec actions. Each saNegotiationAction must
point to only one IKEAction or one IPsecAction.

	So here comes just a brain-storm type idea (ie.. not well thought out)
If We arranged our tables such that the actionName rowpointer in the
actionsInRuleEntry pointed at either an Ike or an IPsec action and then
the IKE/IPsec actions had a columb to point at saNegotiationAction....
then we could re-use common timout type parameters.

---

From: "Casey Carr" <[email-masked]>
Date: Thu, 10 May 2001 08:57:42 -0400

> Sent: Wednesday, May 09, 2001 4:55 PM
> To: Wes Hardaker
> Cc: [email-masked]; IPSec Policy WG
That seems reasonable but it adds complexity to maintaining the
saNegotiationAction for cleanup.  If a saNegotiationActon row is to be
deleted then there has to be a check to make sure it is not referenced from
by an IKE/IPSec entry.  Plus, how do you prevent a user from changing a
column in the saNegotiationAcion to accommodate one IKE/IPSec action without
inadvertently changing another one pointing to the same column?  Is this
price paid for this much additional logic worth the storage for four or five
extra integers per IKE/IPSec action?