10.9 Quality of Service (QoS) and the VPN

Quality of service (QoS) is a topic that is typically found in books on network design — not network security. However, because VPNs inherently increase the delay of traffic through the encryption and decryption process, a word or two is appropriate here.

QoS is an issue that is often sidestepped when designing networks. It is a myth that IP does not support QoS, but true end-to-end QoS can be difficult to achieve. While it does not solve all problems, most network engineers simply address QoS by adding more bandwidth to the network. While this is common, it makes networks more expensive to operate than they need to be and still does not address all QoS issues. Variable delay and queuing delays caused by link aggregation are two common failures of simply adding more bandwidth to the network.

Many times, the issue of QoS will be outside your ability to control, unless you also happen to be a network administrator of the ISP backbone that you are going to use to transport your VPN traffic. Even then, it is unlikely that you will have control over your competitors' QoS solutions if your VPN traffic should need to traverse another backbone. This is not to say that it is a lost cause. The information in this section will give you what you need to discuss QoS requirements and solutions with your service provider and offer suggestions for the traffic that you can control. We will see that the most effective place to apply QoS is normally at the edge of the network, which is exactly where your access-link is located.

While QoS can be complicated to implement, the concept of QoS comes down to a simple idea. You have two packets that need to be sent out a particular interface. Which one goes first? Intuitively, we know that if we want one packet to go before the other, we have to be able to tell the router, firewall, switch, or VPN gateway which one it is. To do this we are limited to information that is already in the packet. There needs to be some way to say to the hardware, "This packet is the more important of the two. Send it out first."

For a VPN, which is a security countermeasure, understanding QoS will typically allow the network to reduce the costs associated with the Internet access. As the above discussion points out, there are two ways to take care of the QoS dilemma. The first is to add more bandwidth. When we are evaluating countermeasures for cost effectiveness, increasing the bandwidth speed to account for any VPN performance issues must also be considered. This might be fine for an ISP, but for most companies, the cost of upgrading their Internet access to higher bandwidths can be high. A cheaper, more sensible solution is to create a way that makes it look like you have more bandwidth available — without having to actually purchase it. This good business sense will translate to a security policy that is secure and cost effective.

A VPN has no special needs or requirements for QoS beyond that for normal IP traffic. To put another way, there is nothing special about how to provide QoS for VPN traffic; all of our normal IP tricks are available to us. It will be the content of the VPN traffic that will determine the specific requirements for any QoS.

The one exception to the above paragraph is the process of differentiating between traffic within the VPN. All QoS relies on a simple premise. There must be something about the packets that allows the device performing the QoS to be able to tell one from another. Without this marking, there is no way to selectively process one packet ahead of another. As an example, Host A is sending to Host B two types of traffic over the Internet with no encryption applied. One type of traffic is a normal file transfer going on in the background. The other type of traffic is a Voice-over-IP (VoIP) session that two users at the host are having. Clearly, the QoS requirements of these two streams are different. Because it is normal IP traffic, there are plenty of ways to tell one type of traffic from another. Although both streams are to the same IP addresses, we can use the IP precedence bits to mark one type of traffic higher than the other. We can also use Diffserv, which simply uses the same IP precedence bits and marks them in a different (but compatible) way. If our network supported it, we could also use the Resource Reservation protocol (RSVP) to reserve a certain amount of bandwidth along the path between the two hosts.

Now encrypt the data and the voice traffic between Host A and Host B and place it in a tunnel between two gateways. Suddenly, this is a lot tougher. Host A and Host B can mark the packets when they leave the host to indicate priority, but those marked packets are then placed inside another IP header at the gateway. Unless the gateway has some method of marking the priority of the outside packet as the inside packet, the differentiating information on the traffic is lost. After all, it is now encrypted. Routers on the Internet know that they are seeing VPN traffic, but do not know that there is data and voice in the packets; each of which requires different service on the network.

The simple yet inelegant solution to this is to create two VPN sessions at the gateway and sort traffic based on transport layer protocols for forwarding down a particular session. One VPN session, the voice, is marked for high QoS. The other, data, is marked for less demanding QoS.

The choices you have for QoS normally rely on the transport technology that you utilize. If you are using multiple protocols over Frame Relay, you are limited to two priorities: high or low. ATM, of course, supports a wide range of priorities being one of the original driving forces for the protocol. It is common to find service provider backbones transporting both toll-quality voice, video, and data over a single network. If you are transporting all of this data encapsulated in an IP packet, then you have protocol identifiers available at that level as well.

