Dynamic and secure management of VPNs in IPv6 multi-domain ...

Computer Communications 29 (2006) 3122–3134 www.elsevier.com/locate/comcom

Dynamic and secure management of VPNs in IPv6 multi-domain scenarios Gregorio Martı´nez Pe´rez *, Gabriel Lo´pez Milla´n, Fe´lix J. Garcı´a Clemente, Antonio F. Go´mez Skarmeta Departamento de Ingenierı´a de la Informacio´n y las Comunicaciones, University of Murcia, 30.071 Murcia, Spain Available online 9 January 2006

Abstract IPsec-based VPN solutions today run mainly in the IPv4 environment and it is important that they have the capability of being upgraded to IPv6 to remain interoperable in next generation Internet. Two of the key components of every VPN solution are the trust management system used to secure the VPN establishment process and the policy mechanism used to control the VPN life-cycle. However, these two components have not received much research effort in the IPv6 world, so although IPsec IPv6-enabled implementations are getting mature, the deployment of secure VPNs in IPv6 is progressing rather slowly. This paper provides a new vision on how trust management based on cross-certification can be extended to IPv6 multi-domain scenarios and presents a policy management architecture proposed to build flexible, large-scale interoperable IPv6 VPNs solutions.  2005 Elsevier B.V. All rights reserved. Keywords: IPsec-based VPN; IPv6; Trust management system; Cross-certification; Policy-based management

1. Introduction and motivation As more organisations transition critical services and applications to data networks, the need to make networks secure, fast, and flexible becomes crucial. Many enterprise networks are based on IPv4-only technologies that may not meet current and near future needs, mainly in inter-domain scenarios where most organizations define SLAs (Service Level Agreements) to offer better integrated services to end users. As a result, organisations are turning to dual IPv4/IPv6 or IPv6-only core and/or access networks to provide these new services and applications. Among these services, VPNs (Virtual Private Network) are getting more and more demanded. In fact, many other communication protocols, services and applications depend on the previous establishment of a VPN to *

Corresponding author. Tel.: +34 968 367646; fax: +34 968 364151. E-mail addresses: [email protected] (G. Martı´nez Pe´rez), gabilm@ dif.um.es (G. Lo´pez Milla´n), fgarcia@ dif.um.es (F.J. Garcı´a Clemente), [email protected] (A.F. Go´mez Skarmeta). 0140-3664/$ - see front matter  2005 Elsevier B.V. All rights reserved. doi:10.1016/j.comcom.2005.11.007

exchange signalling information and/or data over a secure communication channel. A VPN is usually considered as an extension of a private intranet across a public network such as the Internet, creating a secure private connection, essentially trough a private tunnel. The technology to implement these virtual private networks is becoming standardized. Some vendors today are offering non-standard-based VPN solutions that make it difficult for a company to incorporate all its employees and/or business partners/suppliers into an extended corporate network. However, VPN solutions based on IETF (Internet Engineering Task Force) standards such as IPsec (Internet Protocol Security) [1] and IKE (Internet Key Exchange) [2] provide support for a full range of VPN scenarios with more interoperability and expansion capabilities. The key to maximize the value of a VPN is the ability for companies to evolve their VPNs as their needs change and to easily upgrade to future TCP/IP technology. VPN solutions today run mainly in the IPv4 environment, but it is quite important that they have the capability of being

G. Martı´nez Pe´rez et al. / Computer Communications 29 (2006) 3122–3134

upgraded to IPv6 to remain interoperable in current and next generation Internet. Several are the components of a VPN solution based on IETF standards: the IPsec and IKE implementations, the mechanism used to provide trust to the exchange of IPsec and IKE messages, and the VPN policy management system. Regarding implementations different organizations and projects are evaluating the level of interoperability and maturity of IPsec and IKE implementations in IPv6 environments. Examples of them are the TAHI project [3] whose objective is to develop and provide the verification technology for IPv6, including IPsec and IKE. Other important player is VPNC [4], who provides IPsec conformance and interoperability tests. Current results indicate that implementations are greatly improved regarding their level of interoperability and the integration and management of IPv6 information. However, this is not equally true for the other two components of VPN systems mentioned before: trust management and policy management architectures, whose support for IPv6 is still far from being deeply studied and deployed, mostly in multi-domain scenarios. Both components are briefly introduced and motivated now. One the one hand, when different domains need to establish communications in a secure way they need to define and manage a set of trust relationships. This can be the case of different Internet Service Providers (ISPs) offering Internet services and peering in a neutral location (usually an Internet Exchange, IX); the connection between different servers is usually established through VPNs. The key management in IPsec and IKE can be based either on pre-shared keys or on certificates. The second option is preferable as it provides a higher level of security and flexibility [2]. However, it implies the development of certificate management infrastructures, i.e., Public Key Infrastructures (PKI) that need to be ported to IPv6 and extended to multi-domain scenarios to be useful in real interoperable IPsec VPNs. On the other hand, IPsec and IKE policy management is the key for building flexible and dynamic large-scale IPsecbased VPN solutions. By allowing VPN configuration and security policies to be distributed holistically but controlled centrally, policy management greatly simplifies VPN provisioning and administration. With the use of this kind of systems, VPN solutions are no longer provisioned boxby-box, but instead can be delivered and easily adapted to support a range of services and applications over a policy-managed VPN infrastructure. This feature is of great importance in multi-domain scenarios where various implementations with different configuration interfaces need to agree on one security level to negotiate and establish a set of IKE and IPsec Security Associations (SA) [1]. With the use of such policy-based architectures, deployment is simplified and VPN access is under the control of organization administrators. In fact, they can define policies and apply them to support many different levels of access enforcement across the network. For example, sites

