Automated inter-domain security policy generation - CiteSeerX

Automated inter-domain security policy generation F. Barrère, A. Benzekri, F. Grasset, R. Laborde, B.Nasser IRIT/SIERA Université Paul Sabatier, Toulouse, France {barrere, benzekri, grasset, laborde, nasser}@irit.fr

Abstract Collaborative work needs a flexible secured networking management tool, as virtual teams can be formed and disbanded rapidly. Building a multi-domains security policy is a challenge as far as each domain has to kept total control over its policy. One favorite tool to manage domains is policy based. The hierarchical organization of the policy based management fits the intra-domain one but fail when extended to the inter-domain scope. We present an inter-domain security policies based on the coalition concept and policy abstractions. Such abstractions enable policy designers to focus on communication end-points. However, devices standing on these communications have to be configured. We introduce a method that automatically computes policy required for theses intermediate devices. Key words: network management, security policy, policy abstraction, distribution.

1. Introduction 1.1.

Motivation

The Internet tends to become the heart of a real concurrent engineering information system and not only a means of exchanging information between partners using email or web services. The public nature of the Internet heightens the security concerns that exist to some extent on any Wide Area Network. The risks associated with user authentication and unauthorized “eavesdropping” on sensitive data have been recognized for years. Concurrent Engineering Business requires a mobile workforce and virtual teams, whose members (scattered throughout partners) need to exchange data at any time to co-ordinate their work and to quickly attack a particular problem before being disbanded. VPN technologies have been proposed as a means to enable collaborative working [1, 2, and 3]. Companies deploy VPN connections to organize their remote connections, to create extranets for their business partners and to build intranets for their employees. Companies worldwide are increasingly seeking support for their needs in implementing, managing and maintaining VPN connections. Setting up and maintaining a remote access system of one’s own requires expensive and timeconsuming investments from the company. The management of such VPN needs a qualified expertise. Moreover, the concept of extended-enterprise heightened the need for a common security policy to be deployed by each partner. As the Extendedenterprise security policy relies on the security policy of each partner, a common agreement should be stated regarding the deployment of the Extended-enterprise IT infrastructure.

In the context of collaborative working, we need to deploy a logically isolated IT infrastructure that should be thought of as completely dedicated to the projects the collaborative teams are involved in. The common security approach generally admitted consists in defining project zones interconnected thanks to persistent encrypted tunnels or established on-demand, between the security gateways. Servers and applications that are shared within the Extended Enterprise will be hosted in Project Zones. The Project Zones are as safe as one’s own private network, but can be set-up with different security policies. This enables secure sharing, without enabling outside access to the private networks. Therefore, extending a company’s networks with Project Zones, the common IT security approach truly forms an extension to an organization’s current IT Security policies. In this context, several observations can be made: • Each organization administrator wants to keep control on its organization security policies and accepts to make reachable only those devices to the parties who are accountable for. • Such a scheme is built on trust, peering agreements are needed so far and each partner should have a coherent view of the partnership. • The virtual collaborative workspace built in this way lacks a central management authority, and the coordination of the different “administrative domains” is mandatory. Enabling such IT infrastructure is done by deploying data flow security policies. Data flow security policy can be view as an aggregation of specialized security policy found on devices like firewalls, routers and so on. These security policies focus only of data flow protection and do not include information like user Access Control List. The current practice in security policy management, from the administrator point of view consists in four processes. Theses processes are, in order: design, distribution (or deployment), enforcement and monitoring.

Figure 1: Current policy management process.

With this organization, each time a change occurs in the network, the policy designer has to rework its policy in order to adapt it, raising the probability that an error occur. However, with the need of on-demand and complex IT infrastructures, the design step must be done once and then requires the following steps: 1. policy design 2. adapt policy to current domain network state 3. deploy the enforceable policy 4. enforce policy on devices 5. monitor network change 6. restart to step 2 when a change is detected Step 2 to 6 can be done automatically. Some proprietary tools [22] help administrators in such tasks but are limited to an intra-domain management. Moreover, even in the intra-domain scope, such tools have other limitations due to lack of hardware and software interoperability.

1.2.

Policy management/distribution overview

