Chapter 9: IPsec and SSL VPN Design (Part04)

Virtual Tunnel Interfaces Overview

Another mechanism for supporting VPNs is with IPsec virtual tunnel interfaces (VTI). IPsec VTIs provide a routable interface type for terminating IPsec tunnels and an easy way to define protection between sites to form an overlay network. A VTI supports native IPsec tunneling, and allows interface commands to be applied directly to the IPsec tunnels. The IPsec tunnel endpoint is associated with a virtual interface. Because there is a routable interface at the tunnel endpoint, many common interface capabilities can be applied to the IPsec tunnel.

The IPsec VTI supports QoS, multicast, and other routing functions that previously required GRE. VTIs allow for the flexibility of sending and receiving both IP unicast and multicast encrypted traffic on any physical interface, such as in the case of multiple paths. Traffic is encrypted or decrypted when it is forwarded from or to the tunnel interface and is managed by the IP routing table. Dynamic or static IP routing can be used to route the traffic to the virtual interface.

VTI simplifies VPN configuration and design. Customers can use the Cisco IOS virtual template to clone on demand new virtual access interfaces for IPsec. Using IP routing to forward the traffic to the tunnel interface simplifies the IPsec VPN configuration compared to the more complex process of using ACLs with the crypto map in native IPsec configurations. GRE or Layer 2 Tunneling Protocol (L2TP) tunnels are not needed for encapsulation. Dynamic VTIs (DVTIs) function like any other real interface, so QoS, firewall, and other security services can be applied as soon as the tunnel is active. In addition, existing management applications now can monitor separate interfaces for different sites.

The use of VTIs improves network scaling. IPsec VTIs use single SAs per site, which cover different types of traffic and enable improved scaling as compared to GRE. A major benefit associated with IPsec VTIs is that the configuration does not require a static mapping of IPsec sessions to a physical interface.

Both static VTIs (SVTI) and DVTIs are available. SVTI configurations can be used for site-to-site connectivity in which a tunnel provides always-on access between two sites. The advantage of using SVTIs as opposed to crypto map configurations is that users can enable dynamic routing protocols on the tunnel interface without the extra 4 bytes that are required for GRE headers, thus reducing the bandwidth for sending encrypted data. DVTIs can provide highly secure and scalable connectivity for remote-access VPNs. The DVTI technology replaces dynamic crypto maps and the dynamic hub-and-spoke method for establishing tunnels. DVTIs can be used for both the server and remote configuration.

Note

You can use Cisco SDM to configure Cisco Easy VPN Server and Cisco Easy VPN Remote with IPsec DVTIs.

VTIs support interoperability with standards-based IPsec installations of other vendors.

Both Cisco Easy VPN Server and Remote support DVTIs. The tunnels provide an on-demand separate virtual access interface for each Cisco Easy VPN connection. The Cisco Easy VPN with DVTI configuration provides a routable interface to selectively send traffic to different destinations, such as a Cisco Easy VPN concentrator, a different site-to-site peer, or the Internet. The IPsec DVTI configuration does not require a static mapping of IPsec sessions to a physical interface. This allows for the flexibility of sending and receiving encrypted traffic on any physical interface, such as in the case of multiple paths. Traffic is encrypted when it is forwarded from or to the tunnel interface.

Group Encrypted Transport VPN

The Cisco Group Encrypted Transport VPN (GET VPN) feature is a Cisco IOS Software solution that provides a tunnel-less technology to provide end-to-end security for voice, video, and data in a native mode for a fully meshed network. GET VPN can secure IP multicast group traffic or unicast traffic over a private WAN. It uses the ability of the core network to route and replicate the packets between various sites within the enterprise. GET VPN preserves the original source and destination addresses in the encryption header for optimal routing; hence, it is largely suited for an enterprise running a Multiprotocol Label Switching (MPLS) or IP VPN networks.

GET VPN is enabled in customer-edge routers without using tunnels. GET VPN uses Group Domain of Interpretation (GDOI) as the keying protocol with IPsec for efficiently encrypting and decrypting the data packets.

GET VPN enables the router to apply encryption to nontunneled (that is, “native”) IP multicast and unicast packets and eliminates the requirement to configure tunnels to protect multicast and unicast traffic.