3123

can be configured to communicate with encryption for certain Intranet applications, more openly for normal Internet use (e.g., web browsing and email exchange), and with user authentication for remote access to the Intranet. This paper provides the design and further deployment of these two VPN-related components in multi-domain IPv6 networks. It is based on two previous papers directly related with IPv6, but more focused on intra-domain scenarios: [5] that presents the design and deployment of a PKI solution for IPv6 networks, named UMU-PKIv6 (University of Murcia Public Key Infrastructure with IPv6 Support) [6], and [7] that presents the deployment of VPNs in military coalition scenarios where all the partners involved in the VPN and the policies to be used are known beforehand, which is a prerequisite that cannot be always assumed in generic Internet scenarios. This paper is structured as follows. Section 2 presents the design and deployment of cross-certification trust models in IPv6 networks, while Section 3 presents the design and deployment of a policy-based management system able to deal securely and dynamically with IPsec and IKE policies. Section 4 presents our conclusions and provides some words about our current research work. 2. Design and deployment of a multi-domain IPv6-enabled trust management system 2.1. Multi-domain certification requirements Certification models define how PKI domains can establish trust relationships to allow end entities (e.g., a VPN peer) in one PKI domain to trust end entities (e.g., other VPN devices) in different domains. However, the key question is how these relationships can be verified, that is, we need to define what services, processes, applications, and protocols are involved in the validation of a target certificate by a relaying party. This section describes the required certification services needed to define an IPv6-enabled PKI multi-domain scenario and how the X.509 certificate extensions can help to get our objective. 2.1.1. Certification services To allow the definition of hierarchical, peer-to-peer, and BridgeCA certification models [8] to establish complex trust relationships between IPv6 PKI domains, it is necessary to offer advanced multi-domain certification services for IPv6 networks. The main services, following the IETF PKIX standards [9], are now described. The Validation Service (VS) allows the relaying-parties (e.g., VPN devices) of a security domain to delegate the validation process to a third trusted party. The VS will receive validation requests from relaying-parties asking for target certificates (i.e., certificate presented by external entities – VPN peers in other networks – to be validated). This service will be able to get the request from the relaying-party, to retrieve certificates and CRLs (Certificate Revocation Lists) and ARLs (Authority Revocation Lists) from public

3124

G. Martı´nez Pe´rez et al. / Computer Communications 29 (2006) 3122–3134

repositories, and to check OCSP servers; with all this information it will be able to build and validate the certification paths. It will be also able to detect wrong paths, repeated certificates, and loops in the certification path. The VS returns to the relaying-party a status sentence or additional information, depending on the protocol used. Note that VS can be located in every end entity or be defined as a well-known service offered by the local secure domain. The first case implies an overload in the client device, which may be unacceptable in some cases (e.g., mobile devices or PDAs), so it is strongly recommended to use the second option: definition of the VS as a wellknown service in every PKI. Fig. 1 shows how a VS works. To get access to VS it is necessary to offer a well-known service interface, which can be implemented by relaying parties who want to validate target certificates. The main protocols which define this interface are SCVP [10] and DVCS [11]. SCVP is used by relaying-parties to obtain and/or validate the certification chain regarding a target certificate, while DVCS is the IETF-standard protocol used by a client to offload certificate handling services like validation of public key certificates. When a PKI domain needs to obtain information about entities in a foreign domain it is necessary to deploy public repositories which allow storing public key certificates, CRLs/ARLs, cross-certificates, etc. These repositories have to support IPv4 and IPv6 connections to allow interoperability with any kind of PKI domain. The LDAPv6 service is the most common public repository used by PKIs, but also the DNSsec server is an interesting solution which offers a global well-known public repository infrastructure. According to our research in order to allow heterogeneous PKI clients interact with the certification services, the use of a Key Management Protocol is also strongly recommended. Two different alternatives have been defined by the PKIX WG, the CMC [12] (Certificate Management Messages over CMS) and the CMP [13] (Certificate Management Protocols) protocols. These protocols offer an interface to allow end entities to get access to the following

