Generic Authorization Simulation activity plan


Rev 0

Date: Jan 5 — 2000.

Objectives.

The objective of the simulation model is to identify, create and evaluate a number of representative core functions for a Generic Distributed Authorization mechanism to be used within a generic AAA environment.

This document discusses the first steps envisioned to create a simulation model that investigates the operation of one or more instances of generic AAA components as described in draft-delaat-aaa-generic-00.txt:

Above mentioned ID also states:

"At this point in the work, there are numerous questions that need to be addressed and numerous problems that remain to be solved"

In this light, this document tries to identify some basic steps that appear to be logical at this moment to development a simulation model.
 

Step 1: Simple Policy Rule Evaluation

Create a simple simulation model around a few RBE’s that focussed on evaluating methods to execute a simple policy rule of the form:

if ( policy_condition ) then policy_action

where policy_condition is some form of logical expression representing the conditions to be met to allow a certain policy_action to be taken.

Example:

if (

( User.Role(UserName) == RegularUser and

User.Credit(UserName) > 0 and

Port.Speed (NasId, PortId) == 10MB )

or

( User.Role(UserName) == ADMIN )

or

( port.number (nas_id) == 1 )

)

then

{ TOS := HIGH }

Above example policy rule will be retrieved from a simplified RBE policy repository if a request is received. This request could have been generated by a network edge device that needs to have authorization to do some traffic conditioning such as TOS (DSCP) marking. The arguments such as user_name, nas_id, port_id etc. are contained in the request and may have been derived from a RADIUS like access-request (type 4 protocol) which is then translated via a gateway to a type 1 protocol.

After retrieval the policy rule is being evaluated in the RBE. The syntax of the policy rule must comply with thoughts and idea’s generated by the policy working group.

The RBE will recognize that the policy conditions require it to generate subsequent requests to other RBE’s or ASM’s . No information will be contained inside the RBE, so all information must be retrieved using calls or messages to other RBE’s for futher evaluation or to ASM’s or Repositories that have ultimate knowledge. Attached figure shows a possible AAA model environment. At first only ASM and RBE’s are simulated.

User RBE

The user RBE understands how to retrieve user related information such as determining the role of user (User.Role) and the amount of credit associated with a user (User.Credit). The user role may be retrieved from a local repository belonging to a the user RBE. The user RBE will also discover that the user’s credit must be retrieved from another RBE known by the user RBE called the User.Credit RBE. This RBE will ultimately lookup the users credit in its credit repository. The result of the lookup of the user credit will be returned to the user RBE and it will return this result together with the result of the user role evaluation to the service RBE. Note results may be the logical result of the question (e.g binary yes or no’s) or the actual information which can be ultimately evaluated by the requesting RBE.

Port ASM

The port ASM contains a number of device related functions such as port.function yielding the function of the port such as management port, user port or trunk port. port.speed yields the speed of the port.

Execution of policy rule components

The components of a logical expession (e.g. User.Role) called by a policy rule may be executed in serveral places:
  1. Within the generic AAA server itself using some sort of virtual machine.
  2. In an ASM or Repository by using a reference to a policy rule or an abstraction of the rule that gets created and forwarded using a type 1, 2 or 3 AAA protocol.
  3. In an ASM or Repository by means of forwarding part or an abstraction of the policy rule syntax to the ASM or Repository using a type 1,2 or type 3 AAA protocol.
Alternative 1 is not being evaluated at first, the simulation effort will focus on investigating alternatives 2 and 3.

Depending on the AAA model (push-, pull- or agent) the result of the evaluation is returned to the requestor or forwarded to the ASM. All models should be investigated for specific issues.

So:

TOS := High

is the policy_action that the service component must will use to allow it do the subsequent marking. It will be communicated using a type 1 or 2 protocol. The assumption is made that some function will convert this result into a type 5 protocol that will handle the specifics such as setting parameters via LDAP into a directory or to a device using protocols like RADIUS, SNMP or COPS. These mechanisms will not be address until later.

 Step 2: Rule association.

In phase 1 the association between a request and the execution of a single rule was implicit. Phase 2 will investigate methods to associate requests from multiple sources to a number of rules. It will explore the requirements of a type 3 protocol.

This requires service equipment to be identified and may require several rules to be retrieved depending on pre-established conditions.
 
 

Step 3: Addressing services and resources.

In phase 1 knowledge about the existance of service components is implicit. This phase tries to decouple components and make them generically addressable. This step would allow networks of AAA components (ASM’s, RBE’s and Repositories) to be build and found based on their name (user) or name plus argument (port).

Step 4: Rule creation and management.

Investigates methods of managing policy rules by either a network administrator or from a user requesting a service.

Step 5: Interfacing to real world

Incorporate type 4 and 5 protocols to allow the simulation environment to communicate with life equipment such as RADIUS services, COPS or SNMP based devices.

Step 6: Implement more requirements such as accounting, authentication and security as identified by the requirements list.