GET VPN is supported on Cisco IOS Software Release 12.4(11)T and on Cisco VPN acceleration modules:

• Cisco AIM-VPN/SSL module for Cisco ISRs

• Cisco VPN Acceleration Module 2+ (VAM2+) for Cisco 7200 series routers and Cisco 7301 routers

GET VPN Topology

GET VPN uses a group management model in which the GDOI protocol operates between a group member and a group controller or key server. The GET VPN architectural components are illustrated in Figure 9-13.

Figure 9-13: GET VPN Topology

The key server, shown in Figure 9-13, establishes SAs among authorized group members. GDOI is protected by a Phase 1 Internet Security Association and Key Management Protocol (ISAKMP) SA.

Three traffic flows are necessary for group members to participate in a group:

• The group member registers with the key server to get the IPsec SA or SAs that are necessary to communicate with the group. The group member provides the group ID to the key server to get the respective policy and keys for this group. The key server authenticates and authorizes the group members and downloads the IPsec policy and keys that are necessary for them to encrypt and decrypt IP multicast packets. The key server is responsible for maintaining the policy and creating and maintaining the keys for the group.

• Group members exchange IP multicast packets that are encrypted using IPsec.

• Because the key server is also responsible for rekeying the group before existing keys expire, the key server pushes a rekey message to the group members. The rekey message contains new IPsec policy and keys to use when old IPsec SAs expire. Rekey messages are sent in advance of the SA expiration time to ensure that valid group keys are always available.

Managing and Scaling VPNs

The Cisco security management products and internal processes can be used for scalable VPN administration and enforcement. Scaling VPNs involves several considerations, including crypto engine performance for real traffic and routing characteristics and metrics.

Recommendations for Managing VPNs

The Cisco Security Management Suite is a framework of products and technologies designed for scalable policy administration and enforcement for the Cisco Self-Defending Network. This integrated solution can simplify and automate the tasks associated with security management operations, including configuration, monitoring, analysis, and response. Several components of this suite enable the management of VPNs:

• SDM: Cisco SDM is a web-based device management tool for Cisco routers that can improve the productivity of network managers; simplify router deployments for integrated services such as dynamic routing, WAN access, wireless LANs (WLAN), firewalls, VPNs, SSL VPNs, IPSs, and QoS; and help troubleshoot complex network and VPN connectivity issues. Cisco SDM is a single device element manager that can support a wide range of Cisco IOS Software releases and is available free of charge on Cisco router models from Cisco 830 series routers to Cisco 7301 routers.

• ASDM: Cisco ASDM provides security management and monitoring services for the Cisco ASA 5500 series Adaptive Security Appliances, Cisco PIX 500 series security appliances (running Cisco PIX Security Appliance Software Version 7.0 or later), and the Cisco Catalyst 6500 series FWSM Version 3.1 or later through an intuitive, easy-to-use web-based management interface. Cisco ASDM is an element manager that accelerates security appliance deployment with intelligent wizards, robust administration tools, and versatile monitoring services.

  Note

  The replacement for Cisco SDM is Cisco Configuration Professional (CCP). For more information about this product, refer to http://www.cisco.com/go/ciscocp.

• Cisco PIX Device Manager (PDM): Cisco PDM security management and monitoring services for Cisco PIX security appliances (running Cisco PIX Firewall Software Version 6.3 and earlier) and the Catalyst 6500 series FWSM. PDM is an element manager that features an intuitive GUI with integrated online help and intelligent wizards to simplify setup and ongoing management. In addition, informative, real-time, and historical reports provide critical insight into usage trends, performance baselines, and security events. Administrative and device security is supported through the use of user passwords (with optional authentication via a RADIUS or TACACS server) and encrypted communications to local or remote devices.

  Note

  The replacement for Cisco PDM is Cisco ASDM. For more information about this product, refer to http://www.cisco.com/go/ASDM.

• CiscoView Device Manager: The CiscoView Device Manager for the Catalyst 6500 series switch is a device management software application that resides on a switch and manages several Layer 2 and Layer 3 features for a single chassis. A task-based tool, CiscoView Device Manager eases the initial setup and deployment of end-to-end services across modules by offering configuration templates based on recommended best practices. It further enhances the user friendliness of the Catalyst 6500 series through graphical representation of VLANs, and by providing a single launch point for multiple module managers, including the VPN service module, the SSL service module, and the WebVPN service module.

