2.2.2 Policy Framework (policy) bof

Current Meeting Report

POLICY BOF MINUTES

Minute-takers: John Strassner and Ed Ellesson
Time: Chicago IETF: Monday, 24 August, 7:30 - 10:00pm

Introduction - Ed Ellesson
Ed provided an overview for starting up a working group and what this BOF will cover.
The objectives are:

- to scope out the problem space, make sure we understand it
- outline the solution architecture, make sure it's one we can all live with
- outline what work items need to be addressed
- assess interest in a common policy representation
- figure out where we go from here.

The objective is to define a common hierarchical name space for policy management
and administration, intended to serve as a logically centralized policy repository for a
single domain that could be physically distributed, and progress this to a logically
centralized policy repository that coordinates the definitions and actions of its separate
policy repositories. A set of RFCs aimed at the Standards track will be produced, with
supporting Informational RFCs (e.g., Schema Guidelines) as necessary.

It should also be noted that Schema Registration is not enough. The process of Schema
Registration simply ensures that the schema is registered - it does nothing to ensure
that multiple schemata can interoperate. An important goal of this WG is to define
interoperability of policy through interoperable schemata.

Work has already began in several areas. Two drafts capturing foundational work are
the architectural framework and terminology drafts. These drafts help establish a
common view of the problem space and its architectural solution. Several schema
drafts have been created and documented in the form of Internet Drafts in various
WGs. Examples include:

- QOS Service Level Agreements (DiffServ and RSVP/IntServ)
(intended for this WG)
- VPN IPSEC (the IPSEC WG wants to keep ownership of this)
- RADIUS (undecided which WG will own this)
- DHCP (undecided which WG will own this)

All of these schemata need standardization, not just registration. They also need
definition within a common name space, and security support. If the IETF does not
form a Policy Framework WG, then the following are IETF process alternatives:

- form a separate working group formed for each schema definition
- define schema within each protocol working group
- define a common working group for all schemas
- leave it to another standards organization

None of these seem to be suitable alternatives. Note that at the end of the meeting,
there was consensus that this BOF turn into a WG.

Goals and Objectives - Fred Baker
Network Management - origins of this have been particularly successful in monitoring
information. There has been a succession of protocols to replace SNMP - they have
been different, but not better. Therefore, they haven't been allowed to proceed along
the standards track. So if you think of distribution of policy, this is in reality a different
type of network management. The IESG is going to allow this to go forward on a
standards track, but will be watching this very closely. They're concerned about the
potential lack of focus that could develop. Fred describes a need for a schema that will
allow a Service Provider to set up a set of policies in some well-defined way. The
thing that the policy is controlling hits a PEP, which in turn asks a PDP what it should
do. The PDP is going to talk to a database (e.g., policy repository) to get an answer.

(Note: the following paragraph is critical to the development of the Charter for this
group. Since several questions have already been asked about the relationship of
SNMP and the directory, Fred has graciously provided additional clarification to what
was said in the meeting that is incorporated here.)

