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

Re: policy expressive power in IPSec-VPN policy draft

[ NOTICE!  This list will be hosted at lists.tislabs.com as of March 26.
There is no need to resubscribe, if you are on the list, you will remain
on it.  Just begin sending posts, and any administrative requests to
lists.tislabs.com as of now.  List mail to tis.com will cease to be
delivered as of March 26, 1999.  ]

Hi Partha,

Thanks for your reply, I have a few more questions concerning the
policy  examples, though:

In scenario 1 in section 8.1.3, a rule is specified for Quick Mode
negotiations (dn: cn=S1-S2-isakmp-QuickMode-rule, o=XYZ, c=US). Is it
necessary to explicitly state this rule even though it coincides with
the PolicyCondition that is supposed to trigger IPSec processing ?
Shouldn't the default rather be to respond to Quick Mode negotiotiations
and rather use an explicit deny rule if that should not be the case ?

In section 8.1.2 number 3 the following rules applying to S1 are listed:

                dn: cn= S1-S2-AHESP-rule, o=XYZ, c=US
                Objectclass: Policy
                PolicyType: IPSecDataLocal
                PolicyConditionRef: cn=S1-S2-AHESP-traffic, o=XYZ, c=US
                PolicyActionRef: cn=clearIPSecSecurityAction, o=XYZ,
c=US


                dn: cn=S1-S2-AHESP-traffic, o=XYZ, c=US,
                Objectclass: IPPolicyCondition
                SourceIPAddressRange: S1
                DestinationIPAddressRange: S2
                IPProtocolRange: 50-51 (i.e. AH and ESP)

These rules describe that IPSec packets (created by S1) destined to S2
may be forwarded by S1. Couldn't it be assumed, by default, that if a
machine secures an outgoing packet that it created itself, it should be
able to forward it ? Otherwise it would not have made sense to secure it
in the first place. The text states that this rule is used to specify
"whether S1 and S2 can communicate directly or a gateway has to be
traversed", but isn't this already taken care of by specifying a
different IPSecTunnelEndpoint ?

And finally, what is the reason behind having a PolicyType of
IPSecDataLocal and IPSecDataRemote ? Wouldn't PolicyType=IPSecData have
sufficed in all the cases ?

Regards,

Chris


"Partha P. Bhattacharya" wrote:

>  We will update this draft soon. We will align the schema to the base
> policy schema that isbeing defined by the POLICY wg. One reason for
> have having explicit proxied info in the action is that the job of the
> policy searchmodule is simple. It just returns the action module which
> contains all the info. Imagine multiplerules where the conditions are
> different but the actions are the same. The search engine willhit one
> rule but then it will have to collect all the selectors from all the
> rules that point tothe same action in order to form the IDci, IDcr.
> Currently in IPsec only one range/subnetcan be negotiated but in the
> future this may change and multiple ID lists may be allowed.
> Theseattributes 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, explicitphase 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
References: