Subject: Q on policy negotiation

From: Ricky Charlet <[email-masked]>
Date: Tue, 9 Mar 1999 10:55:23 -0800

Howdy ()
	Here is a question for you policy gurus (I only sort-of read this
list with a peripheral interest).
	In IPSec, we have the notion of negotiating proposals. A Policy
Entry will be a set of [if condition,( (do actions 1 and 2) or (do actions 3
and 4) or (do action 5) )] When the condition is first satisfied, the two
endpoints of an IPSec association negotiate with each other to see if they
have some set of matching actions and then pick those actions to be the
policy enforcement rule for the rest of the lifetime of the security
association.

	So my question is, have draft authors been allowing for this
'proposal set negotiated down to particular enforcement set' in your policy
architectures?

	Now, like I said, I dont read the drafts in this group with too much
attention to detail so I could be bad wrong about the following, but here
are my percptions:

	In draft-ietf-policy-arch-00.txt, no specific mention of policy
proposal set negotiated to enforcement set occurres. A policyNegotiation
might best fit in section 4.1.5, policy Trigger and Rule Location.

	In draft-ietf-policy-core-schema-01.txt no specific mention of
policy proposal set negotiated to enforcement set occurres. Perhaps an
attribute in Class:policyRule called policyRuleProposalList would do nicely.
Similar thoughts for the associated draft-ietf-policy-framework-pfdl-00.txt.

###################################
#  Ricky Charlet
#   [email-masked]
#  (510) 795-6903
###################################
end Howdy;

---

From: [email-masked]
Date: Tue, 9 Mar 1999 15:39:37 -0500

Ricky

While it's not the only way to go, here's a solution to your
requirement that occurred to me:

1. Define a subclass of policyAction, say negotiateAndApplyIpsecActions.

2. Your policyCondition now points to whatever condition(s) triggers
   the negotiation, and it points to one instance of this new subclass
   as its action.

3. The subclass has an attribute that points to one or more action
   candidates to be proposed in the negotiation.  This attribute can
   be a simple multivalued DN pointer, or it can have whatever
   ordering and/or grouping you need based on the rules for the IPSec
   negotiation.  (More of the 'n:DN'ery.)

4. The semantics for negotiateAndApplyIpsecActions are just what the
   name suggests.  First the negotiation is carried out, to determine
   which action(s) to use for the association.  Then, once the
   negotiation has been completed, the winning actions are actually
   applied on the association.

I may have some of the details wrong, since, to paraphrase you, "I
only sort-of read <the IPSec mailing list> with a peripheral interest."
But I think my main point is correct:  the Core Schema classes model
only the most basic relationships among rules, conditions, and
actions.  More complex relationships require subclasses.

The counterargument to this would claim that the pattern

"if <condition(s)>
 then (negotiate <actions> and then apply the winning <action(s)>)"

is, while not quite as fundamental as

"if <condition(s)>
 then <action(s)",

still fundamental enough to merit a place in the Core Schema.  I'd need
to see several other instances of this pattern, though, and see that
the negotiations play the same role in all of them, before I'd agree
that negotiated actions belong in the Core Schema.

Regards,
Bob

Bob Moore
IBM Networking Software
+1-919-254-4436
[email-masked]

---

From: Charles Lynn <[email-masked]>
Date: Wed, 10 Mar 99 10:21:36 EST

Ricky,

The points you raise will be needed for the "simple VPN" scenario.
In the bigger picture, something more may be needed - "dynamic
binding" of the enforcement points.  Consider the case where there
are both end-to-end IPSec and security gateways (enforcement points).
The policy may be of the form "everything leaving/entering the domain
must be authenticated".  One could enumerate all the possibilities:
	end-system AH
	end-system ESP authentication with NULL encryption
	end-system ESP authentication with encryption algorithm 1
	end-system ESP authentication with encryption algorithm ...
	end-system ESP authentication with encryption algorithm N
	security gateway AH
	security gateway ESP authentication with NULL encryption
	security gateway ESP authentication with encryption algorithm 1
	security gateway ESP authentication with encryption algorithm ...
	security gateway ESP authentication with encryption algorithm N
or one could abstract out the "enforcement point location" to try and
simplify things.

When domains are nested, or transit domains enter the picture, the
combinatorial explosion gets even worse.

When a domain has multiple enforcement points, they may not all
provide the same services to all types of traffic.  A mechanism to
guide certain traffic within a domain to a specific enforcement point
is needed, i.e., a point to which current routing would not deliver
the traffic .  (The IPv6 Routing Header discussion over on the
mobile-ip, ipng, and ipsec lists is one mechanism to accomplish this,
plus introducing several additional requirements for the objects in
the policy language.)

Charlie