[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: policy expressive power in IPSec-VPN policy draft
We will update this draft soon. We will align
the schema to the base policy schema that is
being defined by the POLICY wg.
One reason for have having explicit proxied info in the action
is that the job of the policy search
module is simple. It just returns the action module which
contains all the info. Imagine multiple
rules where the conditions are different but the actions are
the same. The search engine will
hit one rule but then it will have to collect all the
selectors from all the rules that point to
the same action in order to form the IDci, IDcr. Currently in
IPsec only one range/subnet
can be negotiated but in the future this
may change and multiple ID lists may be allowed. These
attributes are optional; so we attach defaults to imply the
selectors of the matched rule.
We allowed phase 1 rules and also explicit
pointers from IPSecAction. While redundant, explicit
phase 1 rules when you have
few rules; since in that case you don't need to specify the ISAKMPAction
in
every IPSec rule. The intended processing is
- found an IPSec rule
- if there is an attached ISAKMPAction take that
one
- else attemp to match the isakmp
rules
Partha Bhattacharya
>Hi,
>
>Can anyone
(esp. the authors) give an indication of the future of the draft
"An
>LDAP Schema for Configuration and Administration of IPSec based
VPNs" ? Because
>the draft expires in a few weeks, I'd like to know
whether there are any
>updates / new versions
planned.
>
>Basically I share the concerns raised by authors of
previous postings in this
>thread. The 'proxied objects' seem redundant,
as do explicit policy
>conditions/actions for ISAKMPPhase1 and
ISAKMPPhase2. Those extra rules make
>this schema bulky and I wonder why
they have been included. Is there anyone
>(authors maybe) who can shed
some more light on the subject
?
>
>Thanks,
>
>Chris
>
>
>
Follow-Ups: