[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Issue# 1-Security Policy Definition
>[AR] I disagree, if it is IKE stuff, then leave it to IKE to sort it out!
>I believe that if pre-IKE interoperability is to be resolved properly
>then IPSec WG should work on this item, for example, by introducing
>profiles. If you implement this profile, then I would be able to establish
>IKE/IPSec SAs smoothly, otherwise I would have to examine every
>proposal and transform to see if it matches anything I am willing to
>enforce! If attempts to resolve this type of policy issues going to
>fail with IKE, then what is the point of negotiating it here; it is going
>to fail in this phase because it is going to fail in IKE any how!
>In the ATM forum, they have resolved these issues
>by utilizing profiles to accomplish interoperability of security signaling.
The point is that SPD and SA combinations are not independent of each other;
access to a network behind a firewall may be dependent on whether you are
using strong encryption or not. This is part of that domain's policy, and
as such should be made known to the remote user/host/network/firewall.
>[AR] There is a big difference and greater implication as well.
>If you have a firewall allowing certain applications to go through
>and an intruder manages to install filter into your device, you
>would be vulnerable to open attacks by others not to mention
>first the failure to protect the system from the intruder!
>The fact that the policy is IPsec oriented does not mean
>that IPSec is applied. Some rules may have IPsec enforcement
>as optional. Oneway or another, the IPSec policy infrastructure
>will be used to install filters on the fly for application traversing
>firewalls!
Agreed.
-Angelos