Monthly Archives: April 2012

GET VPN or Flex VPN…? Do I need both ?

– How Flex is GET ? – What do you get from FLEX ?

On two recent posts we summarized the concepts and motivations pertaining to Flex VPN and GET VPN, two important IPSec-based solutions offered by Cisco. But the availability of these two VPN paradigms may eventually generate some confusion: – Which way to go ? – Do I need both… ?

The figure below provides the backdrop for our current discussion. The two technologies are actually complementary:

  • GET VPN is designed for use within environments that do not have the public/private addressing issue and is well suited for materializing what I frequently name the Secure Intranet Service. FLEX is more flexible in that sense because it allows you to deal with either Intranet or Internet-related scenarios.
  • GET VPN is tunnel-less in nature and aims at scenarios in which the trust level is shared by VPN participants. An attractive by-product of not using tunnels: GET is very adequate to encrypt multicast, because the same distribution tree built in the WAN to forward the clear text multicast packets is equally available for ciphered ones. (Remember the IP Header Preservation inherent to GET…)
  • FLEX is tunnel-based and is able to handle environments involving dynamic (on demand) tunnel setup between spokes, EasyVPN style deployments (when the remote behaves as a hardware client) and many more.
  • GET VPN employs group-based Security Associations (SAs), as opposed to the point-to-point SAs that appear on tunnel-based VPNs (including the FLEX VPN framework). Again, this is possible as a result of the trust level parity that characterizes remote sites on INTRANET-only deployments. This is not a limitation of FLEX, which was conceived to cover a broader spectrum of VPN styles ( for which you cannot assume the same trust level for every site).
  • GET VPN is used for site-to-site only, whereas FLEX VPN is able to work with site-to-site and Remote Access (RA VPN) deployments at once.
  • GET VPN was designed to take advantage of the inherent full-mesh capabilities of MPLS networks. Of course FLEX can be employed on any-to-any clouds but, given that it is tunnel-based, its logical configuration possibilities will be hub-and-spoke and spoke-to-spoke.
  • FLEX VPN requires IKEv2 while GET VPN currently supports only IKEv1. (Of course there are plans to add IKEv2 to the GET VPN side of life at some point in time… :-)) The key information to remember: immediate IKEv2 support is less critical for GET (which presupposes private transport) than for FLEX VPN, a technology aimed at tunnel-based scenarios that involve Internet-based transport.

Flex VPN or GET VPN: quick comparison

The good news: if you have a security license on your Cisco ISR G2, the two options are available simultaneously allowing you to select the option that better fits the needs of your specific environment (eventually you will end up employing both). Some general guidelines are presented below:

  • For INTRANET-only site-to-site scenarios, GET may prove very appealing. Policy distribution and key management tasks are centralized and the Group SA concept is really convenient. The other key differentiator (associated with its tunnel-less nature) is encrypted multicast.
  • On the other hand, for any environment that includes external connections (INTERNET, EXTRANETS and the like), go FLEX. It provides an unified and structured approach for VPN creation and can handle so many connectivity options. And, remember, it relies on IKEv2 for SA negotiation (much more secure than its v1 counterpart).
  • If you want to stick to a single way of dealing with all VPNs (site-to-site and Remote Access), FLEX is the answer. Although not offering the Group SA, it covers everything. As discussed in the FLEX article, you can end up with a single block of configuration at the hub and be prepared to terminate any VPN connection.
  • If necessary, you can still leverage both technologies at the same router (GET for INTRANET site-to-site interconnection) and FLEX for all the rest.

** Notes:

** Related Posts:

Leave a comment

Filed under English, VPN

Building secure and scalable INTRANETS with GET VPN

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:

  1. 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.
  2. 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.
  3. 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.
  4. 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).
  5. 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:

Leave a comment

Filed under English, VPN

Flex VPN: A new paradigm for IPSec deployment on Cisco Routers

Virtual Private Networks (VPNs) are a classic resource designed to securely and inexpensevely extend the reach of corporate networks. Several options available are built on top of IPSec, a framework that deals with the tasks of ensuring Confidentiality, Integrity, Authentication of origin and secure key distribution for VPNs.

Some of the notable strengths of IPSec are its independence of the transport (UDP, TCP or raw IP) and the provision for easy replacement of one or more of its components (such as the hash functions and cryptographic algorithms) so that it can keep up with hardware evolution and what it means in terms of feasibility of brute force attacks.

If you are familiar with Cisco IOS software, you probably heard terms such as Classic IPSec, IPSec/GRE, Virtual Tunnel Interface (VTI), EasyVPN, Dynamic Multipoint VPN (DMVPN)… But, which of these site-to-site VPN options available on Cisco IOS software should you select ? Well, I will start by saying that each of the technologies was developed to solve specific problems:

  • Crypto Maps are the initial/legacy solution that was devised before IPsec was even an RFC. Although the services available are very basic they do help on interoperability.
  • VTI brings a logical interface to IPSec deployments without the need of using Generic Routing Encapsulation (GRE).
  • EasyVPN allows branch routers (or other types of VPN appliances) to behave as hardware clients that are centrally configured by a VPN concentrator.
  • DMVPN provides the capability of dynamically establishing tunnels between spokes on a hub-and-spoke scenario.

The good news is that Cisco now offers a unified way of dealing with all these options, allowing your network to be prepared to simultaneously handle the different VPN models. The new approach is called Flex VPN and, as the name suggests, is really flexible in terms of configuration possibilities:

  • A router implementing Flex VPN may be configured to expect connections in any of these site-to-site forms: VTI, EasyVPN, GRE/IPSec, DMVPN (and even Classic IPSec tunnels, in case you need to guarantee interoperability with other vendors or older Cisco routers).
  • Flex VPN can deal with remote access either using the Windows 7 native client or a dedicated client such as Cisco AnyConnect.
  • Flex VPN supports both IPv4 and IPv6 implementations.
  • Authentication and Authorization may be performed by means of a local database or using RADIUS (more convenient for Service Provider environments, which typically require multi tenancy).

A critical point in which Flex VPN does not allow flexibility, though, is for Security Association (SA) negotiation and establishment. Flex VPN requires the use of the version 2 of the Internet Key Exchange protocol (IKEv2), a more secure option than the original implementation (IKEv1). But, instead of getting frustrated with the obligation of moving to IKEv2, I hope that you become motivated to start learning Flex VPN. After all, the return on investment is significant: you will not only have a much better control plane protocol in place but also will have just one VPN to support !

It is relevant to emphasize that IKEv2, by design, is not backward compatible with IKEv1. And, as such, if you want to benefit from the increased security in IKEv2, you will need to reconfigure your IPSec VPNs anyway…

To finish this quick post, I present a figure that shows some possibilities associated with the Flex VPN approach. Future articles will cover specific deployment scenarios… Stay tuned !

Summary of Flex VPN Options

** Notes:

  • Backward compatibility may sound attractive for network protocols (remember the example of RIPv1/RIPv2) but for security features it is rather questionable. If IKEv2 was allowed to interoperate with its v1 counterpart, you would be giving up the flexibility and security that v2 provides.
  • Even though it is not possible to enable IKEv1 as part of the Flex VPN framework, you can gradually migrate your IKEv1 configurations (crypto isakmp syntax) to IKEv2/FlexVPN.

** Further Reading:

1 Comment

Filed under English, Security, VPN