A Layered Framework Strategy for Deploying High ...

Copyright 2000. Published in the Proceedings of the 5th Annual IEEE International Symposium on High Assurance Systems Engineering (HASE 2000) Albuquerque NM. USA, Nov. 2000. Personal use of this material is permitted. However, permission to reprint/republish this material for advertising or promotional purposes or for creating new collective works for resale or redistribution to servers or lists, or to reuse any copyrighted component of this work in other works, must be obtained from the IEEE. Contact: Manager, Copyrights and Permissions / IEEE Service Center / 445 Hoes Lane / P.O. Box 1331 / Piscataway, NJ 08855-1331, USA. Telephone: +Intl. 732-562-3966.

A Layered Framework Strategy for Deploying High Assurance VPNs* Samuel Patton

Bryan Smith

David Doss

William Yurcik**

Illinois State University Department of Applied Computer Science {stpatto,basmit3,dldoss,wjyurci}@ilstu.edu Abstract Deploying Virtual Private Networks (VPNs), especially in a large-scale environment, requires a large amount of planning. Based on actual implementation experience, this paper proposes a layered framework as a high-level process that can be used to distribute VPN deliverables among different workgroups. Despite the common perception that a VPN is not a customizable solution, we conclude that there is a broad range of VPN options available with corresponding trade-offs. This framework supports advanced planning to maximize trade-offs depending on individualized requirements.

45 Mb/s (T3)* 1.5 Mb/s (T1)* Frame Relay** Cable Modem***

Keywords: VPN, tunneling, firewalls, IPSEC, GRE

ADSL***

1. Introduction Figure 1 shows the WAN portion of the 2x Corporation VPN. This paper summarizes experiences gained from deploying this VPN which consists of 65 nodes interconnected wih seven point-to-point tunnels. Each node setup with a point-to-point link is running GateD (routing daemon) using OSPF to route traffic through the virtual network. Services currently provided include DNS, WWW, FTP, Email, and IRC. For OSPF, there are five areas with one area router per area – areas 2 and 3 are running ASBR with BGP/BGP2. Future work is directed to implementing multicast OSPF and Certificate Authority between a desktop browser and a server application for secure E-commerce transactions using Secure Sockets Layer (SSL). The goal of this paper is to provide an assurance model for organizations to follow when deploying a VPN. The remainder of the paper is organized as follows: Section 2 describes VPN technology options. Section 3 describes firewall options. Section 4 describes security issues related to interoperability with legacy network infrastructure. Section 5 describes survivability issues and Section 6 describes the continuing support of legacy applications. We close with a summary of the framework and directions for future research. Figure 2 shows an overview of the five layers of analysis. * Manuscript received on 5/26/00. This work was supported in part by grants from Deere & Co., State Farm Insurance Co., and the 2x Corporation. ** Corresponding author; additional contacts: voice/fax 309-438-8016/5113, hard copy: Campus Box 5150, 202 Old Union, Normal IL 61790 USA.

* dedicated ** committed information rate (CIR) variable by month *** asymmetric bandwidth

Figure 1. Wide Area Network Topology for 2x Corp.

2. VPN Technology [4, 6, 9] There are different types of VPNs corresponding to the different layers within the TCP/IP protocol suite: Data Link, Network, Transport, and Application Layers. For purposes of this paper we focus on network layer VPNs using native TCP/IP while acknowledging that this same discussion is also relevant for VPNs using an underlying data link-level infrastructure based on Frame Relay or ATM. The “peer” VPN model is one in which paths are computed on a hop-by-hop basis, where each node in the path is a peer with a next-hop node. The “overlay” VPN model is one in which the network-layer forwarding path is not done on a hop-by-hop basis, but rather, the intermediate link-layer is used as a “cut-through” to another edge node on the other side of a public network cloud. The overlay model introduces serious scalability problems since network management to maintain routing information increases in direct proportion to the number of connected sites. A subtype of the overlay VPN model is “tunneling” with the most common tunneling mechanism being Generic Routing Encapsulation (GRE) tunneling between the source and destination router, router-to-router, or host-to-host.1

1

Specific examples of GRE tunneling protocols include Layer 2 Tunneling Protocol (L2TP), Point-to-Point Tunneling Protocol (PPTP), and Distance

