The term Virtual Private Network (VPN) is employed to define technologies designed to reproduce the characteristics of a private network even when traffic is being transported over a shared infrastructure. The common motivation behind the various VPN options are to extend the reach of corporate networks in a secure and inexpensive manner.
But the word security has a broad meaning and may represent very distinct resources when considered from the standpoint of each of the VPN technologies. For instance, two of the main categories of VPNs (IPSec and MPLS-VPN) are optimized to solve complementary problems and present challenges that are also complementary. A brief summary is presented below:
- The IPSec Framework provides answers for questions such as data confidentiality, integrity, peer authentication and management of cryptographic keys. And, interesting enough, all of these tasks are accomplished by means of standardized protocols and algorithms, a fact that contributed to render IPSec almost omnipresent when the subject is VPN. On the other hand, classic IPSec uses point-to-point negotiations between the communicating parties, which brings significant challenges, mainly in terms of routing, when deployed on a large network.
- The MPLS-VPN service, by its own nature, provides logical segmentation of the transport network and optimized routing (any-to-any) but establishes no definition in what refers to the typical problems solved by IPSec (confidentiality, integrity and the like).
Keeping in mind the capabilities just presented, let’s consider the demand of building the Intranet of a large company that uses Unified Communications among its sites (the traffic nature is any-to-any) and that, in order to comply with market regulations, is supposed to take advantage of the services beneath the IPSec umbrella.
In an initial analysis, two simple-minded solutions could be provided:
- Build IPSec Security Associations (SAs) between each remote entity and HQ. Well, this approach would not be satisfactory because it could compromise the acceptable end-to-end delay budget for voice traffic (150 ms). Moreover we would be giving up the full-mesh appeal of MPLS networks.
- Create sessions betwen each pair of remote sites, so that you keep inter-branch traffic from crossing HQ. Besides being almost unmanageable from a configuration point of view, such a scenario would require that each VPN gateway in the remote location (typically a router) supported a very large of concurrent tunnels, thus impacting the cost.
If the mere superimposition of IPSec on MPLS does not meet the specified project goals, would it be possible to develop a new technology that could benefit from the IPSec security services without losing the optimized connectivity provided by MPLS ?
As a matter of fact, this was exactly what Cisco did. Building upon RFC 3507 (Group Domain of Interpretation – GDOI) and assuming that on Intranets you don’t need to worry about the private/public address issue, the Group Encrypted Transport VPN (GET VPN) came to existence. The main charateristics of GET VPN are listed in the following:
- Definition of group-based Security Associations instead of the traditional point-to-point SAs. This choice is justifiable because we are dealing with Intranets, in which the same degree of trustworthiness can be assumed for the remote routers.
- The access control function, which allows a VPN gateway (Group Member or GM in the GET VPN context) to be accepted in a given group, is performed by an element called the Key Server (KS). The KS is also responsible for centrally distributing the cipher keys and encryption policies that will be used by the GMs.
- IP Header Preservation in the encrypted packet, without changing the standard ESP format. This means that a GET VPN packet is a particular case of IPSec and, therefore, the algorithms and hardware in place can be reused.
GET VPN: IP Header Preservation
Some direct results of the basic GET VPN definitions:
- IP Header preservation ensures that the encrypted packets use the same routing table available for the clear text traffic, thus avoiding the creation of a new layer of routing for the VPN packets.
- The DSCP information is automatically copied to the external IP header and your Quality of Service (QoS) investments (classification and marking) remain valid for the VPN traffic.
- It is possible to account for network utilization on a per-user basis, irrespectively of packets being encrypted. This represents an advance in terms of visibility when compared to classic IPSec.
- Because Group Members (GMs) own the the key to decrypt the packets sent by any member of the group, the distribution of encrypted multicast traffic becomes natural ( in an identical manner that would be employed for clear text). It is important to highlight that GET VPN is the first technology to truly deliver on the promise of encrypting IP multicast (without requiring any tunneling artifice such as GRE).
- The management of encryption policies becomes much easier because it is centrally conducted by the Key Server. This is particularly relevant for Service Providers that will not need to configure VPN tunnels and interesting traffic definitions in hundreds of devices anymore.
Relationships between GET VPN elements
An important aspect to keep in mind is that a router enabled for GET VPN still comes with the classic IPSec solutions provided by Cisco. For example, you can leverage GET VPN to securely build your Intranet and traditional IPSec to establish a VPN connection though the Internet. Another fact to be aware of is that the same router may participate in multiple distinct groups, thus providing a simple solution to isolate departments within the same company.
** Additional Reading:
** Related Posts: