Group Encrypted Transport VPN (GET VPN)

There is a predecessor to GET VPN, called Tunnel Endpoint Discovery (TED). This first section will provide a brief historical overview of TED, describing the requirements, challenges, benefits and drawbacks of the solution that are similar to those of GET VPN.

Tunnel Endpoint Discovery (TED)

Some time ago, Cisco IOS supported a mechanism called Tunnel Endpoint Discovery (TED), which had the following characteristics (also see Figure 1):

The first user packet triggered the first IPsec router to establish an IKE tunnel.

The destination address from the original user packet was used in sending out a probe.

The terminating IPsec router received the probe. An IKE session could now be established and IPsec SAs negotiated between the pair of IPsec routers.

This functionality allowed for a very simple implementation of IPsec in which no peers had to be statically defined, and it supported an on-demand mesh of tunnels (any-to-any).

Advantages of TED:

Full-mesh topology (i.e., on-demand any-to-any topology).

Configuration simplicity: no per-peer configuration.

Disadvantages of TED:

Dropped packets while waiting for SAs to be negotiated.

Only certificates or wildcard pre-shared keys could be used for authentication (per-peer pre-shared keys destroyed the configuration simplicity).

Could only be used in environments where the WAN had routing information for the VPN (e.g., private WAN, MPLS VPN), which excluded the most common need for IPsec – over the Internet.

Figure 1

Tunnel Endpoint Discovery (TED)

The figure illustrates the process of creating an IKE session when using TED.

Group Encrypted Transport VPN (GET VPN)

GET VPN has similar characteristics to TED, but it also tries to solve some of the deficiencies of TED:

Full-mesh topology, but not using the on-demand IKE, because it results in dropped packets and frequent gaps in the operation of the network.

Configuration simplicity, but some simplicity is sacrificed to find a balance between security and manageability.

Let’s analyze IKE authentication options and how they apply to full-mesh implementations:

Digital certificates are ideal for fully-meshed solutions, as they provide any-to-any trust within a PKI domain. The disadvantage of the PKI is its management complexity, which deters many network administrators from using PKI (e.g., CA server is required, CRLs and accurate timekeeping are needed on all devices, CRL distribution point and NTP server must be reachable from all devices, periodic re-enrollment is required etc.).

Wildcard pre-shared secrets suffer from a security standpoint – if one device in the mesh gets compromised, all tunnels are compromised, and all devices need to be reconfigured with a new wildcard pre-shared secret.

Per-peer pre-shared secrets suffer from a manageability standpoint – if a new device is added, all devices must be configured with a secret for the new device.

GET VPN addresses the control and data plane of the solution separately:

Full-mesh topology is retained for user data (IPsec).

A hub-and-spoke topology is used for control sessions (IKE/GDOI).

All members of the group are statically configured with a central key server, thus creating a hub-and-spoke topology on the control plane. The key server accepts IKE sessions on UDP port 848 to create an authenticated and encrypted channel between group members and the key server.

Figure 2

GET VPN Control Sessions

The figure illustrates the control sessions that are established and maintained from all routers that are members of the group.

Through IKE sessions, the Group Domain of Interpretation protocol (GDOI; RFC 3547) is used to send IPsec protection policies and group keys to group members.

Figure 3

GET VPN Policy and Key Distribution

The figure illustrates how the key server distributes not only the encryption keys but also the encryption policies in order to further simplify the configuration.

Once all routers are registered with the server and have received the policy and keys, they can start forwarding encrypted traffic between any pair of sites.

Figure 4

GET VPN Data Forwarding

The figure illustrates how the temporal group keys are used between any pair of sites to exchange user data. The figure also illustrates the usage of tunnel mode with header preservation, in which the original IP source and destination addresses are also used for IPsec packets (similar to TED). Routing within the untrusted cloud should be able to route packets using these addresses (similar to the limitation when using TED).

GET VPN Design Guidelines

Raw GET VPN is useful in environments where the VPN addressing is also routable in the untrusted transport network (e.g., private WAN, MPLS VPN). The last article in this series will discuss the combination of multipoint GRE tunnels and GET VPN for site-to-site VPNs over the Internet.

Authentication

GET VPN only requires group members to authenticate to the key server(s). The most common authentication options are the following:

Digital signatures. This option introduces the complexity of managing the PKI but simplifies the configuration of the key server (no per-peer configuration is required). The any-to-any trust characteristic of the PKI is not required when using GET VPN, as all group members only communicate with the key server(s) – thus creating a hub-and-spoke topology of control sessions.

Per-peer pre-shared keys. This option is more commonly used because it is less complex to maintain, though it requires key servers to be configured with a key for each group member.

Encryption and Packet Authentication

As with any other IPsec implementation, it is recommended that you use algorithms of sufficient strength:

AES (192- or 256-bit key) or 3DES to provide strong encryption.

SHA-1 to provide packet authentication and integrity assurance. MD5 can also be used, despite its collision vulnerabilities (they don’t affect ESP).

High Availability

The most obvious single point of failure in GET VPN solutions is the key server. A redundant key server should be installed on another site, and synchronization with keepalives should be configured between the two servers to provide group members with a backup in case the primary key server fails.

All other important sites should also be designed with redundancy in mind (i.e., redundant routers, links).

Figure 5

High Availability (HA)

