[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. ]
Responses inline.
-----Original Message-----
From: Chris Bohme <chris@oskar.nanoteq.co.za>
To: Partha P. Bhattacharya <pbhattac@cisco.com>
Cc: ipsec@lists.tislabs.com <ipsec@lists.tislabs.com>
Date: Tuesday, March 23, 1999 1:30 AM
Subject: Re: policy expressive power in IPSec-VPN policy draft
>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 ?
When the draft was written, the thinking was to create an explicit rule
for every type of packet that a host sees. That way, the devices could be
"dumb" and just attempt to match a rule with the packet header.
The rule that triggers IPSec processing has S1 and S2 in the policy
condition. But a quick mode packet for a responder has the gateway
addresses in the packet headers and S1 and S2 appear inside
the payload. If we don't have the extra rule you mention, we have to look
for a rule with matching S1, S2. This is certainly possible. However
our experience has indicated that this may not lead to fast processing.
(It is "easier" to match rule sets with a point as given input than with a
set
as a given input; note S1, S2 can be sets)
We have realized that the current method leads to an explosion of rules in
the
repository. So, in the next draft, we will only have one or two rules that
will
describe the traffic going into an IPSec tunnel and let the devices
internally
create the derived rules as necessary.
>
>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 ?
In the general case, security requirements may require nested IPSec
processing.
Think of a remote corporate machine on the Internet that has to do
end-to-end
IPSec and at the same time has to traverse a gateway to enter the corporate
net.
In such cases, an IPSec packet may need to go through another layer of IPSec
processing. In some other cases though, an IPSec packet goes in the clear.
The
above rule was created to let a host differentiate between the two cases.
The
processing rule is then to keep recursively looking for a rule until you hit
the clear
rule.
>
>And finally, what is the reason behind having a PolicyType of
>IPSecDataLocal and IPSecDataRemote ? Wouldn't PolicyType=IPSecData have
>sufficed in all the cases ?
The PolicyType of IPSecDataLocal was for traffic going into an IPSec
"tunnel"; the
PolicyType of IPSecDataLocal was for traffic coming out of a tunnel. The
latter rule
was created to disallow "spoofed" packets that are supposed to come inside
of
an IPSec tunnel. Again, this is a derived rule that was supposed to ease
IPSec
processing on the host. For a spoofed packet that came in the clear, the
policy
engine would match this rule and discard the packet by noticing from the
IPSecSecurityAction that the packet shd have received inbound IPSec
processing.
>
>Regards,
>
>Chris
>
>