[thought] Virtual Private Networks

 

Problem Area 3: Virtual Private networks(VPN)

 

    VPN?s are private networks operating over the public Internet. Like the Mbone, it is a type of overlay network that uses tunnels to form a virtual network on top of the Internet. To a normal user, VPN provides the benefits of a private network (like access to company servers, Intranet etc.), while corporations benefit from the low operational costs offered by it. In many ways, VPN?s are very much similar to multimedia networks that we had discussed in one of our earlier chapters, Multimedia Networks and Communication, and applications intended to be used over VPN?s will have similar functional (viz. support for multicasting, security, mobility and session management) and traffic requirements (viz. guarantees on bandwidth, delay and jitter).

VPNs can either be deployed by the system administrators (sysadmin) of the organization, or a VPN service package can be purchased from an existing ISP (such a VPN is called provider-provisioned VPN or ppvpn). However, I think that most organizations will prefer to buy a full package deal from the ISP, rather than hire a full-time sysadmin (needed for every site that needs to be networked), as sysadmins do not have any control over the core network of the ISP and cannot be of much help other than setting up the initial tunnels. On the other hand, by paying a one-time fee, large organizations can free themselves of the worry of maintaining their network and concentrate on other important issues. (This will even lead to mushrooming of monitoring agencies, that will keep a sharp eye on whether the ISP is delivering on its promise and provide monthly reports to the organization regarding downtime and other faults?..but let us keep this for future discussion)

    Thus I will only concentrate on issues that mar VPN deployment from the service provider?s point of view. I have mapped these issues into operational requirements, and concede that commercial success of any VPN solution will require immense research in providing appropriate solution to them.

 

Some useful terms and their meanings:

·        Customer Edge Device (CE): This is a device that sits at the customer site and interfaces with the customers network on one side and the Provide Edge device (PE, discussed next) on the other side. The ISP may have access to this device.

·        Provide Edge device (PE): This sits at the service providers site and can interface to multiple CE?s.

·        Core Network(CN): Core network of the service provider. No one cares about it other than the ISP. We assume that it is currently best-effort, but will soon be upgraded to guarantee QoS.

 

We now discuss research areas in satisfying the operational requirements for VPNs.

 

·        Scalability concerns: VPNs are private networks (having a private address space) built over public Internet. Thus for every company subscribing to a VPN service, the ISP has to maintain separate routing tables, as well as separate routing algorithm instances to maintain such tables. For example, consider an organization like GE, which decides to connect all its 50 worldwide locations with a VPN. In the simplest case, the ISP from which GE buys a VPN service, might decide to create a fully-connected mesh network. This would entail maintaining a routing table with 49 entries and a different routing instance within each router. If there are more companies like GE, then such a design would put tremendous load on every router. Thus one research area is to find efficient VPN topologies that will provide full connectivity plus minimize cost. 

Also it befalls on the ISP to design a fault-tolerant VPN network as most corporate customers have business that solely depends on connectivity. For example, assume that all 50 locations of GE, have been connected with some topology. If there is a link failure, alternate routes must already be in place and must be automatically activated. I have come across few research papers that concentrate on this issue and are working towards a solution that will minimize single point of failures (router or link failures), by having alternate routes going through physically different links. (Some papers have even mentioned that problem of finding such alternate topology is NP-complete).

 

·        Quality of Service Provisioning:

VPNs are here to replace leased lines with (cheap) virtual circuits, and hence are expected to provide all the benefits of a leased line. For example, a leased line will provide guarantees on bandwidth, delay and jitter and protect company data from snooping by intruders (this assumes that only authorized personnels have access to the physical leased line). With the current best-effort Internet infrastructure, it is not possible for ISP?s to provide any guarantees on bandwidth, delay or jitter. Such guarantees can be provided by upgrading the Internet infrastructure towards either Integrated Services (Intserv), Differentiated Services (Diffserv) or MPLS. However, even with this in place, the ISP?s have to know the traffic characteristics from every location of the company and design the virtual network to maximize profits. (Our monitoring agency can be of some help here.. It can keep on monitoring and learning the traffic patterns at every company site and make suggestions to the company as to what can be the best service package for it).

The most widely researched area in this section is QoS provisioning (Intserv, Diffserv and MPLS). However, another upcoming research area is how to integrate QoS signaling with VPN signaling. For example, one cannot expect corporation to maintain separate protocols for security negotiations, QoS negotiation, policy negotiations etc. There needs to be a standardized way to do all these things.

 

·        Policy management:

It is necessary for the ISP to have an efficient policy management software, that can set-up /tear-down policies on the fly. For example, the company may fire some employees and require that their access rights be terminated immediately. Similarly there might be rules governing certain on-line sites that are forbidden or certain office locations that are accessible only to certain employees. Many complex rules can similarly be given, and it falls on the ISP to implement such rules with minimum latency.

 

 

We now discuss research areas in satisfying the functional requirements for VPNs.

·        Security: Currently most of the VPN solutions depend on IpSec to provide the necessary security architecture. However, setting up IpSec tunnels between two end points is a very complicated task as public/private keys need to be negotiated and agreed upon in advance. If this is followed by QoS negotiations, then the complete task of setting up an end-to-end tunnel, will involve large latencies. Thus, as said earlier, it is necessary to come up with a standardized and uniform way to do such negotiations.

·        Remote Access to users: With the advent of high speed internet access in the form of cable modem, xDSL, cellular networks and wireless LAN, it is now possible for users to get on the internet without having to dial-in. However connecting to a corporate VPN requires them to use tunneling protocols like L2TP that add a lot of overhead to every packet. One research area is to reduce this overhead. I haven?t come across any research paper that discusses the effect of tunneling on real-time applications.

 

·        Mobility: Almost all the organizations can now be assumed to be fully linked with wireless LAN?s. Mobile IP is used to provide mobility in wireless LAN (as well as any other wireless/cellular networks). Mobile IP itself uses tunneling to route information to the mobile host. Thus if mobility support is provided using mobile IP, then there will be two tunnels ((i) for the VPN and (ii) for operation of mobile IP protocol), which will increase the overhead in every packet. It will be interesting to see how mobility can be provided under such situations.

·        Multicasting: Multicasting is an important functionality that needs to be efficiently provided by the VPN. (Still have to think more about this).