services: enrolment, revocation and renewal requests, recovery of certificates and CRLs, queries about the status of a pending certificate request, etc. End entities (i.e., IPsec VPN devices) using these protocols can request on-line certification services using either IPv4 or IPv6 network protocols. Other services like OCSP (Online Certificate Status Protocol) [14] help with getting information that can be used to know about the state of a public key certificate. OCSP was designed to satisfy some of the operational requirements of providing more timely revocation information than with CRLs and may also be used to obtain additional status information. It is also strongly recommended by the IETF [9] to be used by the end entities and validation services to check the on-line certificates status. 2.1.2. Certification extensions When a cross-certificate is going to be defined between two different domains, all the requirements and constraints to deal with the trust relationship to be established have to be included as X.509 certificate extension attributes. Restrictions in cross-certification environments can be described using a well-known group of extensions defined in [15]. The description of these extensions is out of the scope of this paper, but is it worth indicating that some of them need to be IPv6 enabled. For example, CRLDistributionPoint may contain the IPv6 address of a repository where the revocation data are stored; moreover, extensions like AuthorityInformationAccess or SubjectInformationAccess may also point to a well-known IPv6 service, like LDAPv6, DNSsec, etc.; also extensions like IssuerAlternativeName or SubjectAlternativeName can specify an IPv6 address like alternative name to the subject attribute inside the certificate, for example, SubjectAlternativeName = {ip = 2001:720:1710:ff00::1,dns = www6.um.es}. 2.2. Deployment of a cross-certification multi-domain IPv6 scenario To allow the definition of hierarchical, peer-to-peer, and BridgeCA models between a combination of one or more IPv4-only, dual IPv4/IPv6 and IPv6-only domains, it is necessary to use a PKI solution supporting these certification models, and also allowing IPv4 and IPv6 certification services. UMU-PKIv6, as described in [5], offers basic and advanced certification services for IPv6 networks, among them multi-domain certification services. Next sections describe a specific scenario where IPv6 certification services were deployed.

Fig. 1. Validation Service (VS) in a multi-domain scenario.

2.2.1. Description of the scenario A good scenario to show how the UMU-PKIv6 software can be used to establish multi-domain certification models is the network defined by the Euro6IX project. The Euro6IX project [16] is a research project aiming to design and deploy a Pan-European native IPv6 network, and to research on advanced and innovative network

G. Martı´nez Pe´rez et al. / Computer Communications 29 (2006) 3122–3134

services and applications over it. One clear example of advanced service to provide over this network is IPv6enabled public key cross-certification. The network currently deployed as part of Euro6IX is based on three main elements: IPv6 IX (Internet Exchanges) nodes, to interconnect a group of networks to share a common communication channel; IPv6 networks; and end entities (final users, software processes and/or hardware devices) connected to these networks. IXs are not only intended to act as interconnection points at layer 2 or 3, but to provide higher level services to those networks. Examples of these services are: security, QoS, mobility, and multihoming. In terms of security, the main required services in every IX node and their related networks are AAA, DNSsec, and the provision of multidomain secure IPsec-based VPNs, as presented in this paper. These services have a common requirement: the establishment of a trustworthy inter-domain certification environment, allowing one entity in one particular network connected to IX1, to exchange secured and trusted information with another entity belonging to a network in IX2. This information includes AAA accounting records, DNSsec queries and responses, or IKE negotiations (all of them more related to the provision of administrative and network-oriented services), and HTTPS communications or encrypted and signed email messages (more related to end user and application-oriented services). It would be desirable to establish an inter-domain crosscertification model to allow the use of these security services in a trustworthy way among all the involved participants. 2.2.2. Deployed scenario Let suppose that every involved participant implements its own PKI infrastructure, that is, it has an independent root CA, and if needed, an internal hierarchical crosscertification model. To establish trust relationships between the domains there are two solutions: on the one hand, the definition of a full mesh of peer-to-peer cross-certification relationships. This solution produces a very complex scenario, full of cross-certificates and very difficult to maintain and manage. On the other hand, the preferred option is to define a Bridge CA entity (Euro6IX BCA), which acts as a central point and which establishes peer-to-peer cross-certification relationships with the rest of participants. Beside the use of the Bridge CA entity, peer-to-peer cross-certification relationships between the participants can be defined, but it is not recommended, since it makes difficult the path validation and building algorithms in use. To develop the proposed scenario, every participant domain can use the UMU-PKIv6 solution or any other IETF-standard compliant and IPv6 enabled PKI solution, allowing basic and advanced certification services. End entities (e.g., VPN devices) are able to request, renew, revoke, search and check public key certificates, using a web interface, an RA administration point or a protocol interface like CMC. The identity certificates can be stored

3125

