Re: IPSP topics

[Yaron Sheffer <yaron.sheffer@xxxxxxxxxxxx>]

Hi Arnold,

I agree with your discussion as far as it describes the current state of the
art. But I don't think this is the right direction for the long term.

Current thinking is based on templates and they have an analogous set of
problems as macros (to any of you who are C programmers). They are context
dependent and imprecise, or as you phrased it, "qualitative". But there is no
reason *in principle* why high-level (network) policies cannot be formal and
well defined, when after all these policies are talking about collections of
objects that are all formally described in the CIM.

And of course, a formal policy representation can in itself improve the security
of the installation.

For the time being, I have to agree with Angelos that this is still a research
topic. But I'd be happy if someone can disprove this view with an example.

Thanks,
    Yaron

Arnold Jansen wrote:

> I would agree with Cliff that a service provider or large corporate
> customer will try to standardize its VPN services and topological
> elements as much as possible to facilitate large scale roll out and limit
> diversity and proliferation of policy information in the network.
> The examples he gave are pretty good in this sense.
> Also it will enable relatively unqualified service personell to provision
> such a VPN service without getting lost into details. That is the promise of
> policy based networking. There will be a seperation as well in those who can
> define these service provider policies for VPN services in general, and
> those who will apply these on a given VPN instance.
>
> I think this will be done by a concept of "VPN templates" in which
> generic node types and roles within a VPN are defined to which "reusable"
> sets of policies (or policy macros if you want) can be assigned. What these
> higher level macros or templates look like will be largely customer specific
> and holistic of nature and therefor difficult to standardize. These high
> level policies will tend to express more a qualitative statement then a
> quatifiable and measurable statement and one high-level policy may involve
> multiple physical networking entities for enforcement.
>
> However, in the end all these "holistic" or high level policies that have
> meaning in the real world of people (e.g. to which policies the entities
> within a
> public, private or top-secret network perimeter should adhere when
> communicating) should be translateable into policy contructs or sets of
> atomic policy primitives that have meaning on the network level for
> enforcing them. These policy primitives will in any case define the words
> and the semantics with which we can build higher level policy statements
> later.
>
> The common info models proposed for policies do contain PolicyGroup
> contructs
> that can group policies in arbitrary ways which could be the mechanism to
> define
> useful collections of low level policies into higher level contructs.
> These higher level policies will just exist in the service management system
> and do not instantiate at network element level prior to being used in a VPN
> instance. They are meta policies. I think the work group should define in an
> unambiguous way which lower level primitives to standardize so that they can
> later serve to map higher level policy specifications over multiple
> administrative domains between SPs by means of what you could call
> interworking policies.
>
> To support and validate the work of defining these low level policy
> primitives it will however be very useful to define a good set of high-level
> policies and see
> how they would translate into lower level primitives in a consistent and
> non-conflicting manner. These examples can be informative and show the value
> and use of policies in a certain context rather then normative.
> I hope this adds to the discussion.
>
> Regards,
>
> Arnold Jansen
> Architect & Product Manager
> IP VPN Business Unit
> Alcatel Carrier Internetworking Division
> 720 South Milpitas Blvd
> Milpitas CA 95035
> tel: +1 408 586 1074
> cell: +1 408 209 7036
> fax: +1 408 586 7686
> e-mail: arnold.jansen@xxxxxxxxxxxxxxx
>
> -----Original Message-----
> From: owner-ipsec-policy@xxxxxxxxxxxxx
> [mailto:owner-ipsec-policy@xxxxxxxxxxxxx]On Behalf Of Wang, Cliff
> Sent: Friday, August 18, 2000 6:57 AM
> To: 'Angelos D. Keromytis'
> Cc: arayhan@xxxxxxxxxxxxxxxxxx; horman@xxxxxxxxxx; ipsec-policy@xxxxxxxx
> Subject: RE: IPSP topics
>
> I don't think we should label high level policy issues as a research
> project or a rat-hole. Think about this case:
> A Bank would need to roll out a 2,000 node VPN network. Can you afford
> to use an IT team to define per-node policy? You probably would need to
> define a high level policy first, such as (just as a quick example):
>
> Note type:
> Headquarter Gateway
> Regional Gateway
> Branch node
> Home office node
> Mobile node
>
> Data protection policy:
> Banking Customer data protection
> Corp sensitive data protection
> Regular data protection
>
> Authentication method:
> Cert
> Preshared
> Kerbero
> .....
>
> Topology:
> For a group of nodes, using fully meshed or
> hub and spoke.
> Gateway redundancy
>
> Monitoring policy:
> High    (such as every 30 sec)
> Medium  (such as every 20 min)
> Low     (such as every 2 hour)
>
> Box credential update policy
> High
> Medium
> Low
>
> and much more.
>
> If you can define a high level of abstraction and then translate the
> requirements
> into per-node configuration and monitoring requirement, I think life will be
> much
> better for the people who really will deploy and use VPN.
>
> It would be a nightmare to configure and manage the 2000 nodes on a per-node
> basis.
>
> -----Original Message-----
> From: Angelos D. Keromytis [mailto:angelos@xxxxxxxxxxxxxxxxx]
> Sent: Thursday, August 17, 2000 6:07 PM
> To: CWang@xxxxxxxxxxxxxx; angelos@xxxxxxxxxxxxxxxxx
> Cc: arayhan@xxxxxxxxxxxxxxxxxx; horman@xxxxxxxxxx; ipsec-policy@xxxxxxxx
> Subject: RE: IPSP topics
>
> I think the disconnect between high and low level policies has yet to be
> demonstrated anywhere, whereas flexibility in dealing with different low
> level devices is part of a number of products. This is not conclusive
> evidence (and I can believe that if one were to think about it, they could
> create a high-level and a low-level policy language/system that wouldn't
> work well together).
>
> However:
> a) IPSP started with and should remain focused on the issues it tried to
> resolve; trying to expand the charter has resulted (in other WG) in no
> work getting done.
> b) The topic of high-level policies is vague enough, that it's not
> well-suited
> to the IETF; remember, we're not trying to do research, but apply already
> known solutions to problems considered important.
>
> In short, dealing with high-level policy issues in IPSP is what's commonly
> refered to as a rat-hole :-)
> -Angelos

begin:vcard 
n:Sheffer;Yaron
tel;cell:+972-51-628922
tel;work:+972-3-765-8922
x-mozilla-html:TRUE
url:www.radguard.com
org:Radguard
adr:;;Atidim Technology Park, Bdg #4;Tel Aviv;;61581;Israel
version:2.1
email;internet:yaron.sheffer@xxxxxxxxxxxx
title:Group Leader, Technologies
fn:Yaron Sheffer
end:vcard