One document matched: draft-irtf-aaaarch-generic-policy-03.txt
Differences from draft-irtf-aaaarch-generic-policy-02.txt
AAAARCH Research Group A. Taal
INTERNET DRAFT G. Sliepen
Category: Informational C.T.A.M. de Laat
Februari 2003
A grammar for Policies in a Generic AAA Environment
<draft-irtf-aaaarch-generic-policy-03.txt>
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC 2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other docu-
ments at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in
progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This memo describes work in progress within the AAAARCH Research
Group. Comments are welcome and should be submitted to
aaaarch@fokus.gmd.de.
Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2001). All Rights Reserved.
A. Taal et al. Expires: August 2003 [Page 1]
Internet Draft Grammar for Policies in Generic AAA Februari 2003
Abstract
In this document the concept of a so-called Driving Policy is pre-
sented. A Driving Policy determines the behavior of an AAA server
(Authentication, Authorization, Accounting) when it is confronted
with a specific message type of the AAA protocol. The first part
of this document defines the role of a Driving Policy and how it
fits into the AAA concept. According to the model presented, the
main task of a Driving Policy is to describe which pre-conditions
have to be checked before the corresponding actions, needed to
fulfill an incoming AAA request, can be called, and how to deal
with the post-conditions of these actions. In the second part a
grammar is proposed for these Driving Policies accompanied by the
necessary comments about the semantics.
Table of Contents
Status of this Memo . . . . . . . . . . . . . . . . . . . . . . 1
Copyright Notice . . . . . . . . . . . . . . . . . . . . . . . 1
Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1. AAA environment . . . . . . . . . . . . . . . . . . . . . . 3
2. Use Case Diagram . . . . . . . . . . . . . . . . . . . . . . 4
2.1. The Use Case 'Satisfy request' . . . . . . . . . . . . . . 5
2.2. The Use Case 'Lookup Driving Policy' . . . . . . . . . . . 6
2.3. The Use Case 'Evaluate Driving Policy' . . . . . . . . . . 6
2.4. The Use Case 'Authenticate User' . . . . . . . . . . . . . 6
2.5. The Use Case 'Authorize User' . . . . . . . . . . . . . . 6
2.6. The Use Case 'Perform Accounting' . . . . . . . . . . . . . 6
3. Driving Policies . . . . . . . . . . . . . . . . . . . . . . 7
3.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 7
3.2. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.2.1. Conditions . . . . . . . . . . . . . . . . . . . . . . . 9
3.2.2. Constants and variables . . . . . . . . . . . . . . . . 11
3.2.3. Procedures . . . . . . . . . . . . . . . . . . . . . . . 12
3.2.4. Actions . . . . . . . . . . . . . . . . . . . . . . . . 13
3.3. Errors . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4. Data Objects and Message Types . . . . . . . . . . . . . . . 13
5. Example . . . . . . . . . . . . . . . . . . . . . . . . . . 14
6. Other policy languages . . . . . . . . . . . . . . . . . . . 16
References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 16
A. Taal et al. Expires: August 2003 [Page 2]
Internet Draft Grammar for Policies in Generic AAA Februari 2003
1. AAA environment
+----+ +---+ +---+
|User|<======>|AAA|<===================================>|AAA|
+----+ +---+<========= =========>+---+
/\ /\ \\ // /\ /\
|| || || || || ||
|| \/ || || || \/
\/ +--+ || || \/ +--+
+---+ |PR| || || +---+ |PR|
|ASM| +--+ \/ \/ |ASM| +--+
+---+ +---+ +---+ +---+
|AAA|<=========>|AAA|
+---+ +---+
/\ /\ /\ /\
|| || || ||
|| \/ || \/
\/ +--+ \/ +--+
+---+ |PR| +---+ |PR|
|ASM| +--+ |ASM| +--+
+---+ +---+
Figure 1. The abstract view of a generic AAA environment
This section introduces an abstract view of a generic AAA environ-
ment [RFC2903], and what kind of components it consists of. Only
those components are presented that are necessary to support the
discussion in this draft. An AAA server may receive a request
from an entity operating on a user's behalf. The request specifies
what kind of service the user wants. This request is evaluated by
the Rule Based Engine (RBE) of the AAA server where a Driving
Policy resides that needs to be evaluated with respect to the
request. For each message type of a future AAA protocol (section
4) there exists a corresponding Driving Policy that is evaluated.
These Driving Policies are stored in the Policy Repository (PR).
Whether the request will be accepted or rejected depends on the
evaluation of the Driving Policy. For special tasks the AAA server
(RBE) resorts to generic functions or to so called Application
Specific Modules (ASMs).
The contents of the Policy Repository and the ASMs determine the
behavior of the AAA server (see fig.2). By changing the contents
of the PR and the ASMs, the behavior of an AAA server can be
adapted to other kinds of requests, i.e. its behavior can be
modified. This feature should be dynamically supported to give
an Administrator the possibility to adjust the behavior of an AAA
server without the necessity to recompile the AAA server code.
The four components shown in fig.2 make it possible to adhere to
the principles of Object Oriented design, like extendibility,
reusability, and encapsulation. With respect to encapsulation, the
A. Taal et al. Expires: August 2003 [Page 3]
Internet Draft Grammar for Policies in Generic AAA Februari 2003
+-------------+
|+-------------+
+| AAA request |
+-------------+
/\
/ \
/ \
/ \
/ \
/ Generic \
/ AAA \
/--------------\
+----------------+ +-------+
|+----------------+ | ASM |+
+| Driving Policy | +-------+|
+----------------+ +-------+
Figure 2. The AAA server
ASMs hide the low-level details of the service requested. This
also allows for abstract as possible Driving Policies.
2. Use Case Diagram
We will consider the role of a Driving Policy in response to a so
called AAA request. To illustrate the scope of this policy in the
generic AAA environment, we present a UML Use Case diagram for an
AAA request, fig. 3. As this is not the right document to fully
describe these Use Cases, only a concise description is presented.
+-+
+-+
| request +-----------------+ <<include>>
----- <=========> | Satisfy request |============
| +-----------------+ ||
/ \ || \/
User || <<include>> +-----------------------+
|| | Lookup Driving Policy |
\/ +-----------------------+
+-------------------------+
===>| Evaluate Driving Policy |<==========
|| +-------------------------+ \\ <<extend>>
|| <<extend>> /\ \\ policy requires
|| policy requires || <<extend>> \\ authorization
|| accounting || policy requires \\
+------------+ || authentication \\
| Perform | +-------------------+ +----------------+
| Accounting | | Authenticate User | | Authorize User |
+------------+ +-------------------+ +----------------+
Figure 3. Use Case diagram for an AAA request
A. Taal et al. Expires: August 2003 [Page 4]
Internet Draft Grammar for Policies in Generic AAA Februari 2003
We define a single Actor, called User, as an entity that speaks the
AAA protocol. This generalized user wants a request to be
satisfied, the Use Case 'Satisfy request'. The association
between the Actor and this Use Case is bi-directional This depicts
the participation of the Actor in the Use Case. This association is
bi-directional because the User expects an answer to his request.
At the highest level we have:
- Use Case: 'Satisfy request'
- System: Network of AAA Servers
- Actors: User
- Precondition: none
In total we distinguish six Use Cases:
- 'Satisfy request'
- 'Lookup Driving Policy'
- 'Evaluate Driving Policy'
- 'Authenticate User'
- 'Authorize User'
- 'Perform Accounting'
Between the Use Case 'Satisfy request' and 'Lookup Driving Policy',
as well as between 'Satisfy request' and 'Evaluate Driving Policy',
there exists an include relationship. The functionality described
in 'Satisfy request' always includes the functionality of 'Lookup
Driving Policy' and 'Evaluate Driving Policy'. Those last two Use
Cases are mandatory for 'Satisfy request'. The extend relation-
ships are interpreted as conditional include relationships. The
Use Cases 'Authenticate User' and 'Authorize User', and æPerform
AccountingÆ are only performed if some internal condition in the
Use Case 'Evaluate Driving Policy' requires it.
2.1. The Use Case 'Satisfy request'
This Use Case will describe how an AAA server deals with an AAA
request issued by a device acting on the behalf of a real user,
and what answers towards the user can be given. Every request
is forwarded to the AAA server where the process to satisfy a
request actually starts. This AAA server may manage a Policy
Repository where the Driving Policy resides that needs evaluation.
The AAA server evaluates this policy and constructs the corres-
ponding response. A more detailed view of this Use Case would
reveal a set of Use Cases associated with the different message
types of the AAA protocol (section 4).
A. Taal et al. Expires: August 2003 [Page 5]
Internet Draft Grammar for Policies in Generic AAA Februari 2003
2.2. The Use Case 'Lookup Driving Policy'
The AAA server must retrieve the Driving Policy that needs to be
evaluated before the request can be satisfied. There exists a
one-to-one and onto relationship between AAA requests and
Driving Policies, therefore, it is clear to the AAA server which
Driving Policy it has to retrieve. Any request will result in the
lookup of the corresponding Driving Policy in the local Policy
Repository (PR).
2.3. The Use Case 'Evaluate Driving Policy'
This task is delegated to the Rule Based Engine. The request may
contain objects (primitive data types) to be substituted for free
variables occurring in the Driving Policy. The RBE substitutes
everything at the proper place into the policy. If generic functions
or ASMs are referenced in the Driving Policy, the RBE makes the
call with the right arguments. The RBE decides whether the policy
is false, true or undecided yet. This Use Case does not excludes
the evaluation of other policies, as ASMs might have their own
policies. It is the responsibility of the AAA server to keep track
of all the decision processes.
2.4. The Use Case 'Authenticate User'
The authentication of the User is the process of verifying the
proof of his identity. Authentication of the User is only per-
formed if the Driving Policy under evaluation requires it. When
that is the case, the request must contain information about neces-
sary policy variables with respect to authentication. Furthermore,
the request may contain a certificate or password, his proof of
identity. In order to be sure the User is the one he says he is,
his proof of identity needs to be verified.
2.5. The Use Case 'Authorize User'
An AAA server performs authorization of a User's request, i.e.
whether the User is allowed to obtain the requested service or
resource(s). Authentication and authorization is only performed
if the Driving Policy requires it. It is not strictly necessary to
perform authentication before authorization. There are cases where
the decision whether the request is authorized or not does not in
any way depend on information about the User.
2.6. The Use Case 'Perform Accounting'
Accounting is the collection of all the data about resource con-
sumption. Intermediate accounting or accounting indication informs
A. Taal et al. Expires: August 2003 [Page 6]
Internet Draft Grammar for Policies in Generic AAA Februari 2003
the User about currently used resources. The AAA server must
provide the information about which Resource Managers need to be
consulted. Resource Managers resorts to Meters that capture data
about resource consumption in the network.
3. Driving Policies
3.1. Introduction
As can be derived from the Use Case diagram in fig. 3, the behavior
of an AAA server is policy driven with respect to a request. In
this section we present a grammar for Driving Policies. There is a
tight relationship between the grammar and the architecture of an
AAA server. The Driving Polices together with the ASMs determine
the specific functionality of an AAA server. As a consequence the
grammar can be kept as concise as possible. The main
functionality described by a Driving Policy is to check certain
pre-conditions before calls to generic functions or ASMs are made,
and to take actions according to the responses of these calls.
Furthermore, it is supposed that if communication with other AAA
servers is required, a call to a generic function is made. When a
request contains a reference to a policy, this task is also
delegated to a generic function. This means that the grammar does
not need to provide for a policy reference or a call to a remote
AAA server.
3.2. Grammar
The grammar we propose here achieve its generic property through
being minimal specified. We present this grammar to facilitate the
discussion about AAA policies. The notation of the grammar below is
in EBNF (Extended Backus Naur Formalism), terminal symbols are
placed between double quotes:
DrivingPolicy ::= "if" "(" Condition ")" "then" "(" ActionList ")"
"else" "(" ActionList ")"
Condition ::= BoolExpr
BoolExpr ::= Bool
| Var
| {Var "="}? Procedure
| ComputedBoolean
| UnaryBooleanOperator BoolExpr
| "(" BoolExpr BinaryBooleanOperator BoolExpr ")"
A. Taal et al. Expires: August 2003 [Page 7]
Internet Draft Grammar for Policies in Generic AAA Februari 2003
UnaryBooleanOperator ::= "!"
BinaryBooleanOperator ::= "&&" | "||"
Procedure ::= ProcedureName "(" ARGList ")"
ARGList ::= {ARG {"," ARG}*}?
ARG ::= Bool
| String
| ComputedBoolean
| NonBooleanExpr
ComputedBoolean ::= "(" NonBooleanExpr ComparisonOperator
NonBooleanExpr ")"
ComparisonOperator ::= "=="
| ">"
| ">="
| "<"
| "<="
| "!="
NonBooleanExpr ::= Int
| Float
| Var
| Procedure
| UnaryArithmeticOperator NonBooleanExpr
| "(" NonBooleanExpr BinaryArithmeticOperator
NonBooleanExpr ")"
UnaryArithmeticOperator ::= "-"
BinaryArithmeticOperator ::= "+"
| "-"
| "/"
| "*"
| "%"
| "&"
| "|"
ActionList ::= {Action {";" Action}*}?
Action ::= Var "=" Bool
| Var "=" String
| Var "=" ComputedBoolean
| Var "=" NonBooleanExpr
| Procedure
| DrivingPolicy
Var ::= Source {"." Source}*
A. Taal et al. Expires: August 2003 [Page 8]
Internet Draft Grammar for Policies in Generic AAA Februari 2003
Source ::= Identifier
ProcedureName ::= Identifier
Identifier ::= "[a-zA-Z_].[a-zA-Z0-9_]*"
String ::= "\"[^"\n]*\""
Int ::= "-?[0-9]+"
Float ::= "-?[0-9]+\.[0-9]*(E-?[0-9]+)?"
Bool ::= "(true|false)"
A Driving Policy can be viewed as an if-then-else structure.
The Condition (if-part) yields a Boolean value, which may be
the result of evaluating a larger expression. Both the then-
part and the else-part consist of a list of Actions (ActionList).
Actions are tasks to be performed, and their execution is guarded
by the Condition. The Actions in the then-part are executed when
the Condition is true, and the Actions in the else-part are exe-
cuted when the Condition is false. To a Driving Policy we also
attach a Boolean value. We define a Driving Policy to be true if
and only if the Condition is true. A Driving Policy is said to be
false if and only if the Condition is false. In all other
situations, the state of the Driving Policy is undetermined due to
the occurrence of an error (see section 3.3).
Driving Policies can be nested in ActionLists. A Driving Policy in
an ActionList gives the possibility to express a more deterministic
policy.
The component Procedure can be interpreted as a function call to
an Application Specific Module (ASM), or more general a call to a
generic library function the AAA server is equipped with.
In the next sections we will explain the syntax of the grammar
accompanied with remarks about the semantics of the grammar.
3.2.1. Conditions
A Condition is defined as an arbitrary Boolean formula, i.e. we
don't make the restriction to a formula in DNF (Disjunctive Normal
Form) or CNF (Conjunctive Normal Form) notation. The introduction
of brackets avoids any ambiguity, without the need to define a
precedence rule for the logical AND- ("&&") and OR-operator ("||").
It is desirable to define how a Condition is evaluated, or in other
words the if-statement is said to be deterministic. Here we
propose to follow the C language, which also guarantees that `&&'
and `||' are evaluated left to right. For an OR-expression it
holds that the right operand is not evaluated if the left operand
evaluates to true. The same holds for the AND-expression if the
left operand evaluates to false. This also implies that different
parts of a Condition can not be evaluated in parallel. From
A. Taal et al. Expires: August 2003 [Page 9]
Internet Draft Grammar for Policies in Generic AAA Februari 2003
parallel evaluation follows that the requester should be satisfied
with any result making the Condition true or false, unless
concurrency operators are introduced.
A Condition, or Boolean expression, is composed of four different
types of operands: Bool, Var, Procedure or ComputedBoolean.
The use of a variable (Var), see below, implies that the value
referenced can be interpreted as a Boolean value. The same holds
for the return value of a Procedure when applied as a operand.
A ComputedBoolean is a comparison between a left and right hand
expression.
An example of a Driving Policy for authentication illustrates some
of the concepts dealt with above, as well as the semantics of Var
and Procedure:
if( ASM::Authenticator.checkPassword(
Request::AuthenticationData.UserID,
Request::AuthenticationData.Passwd )
) then (...) else (...)
Herein, the Condition consists of a Procedure, a call to an ASM
with the name Authenticator, which has a public method
checkPassword. Two arguments, both Vars, have to be passed. As
the Vars start with the reserved word 'Request', the RBE knows
that the values referenced are located in the Request. The dot-
structure indicates the sub-tree of the Request. It is assumed
that the Procedure returns a Boolean value.
An alternative, wherein the Condition consists of a Computed
Boolean, may look like:
if( ( Request::AuthenticationData.Passwd ==
ASM::Authenticator.getPassword(
Request::AuthenticationData.UserID )
)
) then (...) else (...)
As stated above, the if-statement is said to be deterministic, and
as such there is no need to allow nesting of Driving Policies in a
Condition. Take for instance the following nested Driving Policy:
if( A || if( B ) then( b0 ) else ( b1 ) )
then( a0 ) else ( a1 )
Adopting the C convention this Driving Policy is equivalent to
if( A ) then( a0 )
else ( if( B ) then( b0 ; a0 ) else( b1 ; a1 ) )
A. Taal et al. Expires: August 2003 [Page 10]
Internet Draft Grammar for Policies in Generic AAA Februari 2003
3.2.2. Constants and variables
The grammar allows the use of constants and variables, but like
in other scripting languages (e.g. JavaScript) the grammar does not
provide for type checking. Therefore, the use of variables and
constants of different types in the same expression may result in
an error state. For example the multiplication a string and a
floating point number results in an abortion of the evaluation.
Variables (Vars) refer to a member of an object tree. The
corresponding dot-structure indicates an unique path to a node of
the object tree. We use the following definitions. A node of an
object tree is a leaf if it has no children. All other nodes are
internal nodes. If a Var refers to a leaf of an object tree, it
refers to a primitive type, like an int, float or string value.
A reference to an internal node means that the Var refers to an
object, i.e. an sub-tree of the object tree starting at that
specific internal node. A Var refers to an empty object tree if
the head of the corresponding dot-structure is not the reserved
word 'Request' or 'Reply', and it is neither the head of a
previously mentioned dot-structure. Such a Var may be interpreted
as a leaf without a value. With these definitions in mind we
propose the following semantics of assignments with variables.
Consider the assignment of the form Var = Var with corresponding
dot-structure A.B.C = D.E.
Four different cases can be distinguished.
1) The left and right hand side both refers to an existent object
tree, i.e. a non-empty object tree. Then the assignment means that
the leaf C obtains the value of leaf E.
2) The left-hand side is an existent object tree whereas the
right-hand side is an empty object tree. This means that C becomes
a leaf with no value.
3) The left-hand side is an empty object tree whereas the
right-hand side is an existent object tree. This is the
declaration of a new object tree.
4) Both sides of the assignment refer to an empty object tree.
There is no need to define this as an error. As nothing has to be
done, such an assignment might be ignored.
It is important to notice that all assignments are assignments by
value and NOT by reference. Assignment by reference would lead to
undesirable effects. The assignment A.B.C = A.B would result in an
object tree with node C pointing to itself.
A variable, Var, is a dot-structure and provides the RBE (Rule
Based Engine) with the information where the value referenced
can be retrieved. The object tree of the request always starts
with the reserved word 'Request', whereas the object tree of the
corresponding reply begins with the reserved word 'Reply'.
Consider the following example of an AAA request in XML:
A. Taal et al. Expires: August 2003 [Page 11]
Internet Draft Grammar for Policies in Generic AAA Februari 2003
<Request type="Service" >
<ServiceData>
<SwitchData>
<Source>192.168.1.5</Source>
<Destination>192.168.1.6</Destination>
<Bandwidth>500</Bandwidth>
<StartTime>12:45</StartTime>
<Duration>45</Duration>
</SwitchData>
</ServiceData>
</Request>
A variable 'Request::ServiceData.SwitchData.Bandwidth' indicates a
unique path to the node <Bandwidth>.
3.2.3. Procedures
A Procedure may be interpreted as a function call to an Application
Specific Module (ASM), or as a call to a library function the
Generic AAA server is equipped with. If an assignment is made the
return value is accessible in the remaining policy. If the
Procedure is part of a Condition, it is supposed that the return
value is a Boolean. In that case the truth-value of the Procedure
is implicitly used to determine the truth-value of the Condition,
whether or not an assignment is made.
A Procedure is also used to reference to other policies.
Referencing a local policy, stored in the local PR, might be
implemented as a call to a generic function or to an ASM. If a
remote policy is referenced, a policy stored in the PR of another
AAA server, communication with another AAA server during policy
evaluation is needed. A future AAA protocol should provide for
request / reply objects in order to support referencing remote
policies. Such a reference should be implemented as a call to a
generic function.
3.2.4. Actions
In order to reduce unexpected effects to a minimum and make sure
that different AAA servers always exhibit the same behavior, we
propose the following semantics with respect to Actions.
All Actions in an ActionList must always be executed immediately
after evaluating the corresponding Condition. Immediately here
means that Actions are executed in the order in which they appear
in the ActionList, and an Action is only executed when the previous
Action has finished successfully. During execution of the Actions
in the ActionList, policy evaluation is postponed.
The introduction of concurrency operators in the grammar may open
the possibility to indicate in which order Actions should be
executed.
A. Taal et al. Expires: August 2003 [Page 12]
Internet Draft Grammar for Policies in Generic AAA Februari 2003
3.3. Errors
There are several circumstances under which errors can occur during
the evaluation of policies or the execution of actions. The
Driving Policy might refer to objects that are missing. A
Procedure, for example getPassword(..), might fail to respond
because the database is off-line. Since we allow arithmetic
expressions, another type of error might be caused by a
division by zero. As Vars might be of different types,
incompatibilities might occur during evaluation of an expression,
like a string multiplied by a float. Because the grammar does not
provide for exception handling, the most safe strategy is to abort
the evaluation of the policy after error occurrence. Error codes
might be defined to inform the requester about the abortion of its
request.
There are several possibilities open to reduce the occurrence of
errors. With respect to the failure of Procedures, the
administrator can make sure that the Driving Policies are
constructed in such a way that the occurrence of error states are
limited. This might be done by checking the input for Procedures if
it meets the precondition. Take for instance a Service request for
bandwidth that contains an object ServiceData. A precondition for
the call to the appropriate ASM, might be that the requested
bandwidth is at least 10 and at most 1000. Then a Driving Policy
may look like:
if( (Request::ServiceData.SwitchData.Bandwidth >= 10) )
then
(
if( ( Request::ServiceData. SwitchData.Bandwidth <= 1000 ) )
then(...)
else( Reply::Answer.Message = "Requested bandwidth too large" )
)
else( Reply::Answer.Message = "Requested bandwidth too small" )
If AAA requests are defined by XML, XML Schema's or DTDs might be
used. An XML schema provides a means for defining the structure,
content and the semantics of an XML document. This eliminates
errors due to the bad contents of a request.
The RBE might check division or incompatibilities in arithmetic
expressions, as well as terminate policy evaluation after time out
of a function call.
4. Data Objects and Message Types
This section describes the need for a specification of the message
types and of the top level objects to be carried in a future AAA
protocol. For each message type there should be a corresponding
Driving Policy. Message types occur as a Request Reply couple.
Such a list of message types should certainly contain:
A. Taal et al. Expires: August 2003 [Page 13]
Internet Draft Grammar for Policies in Generic AAA Februari 2003
a) Service Request/Reply
b) Authorization Request/Reply
c) Authentication Request/Reply
d) Policy Request/Reply
e) Policy Evaluation Request/Reply
For instance, a Policy Request is sent to an AAA server to obtain
a remote policy. It would contain a data object, Policy Reference.
The corresponding Reply would contain a Policy data object.
Once these message types and data objects are defined, UML Use Cases
can be defined. As a result pre- and postconditions can be
abstracted to guide the construction of the corresponding Driving
Policies.
5. Example
In this section we present a simple Driving Policy in XML to deal
with an AAA request for bandwidth. A User issues an AAA request
containing the following objects, an AuthenticationData object, and
a ServiceData object:
<?xml version="1.0" encoding="UTF-8"?>
<Request version="0.1" type="Service" >
<AuthenticationData>
<Identity>Joe</Identity>
<Password>aaa</Password>
</AuthenticationData>
<ServiceData>
<SwitchData>
<Source>192.168.1.5</Source>
<Destination>192.168.1.6</Destination>
<Bandwidth>500</Bandwidth>
<StartTime>12:45</StartTime>
<Duration>45</Duration>
</SwitchData>
</ServiceData>
</Request>
The corresponding Reply:
<?xml version="1.0" encoding="UTF-8"?>
<Reply version="0.1" type="Service" >
<Answer><Message></Message></Answer>
</Reply>
A. Taal et al. Expires: August 2003 [Page 14]
Internet Draft Grammar for Policies in Generic AAA Februari 2003
The AAA server recognizes the request as an Service request and
draws the corresponding Driving Policy from the PR:
if
( ASM::Authenticator.Authenticate(
Request::AuthenticationData.Identity,
Request::AuthenticationData.Password )
)
then
( if
( ASM::RM.CheckConnection(
Request::ServiceData.SwitchData.Source,
Request::ServiceData.SwitchData.Destination )
)
then
( if
( (Request::ServiceData.SwitchData.Bandwidth <= 1000 )
)
then
(
R1 = ASM::RM.BoD(
Request::ServiceData.SwitchData.Source,
Request::ServiceData.SwitchData.Destination,
Request::ServiceData.SwitchData.Bandwidth,
Request::ServiceData.SwitchData.StartTime,
Request::ServiceData.SwitchData.Duration )
;
if( ( R1 < 0 ) )
then
( Reply::Answer.Message = "UNKNOWN failure occurred"
)
else
( Reply::Answer.Message = "Request successful"
)
)
else
( Reply::Answer.Message = "Bandwidth too small"
)
)
else
( Reply::Answer.Message = "Bad source or destination"
)
)
else
( Reply::Answer.Message = "Authentication failed"
)
An Action like, Reply::Answer.Message = "Authentication failed",
instructs the RBE to add a text node to the Reply that is returned to
the User.
A. Taal et al. Expires: August 2003 [Page 15]
Internet Draft Grammar for Policies in Generic AAA Februari 2003
6. Other policy languages
The language according to the presented grammar describes policies
that can be implemented in several policy languages, e.g. Ponder
[PONDER]. Due to the concept presented in this paper, Driving
Polices expressed in another policy languages are expected to form
a tiny sub-set of these languages. It is therefore justified to
define a special grammar for Driving Policies.
References
[RFC2903] C. de Laat, L. Gommans, G. Gross, D. Spence and J. Voll-
brecht, "Generic AAA Architecture", RFC 2903, August 2000
[PONDER] http://www-dse.doc.ic.ac.uk/research/policies/ponder.html
Authors' Addresses
Arie Taal
Faculty of Science, Informatics Institute,
University of Amsterdam
Kruislaan 403
1098 SJ Amsterdam
The Netherlands
Phone: +31 20 5257590
Fax: +31 20 5257490
Email: taal@science.uva.nl
Guus Sliepen
Physics and Astronomy department
Utrecht University
Princetonplein 5
3584 CC Utrecht
The Netherlands
Phone: +31 30 2537724
Fax: +31 30 2537555
Email: G.Sliepen@phys.uu.nl
Cees de Laat
Faculty of Science, Informatics Institute,
University of Amsterdam
Kruislaan 403
1098 SJ Amsterdam
The Netherlands
Phone: +31 20 5257590
Fax: +31 20 5257490
Email: delaat@science.uva.nl
A. Taal et al. Expires: August 2003 [Page 16]
--
http://www.science.uva.nl/~delaat/
| PAFTECH AB 2003-2026 | 2026-04-22 04:30:42 |