RE: IPSP topics

[Arnold.Jansen@xxxxxxxxxxxxxxx (Arnold Jansen)]

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
VERSION:2.1
N:;A
REV:20000407T220923Z
END:VCARD