in LDAPv6 repositories or DNSsec servers, and services such as SCVP, DVCS, and OCSP can be used by relaying parties. The root CA in every participant domain is implemented as a self-signed and initially independent authority. The cross-certification between these root CAs and the Euro6IX BCA forms the Euro6IX PKI trust domain. The Euro6IX BCA could be named as DN = ‘‘CN = EURO6IX BCA, OU = BCA, O = EURO6IX’’. The subject of the CA existing in every node could be defined as: ‘‘CN = CA_NAME, OU = PARTNER_OU, O = PARTNER_NAME, C = PARTNER_COUNTRY’’. For example, the UMU (University of Murcia) PKI domain name is CN = UMU PKI CA, OU = UMU DIIC, O = UMU, C = ES. Every CA has a web site, where users can access to the PKI services and information. For instance, the UMU PKI CA web site is http://pki.dif.um.es. UMU-PKIv6 implements the required certification services described above. They are: • LDAPv6 repository: the LDAP service used is OpenLDAP 2.2.17 [17]. This service allows storing end users and CA certificates, CRLs and ARLs. Moreover, cross-certificate pairs can be stored using the crossCertificatePair LDAP attribute. It supports the IPv6 protocol. • DNSsec repository server: Bind 9.2.2 [18] is used to store certificates and CRLs. The communication between the UMU-PKIv6 and DNSsec is based on symmetric keys (TSIG) and actually is being ported to asymmetric keys (SIG(0)). The DNSsec repository can be accessed by client applications or directly from the CA web site. It offers an easy way to download identity certificates to secure applications. For example, the certificate of the user Alice issued by the UMU-PKIv6 can be download easily using the following name [email protected] and requiring the CERT RR object in a DNS query. All the information regarding the real deployment of a DNSsec architecture in an IPv6 multi-domain Pan-European scenario (in coordination with the UMU-PKIv6 software) can be accessed at [19]; it includes detailed information about the deployed hierarchy, documentation, how-to manuals, etc. • OCSP and TSP servers: the OCSP and TSP Authorities have been implemented as Java Servlet applications. They are running in every CA to offer on-line certificate status and time stamping services. • Validation Service: the Validation Service Authority has also been implemented as a Java Servlet application and it is offered by all the CAs. This service validates the target certificate, the revocation status, and the certification path to a trusted entity. It uses external information like CRLs and OCSP status information. It supports DVCS and SCVP request/response protocols.

3126

G. Martı´nez Pe´rez et al. / Computer Communications 29 (2006) 3122–3134

• CMC: relaying-parties can use a Java API implementing the CMC protocol to obtain key management services. The API provides methods to request new certificates, check certificate status, renewal, revocation, and search certificates. More details about this API can be found in [20]. Fig. 2 shows a sample scenario including most of the components indicated in this list. They have been applied to the exchange of a secure email message in a multi-domain scenario, but it works equally well when validating the certificate presented by a remote VPN peer node. 3. Definition of an IPv6-enabled IPsec and IKE policy management framework One of the main goals of policy-based network management (PBNM) [21] is to enable network control and management at a high abstraction layer. The administrator specifies rules that describe domain-wide policies which are independent of the implementation of the particular network node or service. It is then the policy management architecture that provides support to transform and distribute the policies to each node and thus enforce a consistent configuration in all the elements involved. This is considered as a prerequisite for achieving end-to-end dynamic and flexible VPN services, for example. In the IP security field, a policy (i.e., IPsec and IKE policies) can be defined as a set of rules and practices describing how an organization manages, protects, and distributes VPN management information at several levels.

When defining a framework for managing IPsec and IKE policies, two are the components that have to be considered: the policy language used to create a formal representation of the IPsec/IKE policy and the architecture allowing the management (definition, enforcing, and monitoring) of such policies. Next sections describe the main findings regarding these two components and how they have been designed and successfully deployed as part of the UMU-PBNM (University of Murcia Policy-Based Network Management) [22]. 3.1. Definition of a policy language for IPsec and IKE policies The research community, industry, and standardization bodies have proposed different secure policy specification languages to specify security policies at different levels (e.g., network, transport, and application levels), but more research seems to be needed in order to find a common de-facto standard to be used homogenously, or at least a way to combine and validate several application- and/or network-level specification languages in order to cover all the security aspects of any information system. Regarding IPsec and IKE policies, the IETF was doing an important effort within the IP security policy (ipsp) [23] working group. However, the specifications that this working group was producing were mainly focused on the definition of data structures for SNMP (i.e., MIB – Management Information Base) and COPS (i.e., PIB – Policy Information Base), that is, low-level policies that are quite close to configuration commands.

Fig. 2. Sample multi-domain scenario showing some of the components of an IPv6-enabled PKI solution.

G. Martı´nez Pe´rez et al. / Computer Communications 29 (2006) 3122–3134

