POLICY-BASED NETWORK MANAGEMENT

. The policy repository is used for storing the policies created by users through the policy management tool.

. The policy decision point (PDP) is responsible for interpreting the various policies defined by the administrators through the policy management tool. The PDP then instructs the network to take appropriate actions based on the current state so that the policies specified by the administrators can be enforced throughout the network. The PDP may receive input from the network regarding the current state of the network and may be notified by the network about specific events that may require reconfiguration of the network. For example the PDP may be noti- fied when network devices fail, when the performance of the network degrades, and when cyber attacks are detected. On receiving such notitifaction, the PDP can recon- figure the network so that the policies can be enforced under the new network conditions.

. The policy enforcement points (PEPs) are responsible for implementing the decisions that the PDP makes for reconfiguring the network. PEPs are usually network devices such as routers, radios, and firewalls, that can implement the actions required for ensuring that the policies are enforced across the network. In some instances, however, it might not be possible to satisfy the policies. This occurs when the PEPs do not have the capabilities required for enforcing the policies defined by the users.

The PBNM architecture addresses both of the challenges with existing network management systems discussed earlier. Configuration of all the individual network parameters is simplified and automated. Administrators do not need to configure each individual parameter. They just define high-level policies and goals through the policy management tool and the PBNM system is then responsible for configuring the detailed individual configuration parameters automatically based on the high-level input. This is accomplished by the PDP, which parses the high-level policies, as discussed earlier, and then configures the PEPs in a way that is consistent with those policies.

The PBNM also deals effectively with changes whether they are introduced by the administrators or due to changes in the network itself. Administrators can introduce new high-level policies or change existing policies through the policy management tool. The PDP is then responsible for parsing the changes introduced by the adminis- trators and reconfiguring the PEPs to ensure that the updated policies are enforced. The PDP also gets notified about changes in the network such as cyber attacks, faults, and performance degradation. The PDP is then responsible for reconfiguring the PEPs based on the new events to ensure that network effectively supports the high- level policies.

The PBNM architecture is a very elegant architecture that can address the challenge of automating network management and in particular dealing with the constant changes that are of particular importance for wireless ad hoc networks. There are two areas of the archi- tecture that have proven to be challenging in implementing the high-level PBNM architec- ture and have attracted the interest of the research community. The first area is the definition of policy languages that can be used for capturing the high-level goals that need to be enforced by the PBNM architecture. The second area is the problem of extend- ing the PBNM architecture to operate in a fully distributed environment. We will now discuss these two areas in detail.

6.2.3 Policy Languages

The policy language used for allowing users and administrators to define the high-level policies is critical for making the policy management architecture effective. If the policy language is not expressive enough then it cannot capture the user requirements. Therefore it may not be possible to effectively use the policy management architecture for the specific application. If the language is too complex then it may be too difficult for users to understand. As a result, users may not be inclined to use the system.

The best way to define policies is through a natural language that is easy for a user to use and understand. Unfortunately, little progress has been made towards achieving that goal. Three main approaches have been pursued instead by the research community so far for creating policy languages that can be used in the policy management architecture:

. the first approach is based on using structured programs developed specifically for

expressing policies;

. the second approach is based on using formal logic languages;

. the third approach is based on using a set of simple well structured rules. These rules

are similar to “if. . .then. . .else” statements.

We will discuss each of these alternatives in more detail next and we will also provide specific examples for each of these approaches that have appeared in the literature.

The first alternative for defining policies through a policy language is to define policies as small structured programs that can be understood by computers. This can be accom- plished either by using existing programming languages or by developing new program- ming languages specifically for defining policies. This approach of specifying policies has been used extensively and successfully because it is fairly general and extensible, and allows the specification of even very complex policies. The Ponder language [106] is one such example and is described at a high-level in Section 6.2.3.1. The generality and flexibility of these approaches is also their main limitation. Reusability of policy manage- ment systems that utilize such languages is very limited because standardizing all of the components of the language is a fairly complex task.

The second alternative approach that has appeared in the literature for specifying pol- icies through policy languages is the definition of policies through formal logic. Examples of such languages are described in [107, 108]. These policy languages are based on a formal logic called deontic logic. The Rei policy language from [107] is an example of such language and is described at a high-level in Section 6.2.3.1. Even though these languages are well defined and elegant, their main limitation is that they usually require a strong mathematical background to understand, and have very high complexity for typical environments that limits their applicability in large systems.

The third approach for defining policies through policy languages is the most widely used one. This approach is based on using specific well-structured rules that are usually of one of the following types:

. condition action rules, which are rules that are applied to the network when specific conditions are true; an action is implemented when the conditions are satisfied;

. event condition action rules, which are triggered when a specific event occurs; when that happens an action is implemented only if the conditions specified in the policy are satisfied;

. Invariants, which are rules that express statements that need to be true throughout the operation of the network.

