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

QoS-Enabled IPSec VPNs

The growing availability of IP networks has fueled tremendous momentum towards convergence of voice, video, and data onto a single infrastructureall based on IP. Among the obstacles network engineers face when trying to combine voice, video, and data onto one network is that different types of traffic require different levels of service from the network. The answer to deploying these services over IP networks is to use the various IP QoS mechanisms to condition traffic streams based on the type of service that each requires. Although a complete description of IP QoS mechanisms is beyond the scope of this book, in this section you will be presented with an overview of IP QoS mechanisms and will focus on the specific challenges of deploying these mechanisms over IPSec.

Overview of IP QoS Mechanisms

IP QoS mechanisms can be classified into two broad categories:

Packet classification

Congestion management

Packet classification, or coloring of packets, is a means of classifying packets into traffic classes so that the IP network can offer differentiated services based on traffic classes. In an IP network, packets may be classified on a flow basis by the five IP protocol attributesthat is, the 5-tuple: source IP address, destination IP address, IP protocol field, source ports, and destination ports. Although an IP network could apply QoS on an individual flow basis, this mechanism is not very scalable as the number of flows can be very large. The generally accepted best practice is to categorize the packets into traffic classes based on their flow parameters and mark the IP precedence or Differentiated Services Code Point (DSCP) field of a packet based on its traffic class. Once the packets are classified as priority voice/video traffic, congestion management or avoidance mechanisms such as Class-Based Weighted Fair Queuing (CBWFQ), Low-Latency Queuing (LLQ), or Weighted Random Early Discard (WRED) can be applied to the packets. These mechanisms allow the network to treat priority applications with consistency, thereby fulfilling their network requirements.

Figure 8-1 shows the typical IP QoS process flow.

IPSec Implications for Classification

The classification of IP packets on the 5-tuple described previously is easily accomplished on unencrypted traffic, although IPSec presents a challenge to packet classification. As you saw in Chapter 2, "IPSec Overview," IPSec headers may mask the original IP packet header information such as protocol identifiers and source and destination port numbers. We know that the IPSec process will encapsulate the original IP header (tunnel mode) with a newIP header or add an IPSec header behind the original IP header (transport mode). In the process, the protocol identifiers and port numbers are replaced with IPSec protocols and ports. ESP uses the IP protocol ID of 50, and AH uses 51. The IKE protocol uses IP protocol ID 17 (that is, UDP) with port number 500. Finally, IPsec Network Address TranslationTransparency (NAT-T) also uses UDP encapsulation with port number 4500 as a means to provide IPsec establishment through NAT gateways. The only remaining QoS attributes available following encryption are the DSCP bits identified in the IKE, ESP, NAT-T, or AH IP header.

Note that the IPSec standard specifies the automatic preservation of the DSCP bits in the original IP packet. As such, the original IP header's DSCP must be present in the IPSec packet's IP header. Keeping that in mind, you will review the three most common encapsulation models including IPSec transport mode, IPSec tunnel mode, and IPSec protection of GRE, and explore the implications for packet classification.

QoS Applied to IPSec Transport Mode

You may recall from Chapter 2, "IPSec Overview," that IPSec transport mode is typically applied to traffic that originates or terminates on the router itself. Recall that in transport mode the source and destination address fields in the original IP header are intact, but the protocol identifiers from the original IP header are in the IPSec trailer and the protocol identifier in the original packet is replaced with that of IPSec (50 or 51). As such, access to the original protocol identifier and ports becomes inaccessible to the QoS classification mechanisms applied on the IPSec egress interface and any router between the IPSec endpoints. Because the original IP addresses are not encapsulated, they may continue to be used as classifiers for IP QoS. Likewise, the DSCP are preserved in the IP header. Figure 8-2 highlights the typical QoS attributes that are masked and those that remain after IPSec transport mode encapsulation.

QoS Applied to IPSec Tunnel Mode

In contrast to IPSec transport mode, you learned that with the IPSec tunnel mode, the original IP packet is encapsulated with a new IP header; therefore, all of the original QoS attributes in the IP header (that is, the IP addresses, protocols, and ports) are lost, with the exception of DSCP, which must be copied into the encapsulating IPSec header. None of these lost attributes can be used for classification by the router on the IPSec egress interface or any router between the IPSec endpoints. Figure 8-3 highlights the typical QoS attributes that are masked and those that remain after IPSec tunnel mode encapsulation. Note also the disposition of the protocol identifier (Proto ID) from the original packet to the encrypted packet.

IPSec Transport Mode - QoS Attribute Preservation of GRE Tunnels

With IPSec-protected GRE, the original IP packet is first encapsulated during the GRE process. Of course, similar to the IPSec tunnel mode, the entire original IP packet is encapsulated, hiding the original QoS attributes (addresses, protocols, and ports). The new GRE IP header should copy the DSCP field; however, the protocol will change to protocol ID 47 and the IP addresses will be specified by the GRE encapsulation process. Next, the GRE IP packet must pass through the IPSec encapsulation process defined previously. Clearly, the IPSec process will only be able to preserve the QoS attributes specified in the GRE IP header (that is, addresses and DSCP for transport mode, DSCP for tunnel mode, and GRE protocol ID if qos pre-classify is used). Figure 8-4 highlights the protocol attributes typically used for QoS, and shows those that are encrypted or hidden as well as those that remain accessible to QoS processing after IPSec transport mode encapsulation of GRE tunnels.

