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

VoIP Application Requirements for IPSec VPN Networks

It is becoming increasingly important for enterprises that build IPSec VPNs to deliver voice services over the VPN. Voice over IP in itself brings unique challenges; adding IPSec complicates this further. The most critical network characteristics that need to be considered for a successful voice over IP deployment are delay, jitter, availability, and packet loss.

Delay Implications

The generally accepted International Telecommunication Union (ITU) value for one-way delay is considered to be 150msec. In a circuit-switched paradigm, this requirement is easily achieved except for in the most extreme cases such as satellite relays. A packet-switched network may push the delay for a packet flow well over 150msec. In fact, it's not uncommon for a congested IP network to experience delays exceeding 1 or 2 seconds. End-to-end packet delay can be attributed to delays due to switching, queuing, serialization, or propagation.

Switching is the function of receiving an IP packet and making a decision regarding which output interface to switch the packet to. In most modern IP routers, the switching delay for IP packets is a few micro or nanoseconds, and therefore almost a non-issue. Note, however, that because IPSec does increase switching delay, it may be important to consider when dealing with applications like voiceespecially when IPSec encryption and decryption is done in software. For applications such as voice that have a stringent budget on end-to-end delay, the use of hardware-assisted encryption and decryption is recommended. Hardware-assisted encryption and decryption will minimize encryption delays mitigating the impact to the end-to-end voice delay budget. Nevertheless, the hardware-accelerated encryption/decryption processes do add several milliseconds to the delay, which must be considered in the delay budget.

Once the switching decision has been made, the packet is queued for transmission out a physical link. At this point, it is possible to have queuing delay. On an interface that is not very busy or not congested, queuing delay may not be very significant and the default FIFO queuing scheme will suffice. Queuing delay becomes very significant when traffic bursts egress the outbound interface, making the interface congested and thereby causing outbound queues to build up. A priority queuing mechanism such as Low-Latency Queuing (LLQ) should be applied to voice traffic to protect from queuing delays. Typically, voice packets are classified into the priority queue based on DSCP bits in the IP header. As mentioned previously, the original IP packet's DSCP bits are copied into the IPSec IP header; therefore, classification and priority queuing of voice traffic can be performed at the encrypting end of the IPSec tunnel endpoint without a problem. Of course, implementing LLQ of voice traffic end-to-end along each hop is recommended.

All the queuing mechanisms are applied to packets queued on the outbound interface. At the head end of the IPSec tunnel (where packets that match the IPSec policy are encrypted), the encryption engine may only have a first-in, first-out (FIFO) queue. The encryption engine with a FIFO queue will not distinguish between the data and voice packets. It is possible for a low priority data flow to congest the encryption engine. Although queue management on the outbound interface uses LLQ to handle voice, it is negated by the FIFO queue in the encryption engine. Cisco IOS version 12.2(15)T introduced a new feature that adds LLQ at the crypto engine. There is no configuration required to enable this feature; it is enabled by the QoS service on the output interface. This feature is available only with the hardware encryption engine and not with software encryptionanother reason to use hardware-assisted encryption for voice over IPSec. Note that it is still possible to congest the LLQ on the encryption engine. Certain applications (for example, multicast and routing updates in GRE tunnels) will present a flood of replicated traffic to the crypto engine. If this traffic is high-priority and queued on the crypto engines LLQ, then congestion may occur, causing loss.

Once the packet is queued for transmission on the output link, serialization delay comes into the picture. All circuits have a common characteristic known as serialization delay, which represents the time it takes some unit of data to be serialized onto the circuit. The delay is directly related to the length of the packet, the bandwidth of the circuit, and the framing technology employed. For instance, the serialization delay for sending a 1500-byte HDLC-encapsulated packet on a 45Mbps circuit will be:

Serialization delay at low-speed links can contribute significantly to the end-to-end voice delay budget. Voice-over-IP packets are much smaller in size than a 1500-byte data packet. For example, on a 56Kbps leased line link where voice and data traffic coexist, a voice packet may be enqueued to transmit just when a 1500-byte data packet starts transmission (that is, serialization) over the link. Now, there's a problem. The delay-sensitive voice packet will have to wait 214 msec before being transmitted due to the serialization delay for the 1500-byte packet. Fragmenting these large data packets into smaller ones and interleaving voice packets among the fragments reduces the delay and jitter. The Cisco IOS feature Link Fragmentation and Interleaving (LFI) can be configured to do this fragmentation.

Note

LFI is required only on slow-speed interfaces. The recommendation is to use this feature on interfaces whose bandwidth is less than 768kbps.

Alternatively, you may apply a much smaller MTU on GRE tunnel interfaces such that you induce host fragmentation where possible and fragment IP packets prior to encryption, accordingly.

The last delay attribute is called propagation delay. This is simply the time between the completion of data transmission at the application sender and data reception at the other end by the application receiver. This attribute is going to be dictated by the length of the medium and speed of signal propagation in that medium.

Jitter Implications

Jitter is the variance in the arrival interval of a stream of packets. Clearly, a VoIP encoder will generate a constant stream of voice-encoded packets with a defined constant interval between successive packets. Once these packets traverse the packet-switched network, the delays mentioned previously create variability in the arrival interval of the VoIP packets. To accommodate the jitter, a jitter buffer is used to collect the VoIP packets with a minimally induced delay. This allows the voice decoder to continuously play out the voice stream with no drops.

Typically, the jitter buffer will be adaptive with the induced delay starting at a default value such as 20msec. The jitter buffer will attempt to reduce the induced delay if the network demonstrates consistent packet inter-arrival times or increase the induced delay to perhaps 50msec if the network experiences severe congestion and jitter. Scheduling voice packets into the priority queues through the network minimizes the jitter experienced by VoIP packets as they traverse the network. The IPSec encryption and decryption process may induce a negligible amount of jitter; therefore, designers rely on the continuity of the DSCP before, during, and after the encryption/decryption processes at the two endpoints in order to minimize the jitter induced by the network. Typically, a well-managed backbone network will demonstrate no more than 2msec of jitter and may approach jitter values as low as 100usec.

Caution

Platforms that use software encryption and decryption may induce significant jitter due the nonlinear encryption processing requirements for large versus small packets. Hardware-accelerated encryption and decryption should be considered mandatory for VoIP services.

Loss Implications

An extensive amount of research on VoIP's sensitivity to loss has demonstrated that packet loss exceeding one percent of the VoIP data stream will be apparent to end users. It is apparent that the network must preserve the VoIP stream, especially in congested points in the network such as access links. The use of priority queuing on VoIP-encrypted packets allows the VoIP packets to pass through the congested links with minimal loss. Generally, voice and data packets will be passing between two crypto gateways using the same security association. The voice packets are typically identified by a DSCP setting of Explicit Forwarding (EF) while data packets will use one of the Assured Forwarding (AF) DSCP settings. The queue systems that come into play after encryption between the crypto gateways will use the DSCP values to prioritize the voice packets ahead of the data packets.

The ramification of scheduling VoIP packets ahead of other data packets in the same IPSec SA is that the sequence of packets arriving at the decryption device is out of order. By default, IPSec will use a 64-packet anti-replay window to detect packets that are potentially replay attacks. We'll assume the crypto gateway has received crypto packet with sequence number N. The gateway will now accept any valid crypto packet with a sequence number between N-64 and N. Packets that arrive with a sequence number less than the N-64 violate the anti-replay window. Such packets are assumed to be replay attacks by IPSec and are dropped. With a substantial volume of VoIP-encrypted traffic passing through a congested interface, we mitigate packet delay of the voice streams while inducing latency or loss in the other data streams that use the same IPSec SA. If the encrypted data packets of an SA are sufficiently delayed relative to the voice packets, the data packets may violate the anti-replay window while the voice packets are accepted.

Mitigating Anti-replay Loss in Combined Voice/Data Flows

There are two means of mitigating the loss to data streams in a combined voice/data encrypted flow. First, the link capacity may be increased, or more bandwidth may be made available to the data packets in the combined voice/data flow. The additional schedule time available to the data flow decreases the probability of a data packet being delayed beyond the 64-packet window. The second alternative is to increase the anti-replay window. Preliminary testing of this feature indicates that an anti-replay window of 1000 packets is sufficient to mitigate frame loss due to anti-replay violations.

Mitigating Anti-replay Loss in Separate Voice/Data Flows

An alternative to the combined voice/data flow is to create two IPSec proxy policies that specifically put voice into one IPSec SA and place data in a second IPSec SA. The intermediate queuing systems that delay the data packets and forward the voice packets do not change the order of voice or data packets with respect to their individual IPSec SA anti-replay sequence. This approach is acceptable for native IPSec encryption processes; however, this is less feasible inGRE-tunneled scenarios. The native IPSec proxy may select unique IPSec SAs by referring to the QoS attributes of the original packet. The use of IPSec-protected GRE performs GRE encapsulation prior to presenting the encapsulated data to the IPSec encryption processes. The GRE packet has no criteria available to distinguish between the VoIP and data because the original IP addresses, protocol, and ports are hidden. The IPSec proxy cannot use the DSCP values as criteria for creating unique IPSec SAs. The GRE encapsulation process typically uses the same IP source address, destination address, and protocol ID for all encrypted flows between the gateways. The result is the establishment of a single IPSec SA.

The only way to avoid this is to use the parallel GRE tunnels with unique source and destination tunnel endpoints that correlate with unique IPSec proxy statements. The unique tunnel source or destination IP addresses allow IPSec to establish distinct voice and data IPSec SAs for VoIP and data flows, respectively.

Engineering Best Practices for Voice and IPSec

Most network architects find that combining voice and data flows into a single IPSec SA is preferred over splitting voice and data into separate IPSec SAs. The combined voice and data flow saves on the number of IPSec SAs deployed, which improves network scalability. In addition, the routing of voice and data into separate IPSec-protected GRE SA streams becomes quite complicated. Likewise, maintaining distinct IPSec proxies for voice and data streams becomes quite an onerous provisioning task. In general, it's best to traffic engineer the links such that prioritized VoIP traffic will not exhaust the queuing resources or eliminate scheduling time for the data queues.

By using VoIP traffic engineering best practices (that is, by limiting voice streams to less than 33% of the link bandwidth) and ensuring that the combined voice/data flow does not exceed 70% of link utilization, the combined flow of VoIP and data rarely experiences anti-replay loss. Should the operator continue to experience loss due to anti-replay violations, the recommendation is to increase the anti-replay window. A typical voice stream will generate roughly 50 packets per second (that is, 20msec voice-sampling interval). Increasing the anti-replay window from 64 packets to 1000 packets has minimal impact on the security risk of the system. The anti-replay time interval for a single voice flow increases from 1.28 seconds (64 packets divided by 50 packets per second) to 20 seconds (1000 packets divided by 50 packets per second), assuming no other traffic is passing through the IPSec SA which is rarely the case. The IPSec SA is usually carrying a variety of traffic types at a packet-forwarding rate that makes the anti-replay interval short enough to mitigate all but the most determined attacker.