Computer Networks 38 (2002) 165±179
www.elsevier.com/locate/comnet
On virtual private networks security design issues K.H. Cheung, J. Misic * Department of Computer Science, Hong Kong University of Science and Technology, Clear Water Bay, Kowloon, Hong Kong Received 15 May 2000; received in revised form 16 July 2001; accepted 28 August 2001 Responsible Editor: I.F. Akyildiz
Abstract The concept of virtual private networks (VPNs) provides an economical and ecient solution on communicating private information securely over public network infrastructure. In this paper, we discuss two issues on the design of VPN. We ®rst propose the VPN services, the mandatory VPN operations for each VPN service and the design on VPN protocol stack. Afterwards, we propose a list of protocol modules to be used to support the VPN operations and co-relate the mandatory VPN operations to the appropriate VPN protocols. We then propose the design of VPN software that provides guarantees on security, connectivity and quality of service. We also discuss the message processing sequence by the VPN software. Ó 2002 Elsevier Science B.V. All rights reserved. Keywords: Network management; Network security; VPN operation; VPN protocol stack; VPN service; VPN software Abbreviations: ACS, access control subsystem; CSSP, customer sited security processor; ESP, encapsulating system payload; IP, Internet protocol; IP-Sec, Internet protocol security; IPv4, Internet protocol version 4; IPv6, Internet protocol version 6; ISP, Internet service provider; LAN, local area network; MIB, management information base; MPS, message processing subsystem; OSI, open system interconnection; QoS, Quality of Service; RMON, remote monitoring protocol; RSVP, resource reservation protocol; SNMP, simple network management protocol; SNMPv3, simple network management protocol version 3; SNTP, simple network time protocol; SS, security subsystem; VPN, virtual private network; WDM, wavelength division multiplexing
1. Introduction The rapid growth on telecommunication has captured the attention from the business enterprises. The high speed network together with the popularity of world-wide-web allow a huge amount of information to be transferred almost immediately to the other side of the globe. The business
* Corresponding author. Tel.: +852-2358-8767; fax: +8522358-1477. E-mail address:
[email protected] (J. Misic).
enterprise can make use of this vast amount of information to raise their competitive powers and to expand their businesses. Meanwhile, internal communication within the enterprise is getting more ecient by the use of electronic work¯ow programs. This leads to a reorganization on the company structure and results in a better and more eective management hierarchy. By the improvement of Internet technology and management, remote enterprise sta can now communicate with the central oce conveniently by multimedia services in real time, e.g. video conferencing.
1389-1286/02/$ - see front matter Ó 2002 Elsevier Science B.V. All rights reserved. PII: S 1 3 8 9 - 1 2 8 6 ( 0 1 ) 0 0 2 5 6 - 0
166
K.H. Cheung, J. Misic / Computer Networks 38 (2002) 165±179
In order for the remote sta to communicate with their headquarter, the business enterprise subscribes to an Internet service provider (ISP) and makes use of the network of ISP. However, public network is liable to security attacks. The adversary may carry out a denial of service attack to block the availability of public network services. Or, the adversary may intercept the network trac to obtain the important information about the business enterprise. The concept of virtual private networks (VPN) is introduced as a tradeo solution. A VPN makes use of public network resources to connect to the private network of the enterprise. Within the VPN, the communications are protected by security mechanisms to assure con®dentiality, authenticity, integrity and strict access control. As a result, a private network is established. Since this ``private network'' exists in a logical sense, it is known as virtual private network. In general, a VPN has the following favorable features: 1. Minimized capital cost. Since the VPN makes use of public network resources, the business enterprise need not buy its own networking equipment to cover remote users. The initial cost can be greatly reduced. 2. Sharing of responsibility. By purchasing public network resources from the public network provider, the business enterprise migrates part of the network maintenance duties to the public network provider, who is more experienced. The operational and maintenance cost can be minimized. 3. Secure environment. By the use of security mechanisms, communications can be done securely over the public network. This helps to reduce the security breaches by the outsiders. 4. Guarantee on Quality of Service (QoS). By the use of integrated services or dierential services, QoS of VPN connections can be guaranteed. 5. Reliability. If a network point in the VPN fails, then an alternative VPN can be established to bypass this failure point. The recovery action allows full operations of VPN to be resumed as soon as possible. This helps to minimize the damage during the unavailability of VPN
service and to improve the reliability of the VPN. 6. Adaptability to future development. The business enterprise can extend its VPN easily by acquiring more resources from the public network. The business enterprise can also re-structure its VPN design easily by contracting with a new service agreement with public network provider. Since VPN attempts to give a complete solution on the shortcomings of current networks, VPN has become an important technology in these few years. A number of VPN products have been released to the market. These VPN products make use of tunneling and security mechanisms to provide VPN environment over the Internet. We can classify the VPN products into two approachesÐIP-Sec approach or nonIP-Sec approach. IP-Sec is part of the standard feature of IPv6. IP-Sec is intended to provide security at the network layer. The nonIP-Sec VPN products can be further divided into two categories. As a result, there are altogether three categories: 1. Firewall based (NonIP-Sec approach). 2. Layer 2 tunneling (NonIP-Sec approach). 3. Layer 3 tunneling (IP-Sec approach). Firewall based approach [4,5,21] makes use of an existing ®rewall and introduces cryptographic mechanisms on the ®rewall to allow secure connections. By setting appropriate rules on the ®rewall, the LAN can be protected against adversarial attacks from the outside. The VPN products install encryption/authentication mechanisms on the ®rewall to protect the connections against con®dentiality/integrity violation. Layer 2 tunneling approach [6,16,21] implements security over data-link layer. These products make use of the dial-in concept. Instead of dialing to the modem pool of the LAN, the remote users dial to their ISPs and then initiate secure connections to the LAN. Layer 3 tunneling approach [8,21] makes use of IP-Sec mechanism. The basic concept of IP-Sec is to encrypt, sign and encapsulate an incoming IP packet to form another IP packet.
K.H. Cheung, J. Misic / Computer Networks 38 (2002) 165±179
167
Each VPN product has its strengths and weaknesses. However, the following features should be guaranteed in an ideal VPN: 1. SecurityÐincluding con®dentiality, integrity, authenticity and timeliness. 2. ConnectivityÐremote users should be able to connect to headquarter at anytime. 3. Quality of ServiceÐEnough public network resources must be granted to VPN connections according to the negotiation with the public network provider. 4. Network monitoringÐHeadquarter should be able to monitor the VPN and to carry out recovery actions whenever required. This paper discusses the design of a VPN that performs the above features. In particular, this paper discusses the design of VPN protocol stack and VPN software. The rest of the paper is organized as follows: Section 2 proposes a simple VPN architecture. Section 3 discusses the necessary VPN services that must be provided and the mandatory VPN operations to support the VPN services. Section 4 discusses the proposed VPN protocol stack. Section 5 describes the protocol modules to support the VPN operations. Section 6 discusses how the VPN operations are mapped to the VPN protocol messages. Section 7 discusses the design of VPN processor. The message processing sequence is also discussed. Section 8 brie¯y discusses the related work and ®nally Section 9 concludes our work. 2. VPN architecture In this section, we will introduce the logical architecture of the VPN. As we have mentioned in Section 1, security is an essential component of VPN. We ®rst propose the following two-level VPN hierarchy. In the VPN hierarchy, the relationship between top layer and bottom layer is a client±server relation (Fig. 1). The server at the top layer enforces security control while the clients at the bottom layer simply request VPN service. We call the server ``VPN manager'' and the clients ``VPN
Fig. 1. Client±server model of VPN management architecture.
users''. Security mechanisms are implemented at both manager and users. Besides, a database is kept at VPN manager to record the access control feature and other information of the VPN users. Since each VPN is independent of each other, there is no need to have any ultimate authority above the VPN managers to control and manage the VPN managers. Another important feature that needs to be considered is the QoS. Since VPN makes use of network resources from the public network provider, negotiation between VPN manager and public network provider must be made in order to get appropriate amount of resources for the VPN connections. Beside QoS, security guarantee of the VPN should also be considered. However, public network provider is less involved in the security guarantee. This is due to three reasons: 1. Most of the VPN users think that public network provider is less trustworthy. This is understandable as the VPN users know very little on the public network provider. VPN users do not know much on the internal organization of public network provider, nor do they know much on the sta and the operation policies of the public network provider. Any sta in the public network provider company can be a potential hacker. Since there are so many unknowns on the public network provider, the public network provider is likely to be the weakest point in the whole security architecture.
168
K.H. Cheung, J. Misic / Computer Networks 38 (2002) 165±179
Fig. 2. Modi®ed VPN management architecture.
2. Even though the public network provider is trustworthy, large provider is always the targets of many security attacks, e.g. distributed denial of service attack and hacking. 3. Public network provider only needs to assure that the VPN users are eligible to use the reserved VPN resources. Hence only authenticity must be provided while con®dentiality is optional. In the modi®ed architecture (Fig. 2), public network provider participates in granting its resources to the VPN. These resources may be granted in the sense that: 1. Only the VPN user can use the resources (dedicated). 2. Resources are acquired dynamically during the establishment of VPN connections. In the ®rst case, semi-permanent connections are established between the VPN manager and VPN users so that a pre-de®ned amount of bandwidth is available for the VPN. The solution is costly, but the establishment of semi-permanent connections allows VPN manager to manage the dedicated resource. VPN manager can then design its own access policy on the dedicated resource. This leads to an extra level of access control security. In the second case, the VPN manager consumes an integrated service or a dierential service from the public network provider. This is a less costly solution while the QoS can be guaranteed. However, the VPN manager cannot control the use of public network resources. In both cases, reservation protocol must be implemented to carry out bandwidth reservation
(either statically during the VPN establishment or dynamically during communication). In the text that follows we will outline the roles of each VPN component. Public network provider will be in charge of QoS guarantee on the VPN through a negotiation with the VPN manager. It plays no special function after the establishment of VPN. Public network provider gets involved again when the VPN speci®cation needs to be changed. VPN manager plays the central role. VPN manager acts as a gateway to the LAN from the outside world. Security mechanisms must be implemented to check access rights and the validity of each VPN connection. Besides, VPN manager needs to perform operational work to keep the VPN functioning properly. This includes the monitoring of VPN connections and handling VPN attacks. VPN users are just casual users who request VPN services. They carry out security mechanisms to protect the communication messages. Also, they assist on detecting security attacks. VPN users connect to the remote access server of the public network provider. In order to clarify their identities, the VPN users may make use of dierent authentication mechanisms to communicate to the remote access server, e.g. the use of challengehandshake protocols, digital certi®cates or smart cards. After the veri®cation of their identities, the VPN users are permitted to access the pre-negotiated VPN resources. The VPN users can now communicate with each other by their own VPNspeci®c secrets. These VPN-speci®c secrets are known by the VPN members only. 3. VPN services In order to allow the users to control their own VPNs, a number of services must be provided. 1. Operational services to maintain the daily operations of the VPNs. 2. Security recovery services to protect the VPNs against adversaries' attacks. 3. Communication services to enable the VPN members to exchange information.
K.H. Cheung, J. Misic / Computer Networks 38 (2002) 165±179
Our VPN solution must provide the above services to the customers. In particular, our VPN solution must ful®ll the following requirements: 1. Operational requirements. (a) The VPN system should perform liveness checking of the VPN links whenever there is a suspicion about the network problem or the presence of denial of service attack. (b) The VPN system should synchronize the local clocks of all VPN members regularly in order to minimize the success rate of replay attacks. (c) The VPN system should allow users to extract information from the management database. In particular, statistical data kept at the RMON agents should be sent to the RMON manager so that the RMON manager can carry out analysis on the network performance. (d) The VPN system should detect any security attacks on the VPN. For example, the VPN system should be able to detect ``message spoo®ng'' attacks, ``bandwidth stealing'' attacks and ``denial of service'' attacks. We will discuss these attacks when we are considering the security recovery requirements later in this section. 2. Security recovery requirements. (a) The VPN system should make sure that the end-points of all intra-group communications belong to the same VPN group. An adversary may try to pretend to be a VPN member by message spoo®ng and participate in an intra-group communication. In this case, the adversary may be able to trick a VPN member into accepting a message that is not authentic. The VPN system should assure that the probability of successfully forging or altering messages is acceptably small. (b) The VPN system should control access to the VPN-speci®c resources like dedicated bandwidth. An example security breach is ``bandwidth stealing'', in which the adversary tries to use the dedicated bandwidth without approval from the VPN system. In this case, the bandwidth is still dedicated to a VPN but the adversary can ``steal'' its usage. The VPN
169
management system should ensure that the probability of ``bandwidth stealing'' is acceptably small. (c) The VPN system should have security mechanisms to assure the provision of services to the VPN members. The adversary may carry out a ``denial of service attack'' such that the service requests originating from a particular VPN member are blocked. Since the requests cannot reach the recipients, the blocked VPN member cannot get the VPN service. The VPN system should limit the duration of the denial of service attack to an acceptable time value. (d) The VPN system should have security mechanisms to detect the trustworthiness of the VPN members. Based on the trustworthiness, the VPN manager may change the access permissions of the ``not-so-trusted'' users on ¯y so that they cannot access sensitive information. 3. Communication requirements. (a) The VPN system should allow VPN members to communicate with each other (intraVPN communication). (b) The VPN system should allow VPN members to communicate with parties that are not members of the VPN (inter-VPN communication). (c) The VPN system may also allow VPN members to broadcast any messages to other members within their VPNs. Our VPN solution matches all these requirements by de®ning a number of mandatory VPN operations. These operations are grouped into three applicationsÐoperational application, security recovery application and communication application. Table 1 summarizes all the required VPN services and lists out the mandatory VPN operations for each VPN service. 4. VPN protocol stack In this section, we are going to introduce the VPN protocol stack that provides the VPN
170
K.H. Cheung, J. Misic / Computer Networks 38 (2002) 165±179
Table 1 VPN service requirements and corresponding VPN operations Requirements
Operations
Operational requirement
1. Liveness checking of VPN link 2. Clock synchronization 3. Extraction of VPN management information 4. Detection of message spoo®ng 5. Detection of bandwidth stealing 6. Detection of denial of service
Security recovery requirement
1. 2. 3. 4.
Recovery from message spoo®ng Recovery from bandwidth stealing Recovery from denial of service Veri®cation of trustworthiness of VPN members
User communication requirement
1. 2. 3. 4. 5.
Set up of Intra-VPN communication Set up of Inter-VPN communication Intra-VPN communication Inter-VPN communication Broadcasting
features and VPN operations as mentioned in Sections 1 and 3. The protocol stack has three layersÐVPN application layer, convergence and control layer and data protection layer. Network layer is implemented under the data protection layer. Fig. 3 outlines the VPN protocol stack.
The human or non-human VPN components invoke the operations at the VPN application layer. During the invocation, the VPN components provide all the necessary parameters. The parameters are then passed to next layer for processing. At the middle layer (convergence and control layer), the VPN operation will be executed by calling one or more of the underlying protocols. The parameters are encapsulated into messages of the underlying protocols. The messages created at the middle layer are then passed to next layer for data protection. Security mechanisms will be invoked at this layer to provide con®dentiality, integrity, authenticity and timeliness. The protected messages are then transmitted to the remote end. 4.1. VPN application layer This is the top most layer of our VPN protocol stack. This layer directly interacts with the VPN users through the user interface. The VPN application layer hides the complexity of the underlying layers and provides high-level VPN services to the users. The users select the VPN operations with the necessary parameters. On the other hand, the VPN application layer may also provide VPN information back to the users. There is no limitation on how the VPN application should be implemented. Due to the popularity of world-wide-web, the VPN applications can be written by programming languages that are independent of the operating system platforms. Since the VPN applications are platform independent, the compatibility can be enhanced. Moreover, the VPN applications can be browserbased. In that case, only a browser is required at each client machine. This helps to simplify the installation procedure. The VPN application layer provides a number of services, including operation management, security recovery and communications. These services are implemented as VPN operations (Section 3). 4.2. Convergence and control layer
Fig. 3. VPN protocol stack.
This is the core layer of our VPN protocol stack. The convergence and control layer reads the
K.H. Cheung, J. Misic / Computer Networks 38 (2002) 165±179
parameters from the VPN application layer and then formats these information into appropriate messages of the embedded protocols. These messages are then passed to next layer for encryption and authentication. The protocol at this layer also interacts with the database (management information base or MIB in short). Before sending the formatted messages to the remote end, the embedded protocols may be triggered to update the VPN information at the local MIB. Similarly, when a message is received at the remote end, the embedded protocol may be triggered to update the MIB before passing the message to the VPN application layer. 4.3. Data protection layer The messages generated at the convergence and control layer are in ``plaintext'' format, i.e. they are not protected by con®dentiality mechanism (which acts against the disclosure of sensitive information without approval), authenticity mechanism (which provides evidence on the identity of sender in the message) and integrity mechanism (which acts against the modi®cation of message in transit). In order to protect the messages against the adversaries' attacks, we need to apply the security mechanisms on the messages. Since nearly all messages require security protection, we would like to use a single security module to handle the messages. Hence we are not using the security mechanisms provided by the embedded protocols. Instead, we propose an extra layer for security protection. Con®dentiality mechanisms, authenticity mechanisms and integrity mechanisms are required at the data protection layer. The choices of the mechanisms are independent of the VPN management architecture. In our work, we make use of IP security [11±13] (hence the data protection layer is merged with IP layer). IP security is a standard feature of IPv6. It is aimed at providing security at the network layer. IP security can be applied to our VPN management architecture without any modi®cations. According to IP security, encapsulating system payload (ESP) mode of IP security [12] is sucient
171
to provide the required security services of our VPN. ESP provides con®dentiality, authenticity and integrity by encrypting and signing the payload data and part of the header options (e.g. destination options) of the original IP packet. After applying security mechanisms on the messages, the messages are passed to the network layer for transmission. 4.4. Network layer At this layer, the messages are routed to the remote end. Since we are using public network as the underlying network, we assume the use of IP as the network layer protocol. Since there are two versions of IP (IPv4 and IPv6), we need to consider the inter-operability between IPv4 VPN components and IPv6 VPN components. It may happen that one VPN component is using IPv4 while the other VPN component is using IPv6 and they need to communicate with each other. In this case, special action must be done to allow the communication. Here, we adopt the idea of Stevens [22]. Each IPv6 component has an IPv4-mapped IPv6 address in which the address can be transformed into an equivalent IPv4 address. If an IPv4 component wants to communicate with this IPv6 component, then the IPv4 component uses the equivalent IPv4 address and sends an IPv4 packet to the IPv6 component. The IPv6 component, upon receiving the IPv4 packet, extracts the data from the IPv4 packet and converts the IPv4 address into IPv4-mapped IPv6 address. The converted IPv6 address will then be passed to the upper layer. If an IPv6 component wants to communicate with an IPv4 component, the IPv6 component obtains the IPv4-mapped IPv6 address of the IPv4 component and constructs the transport layer packet. The packet and the address are then passed to the IP layer. At the IP layer, the address is then converted to the equivalent IPv4 address. An IPv4 packet will be constructed to transfer the transport layer packet towards the IPv4 component. In both cases, IPv4 packets are sent across the network.
172
K.H. Cheung, J. Misic / Computer Networks 38 (2002) 165±179
The address mapping is performed at the IPv6 components. The IPv6 components implement a dual-stack IP protocol to receive both IPv4 and IPv6 packets. Finally, we illustrate the inter-operability of IPv4 and IPv6 in the following example. Suppose that VPN component A uses IPv4 and VPN component B uses IPv6 and they want to communicate with each other. A starts the communication steps as follows (Fig. 4): 1. A gets B's IPv4 address and constructs a IPv4 packet. 2. The IPv4 packet is passed to ESP for security protection. A new IPv4 header is appended to the ESP payload. 3. The IPv4 packet (encrypted and authenticated) is transmitted across the VPN to B. 4. B receives the IPv4 packet through the communication layer opened by the raw socket and extracts the ESP payload. 5. The ESP payload is passed to ESP for security operations. 6. The original IPv4 packet (which was encapsulated in ESP) is passed to the upper layer. A's IPv4 address is mapped to corresponding IPv6 address and passed to the upper layer. B reverses the above steps to send an IPv4 packet to A.
5. Protocol modules to support the VPN service In order to support the VPN service mentioned in Section 3, a number of protocol modules should be used. The protocol modules include: 1. Simple network management protocol (SNMP). 2. Reservation protocol (RSVP). 3. Simple network time protocol (SNTP). 4. Remote monitoring protocol (RMON). 5. Membership management protocol. 6. Null protocol. The protocol modules access the database (management information base) whenever necessary. The use of these protocol modules are further explained as follows. 5.1. SNMP SNMP [1,3,9,14,25] is one of the embedded protocols that must be implemented in our VPN software. SNMP is designed to manage the MIB of the network components. In our VPN software, SNMP is responsible of: 1. Communication of VPN information. SNMP is used to transfer VPN-speci®c parameters be-
Fig. 4. Inter-operability of IPv4 and IPv6 VPN components.
K.H. Cheung, J. Misic / Computer Networks 38 (2002) 165±179
173
tween the VPN components. The parameters include sensitive ones (e.g. secret keys) and insensitive ones (e.g. QoS parameters). 2. Retrieval of MIB information. SNMP is used to transfer any management information from the VPN members or RMON agents (if RMON is used) to the VPN manager, e.g. the statistical data kept by the RMON agents. The VPN manager may analyze the data for future network planning. 3. Reporting of security alarms. Whenever there is a suspect on security breach, the VPN component under attack generates a security alarm (which is a SNMP trap) to the VPN manager. The VPN manager then triggers the security recovery operations. Examples of security breaches are: (1) message spoo®ng in which an adversary pretends to be a VPN member and spoofs message; (2) bandwidth stealing in which an adversary uses any dedicated bandwidth of the VPN without approval from the VPN system; (3) the denial of service in which an adversary tries to block the service requests of the VPN members.
1. Only authenticity should be guaranteed for the RSVP messages. Con®dentiality (and hence encryption) is not necessary. This helps to speed up the processing of RSVP messages. 2. The checking of available resources at each network device can be completed easily. A table can be kept at each network device which records the amount of all available resources. The VPN software can just simply check this table to determine if the RSVP request can be ful®lled. 3. The update of remaining resources at each network device may be more complex. At the high level (VPN software), the same resource table as mentioned above would be updated. This update should take negligible processing time. At the low level (network device), speci®c actions must be carried out to instruct the device to perform resource reservation. The processing time and processing overhead depend on the nature of the device. If the device is RSVP-enabled, then the device is likely to be optimized to handle resource reservation and hence the overhead should be minimized.
5.2. RSVP
5.3. SNTP
In our VPN software, RSVP [26] is used to handle the bandwidth reservation. During the establishment of a VPN connection, RSVP message is sent across the public network to reserve bandwidth. The intermediate nodes verify if they have sucient resources to satisfy the request. If they have sucient resources, then they forward the request to next hops. Otherwise, they ®nd out the best alternative on satisfying the request and modify the request to re¯ect the alternative. The amended request is then forwarded to next hops. Eventually the destination receives the RSVP request. It generates RSVP responses back to the initiator. When intermediate nodes receive the responses, they carry out bandwidth reservation and forward the responses to the previous hop (towards the initiator of the request). The whole reservation should not add too much workload on the network devices. This is due to three reasons:
SNTP [17] is a compulsory embedded protocol in our VPN software. SNTP is used to synchronize the clocks among the VPN components so that the requirement of timeliness can be met. Timeliness is an important property to minimize the success rate of message replay [7]. SNTP server broadcasts synchronization messages to the agents at regular time intervals. The agents need not send any request to the server except during the start-up phase of the agents. On the other hand, a ``clock synchronization'' operation can be implemented to allow the SNTP server to send a synchronization broadcast immediately before the next time interval. This helps to minimize the damage of message replays on VPN. 5.4. RMON RMON [23,24] is an optional protocol in our VPN software. RMON is used for network
174
K.H. Cheung, J. Misic / Computer Networks 38 (2002) 165±179
monitoring, which is an essential feature of ideal VPN as mentioned in Section 1. RMON is used to collect network statistics for network management and future planning. It can also be used to detect any security breaches on the VPN by monitoring the trac in the VPN. In our VPN software, the VPN manager acts as the RMON management station while the other VPN components and the routers act as the RMON agents. 5.5. Membership management protocol The membership management protocol is used to evaluate the trustworthiness of the VPN members. The protocol is based on Reiter's ``secure group membership protocol'' [20]. Each VPN member carries out its own evaluation on the other VPN members. The evaluation can be based on the validity of the communication messages from the VPN members. If a VPN member suspects that peer VPN member is not trustworthy anymore, then the VPN member raises a noti®cation to the VPN manager. The VPN manager carries out polling with all its VPN members. If over twothird of VPN members agree, then the suspected member will be classi®ed as untrustworthy. 5.6. Null protocol Null protocol is used to pass VPN information (e.g. QoS information) or communication message to the remote party. The protocol simply encapsulates the data by the protocol message header without any translation on the data.
Table 2 Translation of VPN operations into VPN protocol messages Operations Operational management 1. Liveness checking of VPN link 2. Clock synchronization 3. Extraction of VPN management information 4. Detection of message spoo®ng 5. Detection of bandwidth stealing 6. Detection of denial of service attack Security management 1. Recovery from message spoo®ng 2. Recovery from bandwidth stealing 3. Recovery from denial of service attack 4. Veri®cation of trustworthiness of VPN members
User communications 1. Set up of Intra-VPN communication 2. Set up of Inter-VPN communication 3. Intra-VPN communication 4. Inter-VPN communication 5. Broadcasting
Messages sent Null SNTP SNMP SNMP SNMP SNMP SNMP SNMP RSVP, SNMP, Null Membership management, SNMP, RSVP, Null Null Null Null Null Null
1. Identify the mapping between VPN functions and corresponding protocol messages. Table 2 summarizes all the VPN operations and the messages sent for each of them. 2. Design the signaling between the protocol modules. This item is beyond the scope of this paper. 6.1. Mapping between VPN operations and VPN protocol modules
6. Translation of VPN operations
In this sub-section, we brie¯y describe the mapping between the necessary VPN operations and the VPN protocol modules.
We can now co-relate the VPN services, VPN protocol stack and the VPN protocol modules together. As we have mentioned, the VPN services are provided by the VPN operations as illustrated in Table 1. Each operation is carried out by the interaction of the protocol modules in the convergence and control layer. The study of this interaction can be divided into two phases:
1. Operational management. · Liveness checking of VPN link. To check the VPN link, each VPN device sends an ``operation, administration and maintenance'' (OAM) packet to the remote end at periodic intervals. If the remote end does not receive the OAM packet over a pre-de®ned period, then the VPN link is considered to be lost.
K.H. Cheung, J. Misic / Computer Networks 38 (2002) 165±179
In this case, the VPN software only needs to transfer the OAM packet to remote end without the use of any speci®c protocol modules. Hence the null protocol module should be used. · Clock synchronization. SNTP protocol module is designed to handle clock synchronization between the network devices. · Extraction of VPN management information. The VPN management information is stored in the MIB of VPN manager. Among all protocol modules, SNMP is designed to retrieve MIB objects and hence should be used in this case. · Detection of message spoo®ng/bandwidth stealing/denial of service attack. To detect message spoo®ng attacks, a number of VPN counters are maintained at each device to keep track of the number of security attacks. If the counter has exceeded a pre-negotiated threshold, then alert messages would be sent to the VPN manager. The alert messages are sent as SNMP traps and hence SNMP would be used. 2. Security management. · Recovery from message spoo®ng/bandwidth stealing. The recovery action involves the negotiation of a new set of secrets between the victim VPN members. The communication would be done by SNMP. · Recovery from denial of service attack. The recovery involves a change on the VPN topology and hence RSVP must be used. Besides, during the change on VPN topology, VPN information on certain network devices may need to be updated and hence SNMP (and null protocol) may also be used. · Veri®cation of trustworthiness of VPN members. Membership management protocol is designed to verify the trustworthiness of VPN members. If any member is not trustworthy, then new secrets may need to be distributed and hence SNMP (and null protocol) may be used. On the other hand, the VPN topology may need to be changed to bypass untrusted VPN members. Hence RSVP (and SNMP and null protocol) may be used as well.
175
3. User communication. · All user communication operations. The initiating VPN member encrypts and signs the messages and sends the messages to the remote end. In all these cases, the VPN software should only encapsulate the messages by suitable IP headers and forward the messages to remote end. Hence only null protocol should be used in all these operations. 7. VPN software In this section, we are going to introduce the design of a VPN software that incorporates the VPN protocol modules to provide the VPN services. The VPN software carries out the functions of convergence and control layer and data protection layer, i.e. the VPN software converts the VPN service requests to a number of embedded protocol messages and then carries out security mechanisms to protect the protocol messages. 7.1. Architecture of CSSP In our VPN management architecture, the VPN functions are performed by a piece of specialized equipment called ``customer sited security processor'' (CSSP). The CSSP is associated to the gateway station or a user station. The CSSP carries out privacy/authentication/timeliness mechanisms to protect the VPN messages when they are going to transverse through the public network. The CSSP also veri®es the validity of any received VPN messages. The CSSP keeps the VPN parameters and other relevant information in a database (Management Information Base or MIB in short). The CSSP can be either a software package or a hardware processor. Each of them has advantages over the other. A hardware CSSP is tailored for VPN functions and hence it can operate optimally. The security mechanisms are likely to be implemented as hardware (cards or chips) and hence the security operations will be very fast. Besides, the hardware CSSPs are specially designed so that no unnecessary operations or access points are present. This helps to give a simpli®ed environment
176
K.H. Cheung, J. Misic / Computer Networks 38 (2002) 165±179
for security protection. However, hardware CSSPs are expensive. They are less ¯exible and adaptable to network expansion. Software CSSPs cost less and adapt to network expansion easily. By installing the software CSSPs on general workstations, VPN can be established or expanded. Besides, the security mechanisms are implemented as imported modules. This gives extra ¯exibility to the CSSPs on upgrading their security mechanisms. However, software CSSPs require extra eort on security protection and their performance will be worse compared to the performance of their hardwired counterparts. In this paper, we assume the use of software CSSPs. By enforcing strict access control, the CSSPs can be protected against intruders. Moreover, the security mechanisms can be coded in an optimized fashion to increase the throughput. The optimized codes are still imported to the CSSPs and hence the ¯exibility can be guaranteed. The design of CSSP can be considered as a variation of SNMPv3 engine. The architecture of CSSP is shown in Fig. 5: 1. DispatcherÐDelivers VPN messages to corresponding applications on the CSSP, to the message processing subsystem or to the security subsystem.
Fig. 5. Structure of CSSP.
2. Message processing subsystem (MPS)ÐIt helps to prepare messages for sending, or extracting data from received messages. 3. Security subsystem (SS)ÐThe security mechanisms are called by the SS. It is responsible of checking authenticity, privacy and timeliness of received messages. It also protects outgoing messages by encryption/authentication/addition of time-stamp. 4. Access control subsystem (ACS)ÐIt controls the access rights of the management objects in the MIB. Besides, a number of VPN applications reside in the CSSP. These applications handle the VPN operations, including operational operations, security recovery operations and communication operations. 7.2. Message processing sequences of CSSP When the CSSP receives a message from the remote counterpart, the sequence of actions is given as follows (graphical representation is shown in Fig. 6): 1. The dispatcher passes the message to security subsystem.
Fig. 6. Message processing sequence (1).
K.H. Cheung, J. Misic / Computer Networks 38 (2002) 165±179
2. The security subsystem veri®es the authenticity and timeliness of the message. If the message is valid, then it decrypts the message. The security parameters and the mechanisms to be used are determined from the MIB. 3. The security subsystem passes the decrypted message back to dispatcher. 4. The dispatcher passes the decrypted message to message processing subsystem. 5. The message processing subsystem extracts the data from the received message. 6. The message processing subsystem passes the extracted data to the dispatcher. 7. The dispatcher passes the data to corresponding application. 8. The application consults the access control subsystem to check the access rights of the initiator. The application also accesses the MIB whenever necessary. If the CSSP is the initiator of a message, the sequence of actions is given as follows (graphical representation is shown in Fig. 7): 1. The application generates the request/noti®cation. 2. The request/noti®cation is passed to the dispatcher.
177
3. The dispatcher directs the request/noti®cation to message processing subsystem. 4. The message processing subsystem formats the request/noti®cation in IP format. 5. The message processing subsystem passes the formatted message to dispatcher. 6. The dispatcher passes the formatted message to the security subsystem. 7. The security subsystem encrypts and signs the message. The security parameters and mechanisms to be used are determined from the information at the MIB. 8. The security subsystem passes the encrypted and signed message to dispatcher. 9. The dispatcher transmits the encrypted and signed message to the remote end. 8. Related work In this paper, we have proposed a number of ideas on VPNsÐVPN protocol stack, essential VPN services, VPN software and VPN modules. So far as we know, the design of VPN protocol stack, the consideration of VPN services (in particular the services related to security attacks and recoveries), and the mapping between the VPN services and VPN modules are original. The design of VPN software is inspired by the architecture of SNMPv3 engine [3,14]. We modify the architecture of SNMPv3 engine to suit the VPN requirements: 1. Other protocol modules are included in the engine. 2. The message processing sequence is rearranged to match with the design of VPN protocol stack. In the past few years, many researchers were also working on the security and QoS issues of VPNs. In Refs. [2,15], the authors also proposed the use of IP-Sec and DiServ to assure security and QoS guarantees of the VPNs. Our work diers with theirs in the following sense:
Fig. 7. Message processing sequence (2).
1. We consider the security issues and the possible security attacks during the design phases. On
178
K.H. Cheung, J. Misic / Computer Networks 38 (2002) 165±179
the other hand, in Refs. [2,15], the authors were more focused on QoS issue and had not discussed security issues in depth. 2. Our work has focused on the functional mapping between a number of VPN services (operational, security and user communication) and the underlying mechanisms to carry out the operations. Refs. [2,15] were focused on the establishment of VPNs and the dynamic changes to the QoS requirements of the VPNs. Our work gives a more complete picture on the essential VPN services. Ref. [10] had introduced the idea of resource revocation in which dedicated VPN resources can be released dynamically back to public network if they are not used. In our work, we provide the function of resource revocation by using the softstate feature of RSVP. The resource reservation must be refreshed periodically at each network device or else the resources will be returned to public network. If only part of the resource is no longer required, then the soft-state at each network device will be refreshed with a new ¯ow speci®cation. In this case, our work would have similar performance with Isaacs and Leslie [10]. However, if the resource is no longer required, then we do not need to send any request to release the resource. This helps to save the amount of processing work. 9. Conclusion In this paper, we propose several design issues on virtual private networks. In the ®rst part of the paper, we have proposed the design of a VPN protocol stack. The stack consists of four layersÐVPN application layer, convergence and control layer, data protection layer, and network layer. We have also discussed the mandatory VPN services. Our work is not bounded to the underlying data-link and physical layer technology. Our protocol can be implemented over casual OSI architecture, ATM architecture, or directly over WDM optical network [19] (Fig. 8). For the last case, a high speed VPN can be established.
Fig. 8. Implementation of VPN protocol stack over dierent transmission technologies.
In the second part, we have proposed a design on VPN software that guarantees security, QoS, connectivity and monitoring. Our work is based on the generic architecture of SNMPv3 engine in order to provide security. Dierentiated/integrated services are consumed from public network provider to assure QoS. Monitoring and connectivity criteria are satis®ed by the protocol modules in the VPN software. In order to implement high-end VPN product, all the protocol modules must be integrated together. The feasibility of VPN software also depends on the state of the art in Internet technology. One example is the RSVP-enabled routers [18]. The routers allow bandwidth reservation to be carried out over the Internet. We envision that more and more network components will support bandwidth reservation and the essential criteria for an ideal VPN. References [1] U. Blumenthal, B. Wijnen, User-based security model for version 3 of the simple network management protocol, Request for Comments from Network Working Group, no. 2274. [2] T. Braun, M. Guenter, I. Khalil, Management of quality of service enabled vpns, IEEE Commun. Mag. (May 2001) 90±98. [3] J. Case, D. Harrington, R. Presuhn, B. Wijnen, Message processing and dispatching for the simple network management protocol, Request for Comments from Network Working Group, no. 2272. [4] CheckPoint Software Technologies Ltd, Product information available via http://www.checkpoint.com/products/ ®rewall-1/index.html. [5] Cisco Systems, Inc., Product information available via http://www.cisco.com/warp/public/cc/cisco/mkt/security/pix/.
K.H. Cheung, J. Misic / Computer Networks 38 (2002) 165±179 [6] Cisco Systems, Inc., Cisco L2F information available via http://www.cisco.com/warp/public/728/General/vpdn_wp.htm. [7] D. Denning, G. Sacco, Timestamps in key distribution protocols, Commun. ACM 24 (8) (1981) 533±536. [8] Digital Equipment Corp., Product information available via http://www.altavista.software.digital.com/tunnel/ index.asp. [9] D. Harrington, R. Presuhn, B. Wijnen, An architecture for describing SNMP management frameworks, Request for Comments from Network Working Group, no. 2271. [10] R. Isaacs, I. Leslie, Support for resource-assured and dynamic virtual private networks, IEEE J. Selected Areas Commun. 19 (3) (2001) 460±472. [11] S. Kent, R. Atkinson, IP authentication header, Request for Comments from Network Working Group, no. 2402. [12] S. Kent, R. Atkinson, IP encapsulating security payload, Request for Comments from Network Working Group, no. 2406. [13] S. Kent, R. Atkinson, Security architecture for the Internet protocol, Request for Comments from Network Working Group, no. 2401. [14] D. Levi, P. Meyer, B. Stewart, SNMPv3 applications, Request for Comments from Network Working Group, no. 2273. [15] L.K. Lim, J. Gao, T.S. Eugene Ng, P.R. Chandra, P. Steenkiste, H. Zhang, Customizable virtual private network service with QOS, Comput. Networks 36 (2001) 137±151. [16] Microsoft Corporation, PPTP information available via http://www.microsoft.com/communications/PPTP.htm. [17] D. Mills, Simple network time protocol version 4 for IPv4, IPv6 and OSI, Request for Comments from Network Working Group, no. 2030. [18] A. Neogi, T. Chieuh, P. Stirpe, Performance analysis of an RSVP-capable router, IEEE Network 13 (5) (1999) 56±63. [19] Optical Internetworking Forum Web Site. http://www. oiforum.com. [20] M. Reiter, A secure group membership protocol, Symposium on Research in Security and Privacy, 1994. [21] C. Scott, P. Wolfe, M. Erwin, Virtual Private Networks, O'Reilly, 1999.
179
[22] R. Stevens. UNIX Network Programming Volume 1, Prentice-Hall, New York, 1988. [23] The ATM Forum Technical Committee, Remote monitoring MIB extensions for ATM networks, May 1997. Internet draft. [24] S. Waldbusser, Remote network monitoring management information base version 2 using SMIv2, Request for Comments from Network Working Group, no. 2021. [25] B. Wijnen, R. Presuhn, K. McCloghrie, View-based access control model for the simple network management protocol, Request for Comments from Network Working Group, no. 2275. [26] L. Zhang, S. Deering, D. Estrin, RSVP: a new resource reservation protocol, IEEE Network 7 (5) (1993) 8±18. Cheung Kwok Ho received his Bachelor of Engineering degree and Master of Philosopy degree in Computer Science from Hong Kong University of Science and Technology (HKUST) in 1996 and 2000. He is now working as a member of network systems team in Information Technology Service Center (ITSC) of HKUST. His research interests include network management, network security and VPNs.
J. Misic received her Ph.D. degree in Computer Engineering 1993, from University of Belgrade, Yugoslavia. She joined Hong Kong University of Science and Technology in 1995 where she is Assistant Professor. Her current research interests include wireless networks, mobile computing and network security. She is the member of IEEE Computer Society.
