Re: Issue# 1-Security Policy Definition

["Abdallah Rayhan" <arayhan@xxxxxxxxxxxxxxxxxx>]

See comments below!

Abdallah

"Angelos D. Keromytis" wrote:

> In message <399C3D46.179E716F@xxxxxxxxxxxxxxxxxx>, "Abdallah Rayhan" writes:
> >Issue# 1-Security Policy Definition
> >
> >What is the policy that we are trying to address here?
> >
> >   1-Is it a pre-IKE/IPSec initialization process, e.g,
> >     the SA parameters needed to make IKE/IPSec run
> >     smoothly (pre-IKE interoperability)?
>
> Yes, but as a side-effect of (2).

[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 only place where I see this type of policy supported in the policy
model is in the distribution phase between servers and gateways!


> >   2-Resolving the tunneling issues of IKE/IPSec? e.g.,
> >     how to build IPSec tunnels across multiple gateways?
>
> This is the main goal of the WG as specified in the charter.

[AR] Tunneling issues are important part of policy, so they should
be included!

> >   3-Defining IPsec-gateway traversal policy? e.g.,
> >     allow certain policy (filtering rules) to be
> >     defined on the fly and enforced on the IPSec
> >     packets traversing certain gateways (open
> >     pinholes in the gateway for particular
> >     applications)!
>
> I'm not sure what you mean here (in particular, how it's different from (2)
> in any significant way).

[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!

> >   4-Providing low-level policy infrastructure to
> >     facilitate installing network (high-level) policies
> >     into network devices? In this case, what is the
> >     difference between the two? e.g, provisioning,
> >     and how to map the two?
>
> We are not touching high level policy in this WG. At all.

[AR] I leave this to the members of the group. However my
2 cents is we should support this!