MPLS is often touted as the solution to quality-of-service problems. In truth, the MPLS protocol itself does not provide any QoS. What it does is provide a framework that makes it much easier to implement the same QoS techniques that we already use for IP. It becomes so easy that service providers can do it on a large scale. Remember that it is not that QoS with IP is impossible; it is that it is difficult to implement consistently and get it to scale. MPLS allows both consistency and scalability.

QoS in MPLS is typically provided in two ways, both of which can be employed at the same time. The first method is the "pipe." This means that RSVP is being used to create a label-switched path through the network with certain bandwidth reservations. For example, you could create a VPN between your main office site and a remote office. You could also request that the service provider guarantee that the bandwidth of that VPN remains at 1 Mbps, or 10 Mbps, or higher. The service provider would then use the RSVP to reserve the requested bandwidth between the two sites to the exclusion of other traffic if needed. If the network between the two sites should change, RSVP would be able to automatically find another path that guaranteed the bandwidth for the traffic.

The "pipe" reserves bandwidth between two points. Inside that pipe we may wish to treat one traffic type with a priority over the other. If our hypothetical central and remote sites above were also doing video conferencing or VoIP between these two sites along with normal Web traffic and e-mail, then in addition to the bandwidth reservation, we would want to make sure that our high-priority data never gets stuck behind our own low-priority data. To this end, MPLS also supports integration with the Diffserv and IP precedence protocols. Both of these allow the marking of traffic in the MPLS header. The effect is that if two packets sent out the same port between the two company sites over the RSVP reserved pipe, the proper QoS can be applied to each. Inside the pipe, the MPLS label switching router can determine that, "Hey, this MPLS packet is marked with a high priority; I should make sure it gets sent before that other MPLS packet."

Neither RSVP nor Diffserv requires MPLS for operation. The benefit of MPLS, however, is that it becomes much easier to implement. What that is, however, is most likely the subject of another book.

For VPN traffic sent over a LAN technology such as Ethernet, the 802.1q standard applies to Ethernet frames. This is a sorting mechanism that allows Ethernet frames to be marked with much the same priority levels of an IP packet. All of the traffic grooming at the IP level will be useless if the switches used to connect the routers together become congested. While the 802.1q standard applies eight priority levels to traffic, be aware that most switch manufacturers only support two levels of QoS — high and low. While this may seem inflexible, in reality it is more than adequate and prevents the hardware from being bogged down sorting out incremental priority levels. Sometimes, the best QoS solution is a limited one. Too much processing can slow down high-speed QoS.

Depending on your service provider, you will have limited options for VPN traffic sent over their backbone. What should really concern you more is the service level agreement (SLA) for your traffic. How the service provider maintains that SLA and at what cost to them are irrelevant to you as long as their service and prices are comparable to the competition.

While much of the backbone QoS may be out of your hands, it does make sense to think about QoS with regard to your VPN (and other traffic) at your access router. At this device you can control the order in which packets are being sent onto the service provider backbone. Note that you cannot control the return of that traffic — that is what your ISP will do. I have seen, however, noticeable responsiveness to VPN and user traffic by simply configuring QoS on a single site. When considering a network as a whole, this makes sense. Most LANs now operate at 100 Mbps or more. Most company access-links to the Internet are still at T-1 speeds, on average. When you have the potential for 100 Mbps of data trying to fit over a 1.544-Mbps link, there is going to be congestion. A couple of simple QoS techniques for prioritizing your VPN traffic on the single interface link going to your ISP should result in noticeable improvements in this case. If you can get your ISP to configure its interfaces pointing back toward you in a similar manner, the quality of the link increases significantly. Applying QoS at these two points and no place else has such a profound impact because for most traffic, this T-1 link is the slowest link in the chain. Traffic coming from the ISP is generally not congested or delayed on the ISP backbone itself. Any reasonably competent ISP will have bandwidth to burn and its own sophisticated QoS mechanisms on the backbone. The congestion hits when it gets to the link to the customer.

In summary, while the VPN does not have any specific QoS needs above and beyond that which you have assigned to the traffic being encrypted, knowing your options will assist you in creating a VPN service that is secure, robust, and meets the needs of your users.