VPN DEPLOYMENT (1) VPN Technology A peer-to-peer versus overlay B encryption (2) Firewall Considerations A filtering policies B firewall performance (3) Existing Network Infrastructure A supporting legacy traffic and protocols B impact of Internet “problems” on VPN (4) Survivability A replication and graceful degradation B dynamic or pre-planned recovery (5) Infrastructure Dependent Applications A remote dial-up scenario B intranet scenario C extranet scenario

End-to-end encryption to individual end systems provides for the highest level of security. “Tunnel mode” encryption to the subnetwork level is performed between intermediate routers leaving traffic between the end system and the first hop router in plaintext (tunnel ingress and egress points are vulnerable since they are both site network and VPN). Any corruption of operation or interception of traffic at tunnel endpoints will compromise the entire VPN. Other assurance issues related to encryption include the following: • • • •

Figure 2. Layered Framework for VPN Decision-making Tunnels between a source (ingress) and a destination (egress) router encapsulate source packets with a new GRE header and forward them into a tunnel with a destination address of the tunnel endpoint. When the packet reaches the tunnel endpoint, the GRE header is stripped away (un-encapsulated) and the packet is forwarded to its original destination designated in the original IP packet header. A VPN thus can be created by a collection of tunnels between sites where site/VPN routing is isolated since the tunnel egress addresses are within a VPN site’s address space and the packets within the tunnel use a separate VPN address space. Tunneling can also encapsulate other protocols in a format which preserves their functionality – GRE tunnels are a proven, dependable way to encapsulate non-IP traffic for transport over IP networks. As a VPN overlay subtype, in addition to scalability problems there is also inherent inefficiency (suboptimal routing results since the cost of actual end-to-end routes through a tunnel is masked). Encryption technology is effective in providing the security and isolation required for a VPN and it can be deployed at almost any layer of the protocol stack. The evolving standard for network-layer encryption is IP Security (IPSEC).2 IPSEC is designed to allow security arrangements to be made without requiring changes to individual computers by providing two options: (1) sender authentication alone or (2) sender authentication with data encryption. Although most VPN vendors are moving to support IPSEC, not all VPN products are interoperable. In addition, IPSEC-based VPN traffic may encounter layerviolating devices (i.e., firewalls) that do not support IPSEC. Vector Multicast Routing Protocol (DVMRP) upon which the Multicast Backbone (MBONE) is based. 2 IPSEC is actually an architecture – a collection of protocols, authentication, and encryption mechanisms – as described in Internet Draft “Security Architecture for the Internet Protocol,” draft-ietf.ipsec-arch-sec-04.txt (authors Steve Kent and Ran Atkinson).

Determine a system for key management and key escrow. Determine a level of encryption appropriate to threats. Determine level of authentication appropriate to threats. Consider effect of encryption processing on network performance. All of the encryption algorithms are computationally intensive. It is essential to determine the level of processing needed at peak times in order to effectively handle a given number of secure connections. Measure bandwidth and latency on a zero encryption line and use this measurement as a benchmark against bandwidth and latency for various applied encryption levels. Record CPU and memory statistics associated with tests.

3. Firewall Considerations [3, 8] Route filtering via a firewall consists of filtering route propagation such that only specific networks receive routes for other networks that are within the VPN community of interest. Conversely, non-VPN routes are not announced on the networks of the VPN. Ingress security is implemented by the inability of VPN hosts to respond to packets with source addresses from outside the VPN community of interest. A more scalable approach is the use of Border Gateway Protocol (BGP) communities as a method to control route propagation. BGP communities allow a VPN to “mark” BGP network-layer reachability information (NLRI) with a community attribute that will control route propagation in accordance with a community profile. To ensure security for a VPN using tunneling, it is necessary to deploy ingress filters to prevent external packets with GRE formatting from being injected into the VPN. Other assurance issues related to firewalls include: •

•

Develop a security policy. The policy should include protection against source-routing and block the most common service-level addresses for Trojan applications. The policy should also address existing protection against denial-of-service (DOS) attacks and the partitioning effect a DOS attack could have on organizational connectivity. Determine if firewall performance with VPN traffic loads will allow a stateful filtering packet filtering implementation. If traffic loads make stateful filtering

•

