Subject: a question on SPP draft ...

From: Elwin Eliazer <[email-masked]>
Date: Mon, 23 Apr 2001 11:11:21 -0700 (PDT)

Hi,

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.

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

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

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.

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

How is this ambiguity resolved?
The above examples are very simple cases.
More complex cases can be arrived at, that
are practically possible. The fundamental
problem in merging arises from the inherent
ordering of policy rules, and it is difficult
to merge (or not possible to correctly merge)
when there are ambiguious cases, and i believe
these ambiguity are very likely cases.

Would like to hear others opinion on this.

regards,
Elwin.

=====
-------
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/

---

From: Matthew Condell <[email-masked]>
Date: 27 Apr 2001 12:25:37 -0000

Sami,

> I realize this, but this would seem to be less efficient than checking
> against an ordered list.  Or am I mistaken?

Well, yes and no.

If you linearly search a decorrelated list of policy rules, on average
it will be less efficient since there will be a larger list of more
complex policies to search.  No argument there.

However, there are at least two things you need to also consider when
looking at efficiency here.  

1) Searching no longer has to be linear.  You can attempt to optimize
your searches.  For example, you can keep a cache of the most recently
used policies, or move the most often used policies to the top of the
list.  Since they are decorrelated, these (and I'm sure other) techniques
can be utilized to speed up searching.

2) The process of setting up an end-to-end communication is much more
than just looking up SPD entries.  Decorrelation was introduced into
SPP to enable caching of policies from other policy servers, since the
policy exchange and resolution process is fairly expensive.

I don't have numbers to show that decorrelation is worthwhile
system-wide from an efficiency standpoint, but the benefit of being
able to cache policies for resolution seem to intuitively make a 
big difference.

> Eg. the correlated, ordered list:
>     1. 10.0.0.0/8 -> 10.0.0.0/8
>     2. 0.0.0.0/0   (catch all)
> 
> turns into the decorrelated
>     1. 10.0.0.0/8 -> 10.0.0.0/8
>     2. 0.0.0.0-9.255.255.255 OR 11.0.0.0-255.255.255.255
> 
> If I am using the decorrelated version and I have already checked step
> 1, the range checking is redundant.  I would like to optimize this
> redundancy from the policy checking that is actually used.
> 
> In addition, when doing an IKE negotiation to establish SAs that
> these policies require, the correlated (2) is negotiable whereas
> the decorrelated (2) is not (IKE does not, currently, support
> unions of ranges for instance).

The decorrelated rule (2) can be broken into two rules that can be
negotiated:
2. 0.0.0.0-9.255.255.255
3. 11.0.0.0-255.255.255.255

Besides, negotiating ranges with correlated policy rules in IKE can
encounter the same dangers as caching correlated policies in SPP,
so it's much safer to negotiate decorrelated policies in IKE.

Matt