• Cisco Security Manager: Cisco Security Manager is a powerful but easy-to-use solution for configuring firewall, VPN, and IPS policies on multiple Cisco security appliances, firewalls, routers, and switch modules. Using a GUI, Cisco Security Manager enables you to easily configure security policies per device, per device group, or globally.

• Cisco Security Monitoring, Analysis, and Response System (MARS): Cisco Security MARS is an appliance-based solution that enables network and security administrators to monitor, identify, isolate, and counter security threats. Cisco Security MARS obtains network intelligence by understanding the topology and device configurations from multiple routers, switches, NetFlow, IPS, firewalls, and other network devices and by profiling network traffic. The integrated network discovery in the system builds a topology map containing device configuration and current security policies that enables Cisco Security MARS to model packet flows through the network. Because the appliance does not operate inline and makes minimal use of existing software agents, there is minimal impact on network or system performance.

Recommendations for Managing VPNs

There are several recommended practices for managing VPNs:

• Use dedicated management interfaces if possible for out-of-band (OOB) management. If this is not possible, use a VPN for secure management and restrict access over the tunnel to management protocols only.

• Take precautions when managing a VPN device across the Internet. You should use strong authentication, integrity, and encryption practices. You should use a different username for configuration management and for troubleshooting. If you cannot use IPsec to connect to remote devices, use Secure Shell (SSH) or SSL for access.

• Use static public IP addresses at remote sites and static crypto maps at the headend to manage remote devices through a VPN tunnel. Be aware that some services such as TFTP do not always use the public IP address as the source address.

• Use the available IPsec information. IPsec information can be accessed minimally through syslog information or with the IPsec Message Information Base (MIB) via Simple Network Management Protocol (SNMP).

Considerations for Scaling VPNs

Scaling VPNs depends on many factors, but the primary issue is the offered load, in number of packets per second, from the branch routers. The rate in packets per second matters more than throughput bandwidth for the connection speeds being terminated or aggregated. In general, routers and crypto engines have upper boundaries for processing a given number of packets per second. Each time a crypto engine encrypts or decrypts a packet, it performs mathematical computations on the IP packet payload using the crypto key for the tunnel. The crypto engine performance measured in packets per second is the key for sizing the headend.

The marketing numbers for crypto performance rate performance in megabits per second, with 100 percent CPU usage, and using even maximum transmission unit (MTU)-size (approximately 1400-byte) packets to achieve the best results. This is an unrealistic traffic pattern. Internet mix (IMIX) traffic contains a mixture of frame sizes in a ratio to each other that approximates the overall makeup of frame sizes observed in real Internet traffic. Using IMIX traffic provides a better simulation of real network traffic. Converged traffic with a mix of 30 percent voice traffic at a maximum of 80 percent CPU utilization is the most realistic simulation of real network traffic for enterprise networks. Figure 9-14 compares the relative performance of three types of traffic on a router.

Figure 9-14: Packets per Second Versus Megabits per Second

Packets per second are a more critical metric than the number of tunnels, although the number of tunnels impacts the routing processes on the CPU. The number of tunnels also impacts crypto processing; if more than one IPsec tunnel is terminated on a router, the router has multiple crypto keys. When packets are to be sent or received to a different tunnel than the last packet sent or received, the crypto engine must swap keys. This key swapping can degrade the performance of a crypto engine, depending on its architecture, and increase the router CPU utilization.

Determining Packets per Second

The number of packets per second per connection is determined by user applications on the network. High megabit-per-second throughput in the network typically corresponds to a large byte size per packet. The presence of VoIP in network decreases the average packet size and increases the number of packets per second.

To correctly simulate network behavior, test tools must emulate real application behavior. Using packet-blasting tools for testing is a poor indicator of real-world performance.

Enterprise WAN Categories

Characterizing enterprise WANs into categories, as shown in Table 9-4, helps estimate the type of traffic to expect from the remote branches when scaling the VPN.

Table 9-4: Enterprise WAN Categories
Open table as spreadsheet

	Point of Sale	Teleworker or Teleagent	Integrated Services Branch