To enable VPN management at a high abstraction layer a high-level policy definition is required. It allows network administrators to specify rules that describe domain-wide policies which are independent of the implementation of the particular network node (i.e., VPN device), which clearly facilitates the provision of VPN services in IPv4 and IPv6 networks. Moreover, it also enables the provision of this kind of services in multi-domain scenarios, as agreements between them can be more easily negotiated and applied using high-level policies than low-level configurations that are quite different from one VPN implementation to another. To define interoperable high-level policies a standard information model is required. As part of our research work, we have selected the CIM (Common Information Model) [24] from the DMTF (Distributed Engineering Task Force) as the information model to model our IPsec and IKE high-level policy language. A detailed analysis of different policy information models and high-level policy languages can be found at [25]. CIM is an approach that applies the basic structuring and conceptualization techniques of the object-oriented paradigm to provide a common definition of management-related information for systems, networks, users, and services. The latest stable version of the CIM schema (v2.9.0, although 2.9.1 is already in preliminary version) organizes it into 13 components or models. Three models were mainly considered in this research to represent the management information for IPsec and IKE; they are: • Network: this model defines both general and specific networking concepts, including autonomous systems, network services, protocol interfaces, switching and bridging, routing and forwarding services, ‘‘collections’’ (i.e., logical networks and IP address ranges), filter lists, and network buffers. They are quite related with the concepts defined in the IPsec and IKE-standard specifications [1,2]. • Policy: this model provides a framework for specifying configuration and operational information in a scalable way using rules composed of conditions and actions. It includes, among other elements, policy rules, policy groups, and policy conditions and actions, both in generic and vendor-specific form. • System: this model extends the management concepts that are related to a system, and especially a computer system; it includes software processes (e.g., IPsec and IKE processes) among others. The CIM model is independent of any implementation or repository. However, for an information model to be useful, it has to be mapped into some implementation. Thus, as Fig. 3 shows, CIM can be mapped to (or represented as) several structured specifications. According to our approach an advantage of CIM is that the model can

3127

be mapped to structured specifications such as XML (eXtensible Markup Language) or WSDL (Web Services Description Language), which can be then used to define management resources and management interfaces for web services. For mapping CIM objects using XML, there are two different alternatives: schema mapping and meta-schema mapping. The DMTF defines a meta-schema mapping for the representation of CIM classes and instances in XML [26]. This mapping defines the XML grammar written as a DTD (Document Type Definition), where both CIM classes and instances are valid XML documents for that DTD. In other words the DTD is used to describe in a generic manner the notion of a CIM class or instance. CIM element names are mapped to XML attributes or element values, rather than to specific XML element names. On the contrary, the schema mapping defines an XML Schema to describe the CIM classes; in this approach CIM instances are mapped to valid XML documents for that schema. Essentially this means that each CIM class generates its own XSD fragment whose XML element names are the same that the corresponding CIM element names. The meta-schema mapping was mainly adopted by the DMTF, as it only requires one standardized DTD for the whole CIM regardless the version of this information model used in one particular implementation. However, our research identified several benefits related to the use of the schema mapping rather than the meta-schema. The most important ones were more validation power and a more intuitive representation of the VPN policy information. To build automatically such XML schema from any CIM version we designed an XSLT (XSL Transformations) [27] transformation. The main design principles identified as part of this mapping process were: • Every CIM class generates a new XML element. • Every CIM generalization generates the declaration of a new XML extension element.

CIM Meta Model (class, property, association,…)

CIM Models (core, common, extensions)

MIB

PIB

CIM

XML

Repository

SNMP

COPS

WBEM

WSDL

Standard

Fig. 3. CIM modelling levels.

3128

G. Martı´nez Pe´rez et al. / Computer Communications 29 (2006) 3122–3134

• Every CIM key property generates a new XML (or ) element, which allows the unique identification of each XML element (i.e., CIM instance). • Every CIM association is expressed in XML as entry references; this is the most suitable general-purpose mechanism currently available. • A single XML database will host no more than one CIM implementation, and therefore the namespace is the same for all CIM instances stored in this database. The final set of classes designed as part of our research is depicted in Fig. 4. They represent the policy management for IPsec rules. SARule is a base class for defining IKE/ IPsec policy rules. It defines a common connection point for associating conditions and actions for both types of rules. Note that SARules are grouped in PolicyGroup through the PolicySetComponent association. With the IPsec policy language, which was designed to support both IPv4 and IPv6 interoperable VPNs, a VPN policy as ‘‘All the TCP traffic from the 2001:720:1710:203::/64 network to the 2001:720:1710:204::/64 network will be protected using an IPsec-based VPN in tunnel model’’ is represented as indicated in Fig. 5. Similar examples over real VPN devices can be found at [22] (accessing to the system as guest and selecting the ‘‘policy viewer’’ menu). 3.2. Description of the proposed IPsec and IKE policy management architecture 3.2.1. Introduction Once the VPN administrator specifies the policies that will be applied to one specific domain, the policy management architecture provides support to transform and