The problematic we consider is very similar with the inter-domain QoS and routing policy one [21] as well as with distributed firewalls [4]. The solution commonly proposed is to setup a Service Level Agreement (SLA) [6] at the business level then to describe what each partner will share with others. We think the concept of coalition valuable to compute the common collaborative workspace specification [10]. This common agreement within a coalition can be viewed as an SLS and is the highest level of policy abstraction we have implemented e.g. level-3 policy [20]. At this level, the policy defines which service should be available as a set of functionalities and authorized communications between virtual devices. From this level-3 policy, we can derive a level-2 policy suited for policy distribution into a coalition [20] [12]. Furthermore, we would like to integrate it with a Policy Based Networking model (figure 2) generally dealt with in the intra-domain scope (or any management platform supporting PCIM) [11]. A set of roles (in the sense of COPS, a way of grouping devices according to their behavior against given functionalities) is extracted from a network topology knowledge base. From the authorized communications and the security mechanisms offered strategies, end-toend links are then characterized (security attributes, flow identification parameters…) within the coalition physical and real existence, (what domains are running and what devices are effectively present within each domain). A final level-2 policy is the result

of a inter-domain negotiation where all domains share their interpretation of the common agreement (similar to an SLS).

Figure 2: Typical PBN architecture.

Moreover, the real-time monitoring capability offered by typical PBN implementations using COPS-PR [9] (figure 2) enables the use of dynamic security policies. We talk about dynamic policies when the policy enforcement has the two following properties: • The policy rules can automatically fit the underlying network layout. • On-demand generic security policies can be built automatically.

1.3.

Inter-domain enabled policy distribution

If the PBN paradigm is central to the intra-domain management, it is not yet relevant in case of a multi independent domain environment. In fact, each domain’s administrator wants to keep the control on its own policy and on its organization. Even in the case of peering agreements, one will show to the other partners only what they are strictly concerned with. Therefore, it is unconceivable that one administrator can design inter-domain policies and then enforce them into a foreign domain. Indeed, in such a situation, the local administrator must at least check the external policy to verify the local policy compliance. Moreover, as a security policy is mainly describing security links between two devices, administrators have to ensure that both devices can effectively enforce such a secure policy.

1.4.

Security policy abstraction

Using policy abstraction levels imply that we need a policy derivation process to generate a policy from a level (n) to a level (n-1) policy. The final derivation step produces level (0) policy also named policy rules. Thus, this derivation process enables the dynamic enforcement regarding policy changes. The relevance of policy abstraction has already been discussed in details [17, 18]. Here we spot the fact that we can abstract some specific knowledge (such as the IP address, intermediate devices, and so one) that does not directly influence the policy itself. For instance, if we need to allow traffic from one device to another, we probably prefer to use a

symbolic label to reference those devices. Then, we need a tool that will replace those symbolic labels with the right IP addresses. This is the derivation process. The derivation process follows the inference principle: a more specific element replaces a generic one. A binding database (what we have called the knowledge database) is used to derive the abstracted policy in order to obtain an adapted policy form. Each time we apply this abstraction process from one policy (with different abstracted elements) we gain one abstraction level, so we qualify the policy abstraction by its abstraction level. Obtaining a policy that fits more with the administrator objectives must drive the choice of the elements to abstract. In this paper, we describe the automatic policy rules generation process from an abstracted inter-domain enabled policy format. The main idea in the inter-domain distribution system, is to share only abstract information. Then each domain is able to generate its own policy rules under the control of the domain administrator. If policy rules are generated flawlessly, they will match its partner’s ones thus, secure communications may begin. Thus, we first precise some properties of the security policy rule. Then we describe the level-2 policy as an abstracted form of the policy rule but suitable for inter-domain policy distribution, and then expose the problem caused by passive intermediate devices. Finally, we study a method to generate policy rules for these intermediate devices allowing the data flow to pass along its communication path with the correct required security options.

2. Policy for inter-domain distribution. The purpose of the security policy rules is to configure the devices’ behavior belonging to an administrative domain. It generally consists in the list of actions applied on selected data flows. For a dynamic adaptation and service continuation, this configuration needs to be done without rebooting or suspending the system.

2.1.

Security policy rules