unfeasible, determine the risk of implementing static or dynamic filtering. The risks of implementing one of the less secure filtering technologies can be offset through the use of string authentication. However in branch office scenarios where users may use the same link for Internet connectivity, stateful filtering should be used where possible (branch offices are the most probable points of attack). In addition, strong security measures should be taken to protect against mail, Java, Javascript, and ActiveX attacks. Consider the use of a web proxy to provide a higher level of security for branch office users that require Internet connectivity. In addition to preventing direct IP connections to user machines, proxies can provide content filtering capability as well as stronger control over an Internet appropriate use policy.

4. Existing Network Infrastructure [7] Existing network infrastructure and the ramifications of adding IPSEC must be considered when adding highperformance VPN capability. A migration path from current legacy systems to the integration of a VPN is often the practical solution. When existing network infrastructure cannot support a VPN, partitioning of network services should be considered. IPSEC supports two topology implementations: client and gateway. The client implementation, referred to as “bump in the stack” (BITS) is inserted between the local IP stack and network drivers. This approach is appropriate for legacy systems because it does not require access to source code. The gateway implementation, referred to as “bump in the wire” (because the IPSEC program executes on a device at the network edge) can be executed on a firewall, router, or a “black box” which implements IPSEC in silicon for speed. Other assurance issues related to existing network infrastructure include: •

•

•

•

From empirical network traffic measurements, identify legacy traffic that serves a valid business case and determine Quality-of-Service (QoS) requirements in terms of response time (delay), delay jitter, and packet loss. Adding VPN functions to existing routers can cause unacceptable performance impacts as VPN tunnel negotiation and encryption/decryption is processing intensive. If the installed routers cannot handle the load, consider a VPN appliance that is made-topurpose. In a heterogeneous multi-protocol environment, it is important to ensure that the VPN solution being implemented has support for tunneling or some other method for continuing legacy protocols. Network Address Translation (NAT) is one solution to an organization’s IP address depletion problems.

•

However, NAT has a few drawbacks. One problem is managing applications that use multiple service-level ports for communication.3 While solutions exist for integrating these technologies into NAT environments, the additional cost and processing/memory load on routers to maintain larger state tables could prove to be more expensive than simply purchasing routable IP addresses. Integration of VPNs over public networks also pose new challenges to internetwork performance monitoring. Businesses may need to be concerned with network management problems on the Internet worldwide since congestion and failures anywhere on the Internet have the potential to impact VPN performance and operations.

A detailed plan to deploy a VPN should include a pilot network with non-critical traffic in order to verify assumptions and operating costs. After successful completion of a pilot network, discrete network partitions can be migrated in phases with production networks in parallel during the entire process. It is advisable to start with a minimal set of VPN features and gradually turn on new capabilities and then let the network stabilize. Only after the operations and VPN user community have confidence should the old production network be turned off.

5. Survivability [1, 2, 5] Survivability refers to the ability of the VPN to continue to function despite parts of the system being unavailable due to component fault or attack. Single-points-of-failure should be avoided and replication of key resources should be required. If availability requirements are explicitly specified then reliable, diverse, and redundant components necessary to achieve the desired level of probabilistic availability may either be visible to or hidden from the enterprise. Graceful degradation paths should be planned and disaster recovery contingencies should be tested. Restoration timing below network and service thresholds is vital. Specific assurance issues related to survivability include: •

•

3

Protecting the keys to the kingdom. The strongest security policy should be developed for the Certificate Authority (CA) host. If this CA is compromised, the VPN is open to attack. Traffic allowed to and from the CA should be limited to the traffic necessary for the CA to function. CAs solve the scalability problems of user names/passwords and the problems of manual key distribution, making it possible to establish and maintain large VPNs involving millions of users. However, in order for the process to appear seamless to the end-user, the VPN provider must have a

Examples include protocols like H.323 which is used for Microsoft NetMeeting, Real Audio, and Voice-Over-IP applications.

•

•

•

•