distribute the policies to each node and thus enforce a consistent configuration in all the elements involved. The UMU-PBNM system provides a security framework for the management of IPsec and IKE policies in heterogeneous IP (i.e., IPv4-only, IPv4/IPv6 transition and IPv6-only) multi-domain networks. As stated before it is based on the use of public key cryptography as a way to deal with the security concerns associated with current and next generation networking environments. It is also based on the IETF approach to IPsec policies [23], which is attempting to define the basis for a multi-vendor networking environment supporting IPsec and IKE policy control mechanisms. The UMU-PBNM policy management framework is composed of two main elements: the XML policy language based on the DMTF CIM-standard information model described in the previous section, and one secure, flexible, and distributed policy management architecture that will be now described. 3.2.2. General description of the architecture for one single domain In our proposed architecture the network administrator uses a Policy Console (see Fig. 6) to securely access the VPN service administration area. This policy console is usually a web browser supporting HTTPS communications and able to manage XML documents. The VPN service administration area (see Fig. 7) is composed by a set of policy repositories and policy management servers called Policy Management Tools (PMTs). The administrator edits in one of such PMT servers the policies and configuration parameters (also defined as policies) of relevance for the VPN management process; he/she can

Fig. 4. UML diagram of IPsecPolicy classes.

G. Martı´nez Pe´rez et al. / Computer Communications 29 (2006) 3122–3134

3129

Fig. 5. Example of high-level VPN policy in a real scenario.

also access to the monitoring data generated by VPN devices. These policies are then directly stored in the policy repositories; then, they are distributed from these policy repositories to special policy servers, called Policy

Decision Points (PDPs), which appear in management area (e.g., each administrative sub-domain, see Fig. 8). The PDPs process these policies, along data such as network state information,

each VPN domain or with other and take

3130

G. Martı´nez Pe´rez et al. / Computer Communications 29 (2006) 3122–3134

policy decisions regarding which IPsec and IKE policies should be enforced, and how and when this will happen. These policies are sent as configuration data to appropriate Policy Enforcement Points (PEPs), which reside on, or are communicated to, the managed VPN devices and are responsible for installing and enforcing them.

Monitoring information is generated from these operations and is sent back from the PEPs to the PMTs, where the network administrators can determine whether policies are producing the desired results. The security technologies and protocols in use to communicate the different components of the three areas are briefly described now:

Administrator area Policy Console

INTERNET

VPN Service Administration Area

Fig. 6. UMU-PBNM: administrator area.

Fig. 7. UMU-PBNM: VPN service administration area.

G. Martı´nez Pe´rez et al. / Computer Communications 29 (2006) 3122–3134

• The administrator communicates with the PMT, which is the access point for the VPN service administration area, using HTTPS (HTTP over SSL – Secure Socket Layer – or TLS – Transport Layer Security). • Both PMT and PDP servers store/retrieve policies in/ from the database using an interface based on XMLRPC and Java. For implementing this we have been using JDK 1.4, which is IPv6-enabled. • The communication between the PDPs and the PEPs is based on COPS (Common Open Policy Service) [28] and COPS-PR (COPS Usage for Policy Provisioning) [29] protocols. We have defined an extension to the COPS protocol for supporting the exchange of XML documents between the PDP and the PEP. It allows the PEP (i.e., VPN device) to report device capabilities to the PDP using XML and to the PDP to provide XML-based configuration information and updates to the PEP. It can be easily integrated with some of the XML-based management initiatives defined by the IETF. This extension has been successfully tested with both the Vovida 1.5 COPS implementation [30] and with the UMU-jCOPS (University of Murcia Java COPS) implementation used in the UMU-PBNM. It is important to note that the Vovida COPS implementation was ported to IPv6 as part of this research

3131

and that the UMU-jCOPS was designed to work in IPv4 and IPv6 dual-stack or native networks. Both of them have been successfully tested for interoperability.

3.2.3. Extending this architecture to a multi-domain VPN scenario So far, the discussion of this section is focused on only one administrative domain. When there are several administrative domains and they want to exchange policy information, new problems appear, such as policy representation and negotiation and the transport protocol to be used. If all administrative domains use the same policy representation, the exchange of policy information is seamless and direct. However, if the representation is different, it is necessary to agree on a common representation. Following the discussion in the previous section, the policy representation based on the DMTF information model seems to be the most appropriate for this task. In fact, several policy-based research projects and initiatives as Polyander [31] and POSITIF (Policy-based Security Tools and Framework) [32] are considering it as the base for deploying multi-domain policy specifications.

PEP

PEP

Fig. 8. UMU-PBNM: VPN management area.

3132

G. Martı´nez Pe´rez et al. / Computer Communications 29 (2006) 3122–3134

