Re: Issue# 1-Security Policy Definition

["Abdallah Rayhan" <arayhan@xxxxxxxxxxxxxxxxxx>]

"Angelos D. Keromytis" wrote:

> >[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] It still does not make sense. If you have a policy with strong
encryption and there is a remote user trying to access your domain
with a weaker set of requirements, there is a policy configuration
problem and that user should not and will not have access to the
policed domain. Otherwise it is violation of the security policy of
that domain. If the remote user cares to access the domain
then the domain admin should install the proper configuration
into the user system and not allow weaker encryption operation
to take a place. This issue is outside the scope of IPSP.