certification authority and the expertise to issue and manage digital certificates to both VPN devices and end-users. Network Failure. A VPN should provide quick, secure recovery of link and node failures. Upon detecting a failure, restoration schemes include switching to preplanned backup routes or dynamic protocols that search for available backup routes given spare capacity. Early VPN implementations are “chained” together from many separate devices including routers, gateways, and firewalls. If any of these multiple components fail, the entire VPN may be lost or severely compromised. Combining all the VPN functions into a single hardened box with added redundancy features (such as multi-homed connections and reliable router recovery mechanisms) is a far more robust solution. It may be necessary, as a multihoming availability technique, to provision the VPN infrastructure through multiple ISPs. In such cases, the ISPs will need interprovider provisioning and VPN identification. New vulnerabilities for VPNs will surface. For example: if an established encryption algorithm is broken, large organizations using the obsolete algorithm in production will be faced with integrating new algorithms immediately.

6. Legacy Applications Even in cases where legacy network infrastructure can be eliminated, legacy applications will remain. No single vendor, standards body, or service provider has all the application interoperability answers for a VPN. To prevent a patchwork quilt of security protections, applications should be examined in each of the following scenarios: (1) remote dial-up access; (2) intranet VPN (dedicated connectivity within an internal organization); and (3) extranet VPN (dedicated connectivity with customers and suppliers outside of the firewall using permanent VPN connections). Inherently there will be a tradeoff between legacy applications and security with each organization determining an optimal level of risk. Examples of specific assurance issues related to legacy applications include: • • •

Network-dependent applications should be identified to determine the effect of potential addressing changes. Examples include DNS and Email. The use of encryption will pose new difficulties in protocol analysis, fault monitoring, content filtering, and other legacy network management functions. Running off-the-shelf VPN software on top of a general-purpose operating system introduces significant security concerns and performance limitations. The battle to keep general-purpose operating systems secure by applying the latest patches is a never-ending battle. Furthermore, these

•

operating systems contain a large percentage of code unrelated to providing security, which creates a performance burden and unknown security risks. Finally, the potential for subtle and often undetected misconfiguration of general-purpose operating systems makes them a unsound VPN foundation from an assurance perspective. As VPNs become larger and more complex, network management/logistic needs grow exponentially making network management support more attractive.

7. Summary We have presented a framework for VPN deployment decision-making based on actual implementation experience. We identify five distinct layers and describe, in varying detail, the major decision points within each layer. The term “VPN” is often used generically as if it were a single specific solution. The framework we have presented delineates the critical assurance issues for a decision-maker so they can recognize the broad spectrum of VPN options. Each distinct VPN solution has its own strengths, weaknesses, and vulnerabilities and it is anticipated that no single VPN solution will supplant others but instead a diversity of choices will continue to emerge. With the increasing number of options and relative modularity of VPNs, planners need to be clear about what services are required and where each function will be performed. Future VPN research directions include investigation of Multiprotocol Label Switching (MPLS) which combines the use of network-layer routing/per packet switching with linklayer circuits/per-flow switching. MPLS support for VPNs is still in the state of active development and susequent standardization within the IETF.4

9. References [1] S. Chokhani, “Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework,” RFC 2527, 1999. [2] H. Berkowitz, “Requirements Taxonomy for Virtual Private Networks,” IETF draft: draft-berkowitz-vpn-tax-01.txt, Oct. 1999. [3] Cisco IOS Firewall Feature Set, 1992-1999. [4] Cisco IOS Network Security Macmillan Technical, 1998. [5] N. Duffield et. al., “A Flexible Model for Resource Management in Virtual Private Networks,” SIGCOMM’99, ACM Comp. Comm. Rev., Vol. 29 No 4, pp. 95-108. [6] S. Hanks, “Generic Routing Encapsulation over IPv4 Networks”, RFC 1702, 1994. [7] R. Love, “Virtual Private Networks: Secure Access for E-Business,” IEEE Internet Computing, July/August 2000. [8] Lucent. Static vs. Dynamic Filtering, www.ascend.com.au [9] C. Scott et. al., Virtual Private Networks 2nd ed., O’Reilly, 1999. 4

Here are pointers to three works in progress: (1) K. Muthukrishnan and A. Malis, “Core MPLS IP VPN Architecture,” IETF draft: draft-muthukrishnanmpls-corevpn-arch-02.txt, May 2000; (2) E. Rosen and Y. Rekhter, “BGP/MPLS VPNs, “IETF Internet draft: draft-rosen-vpn-mpls-01.txt, March 1999; and (3) J. Heinanen and E. Rosen, “VPN Support for MPLS,” IETF Internet draft: draft-heinanen-mpls-vpn-01.txt, March 1998.