[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
 
-----Original Message-----
From: Chris Bohme <chris@oskar.nanoteq.co.za>
Cc: 'ipsec@lists.tislabs.com' <ipsec@lists.tislabs.com>
Date: Thursday, March 18, 1999 2:13 PM
Subject: Re: policy expressive power in IPSec-VPN policy draft

>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: