IPSec VPN Design [Electronic resources] نسخه متنی

IPSec VPN Architectural Considerations for VoIP

You saw in Chapter 5, "IPSec VPN Architectures," various topological options for the deployment of IPSec VPNs. The previous section defined various implications of running voice applications in IPSec. The large-scale introduction of voice applications on a network has serious ramifications for the viability of designing, building, and managing IPSec VPNs. In this section, we will explore the impact of accommodating VoIP in the various VPN architectures.

Decoupled VoIP and Data Architectures

First, you should consider whether VoIP must be encrypted at all. From a routing perspective, it is much easier to treat all VoIP traffic as high priority data traffic over a single routing topology. The converged voice and data topology must simply handle the traffic classes appropriately through the queuing mechanisms discussed previously. Many organizations are evolving their VoIP communication systems to use end-to-end bearer encryption based on Secure Real Time Protocol (SRTP). In this case, encryption of VoIP traffic with IPSec is redundant. Some organizations have chosen to exclude SRTP VoIP traffic from the IPSec topology. There are two common methods for achieving this architecture.

The first method uses IPSec proxy policies that exclude VoIP traffic. Recall that the IPSec tunneling methods essentially direct encrypted traffic to the peer gateway. Routing decisions in the backbone for data traffic will be based on the IPSec tunnel addresses, whereas routing decisions for VoIP traffic will be based on the bearer endpoint addresses. Essentially, there are two routing topologies and traffic matricesone for voice flows and the other for data. Figure 8-7 shows the disjointed VoIP and data topologies.

The second method uses an explicitly defined overlay topology using GRE tunnels. Essentially, a VoIP GRE overlay topology is built in which the GRE tunnel addresses are excluded from the IPSec policy. A separate data GRE topology is built in which the GRE tunnel addresses are included in the IPSec policy. Now we can use Policy Based Routing (PBR) in the VPN gateway to route the VoIP streams into the unencrypted GRE topology while routing the data streams into the encrypted GRE topology. The VoIP bearers and data streams from end users typically use the same source and destination IP address space; therefore, the PBR must vector the appropriate packets into the disjoint VoIP and data tunnel overlay topologies using protocol and port identifiers.

Note

The whole point of VoIP is to leverage voice and data services in a synergistic manner. Although it is possible to use a distinct VoIP endpoint address space, doing so typically defeats one of the primary motivations for using VoIP technologiesintegrated voice and data applications.

Figure 8-8 shows how the two GRE topologies are defined and where the PBR functions are applied.

Note

The IPSec proxy configured on the VPN gateways must be able to distinguish between the data GRE tunnel and the VoIP GRE tunnel. Because there are no source or destination ports and the protocol ID is always the same, the IPSec proxy must use a unique IP address on one of tunnel endpoints. Generally, it is easiest to configure two GRE tunnel endpoints on the hubone that is used for data tunnels and one that is used for VoIP tunnels. Doing so allows the IPSec proxy on both the hub and spoke to uniquely identify the data GRE tunnels.

The explicit VoIP exclusion techniques (for example, PBR or IPSec proxy) usually become unwieldy in large VPN topologies. It is also difficult to accommodate fault-tolerant architectures using the static configuration techniques. As a result, most customers elect to use a convergent topology for voice and data to simplify their network architecture, traffic engineering, and fault-tolerance models. Therefore, this chapter focuses on these convergent VoIP and data architectures.

VoIP over IPSec Remote Access

In the ideal scenario, designers are able to architect the network according to a known set of design constraints. Provided the service provider or backbone operator has adequately characterized the IP network (for example, it may be Multi-Service CPN certified), designing the VoIP topology and QoS control mechanisms is relatively straightforward. Unfortunately, the same cannot be said for remote access networks in which multiple providers are involved and QoS attributes are rarely honored, much less preserved. Clearly, the network between the two IPSec endpoints (the IPSec client and the Concentrator) must be characterized as best-effort and treated as such.

Nevertheless, you can mitigate certain problems by controlling the flow of traffic at the IPSec endpoints. One aspect where VoIP call characteristics can be improved is through traffic-shaping techniques. We must assume that the IP path between the two IPSec endpoints has no support for QoS. One critical piece of information is the maximum bandwidth available. For example, a remote access user may have a DSL circuit with a maximum of 640kbps downstream and 384kbps upstream. We can improve our packet loss performance by shaping our VoIP and data stream into the maximum bandwidth available such that we avoid loss. Naturally, you want the VoIP stream to have the highest chance of success. By shaping the combined stream to not exceed 640kbps downstream and 384kbps upstream and prioritizing the VoIP stream over the data stream (preferably prior to encryption), you preclude the low bandwidth remote access network link from indiscriminately discarding voice or data. Figure 8-9 demonstrates the optimal shaping, queuing, and scheduling of the VoIP and IPSec flow on a remote access link.

VoIP over IPSec-Protected GRE Architectures

Site-to-site architectures for an IPSec VPN commonly use GRE tunnels protected by IPSec. Applying QoS policies to a tunnel interface that is an abstract interface can be challenging, as it is possible that the encrypted packet flow may be switched out to a high-speed or low-speed link. Obviously, you can assign a queue structure to any of the VPN gateway's physical interfaces, allowing the queues to be defined relative to the physical bandwidth. The tunnel interface QoS structure has no adaptive knowledge of which interface is actually in use; therefore, a hierarchical queue structure is required with explicit bandwidth statements in order to use shaping or bandwidth percentage-based queue structures.

Of course, the bandwidth applied to the tunnel interface may not match the physical interface that the tunnel uses to reach the peer. The principle advantage of applying QoS to the tunnel interface is that the packet order for a set of streams to the same peer is defined, scheduled, and queued prior to encryption. Reordering packets on entry into the tunnel interface forces the VoIP traffic to precede the data traffic upon leaving the VPN gateway. Once the data is encrypted, intermediate nodes between the VPN gateways may reorder packets of the tunnel when congestion occurs; therefore, anti-replay drops may still be a factor. This is a principle disadvantage of IPSec over GRE. There is a single IPSec SA defined for the aggregate set of streams in the GRE tunnel. One effective way to mitigate the anti-replay drops is to set the bandwidth of the GRE tunnel's queue structure to the slowest link between the tunnel peers. Example 8-1 shows a configuration model in which the QoS mechanism uses a parent policy to shape the traffic according to the slowest link while prioritizing the VoIP ahead of the data traffic.

Example 8-1. Hierarchical Shaping of VoIP and Data Prior to Encryption

spoke-2-west# show configuration
...
policy-map vpn
class control
bandwidth percent 5
class mmoip
priority percent 30
class data
bandwidth percent 63
...
policy-map gre-qos
class shape-t1
shape average 1464000
service-policy vpn
...
class-map match-all shape-t1
match any
class-map match-all data
match ip precedence 0  1  2  3
class-map match-all control
match ip precedence 6  7
class-map match-all mmoip
match ip precedence 4  5
...
interface Tunnel1
ip address 9.0.0.2 255.255.255.252
ip pim sparse-mode
service-policy output gre-qos
tunnel source 9.1.1.134
tunnel destination 9.1.1.10
tunnel protection ipsec profile spoke-2-west
...
end

You see that we have two service policies: vpn and gre-qos. The gre-qos service policy is applied to the tunnel interface such that any traffic entering the tunnel conforms to the average bandwidth rate of 1.46Mbps (assuming that the constrained bandwidth available to this site is consistent with a T1). With the traffic shaped to fit inside a T1, we prioritize our VPN traffic such that MultiMedia over IP (mmoip) is scheduled first and set to not exceed 30% of the shaped capacity. We have also guaranteed control traffic, or routing protocols, 5% of the bandwidth with data traffic essentially obtaining the rest. Also, note that we have selected the precedence bits (a component of the DSCP) as the matching criteria. Next, you'll see the implications of QoS when applied to the IPSec architecture.

VoIP Hub-and-Spoke Architecture

Chapter 5, "IPSec VPN Architectures," the hub-and-spoke topology is one of the most widely deployed IPSec VPN architectures. In this topology, all spoke-to-spoke communication (including VoIP) transits via the hub. The introduction of a hub transit point to the VoIP bearer stream needs to be accounted for in the traffic engineering and voice delay budget. Having spoke-to-spoke VoIP traffic hair-pinning through the IPSec hub, wherein the hub has to decrypt the VoIP traffic it receives from the spoke and encrypt the traffic again to the spoke the traffic is destined to, may significantly impact the performance of the network. First, the packet size distribution will be radically altered through the IPSec VPN connections. The substantial increase in forwarding requirements for the increased percentage of small packets may consume an inordinate amount of packet processing resources on the IPSec VPN hub. Second, the underlying IP network queue schedulers must be altered to accommodate the traffic engineering of the transient IPSec-protected VoIP stream. Figure 8-10 shows the implications for these two fundamental changes in the network architecture.