Oct
24

One of the new technologies to be featured in the CCIE Security 3.0 blueprint is the GET VPN. This blog post will give you the basics of this new and exciting technology.

Here is the scenario; you are a large corporation with multiple branch offices that need VPN connections between them in order to protect data that needs to be shared from branch to branch. The standard Cisco solution is to create point-to-point IPSec VPNs between these branch offices. This can quickly become a nightmare for administration, obviously, as this “any to any” encryption model using traditional VPN methodologies simply does not scale. Helping to exasperate this issue is the replication of multicast traffic and the extreme difficulty of implementing Quality of Service mechanisms across the core of the network.

The Group Encrypted Transport VPN model has your routers become trusted members of VPN groups as a replacement for the point-to-point model. Secured packets now use the existing router infrastructure and have their original IP header preserved. This helps to ensure that intelligent services like QoS and multicast are no longer implementation problems!

Another huge scalability issue with the traditional, point-to-point approach for “any to any” VPNs is key management. The GET VPN features simplified security policy and key distribution thanks to the Group Key Distribution Model. This model uses Group Domain of Interpretation (GDOI) as specified in RFC 3547.  The Group Key Distribution Model features a Key Server (a Cisco router) that authenticates group members, and handles the distribution of security policies and any required keys. In the interests of further scaling this already scalable solution, as well as improving availability, Cooperative Key Servers can be used across wide geographic distributions.

Here are the core technologies to explore with the GET VPN feature:

  • Group Domain of Interpretation (GDOI) RFC 3547
  • Key Servers (KS)
  • Cooperative Key Server (COOP KSs)
  • Group Member (GM)
  • IP tunnel header preservation
  • Group security assocaition
  • Rekey mechanism
  • Time-based anti-replay (TBAR)

Here are the GET VPN core benefits:

  • Large scale any-to-any IPSec security
  • Utilizes the underlying IP VPN routing infrastructure
  • Integration with existing multicast infrastructures
  • IP source and destination address preservation

I certainly hope this post wets your appetite and gives you a framework to begin your studies of the GET VPN technology.


You can leave a response, or trackback from your own site.

7 Responses to “Get this! It’s the Cisco GET (Group Encrypted Transport) VPN!”

 
  1. Zak says:

    Hi, it’s new interesting subj, could you tell more about this new technology?

  2. Chris Copley says:

    How does this compare to DMVPN?

  3. Joshua Walton says:

    I love get GET VPN. I was introduced to this technology June 2007 when I attended, at the time, my local Cisco Users Group.

    Presentation is by Mark Egan, CCIE #8775 – Cisco Systems

    http://dfw.cisco-users.org/zips/070606_Group_Encrypted_Transport_VPN.zip

  4. Joshua Walton says:

    Obviously, not “get GET VPN.” :O)

  5. We will be sure to cover this new technology in detail in our upcoming workbooks, but I am sure it will warrant some more blog posts as well :-)

    Regarding the DMVPN comparison question, here is a great quote from the Cisco Design and Implementation Guide:

    “Some provisioning overhead can be reduced using DMVPN. However, DMVPN requires overlaying a secondary routing infrastructure through the tunnels, which results in suboptimal routing while the dynamic tunnels are built. The overlay
    routing topology also reduces the inherent scalability of the underlying IP VPN network topology…Cisco’s Group Encrypted Transport VPN (GET VPN) introduces the concept of a trusted group to eliminate point-to-point tunnels and their associated overlay routing.”

  6. wilczek Jens says:

    jap,i agree, but not complete :-)
    GET-VPN isnt possible to live outside a private netstrukture with public ip addresses,hencmore it can be possible,that you will implement some small offices,there are connectet over xDSL with public ip`s. In this case you need to combinine GET-VPN with DMVPN together.
    In this scenrario the DMVPN IPSec tunnel will use the TEK groupe key from GET-VPN Groupmembers. No longer negotiasion becouse from now on its a static connection.

  7. mgj says:

    Though we have implemented get vpn for smaller scale (data only)and if we want to hook over the net does this mean dmvpn is the way?

    Is there any matrix where i can find if we want to deliver multicast traffic in both private and public net?

    Pls clarify further. TIA.

 

Leave a Reply

Categories

CCIE Bloggers