Subject: RE: New Schema I-D Requested to be Posted to IETF Repository

From: "Stevens, Mark" <[email-masked]>
Date: Tue, 25 May 1999 11:36:46 -0400

David:
I don't know that all of the planets are aligned. While I understand the
transactional and logical problems you outline, I do not see how an
architectural model will facilitate a solution. Knowing that we have an
entry console talking to directory, and a policy server talking to directory
and a network device doesn't bring us any closer to understanding how to
solve LDAP's lack of atomic transaction support, or how to eliminate cycles
in the DIT, nor does it bring us closer to solving what I think is the real
problem, which is expressing network policy in a common, standard format. An
architectural model would merely speak to an method of implementation and
implemetations can vary if the policy itself is expressed universally. A
policy, to be of any value, should represent a business goal, the expression
of which should not be too rigidly tied to a particular architecture or
implementation. Architecture should be changeable like the underlying
technology without severely impacting the expression of policy. Initially,
the effectiveness of policy statements may be limited by underlying
technology and architecture, but the current technology should not freeze
the expression of policy itself.

I think that we need to focus defining the contents of conditional
expressions and begin to pay attention to defining actions as well. When we
begin to define the terms of policy statements like "if ((bandwith consumed
by HTTP traffic) < 15%) then admit a new HTTP flow at medium priority" we
will be making progress. Terms that represent measurement like "HTTP
bandwidth" and terms that represent packet treatment like "medium priority"
need to be defined before we worry about the architecture in which to
execute such policies and perhaps even the structures in which we store
them.

Mark Stevens
Lucent Technologies, 300 Baker Avenue, Concord, MA 01742
Voice/fax: 978 287 9102

> -----Original Message-----
> From:	Durham, David [SMTP:[email-masked]]
> Sent:	Monday, May 24, 1999 8:33 PM
> To:	'R. Rajan'; [email-masked]
> Subject:	RE: New Schema I-D Requested to be Posted to IETF Repository
> 
> Hi Raju,
> 
> I am glad we are spiritually aligned:) I'm sorry I brought up
> schema issues since we are (as everyone seems to be agreeing)
> putting the horse before the carriage (schema before 
> architecture).
> 
> My point with the LDAPized core schema is that there needs to be
> more thought as to the structure. Groups can contain groups, and
> the draft states that cycles are not allowed, but the schema does
> nothing to prevent them. So one console can be editing:
> 
> Group A contains:
> 	Group B
> 	Group C (just added)
> 
> While another
> 
> Group C contains
> 	Group D
> 	Group A (just added)
> 
> In practice, such alterations will be very difficult to detect/
> prevent leading to a corrupted database. This
> could be fixed if there were real structural constraints, such
> as only one or a fixed number of levels of groups. These different 
> levels of groups could structurally constrain the other kinds they 
> can contain, making cyclic-references impossible.
> 
> Example:
> 
> Categorical groups (CG) can contain Organizational groups (OG)
> Organizational groups can contain Sub-groups (SG) which contain
> the actual rules/elements.
> 
> CG 1:
> 	OG 1
> 	OG 2
> OG1:
> 	SG 1
> 	SG 2
> OG2:
> 	SG 3
> 
> Stronger structural enhancements will also help where lack of
> atomic transactions will cause problems. Corruption of policies
> is a hazardous issue in general, but is more serious when 
> elements are ANDed than ORed. For example:
> 
> * If (srcuser==Jay && srcaddr==128.132.32.3) then give traffic
>  high priority
> 
> is potentially more dangerous to get wrong in two transactions than
> 
> * If (srcuser==Jay || srcaddr==128.132.32.3) then give traffic
>  high priority.
> 
> In the first case, if Jay gets set by a console and then the 
> host address is specified, a client getting the policy at the
> wrong moment will be enforcing the wrong policy. I only wanted
> Jay's traffic to get high priority if he is using the host 
> 128.132.32.3! This would be even worse if it were a security
> policy.
> 
> In the second case, the incomplete rule will still give the correct
> result for Jay or 128.132.32.3, so the client was never actually
> enforcing the "wrong" policy... Eventually, it will retrieve the
> complete policy. Allowing only DNF style policies with one level
> of conditions could force the ANDed statements to be within
> the context of a single attribute update.
> 
> As yet another gripe, I believe that the associations between 
> actions and conditions is too weak. Some actions may only
> correspond to specific conditions. I don't see this fact
> coming out of the core schema. Conditions should be grouped
> together with respect to only the actions that apply. 
> 
> Example:
> 
> * If (featherColor==Red && beakShape==Oval) 
> 	then feed bird seed.
> vs.
> 	then feed elephant grass
> 
> The first makes sense, the second does not. Allowing arbitrary
> associations between actions and condition groups will lead to
> strange statement possibilities as these. I believe it is the
> task of the schema to be structured so that such ridiculous
> things simply cannot be stated. This can be enforced structurally
> or simply loosely as additional attributes that specify things
> such as "actions of type A relate to conditions of type B & C".
> 
> Furthermore, multiple kinds of actions that are grouped together
> and associated with multiple kinds conditions further exasperates 
> this problem!
> 
> ...For starter's, I'll let someone shoot these down before I 
> perform my next core dump:) Most of my issues could be 
> easily addressed if we had a consistent architectural model...
> 
> - Dave
>

---

From: "Raju Rajan" <[email-masked]>
Date: Tue, 25 May 1999 17:24:13 -0400

Hi all,

The lack of consensus over "architecture/framework" is not merely on
technical or design issues. There are underlying disagreements over the role
of policy (should it be used to "program" the network or merely configure
protocols), what protocols should be addressed (DS, RSVP, IPSec, DHCP, HTTP
???), and how far should the group go in its standardization efforts (schema
only?, PFDL?, server to server protocol?). These issues go directly to the
charter of the group, and are not resolvable based on an "architecture".
Anyone writing an architecture draft has to assume certain answers to the
above questions, and it is no surprise that different assumptions lead to
completely different designs.

I would urge the WG chairs to put out a new charter, with clearly stated
goals and meaningful timelines. And it would be so much nicer to have this
posted first on the mailing list, rather than have it sprung (even as a
pleasant surprise) on us at the interim meeting.

raju rajan

---

From: sanjay <[email-masked]>
Date: Tue, 25 May 1999 18:24:50 -0400 (EDT)

And I would like to add the following to what Raju wrote:
1. Let us bear in mind that the mission of this group is not to collectively design
   a Policy Based Networking solution but to agree on a minimal set of specifications
   for storing, retrieving and interpreting policy information in a consistent way
   so that products from multiple vendors can inter-operate. 

2. We cannot pretend that "policy based networking" is a mature field and that the first
   set of specs will be able to handle all conceivable policies right away. We got to
   start simple and evolve with implementation and operational experience. If the policy
   work focuses on standards that will facilitate creating and managing VPN services 
   (QoS + security using DiffServ, RSVP, IPSEC standards) it would gather a lot of
   momentum. If we don't make progress soon enough, customers will have to resign to 
   proprietary policy management solutions that will fall short of the desired goal.

-Sanjay Kamat