Subject: Policy Framework and IPsec policy

From: Matthew Condell <[email-masked]>
Date: Wed, 28 Jul 1999 08:35:17 -0400 (EDT)

[Sorry for the repeated message to ipsec-policy.  The policy address
 is now spelled correctly]

Hi,

I've been reviewing the policy WG drafts from the perspective
of IPsec policy.  My interest is more in framework issues than
data model/schema issues.  Most of my comments are based on
draft-ietf-policy-terms-02.txt.  

In general, I believe the general policy framework works well 
with the security policy framework, except it one basic assumption.
The general policy framework is based on an intra-domain model
where as IPsec policy MUST deal with inter-domain issues.

However, I think a few modifications to the model would allow
IPsec policy to fit in the framework, without disturbing the
intra-domain model that is already present.

In draft-ietf-policy-terms-02.txt:

Section 4.1:

For inter-domain policy negotiation, different domains will not
share a policy repository, so it is necessary for the PDPs to 
be able to communicate with each other.  We should make sure 
that the architecture does not prohibit this.

Section 5.10:

Inter-domain policy conflicts are not necessarily resolvable, 
since it is not really possible to choose one conflicting 
policy over the other.

Additionally, to allow inter-domain policy caching, it is necessary to
be able to maintain (either in the repository or PDP) policies in a
non-overlapping form. (draft-ietf-ipsec-spp-00.txt refers to
non-overlapping policies as decorrelated.) In decorrelated form, the
conditions of no two policies can be simultaneously satisfied.  The
framework must be able to support such a set of policies to enable it
to support IPsec policy.

This example shows why decorrelation is necessary for an inter-domain
policy framework.  (The example is from the Security Policy Sytem
Architecture draft which is not yet published.)

>Caching correlated policies can lead to incorrect policy
>implementation based on those cached policies, as the following
>example shows.
>
>           H1 --- SG1 --------- SG2 --- H2
>                   |             |  \__ H3
>		    |             |
>		   PS1           PS2
>
>PS2 contains the following policies in its master file:
>	src	dst	proto	direction	action
>   1)	*	H2	*	inbound		permit
>   2)	*	*	*	inbound		deny
>
>These two policies are correlated since all the selectors (src, dst,
>proto, and direction) overlap.  The following SPP exchanges occur:
>
>  1)  PS1 requests policy for H3.
>  2)  PS2 returns policy #2 to PS1 which then caches policy #2.
>  3)  PS1 now looks up the policy for H2 and discovers that it already
>      has a matching policy (policy #2) and uses that.
>
>This is clearly wrong, since policy #2 indicates that the
>communication to H2 should be denied, though PS2's policy actually
>indicates that it should be allowed.
>
>	The solution is to remove the ambiguities that may exist in
>the master file.  The policies of the master file MUST be decorrelated
>before they are entered into the Local Policy Database.  That is, the
>policies must be rewritten so that for every pair of policies there
>exists a selector for which there is a nil intersection between the
>values in both of the policies.
>
>The policies in the above example could be decorrelated as follows:
>	src	dst	proto	direction	action
>   1')	*	H2	*	inbound		permit
>   2')	*	not H2	*	inbound		deny
>
>Now the exchange is a bit different:
>   1)  PS1 requests policy for H3.
>   2)  PS2 returns policy #2' to PS1 which then caches policy #2'.
>   3)  PS1 now looks up the policy for H2, doesn't have a matching 
>       policy, so it requests a policy for H2.
>   4)  PS2 returns policy #1' to PS1 which then caches policy #1', 
>       which is the correct policy for H2.
>

These are the main points where I believe the IPsec policy framework
diverges from general policy framework.

Matthew Condell
BBN Technologies

---

From: "He Huang" <[email-masked]>
Date: Wed, 28 Jul 1999 13:13:15 -0400

Hi, 

Certainly, before one policy is saved in policy repository/master
database, it's necessary to do conflict detection and resolution. The
question is that who is responsible for that work, PolicyFramework or
LDAP itself(Assume repository is LDAP directory). In addition, Policy
Framework suggests two solutions for policy conflict(
draft-strassner-policy- terms-00.txt): first matching rule and priority
rule. It seems not to work well in some situations. Any new solution for
policy conflict?

---

From: Matthew Condell <[email-masked]>
Date: Wed, 28 Jul 1999 13:46:40 -0400 (EDT)

Hi, 

>rule. It seems not to work well in some situations. Any new solution for

There are really two levels of conflict resolution when dealing with
inter-domain policy.  The intra-domain conflict resolution which can
be solved using first match or priorities.  

