Subject: Re: a question on SPP draft ...

From: Matthew Condell <[email-masked]>
Date: 23 Apr 2001 19:17:08 -0000

Elwin,

> I am referring to the SPP defined in
> draft-ietf-ipsp-spp-00.txt.
> SPP relies heavily on the capability to merge
> policy rules from different places. I think
> this merge is not *always* feasible.

SPP avoids the problem you describe by requiring that all the
policies that are exchanged be decorrelated -- that they do 
not have overlapping conditions so there is no inherent ordering
constraint.  (There was more information about decorrelation 
in an earlier draft submitted to the IPsec WG that was pulled out
of this version of the draft in anticipation of it going into
a different draft which never materialized).

I'll work through your example to illustrate:

> Take for example a host H1, configured with
> policies:
> 
> SRC-IP      DestIP         Action
> ------      ------         ------
> 0.0.0.0/0   150.1.0.0/16      A1
> 0.0.0.0/0   0.0.0.0/0         A2

SRC-IP      DestIP            Action
------      ------            ------
0.0.0.0/0   150.1.0.0/16        A1
0.0.0.0/0   not 150.1.0.0/16    A2

> And policy server PS2, having the following
> policies for H1:
> 
> SRC-IP      DestIP         Action
> ------      ------         ------
> 0.0.0.0/0   150.1.2.0/24      A3
> 0.0.0.0/0   150.0.0.0/8       A4
> 0.0.0.0/0   0.0.0.0/0         A5

SRC-IP        DestIP          Action
------        ------          ------
0.0.0.0/0     150.1.2.0/24      A3
0.0.0.0/0     150.0.0.0/8       
              which is not also 
              in 150.1.2.0/24   A4
0.0.0.0/0     not 150.0.0.0/8   A5

> When the SPP fetches the policies for H1, how
> are these merged into H1, since there are
> different merged outcome possible, two of which
> are listed below.

SPP will only fetch 1 policy rule at a time -- the one relevent to the
requested communication.  So, for example, if the request was for policy
between 10.0.0.1 and 150.0.0.1 the two relevent rules would be exchanged:

SRC-IP        DestIP          Action
------        ------          ------
0.0.0.0/0   not 150.1.0.0/16    A2
and
0.0.0.0/0     150.0.0.0/8       
              which is not also 
              in 150.1.2.0/24   A4

The resulting merged policy rule would be (asuming I had merged
these correctly...):

SRC-IP        DestIP                       Action
------        ------                       ------
0.0.0.0/0     150.0.0.0 - 150.0.255.255
          and 150.2.0.0 - 150.255.255.255   A2 ^ A4
 
> Merged-outcome-1-at-H1:
> 
> SRC-IP      DestIP         Action
> ------      ------         ------
> 0.0.0.0/0   150.1.2.0/24      A3
> 0.0.0.0/0   150.1.0.0/16      A1
> 0.0.0.0/0   150.0.0.0/8       A4
> 0.0.0.0/0   0.0.0.0/0         A5
> 
> Merged-outcome-2-at-H1:
> 
> SRC-IP      DestIP         Action
> ------      ------         ------
> 0.0.0.0/0   150.1.2.0/24      A3
> 0.0.0.0/0   150.0.0.0/8       A4
> 0.0.0.0/0   150.1.0.0/16      A1 /* may be deleted */
> 0.0.0.0/0   0.0.0.0/0         A2

Since we are not merging sets of policy, we don't need to
do these, but with the decorrelated policy, the merge 
could be done.

Hope this clarifies things,

Matt Condell
BBN Technologies

---

From: Elwin Eliazer <[email-masked]>
Date: Tue, 24 Apr 2001 20:45:38 -0700 (PDT)

Matthew,

Do you expect policy server to run the
decorrelation algorithm? And represent
policies in decorrelated form?

The decorrelated representation can
result in a big exclusion list.
The implementations i have seen all use
only ordered policy lists.

Thanks,
Elwin.

> Hope this clarifies things,

=====
-------
Elwin Stelzer Eliazer
Corona Networks
San Jose, CA
408-519-3832
-------

__________________________________________________
Do You Yahoo!?
Yahoo! Auctions - buy the things you want at great prices
http://auctions.yahoo.com/