Note

Note that qos pre-classify may be applied to the tunnel interface as well. Doing so allows the original IP packet's attributes to be available for subsequent crypto and QoS processing. These attributes are only available to the processes on the encrypting gateway. Any QoS functions between the encrypting and decrypting gateways will not have access to this information;therefore, it's imperative that the DSCP be marked appropriately for consistent application of QoS tools.

Transitive QoS Applied to IPSec

In this scenario, the only persistent QoS attribute is the DSCP from the original IP header. Again, this emphasizes the importance of classifying and marking an unencrypted packet's DSCP prior to incurring any encapsulation (GRE or IPSec) as the pre-classification and marking dramatically simplifies the QoS models required to provide end-to-end QoS. Assuming the unencrypted traffic is properly marked, the same QoS classification and queuing mechanisms may be used in the sub-networks prior to encryption, those after encryption, and those after decryption. Figure 8-5 demonstrates the value of the transitive nature of the DSCP.

Internal Preservation of QoS Attributes

To reconcile the loss of information during the IPSec encapsulation process, Cisco has implemented a special QoS mechanism referred to as qos pre-classify (described previously). With this feature, the original IP packet's attributes (addresses, protocol, ports, DSCP) are copied to the IPSec-encapsulated packet as it moves to the egress queue. When classification methods are applied to the egress interface, the IP QoS mechanisms will use the copied original IP packet QoS attributes as opposed to the encapsulating IPSec header. This model allows the designer to build queue structures that may queue packets based on the original addresses, protocols, and ports. The copied information is simply discarded as the packet leaves the router. Figure 8-6 demonstrates how the gateway performing encryption may leverage additional attributes of the packet for classification.

Of course, any interim router processing the packet between the two IPSec endpoints will not have access to the same QoS attributes as the encrypting gateway. All the interim routers will still have access to the DSCP bits in the IPSec encapsulated packet which were copied from the original IP packet and preserved. Therefore, it is a best practice to set the DSCP bits as close to the original host as possible. Doing so allows a consistent packet classification end-to-end.

Table 8-1 highlights the parameters that are preserved by the encryption and encapsulation processes. Although some of the attributes used for QoS are available on the encrypting router, the only attribute that is consistently available between the encrypting and decrypting routers is the set of DSCP values.

IPSec Implications on QoS Policies

The introduction of IPSec encryption (or IPSec protection of GRE encapsulation) may significantly affect the queuing model used to provide quality of service. It is worthwhile to focus on the implications of IPSec on queue structures and bandwidth allocations. Of particular interest is the size of the packets as they go through the encryption or encapsulation processes.

IPSec Implications of Packet Size Distribution on Queue Structures

Chapter 2, "IPSec Overview," described the impact of IPSec encapsulation on the MTU. It is evident that the process of encapsulating and fragmenting packets may dramatically change the probability distribution for various packet sizes. The observed packet size distribution used on an unencrypted FR interface may be quite different on an IPSec-protected interface; therefore, careful consideration must be given to buffer allocations assigned to class queues as well as system buffers. As an example, assume a simplified data traffic flow with a packet size distribution ratio of 4-7-4 for 40-, 512-, and 1500-byte packets, respectively. If we pass this packet stream into an IPSec-protected GRE tunnel where the GRE MTU is specified as 1400 bytes, the packet size distribution will change due to packet fragmentation to a ratio of 4-7-4-4 with packet sizes of 40, 512, 100, and 1400 bytes, respectively. Note that the frequency of small packets (those less than 104 bytes applicable to the system's small buffers) is doubled. Likewise, the class queue structure and buffers allocated to each class may need to be adapted from the default 64 packets to handle the modified packet distribution.

IPSec Implications of Packet Size on Queue Bandwidth Assignments

Another interesting challenge with IPSec encapsulation is the assignment of bandwidth parameters associated with QoS policies applied to interfaces. Obviously, the encapsulation overhead of IPSec and GRE will increase the number of bits per second that must pass through an interface. A common error made by designers is to assess gateway QoS requirements based on the application's bandwidth (that is, VoIP bearer bit rates), but fail to consider the additional bandwidth that encryption and encapsulation add to the flows at the encrypting router. The issue is particularly relevant on low-speed interfaces and traffic flows with a high concentration of small packets.

The appropriate solution to this problem is to set the QoS bandwidth allocation to a value higher than the actual application bandwidth requirements such that the post-encrypted flow approaches the actual bandwidth assigned to the application's queue. Again, the traffic application's expected packet size distribution profile is necessary to estimate the percentage of overhead required on a particular interface. A low-speed interface will be much more susceptible to congestion; hence, the ramifications of IPSec on QoS are much more severe on low-speed interfaces. Likewise, traffic flows dominated by VoIP will incur a large percentage of overhead due to the small packet size of VoIP frames. Now, you'll explore some of the intricacies of running VoIP flows through IPSec VPN connections.