Virtual private nets show QoS no respect

By Jim Duffy AND Tim Greene
Network World, 06/21/99

Users looking for quality of service from their VPNs may be in for a rude awakening.

It may be difficult for service providers to differentiate QoS on virtual private networks (VPN) built with encrypted tunnels because encryption scrambles the data in the IP packet vital for defining and requesting QoS from the network, say analysts and other observers.

"It is one of the key issues, and it is one of the arguments that says to me that VPNs as a service may not make sense," says John Freeman, an analyst at Current Analysis in Sterling, Va.

"It's hard to classify the traffic when you can't look into the packet," says Dave Passmore, president of consultancy NetReference, also in Sterling.

The VPN tunneling and encryption-standard IP Security (IPSec), for example, encrypts both the payload and header portions of an IP packet, Freeman says. The header contains the type of service (ToS) field where QoS services - such as Differentiated Services (Diff-Serv) - reside.

"Any ToS bits that have been set are scrambled" by IPSec, Freeman says.

Likewise, if the VPN is set up using the common tunneling protocol called Layer 2 Tunneling Protocol (L2TP), the network being tunneled through may have trouble figuring out what QoS to grant to what applications. That is because the L2TP protocol does not address how to ensure QoS via Diff-Serv or the IETF's Multi-protocol Label Switching (MPLS) standard for traffic engineering.

Vendors are circumventing the problem by mapping ToS bits within the encrypted header to an unencrypted, or "clear text" header ahead of the tunneled packet. Cisco has been shipping this capability in IOS 12.0 since January, says Richard Palmer, vice president of marketing for Cisco's Enterprise line of business. Likewise, Nortel Networks started shipping the clear text feature in Version 2.5 of its Contivity Extranet Switch software earlier this month, says Bruce Perlmutter, a Contivity product manager at Nortel.

But there are two problems with the workaround, analysts say. One, it's not standard, so QoS may not be consistent in a public network with multivendor switches and routers.

"It's a lot easier if you've got it all integrated into one platform," says Karen Barton, vice president of marketing for VPN switch vendor Xedia in Littleton, Mass. "If you have two different pieces of equipment on either end of the VPNs . . . we couldn't make any representation about the ability to provide a QoS guarantee to the applications on the other side."

The second problem with the clear text header approach is that it provides network-level QoS, not application-level QoS, using service-level policies. Application-level QoS is vital for service-level agreements (SLA) between enterprises and service providers that guarantee the response time of mission-critical applications.

"The only guarantees service providers are making are with respect to network transport," says John Morency, an analyst at Renaissance Worldwide in Bedford, Mass. "You're not going to get the end-to-end QoS you're looking for."

Application-level QoS information typically resides in the TCP/UDP port number field of the IP packet, which is deeper within the packet than the IP header. If this information is left unencrypted, it's an invitation for hackers, analysts say.

"Now I know what packets to look for if I'm targeting a specific application," Freeman says. "It does compromise security."

Right now, service providers are throwing bandwidth at the policy-based VPN QoS encryption problem. For example, Concentric Networks uses Xylan gear to queue traffic according to policies before the traffic is encrypted and sent across Concentric's backbone.

The backbone has to be engineered with ample bandwidth so traffic doesn't encounter congestion that increases delay and disrupts QoS.

"To do SLAs today, we just throw more capacity at it," which is inefficient, says John Lawler, Concentric's product line manager for VPNs. The IETF is currently working on ways for service providers to simplify their VPN QoS schemes.

Some vendors and analysts say label switching schemes, such as the IETF's MPLS, solve the VPN QoS problem because they create closed user groups in which certain sites are only able to communicate with certain other sites. Therefore, encryption is not needed, they say.

Still, there will be some enterprises that insist on tunneling all VPN traffic. And things could become even more complicated when Microsoft releases Windows 2000, which is currently undergoing beta testing.

Windows 2000 calls for using L2TP and IPSec, which Microsoft says are valuable for encrypting and tunneling non-IP packets across an IP VPN. But this "double tunneling" shields QoS information from MPLS routers, says Greg Marcotte, vice president of marketing for Altiga Networks.

The only decisions the router can make would be based on the source and destination IP addresses as shown in the L2TP packet header. Individual applications between two IP addresses could not be given different QoS levels, Marcotte says. The IETF is considering two proposals to overcome this. One describes how two L2TP devices could negotiate a Diff-Serv indicator for dial-in users. The other describes how two such devices could negotiate an MPLS label. o