Number of Branches	Extra Large 1000–10,000	Large 1000–3000	Medium 500–1000
VoIP Support?	No	Yes, Usually One Call	Yes, 33% Bandwidth
IP Multicast?	Generally Not	Nice to Have	Yes
Availability?	Required—Asynchronous DialBackup	Too Costly—Dial Bandwidth Insufficient for VoIP	Multiple WAN Links
Physical Interface?	Broadband or POTS	Broadband	Leased Line

Table 9-4 shows how enterprise WANs can be categorized into three groups:

• Point-of-sale WANs: These WANs typically support a high number of retail branches for credit card and point-of-sale applications. The number of branches here may be 2000 or more. They have low data volume and do not support VoIP or IP multicast. The WANs need availability that the routing protocol provides. The physical interface for the remote sites is typically broadband or dialup plain old telephony service (POTS).

• Teleworker or teleagent WANs: These WANs typically support a single user with an IP phone at the remote end. In the Cisco Enterprise Architecture, this is the “Branch of One” or “Teleworker” design. There can be large numbers of remote sites to support. Support for IP multicast is nice to have but might not be present. Backup availability is typically not provided because dial backup bandwidth is insufficient for the VoIP application. The remote sites typically connect using broadband.

• Integrated services branch WAN: These WANs typically connect remote enterprise branches to the central site. They also have high or bursty data volume and a relatively high number of branches, from 500 to 1000. They are likely to support converged applications, including voice, video, and IP multicast. VoIP traffic is typically 30 percent of the bandwidth. Backup availability is provided with multiple WAN links. The physical interface is typically a leased line or high-speed DSL.

Traffic Profiles per Branch Router

The major factor in headend VPN scaling is the PPS load of the hub for switching packets. Packet switching is impacted by the size of the packets. Based on field testing, the Cisco Enterprise Systems Engineering group has developed the following traffic profiles for representing real enterprise branch routers in the lab. Table 9-5 shows how the average packet size is influenced by the applications in use in the traffic profile.

Table 9-5: Traffic Profiles per Branch Router
Open table as spreadsheet

Point of Sale	Teleworker or Teleagent	Integrated Services Branch Enterprise Mix Voice and Video-Enabled VPN
TCP, 18 HTTP Get, 300 Bytes Up, 1000 Bytes Down 2 FTP (1 Up, 1 Down, and 120K File Size)	UDP, 1 G.729 Voice Call (100 p/s), 1 DNS, 1 Post Office Protocol 3, 1 Call Setup (CS3), 1 TN3270 (Best Effort), 1 TN3270 (AF21), 1 HTTP (Best Effort), 1 HTTP (AF21), 1 FTP (1 Up 240,000 File)	UDP, 33% Bandwidth for G.729 VoIP (100 p/s per Call), 9 Calls per T1, 9 DNS, 4 POP3, 6 TN3270 (Best Effort), 6 TN3270 (AF21), 3 HTTP (Best Effort), 3 HTTP (AF21), 4 FTP (2 Up, 2 Down, 768,000 File)

• Does traffic mix include VoIP, video, or IP multicast? What VoIP codec is in use (G.711 at 4 Kb/s versus G.729 at 8 Kb/s)?

• Do the devices support changing interface MTU? Do devices use path MTU discovery? Is the router configured to adjust TCP maximum segment size (MSS)?

• What applications are in use? Is application optimization, such as HTTP pipelining, in place?

• Scaling considerations at the headend are also impacted by the number of neighbors per hub, which impacts path selection overhead.

Example: Enterprise Mix Packet Size

Figure 9-15 shows the average packet sizes for representative downstream and upstream traffic captured with NetFlow. The key point to notice is that the average packet size with VoIP traffic in the mix is significantly smaller than the 1400-byte packets used to describe marketing performance.

Figure 9-15: Example: Enterprise Mix Packet Size

Note

Because average packet size will vary depending on the applications used, you should measure average packet size in your own environment.

Estimated PPS Based on Branch Profile

To accurately size the headend device, you need to measure the average and busy hour PPS rate of the branch routers.

The Enterprise Systems Engineering group has the following rough packets per second estimates shown in Figure 9-16 that can be starting point for VPN scaling:

• A point-of-sale branch on a low speed link that supports only data may have only an average of 50 p/s of traffic.

  
  Figure 9-16: Estimated PPS Based on Branch Profile

• A teleworker on a higher speed link will have higher traffic requirements. The teleworker may generate 125 to 800 p/s depending on the link speed and network configuration.

• The integrated services branch may need to support multiple voice calls. If we use the general principle that 30 percent of the bandwidth is used for voice, then a T1 line could support nine voice calls of 100 or 50 p/s in both directions. The headend would need to support 900 p/s for VoIP traffic plus the data requirements of the remote site.

Determining the PPS Rate

If you are migrating an existing network, you can measure the average and busy hour PPS rate of the existing branch routers.

Measuring traffic rates at the remote branches at the busy hour will provide useful data because most network managers do not know the details of bandwidth use. Many network managers, when asked, will not have any details and may reply, “I have 500 branches and a 45-Mb/s link at the headend.” Network designers need to know details of bandwidth use, not just how the network is implemented.

The measurement can be as simple as using the show interfaces fastethernet number | include rate command. You can also use network management tools to query SNMP or NetFlow data.

Example: Packet and Application View from NetFlow Analyzer 5

Figure 9-17 shows a view from the AdventNet ManageEngine NetFlow Analyzer 5 of the packets per hour and types of packets for a teleworker that supported a conference call, web-based data backup, and some web surfing during the day.

Figure 9-17: Example: Packet and Application View from NetFlow Analyzer 5

Routing Protocol Considerations for IPsec VPNs

Both EIGRP and OSPF are appropriate enterprise routing protocols that can be supported on IPsec with GRE tunnels, DMVPNs, VTIs, and GET VPNs.

The distance vector characteristics of EIGRP are typically better for the hub-and-spoke VPN topology:

• EIGRP can summarize per interface. By summarizing to the core and to the spoke, the branch routers will have fewer routes in the routing table.

• EIGRP is a “quiet” protocol when it is configured with stubs. There is no need to flood the topology database with EIGRP.

• EIGRP stub eliminates queries to spokes. As a recommended practice, configure the branch routers as stubs. The stub routers receive the default route from the headend router and advertise back up the branch subnets.

There are some disadvantages to the link state characteristics of OSPF for hub-and-spoke IPsec VPNs:

• OSPF needs to synchronize router databases periodically.

• OSPF brings hierarchy decisions into the hub-and-spoke topology. The number of routers per area needs to be allocated. A recommended practice is to use a power of two for best summarization.

• OSPF stubs require the use of default routes. However, the default route in OSPF typically points to the Internet, not a tunnel.

With either protocol, increasing the number of neighbors increases the amount of process switching the hub routers need to support. Buffer tuning can help maintain network stability by minimizing the number of buffer misses and failures that may equate to losing or dropping neighbors.

EIGRP Metric Component Consideration

The EIGRP metric components can impact IPsec VPNs.

EIGRP calculates delay as the cumulative network delay. It adds the delay from all the hops to the source network. EIGRP delay is based on the input interface value of the receiving router.

EIGRP uses the minimum bandwidth for all the links to a network. The default bandwidth value for a tunnel is 9000. EIGRP updates are throttled to 50 percent of bandwidth of the interface. You should consider matching tunnel bandwidth to physical link value if you send more than the default route and a summary route across a link, because the EIGRP process can be throttled by the 9000 default bandwidth value of the tunnel.

Summary

VPNs enable the secure use of cost-effective, high-speed links. VPNs also encrypt and authenticate traffic traversing the WAN to deliver true network security in an unsecure, networked world. This chapter examined the following subjects:

• Remote-access VPNs permit secure, encrypted connections between mobile or remote users and their corporate networks using IPsec and SSL technologies.

• Site-to-site VPNs are an alternative WAN infrastructure used to connect branch offices, home offices, and business partners to all or portions of an enterprise network using service provider networks.

• Several types of technologies can support IPsec VPNs, including Cisco Easy VPN, GRE over IPsec, DMVPN, VTI, and GET VPN.

• Both products and internal processes are needed for managing VPNs. Scaling VPNs involves several considerations, including crypto engine performance for real traffic and routing characteristics.

v