The figure illustrates a failure of a primary key server. All group members that need to register to a key server will first try to connect to their primary key server. Eventually, they will try registering to the secondary server. Key servers used for the same group will negotiate which server is primary (based on configured priority), and the elected primary key server will replicate its group configuration (policy and keys) to secondary servers.

Performance and Scalability

Unlike other IPsec solutions where performance limitations can be influenced by a number of parameters such as bps, pps, number of IKE sessions, DPDs, IGP hellos etc., GET VPN can be divided into two groups of devices with different parameters influencing their performance:

Group members whose performance is limited solely by the amount of traffic they need to encrypt/decrypt. This is typically measured in both bps and pps.

Key servers whose performance depends on the number of registered group members.

There are two events that put a load on a key server:

Initial registration of a group member. This load is especially significant when a key server is first started (since all group members are trying to register at the same time), or when all group members try to re-register to a secondary key server because the primary is not responding. This event is relatively rare and is typically not considered, though we have to bear in mind that in such scenarios it may take some time before the network converges.

Re-keying when a key server must send updated policies and new keys to all group members. This event happens frequently and periodically, depending on the configuration of the policy (i.e., SA lifetimes).

In large environments, multiple key servers can be used to share the load for registering group members. Multiple subgroups can be defined, each statically configured with a different primary key server. Thus, group members will direct their registration attempts at different key servers, and the registration load and the re-keying load will be shared among multiple key servers.

Figure 6

Load Sharing

The figure illustrates an environment in which some group members have one key server configured as primary, while other members have the other key server configured as primary.

Additionally, key servers can be configured to re-key using multicast instead of unicast. This means that a single multicast message is generated by the key server instead of a number of unicast messages to each group member, thus reducing the load on the key server. The WAN must be configured with multicast support in order to enable this functionality.

GET VPN Implementation Example

The following example illustrates a simple redundant configuration for a single VPN group.

Listing 1

Example: Primary Key Server Configuration

!

! Pre-shared secrets used to authenticate redundant key server

crypto isakmp key nptbUsX3nMCnPHQNhXOIp16UyTc address 192.168.1.1

!

! Per-peer pre-shared secrets used to authenticate group members

crypto isakmp key djZ2PkBnNdGoG2RpjTXhg4w3WsI address 192.168.1.2

crypto isakmp key wYyfwMrEGseKT0JsYadiDTyJnv8 address 192.168.1.3

crypto isakmp key rHVM9VeibvHrUoq7FJOw9oWVPYY address 192.168.1.4

...

!

! IKE policy for group member registration

crypto isakmp policy 10

 encr aes 256

 authentication pre-share

 group 5

!

! IPsec profile to download to group members

crypto ipsec profile IPsecProfile

 set security-association lifetime seconds 3600

 set transform-set TS

!

! Access list identifying VPN traffic that needs encryption

access-list 100 permit ip 10.0.0.0 0.0.0.255 10.0.0.0 0.0.0.255

!

crypto gdoi group VPN

 identity number 1

 server local

  rekey retransmit 10 number 3

  rekey transport unicast

  !

  ! IPsec SA to download to group members

  sa ipsec 1

   profile IPsecProfile

   match address ipv4 100

   replay time window-size 5

  !

  address ipv4 192.168.1.1

  !

  ! Redundant Key Server definition

  redundancy 

   local priority 100

   peer address ipv4 192.168.1.2

 !

!

Listing 2

Example: Group Member Configuration

!

! Pre-shared secrets used to authenticate to Key Servers

crypto isakmp key djZ2PkBnNdGoG2RpjTXhg4w3WsI address 192.168.1.1

crypto isakmp key djZ2PkBnNdGoG2RpjTXhg4w3WsI address 192.168.1.2

!

crypto isakmp policy 10

 encr aes 256

 group 5

 authentication pre-share

!

crypto gdoi group VPN

 identity number 1 

 server address ipv4 192.168.1.1 

 server address ipv4 192.168.1.2

! 

crypto map CM 10 gdoi 

 set group VPN

! 

interface FastEthernet0/0

 crypto map CM

!

Summary

While GET VPN enables any-to-any connectivity like TED, it doesn’t result in packet drops and IKE setup delay.

The main advantages of using GET VPN include the following:

Enables any-to-any VPN connectivity with hub-and-spoke control sessions.

No need to support routing protocols, because it relies on WAN routing.

Improved manageability by centralizing most of the IPsec configuration.

Supports multicast.

The main challenges with using GET VPN include the following:

Requires VPN routes to be routable in the transport network, which prevents it from being used over the Internet.

Multicast support also needs to be implemented in the transport network if used in the VPN.

Related learning solutions:

Designing Site-to-Site IPsec VPNs

Designing Site-to-Site IPsec VPNs - Part 2

Designing Site-to-Site IPsec VPNs - Part 3

Designing Site-to-Site IPsec VPNs - Part 4

Securing Networks with ASA Advanced Course

Securing Networks with ASA Advanced Remote Labs

Securing Networks with ASA Fundamentals Course

Securing Networks with ASA Fundamentals Remote Labs

Securing Networks with Cisco Routers and Switches Course

Securing Networks with Cisco Routers and Switches Remote Labs

Securing Networks with Cisco Routers and Switches E-course

More to explore:

Group encrypted transport VPN (GET VPN) design and implementation guide

Cisco Group Encrypted Transport VPN

Cisco Group Encrypted Transport VPN Data Sheet

Cisco Site-to-Site VPN Technologies Comparison