Even though these rules are not as general as the ones that can be defined by programming languages, policies expressed by these simple rules can be used for defining a very wide variety of policies. An example of the use of such rules is the Policy Description Language (PDL) [109] that is described in Section 6.2.3.1. The advantage of using well-structured rules for defining policies is that, since policies are expressed as simple and well- structured rules they can be standardized fairly easily. Hence, this approach supports reusability and interoperability across systems. These types of policies are described in more detail below.

Condition action rulesare expressed as “if then” statements. For example, the follow- ing syntax can be used:

If (C1,C2,. . .,Cn) then (A1,A2,. . .,Am)

whereCiis a condition that needs to be satisfied. Conditions are usually statements that are

true or false depending on values that specific network or system parameters take. For example, a condition might be true, when a node has been compromised (as detected by the IDS), the CPU utilization goes above 70 percent, or a link is loaded more than 80 percent.

Aiare actions that the policy system needs to implement. These could be revoking the

credentials of a compromised node, performing network reconfigurations or changes in system configuration parameters, or implementing new firewall rules.

A simple condition action rule can be the following:

If (node A has been compromised) then (revoke credentials of node A) and (migrate server from node A to node B).

This policy states that, if node A is compromised (based on alerts provided by the IDS), then the credentials of the node need to be revoked and the server running on node A needs to be migrated from node A to node B. A more complex policy may state that:

If (node A has been compromised) or (node A CPU utilization.70 percent;) or (connectivity to node A is intermittent) then (migrate server from node A to node B).

This policy states that, if the CPU of node A has been compromised, or is overloaded or if the connectivity to node A is intermittent (e.g. due to congestion or link unavailability), then the server needs to be migrated from node A to node B. That would allow other nodes to more easily access the server and receive improved performance.

Event condition action rulesare similar to condition action rules that are triggered only when specific events occur. These rules can be described as follows:

(E1,E2,. . .,Ek) causes (A1,A2,. . .,Am) if (C1,C2,. . .,Cn)

whereEiis an event that occurs in the network or in one of the systems. For example, an

AiandCiare events and conditions, respectively, and were explained in the condition

action rule description. A simple event condition action rule can be the following:

(An alert from the IDS indicating node A is compromised) causes (node A’s credentials to be revoked) if (IDS system is not compromised).

This policy specifies that, if the IDS sends an alert indicating that node A has been com- promised and if the IDS itself has not been compromised (and can be trusted), then the credentials of node A should be revoked.

Invariantsare rules that can be used for making assertions and expressing truths that need to be maintained throughout the operation of the network. A simple invariant rule can be the following:

All ftp traffic from external networks should be blocked

6.2.3.1 Example Policy Languages In this section we describe briefly some example policy languages that have been proposed in the literature and cover all three policy language approaches described earlier.

6.2.3.1.1 Ponder The Ponder language has been developed at the Imperial College over several years [106]. It is a declarative object-oriented language that was developed with a focus on two types of policies: policies that can be used for automating management of networks and security policies. Policies are expressed in a syntax similar to small com- puter programs. Therefore, Ponder belongs to the first category of policy languages dis- cussed earlier that define policies using structured programs.

Network management policies are called obligation policies and are event-triggered condition action rules. Policies specify actions that need to be applied ontargetobjects by asubjectwhen a specific event occurs. The following is a simple example of such a policy from [106] which is a loginFailure policy:

Inst oblig loginFailure{

On 3loginfail(userid);

Subject s¼=NRegion=SecAdmin; Target ,userT. t¼=NRegion=users^{userid}; Do t:disable( )!s:log(userid); }

This policy example specifies that, when a user has three login failures, then the admin- istrator will disable the user. The subject in this case is the security administrator for the domain. The/NRegion/SecAdminsubjectfield demonstrates the concept of how objects are grouped in the Ponder language, which is similar to a file system. The grouping may be based on an organizational hierarchy, administrative control, geography, or other attri- butes. The top level in the hierarchy is called a domain. Domains have subdomains and subdomains may have their own subdomains. The target for the policy is the user object that is associated with the three login failures. There are two actions associated with the policy which are separated by the!operator. The first action states that the

user that had the three login failures needs to be disabled. The second action states that the security administrator needs to log the id of the user that had the three login failures.

Security policies in Ponder are more complex than network management policies. There are four primitive policy types which can be used for defining more complex secur- ity policies. These are: (1) authorization policies that define which member of the domain has access to the various services; (2) refrain policies that define what members of the domain should refrain from doing even if they may be allowed to do that; (3) delegation policies that allow members of the domain to delegate some of their authority to other members; (4) information filtering policies that limit the information that can be disclosed such as for privacy reasons.

We now discuss a simple example of security authorization policy from [106]. The policy language allows the definition of policy types that can be used for instantiating specific policies. Below is an example policy type:

Type authþPolicyOpsT(subject s, target ,PolicyT. t) { Action load( ), remove( ), enable( ), disable( );}

This example specifies that subject s is allowed to perform the specific actions (load, remove, enable, and disable) to the target object of typet. The following is a specific instantiation of this policy type.

Inst authþ swithPolicyOps¼PolicyOpsT

(=NetworkAdmins,=Nregion=switches);

The security policy is instantiated from the PolicyOpsT type. The policy allows network administrators to load, remove, enable, or disable switches in the domain Nregion.

6.2.3.1.2 Ismene In the Ismene Policy Description Language (IPDL) [110, 111] policies are defined as structured programs and therefore belong to the first category of policy languages discussed earlier. On IPDL a policy is defined as an ordered set of clauses. Each clause is defined by a tuple of tags,conditions, andconsequences. Tags

are used for assigning policies to a specific grouping. Multiple policies that belong to the same grouping (such as key management) are ordered based on which one appears first.Conditionstest whether a specific measurable aspect of the system is either true or false.Consequencesare specific actions to be taken if all of the conditions listed in the policy are true. Below are some example policies from [110, 111]:

Key management: GroupIncludes(Manager), GroupSmaller(100) :: Config(LKHKeyManager(rekeyOnJoin¼true,rekeyOnLeave¼true));

This is a key management policy that specifies that, if the group includes a manager and the group has fewer than 100 members, then LKHKeyManager scheme will be used with rekeying required on new joins and leaves.

Join: Credential(Role¼Manager, IssuedBy¼$Trusted CA) :: accept

This is a join group management policy for authorizing new members to join a group. This policy specifies that, if the role of a node is a manager and the credentials

for the node have been issued from a trusted CA, then the node is allowed to join the group.

Another possible policy is as follows:

Intrusion Response: Alert(CompromisedNode¼x, IssuedBy¼$Trusted IDSÞ:: RevokeCredentials(Node¼x)

This policy defines that, if an alert is issued by a trusted IDS stating that nodexhas been compromised, then the credentials for nodexshould be revoked.

6.2.3.1.3 Rei Policy Language The Rei language is a policy language based on deontic language and therefore belongs to the second category of policy languages as discussed earlier. The Rei language is described in [107]. Rei defines rights, prohibitions, obli- gations, and dispensations:

. rightsare permissions that an entity has and can be expressed as actions that entities

are allowed to perform if they meet specific conditions;

. prohibitionsare statements that do not allow entities to perform specific actions; . obligationsare actions that a specific entity must perform usually when specific con-

ditions are satisfied;

. dispensationsare obligations that are not required to be performed anymore. Policies are associated with an entity with a construct called “has.” Below is an example policy:

Has(administrator, right(LogOnAsRoot, RightsNotRevoked))

This policy states that administrators are allowed to log on as long as their rights have not been revoked. The Rei language has additional constructs for defining actions, delegating rights, making requests, canceling requests, and revoking rights. The details of the Rei language are described in [107].

6.2.3.1.4 Policy Description Language The Policy Description Language (PDL) was developed by Lucent [109] with a focus on network management. PDL was implemented in Lucent’s softswitch product for handling voiceover IP calls, but is general and applies to other applications. Policies in PDL are defined as event condition action rules and therefore belong to the third category of policy languages discussed earlier. In PDL, policies are a collection of propositions of two types: policy rules and policy-defined events. These two types of propositions are defined below.

1 Policy rules are statements with the following format:

Event causes action if condition

This type of proposition specifies that, when a specific event occurs, a specific action is triggered by the policy management system if a specific condition is true.

2 Policy defined events (pde) have the following format:

Event triggers pde (m1¼t1,. . ., mk¼tk) if condition

This type of proposition specifies that, when a specific event occurs and a specific condition is true, then that triggers a set of events (which are policy-defined events) within a predefined period of time specific to the application with the valua- tion oftkfor each attributemk.

The strength of the PDL language is its flexibility in defining events in policies. Events can be either of two types. They can be a basic simple event or they can be complex events that include several events within a prespecified period of time. Complex events include the following:

1 e1 & e2 &. . .& en, which means that all events occurred within the prespecified period of time;

2 e1je2j. . .jen, which means that any of the events occurred within the prespecified period of time;

3 !e, which means that there was no occurrence of the event within the prespecified period of time;

4 ^e, which means that there was a sequence of one or more occurrences of the event. Additional complex events are defined in [109] and are omitted here for brevity.

Some complex functions are also defined and can be used when stating conditions in policies. For example, the function Count counts the number of occurrences of a specific event within the prespecified period of time. Functions Min, Max, Sum, and Avg can also be used for specifying the number of occurrences of a type of event.

Below is an example policy based on the discussion in [109]. The policy shown below defines a policy-defined event as defined earlier called response_mode. The goal of this