Fred sees the use of the directory in networking (whether that is Directory Enabled
Networking or some other specific proposal is immaterial) as a potentially useful
configuration management paradigm, and potentially a useful paradigm for extracting
certain reports. It is a way to manage the *network*, as opposed to individual systems
*in* the network. It is, therefore, inherently different and more powerful than SNMP.
It is another framework, but the benefit of embracing it potentially justifies the cost.
Proving that it in fact does is part of the job of this effort. Therefore, using the
directory in networking does NOT replace SNMP per se; while it could be used to
implement the instrumentation of individual systems, that is not its current target.
Rather, it targets defining the outcome of system configurations ("VoIP should get a
certain kind of service in my network"), which individual systems will have to interpret
locally ("VoIP traffic is marked with diff-serv PHB 111000, and should be admitted
using RSVP and placed into the EF queue on each interface.") SNMP then becomes a
way to monitor and do certain kinds of configuration, while the directory manages
certain other aspects of configuration, and manual configuration is required perhaps
for yet other kinds.

Fred points out that in the QoS Policy example, we've actually been doing this for a
while now - it's called access lists. This is happening in real time, so we're not talking
about protocols, we're talking about APIs. And the only thing that we could standardize
in this area is the description of policy itself. However, this would be a Good Thing.

In the Login Access Control (AAA) example, there is an underlying legal requirement
in how it is handled.

Fred gave a few other examples. However, the point is that policy comes in many
flavors and there is not a single way to handle all of them. The plea: let's solve each
part of the problem once, and use them as building blocks. We're here tonight to write
a charter describing what problems we want to solve, a set of mechanisms for solving
them, and a resulting set of measurable goals. Non-goals are protocols (whether or
which are to be used - go to the AAA Bof) and detailed solutions (do this when we are
in a WG).

Question: what's different now than 2 years ago when a policy group tried to form?

Answer: For one thing, the industry has progressed and we have a better handle on
what policy is - we didn't have this 2 years ago. Also, we're talking at a different level
tonight that reflects progress in the industry with respect to specific implementation
schemata.

Question: are we talking about two paradigms - active network with a centralized
control, or rsvp-like decentralized control? Answer: No - what we are talking about
tonight is just schema. Other things, like protocols, are out of scope.

Proposed Charter - Ed Ellesson
We will provide a brief overview now in order to serve as motivation for the following
talks. Then, after the talks conclude, we'll come back to this if it seems like a charter is
called for.

We want to define the problem space, make sure that it is applicable to other WGs, and
outline an architecture that can solve this problem space. We are starting with a set of
very focused efforts.

We want to define a common hierarchical namespace for policy admin and mgmt so
that people can interchange and share policy definitions. There is a central (logical)
policy repository (within a given administrative domain) that contain policy definitions.

Schemas should be standardized - the architectural framework might be informational.
Note that schema registration is not enough, because that doesn't guarantee
coexistence, sharing and interoperability.

Need the guidelines draft to help subsequent groups add to and fit in with our work.

Architecture - John Strassner
Overview of the architecture will answer some of the questions that came up earlier in
the BOF.

All the major networking vendors are implementing policy servers. Customers will be
deploying them. How do we get these things to talk to each other? That is, to
understand a common view of the network administrator's view of what the policy
should be in that domain. This is not a central policy box that sits in the Internet and
decides policy for the entire Internet!

Policy was then defined in a meta sense. In our case, a policy-enabled system is a
declarative system that is used primarily for controlling device configuration. It
describes the desired state of devices in a network, not the changes needed to each
device to get to that state. It monitors the system and/or network to verify conformance
to the service level agreements that the policies implement and adjusts the system as
necessary to maintain that conformance. In general, it controls configuration of objects
to regulate access and use of resources. We need a common way to specify policies
policy management capabilities, policy error and control messages. To do this we need
a vendor-independent policy definition language.

Policy meta-model. SLA describes the business goal that we want to achieve. This fans
out into a number of Service Level Objectives. The set of them provides a set of policies
which describes the functions that need to happen in the network. The policy then links
to the conditions and actions that define when a policy is active. You can disable or
enable objects (e.g., SLOs, policies, conditions, etc.) at any level in this meta model. This
enables complex policies to be built from a set of simpler policies. This is critical for
scalability and manageability.

Suggestion: Diff Serv view of SLA is lower level than what we have define it. Should
we use a different term? Actually, the policy terms draft defines SLA and SLO at a
lower level than DiffServ does. This will get resolved when the WG is formed.

Policy Model: This is the DEN policy model, which seems like a good starting point
for us. A Policy object aggregates a set of PolicyConditions and a corresponding set of
PolicyActions. Policy objects can be nested to create complex, more hierarchical
policies. Question about resolution of policy conflicts. The work that has gone
forward has taken this into account in the form of schema hooks and in the form of the
language that is used to express policy.

An appropriate analogy seems to be to that of a set of policy "MIBs." This does NOT
mean that we are suggesting this as an implementation; rather, it is used to
demonstrate the same cross-vendor vocabulary that is needed for a consistent, coherent,
interoperable policy framework. Policy Conditions: forms of templates. Time of Day
formats, as an example. They are canonical so that interoperability can be achieved.
That is, there are a set of pre-defined policy condition types for domain-specific
functions. Policy statements include a set of policy condition elements that are
instances of these policy condition types. The policy condition elements are related
together to form a Boolean expression. The analogy is a pre-defined template that has
values that can be filled in - the values define the applicability of this set of conditions.

Question: what about abstract attributes, such as User Name, and Organizational Group.
This leads one to ask about extensibility for things we have not thought of at the beginning.

Answer: Yes, that is the objective, and we need the working group to address this. The
DEN policy model has some of this implemented; this WG will flush that out,
especially in the context of QoS for DiffServ, IntServ, RAP, and ISSLL.

Application of the Policy: Must be safe to apply, and do no harm. To do this, we
must know something about the current state of the network and/or environment, what
the effects of our policy change will be, and whether it makes sense. The policy
definition language can address this.

Suggestion: don't try to know too much about the environment, or you will make
inaccurate assumptions. Answer: good suggestion.

There are vendor-specific ways to define the way devices work. Policies address
conflict resolution satisfaction and feasibility, and this eventually gets turned into the
way the specific device works, but that is not what we are standardizing. We are
standardizing schema that represents the policy, and a language that can be used to
exchange and manage policy information and detect conflicts, among other things.
Policy conflict resolution can be arbitrarily difficult. Comment: this is an ambitious
task. Are all policies knowable or known? Answer: We mean that it is appropriate to
resolve conflicts about what we do know, and that we don't have to know about all of
the possible policies that exist, just those that effect our system.

Question: What about procedural methods? If this is just schema, do we not want to
tackle procedural stuff into the policy? Answer: You could bind values in the schema
to procedures. Problem with procedures is that the semantics can be hidden. We may
not understand the effects, and the conflicts. This could be taken up by the WG.

The architecture picture. The validation of policy may be a later thing. Maybe too big
a task. Let's concentrate on the schema.

Positioning of this Framework relative to other IETF WGs - various authors COPS and
RAP - Raj Yavatkar Talked about how RAP can use the output of this group and how it
can add to this group. Raj described the problem that RAP is solving - a device receives
a QoS request and contacts the PDP to decide what to do. The motivation, then, is for
this WG to provide schema that the PDP can use to provide the PEP with an answer.
Doesn't necessarily have to be limited to RSVP, but that is certainly a prime focus.
Gave a brief history of RAP. It was chartered to specify a framework for providing
policy-based control over QoS admission control decisions. Focused on policy-based
control over admission control using RSVP. Support for monitoring and accounting.

Focused on specifying the different operations between the PEP and the PDP. One is
outsourcing a decision from a PEP to a PDP. The other are configuration requests,
where the PDP configures the PEP with information needed to enforce policies.

Described COPS - a request-response protocol for itneraction between the PEP and
the PDP. Uses TCP for transport, its own Keep-Alives to detect failures, and features a
state synchronization mechanism.

Described use of COPS with respect to IntServ and DiffServ.

Wants to develop a schema to help provision COPS-based actions and standardize
them. Also wants to define a common IntServ-DiffServ schema.

DiffServ - Jean Christophe Martin
Defined characteristics of DiffServ - heterogeneous nodes, multiple functions and
functional elements within a node, and multiple service definitions (PHBs) in a node.

Flow is defined by at least a 5-tuple {IP Source, IP Destination, Protocol, Source Port,
and Destination Port}. Or it could be a Behavior Aggregate defined by Code Point. Or
it could have an IN or OUT marking.

Point is that Classifier must look at the flow-tuple - this is where the policy will get
enforced. Must also account for the IPSEC case where all you have is the DS Byte.

Actions that should be specified are modifying the conditioning of the traffic by
changing the queueing or dropping behavior (for example), modifying code points, etc.
A schema is needed because the environment in which policy is operating is very rich -
there are time of day parameters that vary that must be taken into account, as well as
other non-related networking factors (e.g., credit balance).

Also wants to define relationships for people (users as well as administrators), groups
of devices, and precedence of policies.

Policy for Other Applications - Tim Moore
Work covers schema that has been and is being developed based largely on the DEN
schema.

Need a common policy framework. Their schemas were designed to be stored in a
directory that would use LDAP as its access protocol. This has effected the resulting
schema, but could be abstracted out if needed. Note in particular that this does NOT
address the distribution of policy. However, that is OK, because it enables vendors to
add value in this area to do this.

Three main things that we wanted to solve in QoS: (1) how do you configure
provisioned QoS, (2) how do you configure DS Field, and (3) how do you perform
RSVP policy decisions.

RSVP Schema: policy is a set of conditions that produces an action or actions; both
are in the same policy object.

VPN/IPSEC - William Dixon
IPSEC Problem: vast array of features, and even if you do happen to choose the same
set of functions, how do you make it: (1) easier to deploy, (2) easier to manage
network security, and (3) interoperate. Strategy is a common deployment policy model
for many IPSEC "speakers".

Need a standard "policy" expression to represent configurations - was part of the DEN
work and is now a charter item in IPSEC.

Model is to have a single Policy Object with a set of rules inside it. A rule is an
association of

- filter/selector/trafficProfile
- IPSEC Security Action for traffic (may have multiple proposals)
- IKE negotiation parameters (may have multiple proposals)
- May specify tunnel end-point

Remember that in Ipv6 IPSEC is mandatory, so pay particular attention to this.

Can define policy at any point in the path. At any of these point, you need to select
the packets, then decide how to secure them, optionally audit it. Policy is not
necessarily static (how to allow change?). Policy is not necessarily public. Policy
itself must be secured.

RADIUS - Tim Moore

RADIUS/RAS schema implemented either by the NAS or by a RADIUS server used
by the NAS. Same model of policy; different types of conditions and actions.

Summary - Tim Moore
They've found that there are similar policy frameworks that can be used for very
different applications. The DEN model of a policy object that defines sets of
conditions and actions can be used in all cases. Needs to reduce administrator
understanding of policy usage. In their cases, don't want to depend on IP address
to identify the user - would rather use other mechanisms.

It was pointed out that since the Hacker's conference, corporate paranoia has
increased, and IPSEC is being deployed more and more. So it's more important to
be able to classify.

Next step is common way to discover/assign policy. E.g., OUs, subnets,etc.

Policy From a Carrier Application Perspective - Tim Edwards
Carrier vs. Enterprise concerns:

- Scalability vs. Speed (Millions vs. Tens of Thousands of Users)
- Admission Control / Authentication (SLA vs. User Profiles)
- Aggregation (whole organizations vs. Users/workgroups)
- Security (Encryption (IPSec) => application invisibility)
- Four key points:
- Leightweight admission policies which relate to SLAs
- SLA policies for contract policing and over-subscription
- Scalable architecture
- End-to-end solution makes no assumptions

Plea: carriers need this as much as Enterprises, and both needs, though conflicting,
should be addressed in this WG.

Review of Proposed Charter - Ed
(John Tavs:) IBM has filed patents w.r.t. specific mechanisms for policy, and as the
WG is chartered IBM will make additional disclosure. Note that there are 299 patents
that talk about policy in some form. Scott Bradner adds that that was a good thing to
disclose, and don't be discouraged. Also doesn't mean that the WG should disband or
panic. It does mean that procedure must be followed. Finally, points out that schema and
data structures shouldn't be patented, so if the WG stays with schema we should be ok.

Problem Statement discussion:
Add adjectives to policy to ensure that it is tightened down - some disagreement,
because this will depend on the application that policy is being applied to.

Last sentence: way should be changed to something like "set of schemas."

Single domain - may simplify things now, but must be addressed (remember RADIUS -
now we have ROAMOPS). Fred suggests to focus initially on a single admin domain
but keep real problem in mind.

Charter Slide
More detail on policy language - what it's focused on and what it will address.

Maybe we need to state non-goals.

Scope - framework seems to be too general. Although a framework is supposed to be
general, we need to be careful that we stay focused. Policy schema should be priority
for first deliverable. Scalable is scary -what is scalable to an end-system guy is not
scalable to a routing guy.

Language - single vs. set. Must exclude vendor-specific mechanisms and concentrate
on an intermediate level that is vendor-independent. Consistency in defining a policy
schema for mumble, where mumble spans this group and other WGs. This needs to
follow a similar model as was done in snmp.

Multiple devices and device types - would rather see a reference to heterogeneous PEPs.

Framework seems too large.

Get policy definition language out asap - within a month if at all possible. This will help
maintain the focus of the group.

Add a "we won't do" section.

Add a specific section on security. Probably want the Security AD to assign a security
consultant to this.

Remove Other Schemas at this point, and wait for re-chartering.

At this point the co-chairs asked Fred to call a vote to see if the requirements had been
met to consider chartering as an official WG. Fred asked the audience, which gave
consensus that it had and expressed interest in working in this WG. Fred then asked if
anyone had an issue with John and Ed remaining as the co-chairs, and no one did.

Slides

Policy Schemas for Directory Enabled Networks Agenda
The Requirement for PBM for Carriers

Attendees List

go to list