Inter-domain conflict resolution is different, however.  If two
policies that are from different domains conflict about a particular
communication, there is no appropriate resolution since the two
policies are established by two different administrative domains. The
communication may just not be possible.  The framework should
acknowledge this possiblility to not exclude inter-domain policy from
fitting withing the framework.

Matthew Condell
BBN Technologies

---

From: "Ryan Moats" <[email-masked]>
Date: Wed, 28 Jul 1999 13:08:16 -0500

| Hi, 
| 
| >Certainly, before one policy is saved in policy repository/master
| >database, it's necessary to do conflict detection and resolution. The
| >question is that who is responsible for that work, PolicyFramework or
| >LDAP itself(Assume repository is LDAP directory). In addition, Policy
| >Framework suggests two solutions for policy conflict(
| >draft-strassner-policy- terms-00.txt): first matching rule and priority
| >rule. It seems not to work well in some situations. Any new solution for
| >policy conflict?
| 
| There are really two levels of conflict resolution when dealing with
| inter-domain policy.  The intra-domain conflict resolution which can
| be solved using first match or priorities.  
| 
| Inter-domain conflict resolution is different, however.  If two
| policies that are from different domains conflict about a particular
| communication, there is no appropriate resolution since the two
| policies are established by two different administrative domains. The
| communication may just not be possible.  The framework should
| acknowledge this possiblility to not exclude inter-domain policy from
| fitting withing the framework.

Just a technology note.  LDAP is not going to do conflict resolution
beyond anything provided by LDUP (replication conflict resolution).
Conflict resolution that involves syntactical interpretation of the data
is not something LDAP does (or was ever intended to do).

Ryan

---

From: John Schnizlein <[email-masked]>
Date: Thu, 29 Jul 1999 15:45:06 -0400

At 01:13 PM 07/28/1999 -0400, He Huang wrote:
>LDAP itself (Assume repository is LDAP directory)...

This is not the question. An LDAP (repository) cannot be responsible
for detecting and resolving conflicts in the semantics of a policy.
Its capability is limited to detecting conflicts (most would call 
these attribute or syntax violation rather than conflicts) between
input attributes/values and the schema.

Matthew's point is that there are potential semantic conflicts between
different administrative domains even after all internal conflicts are
resolved in each domain. The assumption is that some negotiation is
necessary between the domains. If I understand his proposal, this
negotiation is easier if those rules that might conflict (are relevant
to the other domain) are separated and disambiguated with those of the
other domain as early in the process as possible.

Even though this proposal requires an explicit negotiation cycle, in
addition to a distinction in the policy store we have not considered
in the policy framework WG, is much more attractive than surprises
when the execution of policy is other than what was intended.

Have security folks determined if there is sufficient value in keeping
policy for different domains in separate subtrees of the DIT?

John

---

From: "Bernie Volz" <[email-masked]>
Date: Fri, 30 Jul 1999 09:30:43 -0400

FYI - Have implemented NFS (and other caching protocols) on platforms that
were not native to NFS, I have one piece of advice for doing caching. It is
best to use cached data ONLY when the question is the same. So, in your
examples, PS1 could only use the cached data (that it got for H3) if it was
again trying to see what the policies were for H3. It could not use it if it
was asking what the policies where for H1. The more complex a system of
conditions you have, the more important this becomes. I feel the PS<n> can
not assume that information it got about one question applies to a
completely different question. This does make caching less useful (and
requires the cache to store much more), but it really is the only safe way
to go, IMHO.

It also avoids your problem (though it doesn't resolve the issue of
conflicting policies in separate administrative domains).

- Bernie Volz
  Process Software

---

From: Matthew Condell <[email-masked]>
Date: Fri, 30 Jul 1999 10:52:49 -0400 (EDT)

Caching policies from another server is actually safe, if you can
guarantee that all the servers keep their policies in a decorrelated
form.  (More on this below.)  The system we have for exchanging IPsec
policies requires all policies to be decorrelated, so our policy
servers *can* assume that information it got about one question
applies to a completely different question, if the conditions match.

Decorrelation is a process that removes all overlap of the conditions
in a set of policy rules.  The process maintains the implicit
information about the policies that is contained in the rule ordering
(using either first match or priorities).  As a result, a question
can only match the conditions of *one* policy rule.  Also there is no
longer any need to order the policies.

Decorrelation is explained in more detail in draft-ietf-ipsec-sps-00.txt.  
An algorithm for decorrelation is also presented there.  (The draft
has expired, but is still in the drafts repository.  The draft is
currently being reworked and split into multiple drafts.  The new
draft with the decorrelation process is still in the works.)

My main concern here is to make sure that the policy framework doesn't
prohibit policies to be stored in the repository in a decorrelated
form so that an inter-domain policy protocol that requires
decorrelation will still fit into the gereral policy framework.

Matthew Condell
BBN Technologies