On the other hand, the proposed model is open to several transport protocols such as HTTP, Diameter or SNMP (as shown in Fig. 9). Moreover, the use of an architecture based on the IETF proposal (as the UMU-PBNM) provides interoperability to policy systems and some other advantages: • They reduce the complexity and scale of the management problem and automate the VPN management tasks [33]. • They introduce the ability of the management system to adapt its behavior dynamically to different VPN environmental conditions. • They allow the system to achieve higher-level objectives, such as business goals and service-level agreements (SLAs), which may contain a section related with IPsec and IKE policies. • They improve the level of security through the use of authorization policies and explicit specification of the behavior of security components within the network through obligation policies [34].

3.2.4. A real example of multi-domain policy-based IPv6 VPN Fig. 10 shows a real example of VPN implemented dynamically between two IPv6 VPN domains: 2001:720:1710:203::/64 and 2001:720:1710:204::/64, each of them with one VPN device and running a PKI solution with cross-certification support, as the one described in Section 2. Both Certification Authorities have a crosscertificate allowing any certified entity (i.e., user, software process and VPN device) from one domain to trust any other certified entity from the other domain. The XML high-level policies defined for this example by each network administrator setup an IPv6 VPN in tunnel model when the user (in this case running a CVS client) tries to get access to the CVS server, which is located in a different network. To do that, when the VPN gateway in the client network (administrative domain #1) detects traffic going to the server network (administrative domain #2) it sends a request COPS-PR message to the VPN PDP existing in its domain (PDP #1) and receive the set of low-level policies (i.e., PIB – Policy Information Base) that it should apply. This

Fig. 9. Exchange of VPN policies between different administrative domains.

Fig. 10. Example of a real deployment of multi-domain IPv6 dynamic VPN.

G. Martı´nez Pe´rez et al. / Computer Communications 29 (2006) 3122–3134

PIB indicate, among others, the list of algorithms and key lengths that it should apply to the IPv6 IKE daemon in order to start the negotiation process with the security gateway of the server network. When the VPN device in the server network receives an IKE message, it launches a similar query process to its PDP (PDP #2) and recovers the appropriate VPN policies to apply. It allows the dynamic negotiation and establishment of an IPv6 VPN with the only prerequisite that both administrators define similar VPN policies and both administrative domains have an appropriate trust management, which in our design and implementation is based on cross-certificates. The VPN is maintained while the user keep the session with the server and some data packets are exchange; according to the policy defined for this example after 10 min of inactivity the VPN is automatically dismantled by the two involved VPN devices. 4. Conclusions and future work The Internet has become a popular, low-cost backbone infrastructure. Its universal reach has lead many organizations to consider building secure IPsec-based VPNs over the public Internet. The challenge in designing a VPN for today’s communications environments is to take advantage of the public Internet backbone for both intra-domain and inter-domain (i.e., inter-organisation) communications, which currently include IPv4-only, IPv4/IPv6 transition and IPv6-only network scenarios. To consider these new kind of IPv6-related networks as part of the deployment of VPNs, this paper proposes the integration of cross-certifications models in IPv6 multidomain environments as well as IPv6-enabled policy management architectures able to control and manage VPNs at a high abstraction layer. The use of these two components helps in the provision of flexible, secure, and dynamic wide-area communications based on IPv4 and/or IPv6 VPNs. As a statement of direction mobility, especially Mobile IPv6 is starting to be considered as part of the list of services to be provided over IPsec-based VPN networks. Moreover, dynamic and secure VPNs are being used for creating and managing secure overlay data networks. Investigation on the dynamic and flexible provision of IKEv2 (Internet Key Exchange version 2) and MOBIKE (IKEv2 Mobility and Multihoming) services in multidomain scenarios is also being currently deployed. Acknowledgments This work has been partially funded by EU SEINIT (Security Expert INITiative, IST-002-01929) IST project and EU POSITIF (Policy-based Security Tools and Framework, IST-002-002314) IST project.

3133

References [1] S. Kent, R. Atkinson, Security Architecture for the Internet Protocol, RFC 2401, IETF, November 1998. [2] D. Harkins, D. Carrel, The Internet Key Exchange (IKE), RFC 2409, IETF, November 1998. [3] TAHI Project, Test and Verification for IPv6, http://www.tahi.org/. [4] Virtual Private Network Consortium (VPNC), http://www.vpnc.org/. [5] A.F. Go´mez Skarmeta, G. Martinez Pe´rez, O. Ca´novas Reverte, G. Lo´pez Milla´n, PKI services for IPv6, IEEE Internet Comput. 7 (3) (2003) 36–42. [6] University of Murcia Public Key Infrastructure with IPv6 support (UMU-PKIv6), http://pki.dif.um.es/. [7] G. Martı´nez Pe´rez, A.F. Go´mez Skarmeta, Policy-based dynamic provision of IP services in a secure VPN coalition scenario, IEEE Commun. Mag. 47 (11) (2004) 118–124. [8] S. Lloyd (Ed.), CA-CA Interoperability, PKI Forum, 2001. [9] Public-Key Infrastructure (X.509) (pkix) Working Group, IETF, http://www.ietf.org/html.charters/pkix-charter.html. [10] A. Malpani, R. Housley, T. Freeman, Simple Certificate Validation Protocol (SCVP), Internet Draft, IETF, February 2005. [11] C. Adams, P. Silvestre, M. Zolotarev, M. Zuccherato, Internet X.509 Public Key Infrastructure Data Validation and Certification Server Protocols, RFC 3029, IETF, February 2001. [12] M. Myers, X. Liu, J. Schaad, J. Weinstein, Certificate Management Messages over CMS, RFC 2797, IETF, April 2000. [13] C. Adams, S. Farrell, Internet X.509 Public Key Infrastructure Certificate Management Protocols, RFC 2510, IETF, March 1999. [14] M. Myers, R. Ankney, A. Malpani, S. Galperin, C. Adams, X.509 Internet Public Key Infrastructure Online Certificate Status Protocol – OCSP, RFC 2560, IETF, June 1999. [15] R. Housley, W. Polk, W. Ford, D. Solo, Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile, RFC 3280, IETF, April 2002. [16] Euro6IX (European IPv6 Internet Exchanges Backbone) EU IST Project, http://www.euro6ix.org. [17] OpenLDAP Home Page, http://www.openldap.org. [18] ISC Bind Home Page, http://www.isc.org/index.pl?/sw/bind. [19] Deployment of a DNSsec hierarchy in the EU IST SEINIT project, https://www.dnssec.seinit.org/. [20] UMU-PKIv6 CMC Page, http://pki.dif.um.es/CMC/. [21] J. Strassner, Policy-Based Network Management: Solutions for the Next Generation, first ed., Morgan Kaufmann, Los Altos, CA, 2003. [22] University of Murcia Policy-Based Network Management system (UMU-PBNM), http://pbnm.dif.um.es/. [23] IP Security Policy (ipsp) Working Group, IETF, http://www.ietf.org/ html.charters/ipsp-charter.html. [24] Common Information Model (CIM), DMTF, http://www.dmtf.org/ standards/cim. [25] G. Martı´nez Pe´rez, F.J. Garcı´a Clemente, A.F. Go´mez Skarmeta, Policy-based management of web and information systems security: an emerging technology, in: E. Ferrari, B. Thuraisingham (Eds.), Web and Information Security, Idea Group Inc., 2005, in press. [26] Web-Based Enterprise Management (WBEM) Initiative Standards, DMTF, http://www.dmtf.org/standards/wbem. [27] XSL Transformations (XSLT), W3C, http://www.w3.org/TR/xslt. [28] D. Durham, J. Boyle, R. Cohen, S. Herzog, R. Rajan, A. Sastry, The COPS (Common Open Policy Service) Protocol, RFC 2748, IETF, January 2000. [29] 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, IETF, March 2001. [30] Vovida COPS implementation, http://www.vovida.org/protocols/ downloads/cops/. [31] Polyander project: Language Based Policy Specification, Analysis and Deployment for Large-scale systems, Imperial College, http://www. dse.doc.ic.ac.uk/Projects/polyander/.

3134

G. Martı´nez Pe´rez et al. / Computer Communications 29 (2006) 3122–3134

[32] POSITIF (Policy-based Security Tools and Framework) EU IST Project, http://www.positif.org/. [33] D.C. Verma, Simplifying network administration using policy-based management, IEEE Network 16 (2) (2002) 20–26. [34] M. Sloman, E. Lupu, Security and management policy specification, IEEE Network 16 (2) (2002) 10–19.

Gregorio Martı´nez Pe´rez is a lecturer in the Department of Information and Communications Engineering of the University of Murcia. His research interests include security and management of IPv4/IPv6 communication networks. He received an MSc and PhD in computer engineering from the University of Murcia.

Gabriel Lo´pez Milla´n is a lecturer in the Department of Information and Communications Engineering of the University of Murcia. His research interests include network security, public key infrastructures and IPv6. He received an MSc in computer engineering from the University of Murcia.

Fe´lix J. Garcı´a Clemente is a lecturer in the Department of Computer Engineering of the University of Murcia. His research interests include network security, security infrastructures, security policy architectures and IPv6. He received an MSc in computer engineering from the University of Murcia.

Antonio F. Go´mez Skarmeta is an assistant professor at the University of Murcia, Spain. His research interests include advanced networking services and applications over IP networks, distributed artificial intelligence and computer support for collaborative learning. He received an MSc in computer science from the University of Granada and a PhD in computer science from the University of Murcia.