QoS pre-classify was designed so that tunneled interfaces could classify packets on the output interface before data was encrypted and tunneled. Considering the growth of VPN popularity, the ability to classify traffic within a tunnel for QoS purposes is increasingly in demand. QoS pre-classify allows Cisco IOS QoS features and services to remain effective even on tunnel interfaces and when encryption is used. Therefore, service providers and customers can continue to provide appropriate service levels to voice, video, and mission-critical traffic while they use VPN for secure transport.
Virtual Private Networks (VPN)
Virtual private network (VPN) is a private connectivity path between two end points, built on a public or shared infrastructure. Traditional ATM and Frame Relay circuits are referred to as Layer 2 VPNs, whereas IPsec tunnels over the Internet are called Layer 3 VPNs. A Layer 3 VPN can use tunneling, encryption, or both. The three main functions that VPNs can provide are as follows:
■ Confidentiality—This is usually accomplished by encryption, using methods such as DES or 3DES. The intention is that eavesdroppers should not be able to decrypt/decipher and read the encrypted data (within a reasonable period).
■ Authentication—This provides proof of origin to the receiver. Through authentication, origin of information is certified and guaranteed by the receiver. Certificates are often exchanged to facilitate the authentication process.
■ Data integrity—The receiver of packets and data is often interested in making sure that the data has not been altered or corrupted during transit. A data integrity check using hashing algorithms such as SHA and MD5 helps do just that.
You can implement confidentiality using encryption at different layers of the OSI model: at the application layer, transport layer, Internet layer, or network interface (data link) layer. Secure Shell (SSH) and Secure Multipurpose Internet Mail Extensions (S/MIME) are examples of protocols that provide encryption or authentication services to applications. Secure Socket Layer (SSL) can provide authenticity, privacy, and integrity to TCP-based applications. When these services are offered at the application or transport layer, they only work for one or a few concurrent applications; therefore, they are not considered application-independent and flexible. On the other hand, security services at the data link layer are nonscalable and expensive because they must be configured on a link/circuit-by-link/circuit basis. As a result, providing security services at Layer 3 (Internet layer), which means providing protection for as many applications as desired without having to do multiple configurations, has become the most popular.
The end points of a VPN are either end systems or networks; based on that, VPNs are divided into two categories:
■ Remote access VPNs
■ Site-to-site VPNs
The first category of VPN, remote access VPN, is either client-initiated or network access server (NAS)-initiated. When a person uses a VPN client application to establish a secure tunnel across an Internet service provider (ISP) (shared) network directly to an enterprise network, the VPN is referred to as client-initiated. In the network access server (NAS)-initiated case, however, the user dials in to the ISP, and the ISP NAS in turn establishes a secure tunnel to the enterprise private network.
The second category of VPN, site-to-site VPN, has two main types: intranet VPN and extranet VPN. The intranet VPN connects offices of an enterprise, such as the headquarters, branch offices, and remote offices, over a public network. The extranet VPN, on the other hand, provides private connectivity between offices of different companies and enterprises over a public infrastructure. These companies and enterprises, due to their business relationship, have connectivity requirements; suppliers, partners, or communities of interest often have such requirements.
QoS Pre-Classify Applications
Two commonly used tunneling protocols that are relevant to VPNs, discussed in the ONT course, are GRE and IPsec. Because these tunneling protocols, at the tunnel end points, encapsulate the original IP packet and use a new IP header, the original IP header is no longer available to the QoS mechanisms on the outbound (egress) interface. The good news is that the original ToS byte of an IP packet is copied to a ToS byte of the new IP header. Therefore, if the QoS mechanisms on the egress interface only consider the ToS byte (DSCP and ECN, or IP Precedence), it is unnecessary to perform any extra configurations, such as using the qos pre-classify command (on the router where the tunnel emanates). However, if other fields—such as the source or destination IP address, protocol number, or source port or destination port numbers—need to be processed, QoS preclassify configuration is necessary on the tunnel head router. When packets from different flows and applications are transported through a tunnel interface, they are encapsulated with the same new IP header with identical source and destination IP addresses (tunnel ends) and protocol numbers (tunnel protocol number). The only difference between those packets might be the ToS byte, which is directly copied from the ToS byte of the original IP packet header.
GRE can encapsulate different protocol packet types inside IP tunnels, creating a virtual point-to-point link to remote Cisco routers over an IP internetwork. GRE, however, does not provide data confidentiality using encryption. The main strength of GRE tunnel is that, in addition to transporting IP unicast packets, it can transport packets of IP routing protocols, multicast packets, and non-IP traffic.
Secure VPNs use IPsec because it can provide data confidentiality, data integrity, and data authentication between the tunnel end points/peers. Two mechanisms protect data sent over an IPsec tunnel:
■ Authentication Header (AH)
■ Encapsulating Security Payload (ESP)
Using Secure Hash Algorithm (SHA) or Message Digest 5 (MD5), IPsec AH provides partial integrity and authentication for IP datagrams. IP protocol number assigned to AH is 51. IPsec AH can operate in either transport mode or tunnel mode. In transport mode the AH header is inserted after the original IP packet’s header. In tunnel mode however, the original IP packet is entirely encapsulated in another IP packet (new/outer) and the AH header in inserted after the encapsulating/outer IP packet’s header. Figure 6-1 illustrates this. Tunnel mode is often used to provide connectivity between networks that use private addressing; the outer IP packet’s address is routable and allows delivery of the inner IP packet from one private site to another. Figure 6-1 shows two IPsec packets with AH headers: one in transport mode, and the other in tunnel mode. IPsec AH alone does not provide data confidentiality through encryption.
Figure 6-1 IPsec AH in Tunnel Mode and in Transport Mode
IPsec ESP provides data confidentiality (through encryption) and data authentication. If only the payload of the IP packet needs to be protected, the ESP header is inserted between the IP header and the IP payload, and only the IP payload is encrypted. This is ESP in transport mode. The IP protocol number 50 identifies ESP. If the entire IP packet including its header needs to be protected, the original IP packet is encrypted and encapsulated in another IP packet, with the ESP header between the new IP header and the encapsulated and encrypted (original) IP header. This is called ESP tunnel mode. Figure 6-2 shows two IPsec packets with ESP headers: one in transport mode, and the other in tunnel mode.
Figure 6-2 IPsec ESP in Transport Mode and in Tunnel Mode
Please note that in tunnel mode, with both IPsec AH and ESP, the original packet header ToS byte is copied to the encapsulating IP packet header ToS byte; therefore, it is available for QoS purposes. In transport mode, the entire original IP header is available for QoS processing.
QoS Pre-Classification Deployment Options
Many QoS features that are supported on physical interfaces are also supported on, and are often required on, tunnel interfaces. A QoS service policy that is normally applied to a physical interface can also be applied to a tunnel interface. In that situation, you must answer two questions:
1. Does the QoS policy classify an IP packet merely based on the ToS byte?
2. If the QoS policy classifies traffic based on fields other than or in addition to the ToS byte, should the classification be done based on the values of those fields in the pre-tunnel IP packet header or based on the values of those fields in the post-tunnel IP packet header?
With GRE tunnel, IPsec AH (transport and tunnel mode), and IPsec ESP (transport and tunnel mode), if packet classification is ToS based only, no extra configuration is necessary. That is because the IOS by default copies the ToS byte from the inner IP packet to the ToS byte of the encapsulating IP packet when tunneling. Of course, when IPsec AH and IPsec ESP are in transport mode, the original ToS byte is already present and available for examination. Therefore, the challenge is presented when packet classification is based on fields other than or in addition to the ToS byte on the pre-tunnel IP packet. A pre-tunnel IP packet means that, in addition to being encapsulated, the inner IP packet of a tunnel may be encrypted.
The qos pre-classify command configures the IOS to make a temporary copy of the IP packet before it is encapsulated or encrypted so that the service policy on the (egress) interface can do its classification based on the original (inner) IP packet fields rather than the encapsulating (outer) IP packet header. If the classification is merely based on ToS byte, though, qos pre-classify is not necessary. A QoS service policy can be applied to the physical interface or to the tunnel interface. Applying a service policy to a physical interface causes that policy to affect all tunnel interfaces on that physical interface. Applying a service policy to a tunnel interface affects that particular tunnel only and does not affect other tunnel interfaces on the same physical interface.
When you apply a QoS service policy to a physical interface where one or more tunnels emanate, the service policy classifies IP packets based on the post-tunnel IP header fields. However, when you apply a QoS service policy to a tunnel interface, the service policy performs classification on the pre-tunnel IP packet (inner packet). If you want to apply a QoS service policy to the physical interface, but you want classification to be performed based on the pre-tunnel IP packet, you must use the qos pre-classify command.
The qos pre-classify command is an interface configuration mode command that is not enabled by default. This command is restricted to tunnel interfaces, virtual templates, and crypto maps, and it is not available on any other interface type. Example 6-1 shows a QoS service policy called to-remote-branch is applied to the serial1/1 interface of a router. A GRE tunnel with IPsec emanates from this serial interface. Because in this example it is required that the QoS service policy classifies pre-tunnel IP packets, the qos pre-classify command is applied to the tunnel1 interface and to the crypto map named vpn.
Example 6-1 QoS Pre-Classification Example
You might wonder why the service policy applied to the serial1/1 interface in Example 6-1 was not applied to the tunnel1 interface instead. It is because, this way the service policy applies not to just one, but to all the tunnels that emanate from that physical interface. Also, please notice that the qos pre-classify command, in Example 6-1, is applied to both the tunnel1 and to the crypto map called vpn. If the qos pre-classify command were not applied to the crypto map, the router would see only one flow: the GRE tunnel (protocol 47).
