[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: a question on SPP draft ...



Matthew,

> > Most IPsec/IKE implementations rely on an ordered list of
> > IPsec policies for policy matching.  Is there an efficient
> > method of converting the decorrelated representation into
> > an (efficient) ordered list, that only requires 'standard'
> > selectors (ie no exclusion lists or such)?
> 
> We don't have an algorithm for converting the decorrelated
> representation into a correlated version, however, I don't understand
> why that is necessary.  Decorrelated policy rules do not have to be
> represented using an exclusion list, it's just easier to write it that
> way when doing it by hand.  For example, !10.0.0.0/8 is equivalent to
> the inclusive list of ranges:
> 0.0.0.0 - 9.255.255.255, 11.0.0.0 - 255.255.255.255
> 
> In terms of searching, a set of decorrelated policies _can_ be used as
> an ordered list for SPD lookups. It's just a list of policy rules that
> have the same meaning no matter what order they are in.

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

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

IKE will be undergoing changes in the near future, but from what
I understood from the WG charter, the work should be in line with
the current IPsec RFCs.

-S