We suppose that the initial device configuration forbids all the communications, except those needed by the PEP agent with its PDP. Therefore, in order to configure each domain’s device, the policy will be split into a per device set of policy rules. We call such policy rules, which are devices dependent, level-0 policy but are out of the scope of this paper. However, not all devices belonging to a domain may support the same level-0 policy description format. Moreover, on a device, policy rules are grouped by specialized list and are applied from the first to the end of the list. To achieve our goal we have to handle the following kinds of policies rules: 1. firewall 2. Routing 3. IPsec 4. Tunneling (L2TP, PPTP, SSH, etc) The number, the purpose and the treatment order of each list are system specific and differ from one device to another. This is why we need to consider policy rules described in a device independent language. We call level-1 security policy (policy

rules), related to an administrative domain, the complete set of security policy rules that will be enforced into a domain’s security devices. The Policy Core Information Model (PCIM) [11, 12, and 13] is an example of a level-1 policy that can be used for security purpose. As the syntax proposed in this model is far complex, we have chosen to use a simplified one’s and so we will not follow strictly these recommendations. Recall that the purpose is not to propose yet a new policy rule format, but just to precise what we understand by security policy rules. We said that the rules’ order in a policy is part of the overall behavior and may vary with the implementation. The decorrelation algorithm [14] has be design in order to avoid this problem. Thus, the derivation process must insure that each policy rule is decorrelated from others. In order to distribute policy rules to correct devices, policy rules are tagged with a role name. This is a standard behavior, defined at least, in PCIM and PBN. Thus, several devices can use a common policy group. The intra-domain distribution tools use role combination to bind a device with its policy. Now, let us describe the policy rule format for a unidirectional flow: to ->

