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

Re: a question on SPP draft ...



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.

--- Matthew Condell <mcondell@xxxxxxx> wrote:
> 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


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