where and are the unidirectional flow selectors. They have the following format: (IP device[,network protocol[, transport protocol[:port[-port]]]]>

Arguments in brackets are optional. When they are missing, it means that any value is possible for the filter. The describe the transforms to apply in order to allow the communication (by default, communications are not allowed). Actions we consider here are to accept (pass) or to protect with a selected protocol. For instance, let us examine this policy sample: dns_access: (192.168.2.10, ip, tcp) to (192.168.5.2, ip, tcp: 53) -> pass (192.168.5.2, ip, tcp: 53) to (192.168.2.10, ip, tcp) -> pass udp_protect: (192.168.5.12, ip, udp: 500) to (192.168.2.10, ip, udp: 500) -> pass (192.168.2.10, ip, udp: 500) to (192.168.5.12, ip, udp: 500) -> pass (192.168.2.10, ip, udp) to (192.168.5.12, ip, udp) -> IPsec (mode=transport, …) (192.168.5.12, ip, udp) to (192.168.2.10, ip, udp) -> IPsec (mode=transport, …)

There are two groups: “dns_access” and “udp_protect”. The first group contains two lines allowing bidirectional flow between 192.168.2.10 and a DNS server. In the next group, the two first lines allow the IKE protocol [15] between two hosts and the last two lines define a secure link protecting UDP flows between these hosts. Note that in order to enable a correct usage of IPsec with automatic keying policy builder, the IKE protocol is mandatory. In this policy abstraction level, the device, which will enforce a rule, may not be directly involved in this rule. This is the case for transparent firewalls. For instance, from the latter example the “dns_access” rules may not be enforced on either involved hosts. Now, we can examine policy abstractions on what should rely any dynamic policy management system.

2.2.

Level-2 security policy

While our architecture is suitable for the management of dynamic security policies on a single domain like distributed firewalls, its best value is reached in the inter-domain distribution facility. Considering the fact that a domain can be viewed as a coalition with a single member, we suppose that a level-2 policy always refers to an existing coalition and to this coalition only. The level-2 policy is designed as an abstract form of policy rules enabling the capacity to focus on end-point communication devices avoiding the need for a domain to show its internal network organization. In a coalition, a given domain does not need to know neither its partner’s network topology nor the devices list. This domain has to know only about devices with which it will establish a communication. This fact leads us to abstract a policy rule as a link between two devices. Such a link describes a data flow on which some actions have been attached. By the way, we commonly refer to a level-2 policy as policy links. In PBN, the well-known notion of roles is used to designate groups of policy rules. With level-2 policy links, roles are used to designate a set of devices doing the same thing in a given coalition. In fact, this is very similar with the way PBN consider things. However, the difference is that multiple coalitions (and then level-2 policies) may coexist inside a single administrative domain. Indeed, a level-2 policy description is partitioned into the intra-domain and the coalitions the domain belongs to. In each part, a given device may play a different role. In MSPDA, we call High Level Policy (HLP) [19] the level-2 policy used to describe the common coalition policy. A revised version of such policy includes two parts: the link description and the link dependency. The link description is given below:

, , ->

Where: - and are coalition specific role names to abstract devices - is a list of transport level filters required to select data flow for a given network service. The elements of the list are triples (, , ) - Finally, the is a list of non-conflicting actions to be taken when data flows are selected. Here is the list of the main action we consider: - Deny: denies data flows to pass through. (Conflicts with all other actions) - Protect: adds protection services to selected data. A parameter indicates the protection methods. - Tunnel: creates a tunnel type encapsulation. Parameters indicate the tunnel type and the managed network address range on both end-points. - Allow: allow unmodified data flows to pass through (is implied by the protect and tunnel action and conflict with other). The link dependency part indicates that some links need the presence of others, and cannot be enforced if the latter are not. This dependency adds information about what the policy designer’s aims. In fact, a level-2 policy may be automatically generated from an upper abstraction level that has more knowledge about the policy designer goal. Therefore, the policy link dependency enables not to loose all these information.

This part is represented by an oriented graph where nodes are the links and edges are the dependencies. This representation will be useful for internal calculus.

2.3.

Terminal and intermediate devices

The description of a secure communication involves two subjects (physical devices, roles or whatever abstraction). These subjects are named “terminal devices”. Other devices are intermediate devices. Note that a device may be “terminal” in a context and “intermediate” in another. For instance, in figure 3, routers are “terminal devices” for the tunnel link represented in bold. Firewalls in between routers are “intermediate devices” for this tunnel. However, if we now consider the end to end link, workstations are “terminal devices”, routers are now “intermediate devices” and the link is transparent to the firewalls.

Figure 3: relation between TD and ID

Other intermediate devices are not relevant from this abstract point of view. This is the responsibility of each domain to ensure that these intermediate devices will not conflict with the common coalition policy. Intermediate devices are not involved in level-2 (and upper) policies but they are met in the final level-1 policy. Thus, if a flow has to pass through a firewall, the latter one has to be configured accordingly. However, along with a level-1 policy, intermediate devices may also influence terminal ones. For instance, let us suppose that a domain’s administrator wants to say that inside a VPN, workstations can access a server without any security protection. Consider the network topology is built in a manner that a VPN connection has to pass by a specific router. This specific router is an intermediate device but it influences the routing table of the workstation in order to send VPN related data flows to this specific router.

Figure 4: Virtual network topology of the coalition from the domain A point of view.

This intermediate devices related calculus concept is introduced in [16] for validation purpose and is the key element for the level-1 policies generation, to ensure the end-to-end security chain. So in next section, we discuss the policy rule generation from the level-2 policy. Hence, we need to describe where information about common devices in a coalition comes from.

2.4.

Secure Network Access Interface

The coalition policy comes from an agreement. In fact, partners agree about the secure communications to be allowed and about the devices to share. Shared devices are formalized as roles and communications are defined between these roles. The mapping between a coalition role and the physical devices is done via the help of the members Secure Network Access Interface (SNAI) [19]. Each member sends a coalition’s specific SNAI to all the other active members. From a member point of view, the SNAI it sends includes the specific list of devices it brings to the coalition. Nevertheless, not all devices involved within the coalition’s security policy have to be declared into a domain’s SNAI. Only “terminal devices” have to appear in a SNAI.

Figure 5: SNAI for a coalition extracted from members network topology.

For instance, figure 5 shows three domains belonging to a coalition exporting their SNAI extracted from their network topology. All “intermediate devices” from the domains topology have been removed in each SNAI. We also notice that domain A has not exported its private server. Nevertheless, locally, some devices could be used in order to let the coalition policy be enforced but they would not be visible to the rest of the coalition members. These intermediate devices do not directly participate to a coalition’s communication. These kinds of devices have to allow communications that the coalition members expect. The aggregation of the SNAI of the coalition’s partners builds a common vision of the “virtual” network topology of this coalition. The coalition security policy is described from a simplified vision of this common coalition representation. When this policy is designed, the members know only devices roles. In fact, the level-2 policy describes links between two devices roles belonging to the coalition. The list of available device’s role is agreed when the coalition is created [20]. With its SNAI, a member can declare that a device offers given services. Security protocols can authenticate devices and thus check that a connection request comes from the declared devices. However, members have to trust their partners about the correctness of each device role. Therefore, members have first to agree on what devices should be shared within the coalition then, the most important, what these devices are allowed to do in terms of network communications. Thus, having to trust the role of device partners is not an issue.

3. Policy Derivation When comes the time to generate policy rules to maintain the domain distribution system (the PDP in our case), the derivation process (acting on behalf of the domain) must have access to two kinds of knowledge bases: 1. Those coming from the coalition management system: • The policy links. • The SNAI of partners domains. 2. Those specific to the domains management systems: • The domain’s network topology • Service to transport filter bindings • Devices states and functionalities. • Per coalition Service bindings.

Figure 6: knowledge base needed for the policy rules generation process.

The important note here is to understand that each domain will run the same process. Therefore, from now, all policy related things are specific to the domain generating the policy rules. The challenge when translating level-2 policy links into the set of policy rules is to be able to include all intermediate device policy rules without open any security breach. As the domain knows all about its own network, it can compute all potential paths for each data flow and so enumerate potential intermediate devices. The original policy links include multiple service and action descriptions per flow and may include circular link dependencies. Thus, this original policy links format is not adapted for policy derivation processing. The derivation process includes three steps: 1. Re-format data to a workable one. 2. Compute the complete list of the potential paths. 3. Generate a policy for all the devices listed in a path in order to enable networked data to pass through. We now describe each of these stages.

3.1.

Internal representation

The initial step to obtain workable policy links is to expand each link in order to obtain a link with only one description service and action fields. - From the domain’s knowledge about services, the original link is split and replaced according to the service field in such a way that this field on each new link contains only one transport filter. - This operation is repeated following the action list fields on each link newly created. At the end of these operations, the policy links have the following format: , , ->

Expanded links coming from a single original link are all related to each other, so they are added (as a cycle) to the dependency graph. For instance, a protected tunnel for an FTP service is an association of two services (the control channel and the data one) and two actions (the tunnel and its protection). After expanding, this link will be replaced by four simple links (the Cartesian product of the service set with the action one). At this step, policy links are represented by a graph where a node is a policy link and an edge is a dependency. In order to proceed, we need to arrange the nodes in a suitable order. However, as it is, the graph has not yet a useful property as it may contain cycles. To eliminate the cycles there are two steps (figure 8 illustrates the process): • First we isolate the unconnected part of the graph (All Connected Components method). The result is a set of Connected Components (CC). • Then in each CC we locate all cycles with the All Strong Connected Components method (Tarjan algorithm [23], for instance) and we build the equivalent reduced graph where SCC became a node.

Figure 7: Steps to eliminate cycles in a dependency graph.

Finally, in each CC, nodes are sets of interdependent links. We can pass to the next stage: list all valid paths and relevant intermediate devices.

3.2.

Path validation

In the following, we work only in a CC computer in previous stage. As each CC are not related to others, the process can be reiterated on each CC individually. tmpCC = list_nodes(CC) PotentialPaths = Ø for each Node in tmpCC for each Link in Node PathList = List_path(L, potentialPaths, Network_topo) If PathList = Ø then /* related links are removed */ tmpCC = tmpCC \ Depend(CC,Node) else PotentialPaths = PotentialPaths ∪ PathList end if end for end for

At the end of this algorithm, we obtain the set of all potentials paths from all the links stored in the CC. A path includes all the involved intermediate devices (what we are looking for) as well as the data filter corresponding to the one at the beginning of the flow (the filter may change along the path). Here is the description of the following functions used in the previous algorithm: - list_nodes(CC) : extract the list of nodes belonging to the given CC graph. - List_path(L, potentialPaths, Network_topo): list all valid paths from the source L to its destination, verify that it does not conflict with existing path. - Depend(CC,Node) : extract the set of all nodes that depend on Node from the CC, including Node itself. List_nodes and Depend are trivial, so let us explain the List_path function that does the big job. Figure 9 shows the principle of getting intermediate nodes from the network topology.

In this example, there are two paths: (1, 2, 3, 5, 6) and (1, 4, 5, 6). Function List_path(L, potentialPaths, Network_topo) /* PhyLink is a (S,D) couple */ PhyLink= Map(L.source) × Map(L.destination) PL = Ø For each cpl in PhyLink tmp_path=get_path_in_graph( cpl, Network_topo ) For each path in tmp_path

filter=to_rule_filter( path ) action=to_action( L ) new_path= Ø /* filter of the beginning of the path */ new_path= set_filter( filter ) For each dev in path New_rule=(filter, action) If conflict( dev, new_rule, potentialPaths) Then new_path= Ø /* stop for iteration and continue to next iteration in tmp_path */ break Else ndev=Update_dev_info( dev, new_rule ) /* if device does not need any change then ndev = dev */ new_path= add_dev( new_path, ndev ) Filter = Update_filter( dev, filter ) End if PL = PL ∪ new_path End for End for End for Return PL

-

-

get_path_in_graph(cpl, Network_topo ) return the list of path from cpl.s to cpl.d in the graph Network_topo. to_rule_filter( path ) assemble a policy rule filter from the link information. to_action( L) extract the action information from L. set_filter( filter ): setup the starting filter information. conflict( dev, new_rule, potentialPaths) verify that new_rule does not conflict with the given device state, including the addition of previous rules (potentialPaths). Update_dev_info( dev, new_rule ) return the device with the updated state: o If we are in a tunnel the exit with device untouched o A routing policy is added o New_rule is added o Firewall was set accordingly to the current filter, if not conflicting with existing rules. Update_filter( dev, filter ) : update the filter if the previous actions change it.

3.3.

Rules generation

This is the simplest stage as we have already computed all the elements needed to produce the policy rules: we have the list of all the involved devices and the list of the potential paths. So we iterate on each path of the list, adding to each device the rule composed by the actual filter and the corresponding action. Each time we add a new rule on a device, two actions will be taken: 1. We have to ensure that the rule is decorrelated from the existing one. If not then we split the rule that conflicts with the new one. 2. We have to tag the rule with the corresponding role. When the rule is added to a terminal device, this role may be deduced from those used in the link. On

other side, roles for intermediate devices are specific so may use a unique role identifier. An interesting remark here is that decorrelated policy rules are not very efficient concerning the number of rules produced. Therefore, instead of trying to decorrelate the rules, we may try to aggregate them to save space. We keep this enhancement for further works.

4. Conclusion With this final stage, we have terminated the policy rules generation from the inter-domain level-2 policy links. We have described the mechanism of policy links dependency that, coupled with the path validation (using up-to-date data), enables the dynamic capability of the policy links by accurately adapting their policy rules to the current network state. This derivation process needs some refinement to be complete (like the possibility to describing choices in policy link dependencies), but is workable for non-complicated coalition policies, that is the case of most collaborative networking spaces via a VPN. The key to dynamically align extended enterprise requirements with network resources are to define and implement a set of policies that map the organizational and user goals and expectations with the specific network actions. To simplify this process, our Policy-Based Networking architecture proposes a framework to support such an implementation. Meanwhile Policy-Based Network basics include an intelligent approach that combines a centralized approach to implement network policy management, and a standard approach to enforce policy rules into a PEP, its principle lack comes from inter-domain capabilities. Several organizational models exist to enable inter-domain cooperation, but none of them fits with the security policy requirements. Hierarchical models even with the delegation concept, DNS-like, is not conceivable for most of the administrative domains with respect to the security requirements. We proposed, in the MSPDA solution, a coalition based organizational model to enable an inter-domain policy design and distribution. The concept of coalition extends the peering one. Peering agreements are one to one whereas coalitions enable agreements within a group. To achieve these goals, MSPDA introduces an information model based on policy abstraction levels with an automatic derivation process. This model enables first the inter-domain policy negotiation then the dynamic security policy deployment. The policy negotiation respects the domain’s privacy, dealing only with shared/common resources. Along with the security policy distribution, MSPDA ensures real-time interdomain policy enforcement. This inter-domain Communication Protocol bounds domains into an active coalition enabling a real-time monitoring. The core of MSPDA comes from the knowledge databases enabling the security policy inference producing a policy from an abstracted one. These databases contain, among administrator preferences, things like physical devices data such as network services provided, IP addresses, hardware capacity and so on. This kind of information can be grabbed from management platforms such as HP OpenView. This leads us to increase the use of an information model from standard management platforms for interoperability purpose. MSPDA project considers further

CIM investigation, in addition of PCIM already in use for the policy enforcement. So defining some methods to interoperate properly with external management tools require introducing new objects into the functional model of MSPDA. To conclude, the final ambition of MSPDA is to connect network application requirement in terms of security with the security policy that will be enforced. The investigations in this area are encouraging. We study the possibility to introduce a new abstraction level. In this abstraction level, the policy, designed by the administrator designates potential allowed communications. Then the application security requirements drive the selection of the needed communications among the potential ones. This policy level introduces things like user profiles and user mobility that will be the object of further publications.

References [1] D. Kosiur. Building and Managing Virtual Private Networks. Wiley ,1998. [2] S. Brown.Implementing Virtual Private Networks. McGraw Hill, 1999. [3] C. Scott, P. Wolfe, M. Erwin, Virtual Private Networks, O’Reilly (second edition), 1999. [4] Policy Distribution Using COPS-PR in a Distributed Firewall. Paper URL: http://users.bigpond.net.au/freaky/final_submission.pdf [5] S. Betgé-Brezetz, O. Martinot, G. Delègue, E. Marilly. Pro-active SLA assurance for next generation network, WTC 2002. [6] SLA Management Handbook, TMF GB971, June 2001. [7] J. Martin, A. Nilson. On Service Level Agreements for IP Networks, IEEE Infocom 2002. [8] A. Westerinen, J. Schnizlein, J. Strassner, M. Scherling, B. Quinn, S. Herzog, A. Huynh, M. Carlson, J. Perry, and S. Waldbusser. Terminology for Policy-Based Management, RFC 3198. Nov. 2001. [9] K. Chan, J. Seligson, D. Durham, S. Gai, K. McCloghrie, S. Herzog, F. Reichmeyer, R. Yavatkar, A. Smith, COPS Usage for Policy Provisioning (COPS-PR), RFC 3084. March 2001. [10] The Multi-dimensional Security Management and Enforcement (MSME) Project URL: http://www.ir.bbn.com/projects/msme/msme-index.html [11] B. Moore, E. Ellesson, J. Strassner, A. Westerinen. Policy Core Information Model -Version 1 Specification. RFC 3060. February 2001. [12] B. Moore, Ed. Policy Core Information Model (PCIM) Extensions. RFC 3460. January 2003. [13] J. Jason, L. Rafalow, E. Vyncke. IPsec Configuration Policy Information Model. RFC 3585. August 2003. [14] Z. Fu, S. F. WU, H. Huang, K. Loh, F. Gong, I. Baldine, and C. Xu. IPsec/VPN security policy: Correctness, conflict detection and resolution. 2001. [15] D. Harkins and D. Carrel. The Internet Key Exchange (IKE). RFC 2409. November 1998 [16] F. Barrère, A. Benzekri, F. Grasset, R. Laborde, B. Nasser. SPIDERNet : the Security Policy Derivation for Networks tool. In : 3rd IEEE Latin America Network Operations and Management Symposium (LANOMS), Iguaçu, Brazil, September 2003. . Edmundo R. M.

Madeira and Elias P. Duarte Jr., p. 29 – 36 [17] J. Moffett and M. Sloman. Policy hierarchies for distributed systems management. In IEEE Journal on Selected Areas in Communications, volume 11, pages 1404-1414. December 1993. [18] M. Sloman. Policy driven management for distributed systems. Journal of Network and Systems Management, 2:333, 1994. [19] F. Barrère, A. Benzekri, F. Grasset, R. Laborde, and Y. Raynaud. A multi-domains security policy distribution architecture for dynamic IP based VPN management. Policy 2002: IEEE 3rd International Workshop on Policies for Distributed Systems and Networks. June 2002.F. Barrère, [20] A. Benzekri, F. Grasset, R. Laborde, and B. Nasser. Inter-domains policy negociation. Policy 2003: IEEE 4th International Workshop on Policies for Distributed Systems and Networks. June 2003. [21] Policy-Based Routing, white paper from CISCO. Site URL: http://www.cisco.com/warp/public/cc/techno/protocol/tech/plicy_wp.htm [22] Solsoft, company’s URL: http://www.solsoft.com/pages/home/home.php [23] R. Tarjan. Depth-First Search and Linear Graph Algorithms. SIAM J. Computing, Vol. 1, No. 2, June 1972.