Group VPN Overview

Group VPN Technology Overview

• Understanding Group VPN

• Group VPN and Standard IPsec VPN

• Understanding the GDOI Protocol

• GDOI Protocol and Group VPN

• Group VPN Traffic

• Group Security Association

• Group Controller/Key Server

• Group Member

Understanding Group VPN

Group virtual private network (VPN) is a new category of VPN that eliminates the need for point-to-point VPN tunnels in a mesh architecture. It is a set of features that are necessary to secure IP multicast group traffic or unicast traffic over a private WAN that originates on or flows through a router.

Group VPN introduces the concept of a trusted group to eliminate point-to-point tunnels and their associated overlay routing. All group members share a common security association (SA), also known as a group SA (GSA). This enables group members to decrypt traffic that was encrypted by any other group member.

• Provides data security and transport authentication, helping to meet security compliance and internal regulation by encrypting all WAN traffic.

• Enables high-scale network meshes and eliminates complex peer-to-peer key management with group encryption keys.

• Maintains network intelligence such as full-mesh connectivity, natural routing path, and quality of service (QoS) in MPLS networks.

• Grants authenticated membership control with a centralized key server.

• Helps to ensure low latency and jitter by enabling full-time, direct communications between sites, without requiring transport through a central hub.

• Reduces traffic loads on customer premises equipment (CPE) and provider-edge (PE) encryption devices by using the core network for replication of multicast traffic, avoiding packet replication at each individual peer site.

Group VPN and Standard IPsec VPN

A group VPN is built on standards-based technologies that integrate routing and encryption together in the network. An IPsec SA is a unidirectional agreement between VPN participants that defines the rules to use for authentication and encryption algorithms, key exchange mechanisms, and secure communications.

Traditional IPsec VPN deployments tackle the problem of securing traffic between gateways in the network by creating an overlay network based on the use of point-to-point tunnels. Traffic carried over these tunnels is normally encrypted and authenticated in order to provide data integrity and confidentiality. Secure group members are managed through the Group Domain of Interpretation protocol (GDOI). The GDOI solution takes a different approach by disassociating the encryption and authentication problem from the transport. By doing this, GDOI-based solutions provide a way to encrypt branch-to-branch communications without the need to configure branch-to-branch tunnels.

With current VPN implementations, the SA is a point-to-point tunnel between two routers. A group VPN extends the IPsec architecture to support SAs that are shared by a group of routers (see Figure 1). A key server distributes keys and policies to all registered and authenticated member routers. By distributing policies from a centralized point and by sharing the same group security association (the entire group has a single Phase 2 IPsec SA) with authenticated group members, key distribution and management are greatly simplified.

Figure 1: Standard IPsec VPN and Group VPN

Group VPN is a client/server architecture. All members have a unique Phase 1 IKE SA with the key server. Hence, if there are n members, there is a total of n Phase 1 IKE SAs. However, the entire group shares a single Phase 2 SA.

In traditional IPsec, tunnel endpoint addresses are used as a new packet source and destination. The packet is then routed over the IP infrastructure, using the encrypting gateway source IP address and the decrypting gateway destination IP address. In the case of group VPN, IPsec-protected data packets encapsulate the original source and destination packet addresses of the host in the outer IP header to preserve the IP address. The biggest advantage of tunnel header preservation is the ability to route encrypted packets using the underlying network routing infrastructure.

Thus, with group VPNs, any-to-any connectivity is achieved by preserving the original source and destination IP addresses in the outer header. Secure multicast packets are replicated in the same way as cleartext multicast packets in the core network. The external IP header in the group VPN is an exact copy of the IP header of the original packet within the ESP header versus the external IP header in a traditional VPN that contains the IP addresses of the VPN gateways.

Understanding the GDOI Protocol

The Group Domain of Interpretation (GDOI) protocol described in RFC 6407 is used to distribute a set of cryptographic keys and policies to a group of devices. GDOI is defined as the Internet Security Association Key Management Protocol (ISAKMP) Domain of Interpretation (DOI) for group key management. In a group management model, the GDOI protocol operates between a group member and a group controller or key server (GC/KS) and manages group security associations (GSAs) and group keys for a set of security participants. The ISAKMP defines two phases of negotiation. GDOI is a Phase 2 protocol protected by a Phase 1 ISAKMP security association. IKEv1 is specified in RFC 6407 as a Phase 1 protocol.

• Key encryption key (KEK)—Used to secure the control plane. KEK is the name of the key used by the group members to decrypt rekey messages from the GC/KS. This key is part of the Security Association Key Encryption Key (SAK).

• Traffic encryption key (TEK)—Used to secure the data plane. TEK is the name of the key used by the group members to encrypt or decrypt communication between other group members. This key is part of the Security Association Transport Encryption Key (SAT).

As with standard IPsec, all keys have a lifetime and have to be rekeyed. The keys distributed through GDOI are group keys and are used by the entire group.

• groupkey-pull—This exchange allows a member to request SAs and keys shared by the group from the server.

  In the pull method, the group member requests the group SA and policy from the key server. This request is protected over the IKE SA.

  The groupkey-pull is the first exchange in the GDOI protocol and is used for group member registration with the GC/KS. The group member specifies the group with which it wants to register, and the GC/KS sends all necessary GSAs and keys to the group member if the member is authorized to join the group. The complete exchange is secured by a Phase 1 SA (IKEv1 SA), which is established with IKEv1 before the groupkey-pull exchange begins. The groupkey-pull is part of Phase 2 of the GDOI protocol.

• groupkey-push—This exchange is a single rekey message that allows the server to send group SAs and keys to members before existing group SAs expire. Rekey messages are unsolicited messages sent from the server to members.

  The groupkey-push is the second exchange in the GDOI protocol and is used to send new GSAs and keys from the GC/KS to the group members of a group (rekeying). This exchange is secured by an SA KEK (SAK), which is installed during the groupkey-pull exchange. The groupkey-push is part of Phase 2 of the GDOI protocol.

GDOI Protocol and Group VPN

Group VPN is the name of the security technology from Juniper Networks. Group VPN uses the GDOI protocol (specified in RFC 6407) as a base, in addition to other functionalities.

The group VPN technology is based on the GDOI protocol to handle the most important functionality. This protocol defines an ISAKMP Domain of Interpretation (DOI) to manage GSAs and keys for a group of security participants. Thus, all members of the group share identical information to encrypt and decrypt traffic among each other. The creation, management, and distribution of GSAs and group keys are centralized and performed by the GC/KS. Figure 2 provides a brief overview of the group VPN functionality using GDOI.

Figure 2: Group VPN Using GDOI

The group members use the Encapsulating Security Payload (ESP) protocol in tunnel mode to secure the traffic. However, in group VPN the tunnel mode is modified. Because there is no direct association between the group members, it is not necessary to use special IP addresses in the outer IP header (that is, IP addresses of IPsec gateways). Every group member can decrypt the traffic of every other group member. Thus, the inner IP-Header is copied to the outer IP-Header, and the underlying routing infrastructure and QoS infrastructure can be used. This feature is called Header Preservation and is shown in Figure 3.

Figure 3: Header Preservation

To get GSAs and group keys, the group member must register with the GC/KS for a specific group. The result is an IKEv1 SA, which is only needed to secure the registration process. After the registration, the group member has all the information to communicate with the other group members (SAT), as well as the information to successfully decrypt the rekeying messages (SAK). The GC/KS sends out rekeying messages before either the SAT or SAK lifetime expires. It is also possible to send a SAT update as well as a SAK update in the same rekey message. The IKEv1 SA is no longer needed and is deleted after the lifetime expires (no IKEv1 rekeying).

Group VPN Traffic

• Control-plane-traffic—Traffic from the group members to the GC/KS in the group VPN deployment with the GDOI protocol only.

• Data-plane-traffic—Traffic between the group members in the group VPN deployment with the ESP protocol only, that is already known from IPsec.

Group Security Association

Unlike traditional IPsec encryption solutions, group VPN uses the concept of a group security association (GSA). GSA is similar to an IPsec SA in terms of functionality. GSAs are shared among all group members of a common GDOI group. All members in the group VPN group can communicate with each other using a common encryption policy and a shared GSA. With a common encryption policy and a shared GSA, there is no need to negotiate IPsec between group members. This reduces the resource load on the IPsec routers. Traditional group member scalability (number of tunnels and associated SA) does not apply to group VPN group members.

Group Controller/Key Server

A group controller or key server (GC/KS) is a device used for creating and maintaining the group VPN control plane. It is responsible for creation and distribution of GSAs and group keys. All information the group members need to communicate with other group members is provided by the GC/KS. All encryption policies, such as interesting traffic, encryption protocols, security association, rekey timers, and so on, are centrally defined on the GC/KS and are pushed down to all group members at registration time. Group members authenticate with the GC/KS using IKE Phase 1 and then download the encryption policies and keys required for group VPN operation. The GC/KS is also responsible for refreshing and distributing the keys. Unlike traditional IPsec, interesting traffic defined on the GC/KS is downloaded to every group member, whether or not the group member owns that network.

Group Member

A group member is a device used for the traffic encryption process and is responsible for the actual encryption and decryption of data traffic. A group member is configured with IKE Phase 1 parameters and GC/KS information. Encryption policies are defined centrally on the GC/KS and downloaded to the group member at the time of registration. Based on these downloaded policies, the group member determines whether traffic needs to be encrypted or decrypted and what keys to use. The group members use the ESP protocol for securing transport data sent to other group members.

From a functionality point of view, a group member is similar to an IPsec gateway. However, the SAs in normal IPsec are handled per connection between both IPsec gateways and in GDOI, whereas in group VPN the SAs are provided by the GC/KS on a per group basis.

The group member registers with the key server to get the IPsec SA or SAs that are necessary to communicate with the group. The group member provides the group ID to the key server to get the respective policy and keys for this group. The group members re-register with the server before the current IPsec SAs expire as part of the rekeying process, so that there is no loss of traffic.

Group VPN Implementation Overview

• Enabling Group VPN

• Registering a Group Member

• Rekeying a Group Member

• Authenticating a Group Member

• Fragmenting Group VPN Traffic

• Encrypting Group VPN Traffic

• Decrypting Group VPN Traffic

• Configuring a Routing Instance for Group VPN

• Establishing Multiple Groups, Policies, and SAs

• Connecting with Multiple Cooperative GC/KS

• Changing a Group VPN Configuration

• Bypassing a Group VPN Configuration

• Supported GDOI IPsec Parameters

• Supported GDOI IKEv1 Parameters

• Applying Dynamic Policies

• Supporting TOS and DSCP

• Interoperability of Group Members

• Group VPN Limitations

Enabling Group VPN

• Configuring the Service Set

• Applying the Service Set

• Packet Steering

Configuring the Service Set

The group VPN is configured inside a service set using the ipsec-group-vpn statement at the [edit services service-set service-set-name] hierarchy level.

The following is a sample service set configuration:

Applying the Service Set

A service set is applied at the interface level.

The following is a sample service set application configuration:

Packet Steering

The interface-style service set configuration is used to steer traffic from the Packet Forwarding Engine to the PIC. Packets received on an interface with a service set pointing to the group VPN object are forwarded to the PIC by being injected into the corresponding service interface.

Registering a Group Member

The group member registration to the server starts when the ipsec-group-vpn statement is configured for a service set and the service interface is up. When the service interface goes down, all GSAs associated with this PIC are cleared, and no registration is triggered for these group VPNs until the PIC comes up.

Group member registration involves establishing IKE SA with the GC/KS followed by a groupkey-pull exchange to download the SAs and the traffic keys for the specified group identifier.

Rekeying a Group Member

Junos OS group VPN does not support server-to-member rekeying. If rekeying is done from the GC/KS, the key is ignored by the group member.

For group member rekeying, the group members re-register with the GC/KS at the end of the soft lifetime expiry. After rekeying, both the old key and the new key can be used for decryption. However, the new key is not used for encryption until 30 seconds of lifetime of the old key is remaining.

Taking as an example, the GC/KS is configured with a lifetime of 3600 seconds and is connected to one group member without retransmit. Based on the server configuration, the GC/KS generates a new key when 10 percent of the lifetime is remaining. The group member, however, re-registers with the GC/KS when 5 percent to 7 percent of the lifetime is remaining.

Figure 4 represents the rekeying process between the GC/KS and the group member.

Figure 4: Group Member Rekeying

Authenticating a Group Member

Junos OS does not provide Public Key Infrastructure (PKI) support for group VPNs, and as a result, pre-shared keys are used for group member authentication.

Fragmenting Group VPN Traffic

Because of the header preservation functionality and the usage of the underlying routing infrastructure, it is necessary to fragment the packets before encryption occurs (if it cannot be prevented).

Hence, pre-fragmentation is supported and is recommended for all deployments.

To avoid post-fragmentation, set the clear, set, and copy options for the DF bit in the group VPN configuration.

Based on this flag setting, the IPsec header has either the df-bit set to clear, set, or copy from the inner packet.

The following is a sample DF bit configuration:

Encrypting Group VPN Traffic

1. Packet received by the Packet Forwarding Engine is checked against a flow match. If a match is found, the packet is further processed and transmitted.
2. If a match is not found, a rule lookup is performed. If a match is found, a flow is created, and the packet is further processed and transmitted.
3. If the rule lookup fails, the packet is dropped.

Decrypting Group VPN Traffic

1. Packet received by the Packet Forwarding Engine undergoes a fragmentation check. If the packet is fragmented, it is assembled for further processing.
2. After packet assembling or if the packet is not fragmented, a zero source and destination IP is used in the 5-tuple decrypt flow lookup. If a match is found, the packet is further processed and transmitted.
3. If the decrypt flow lookup fails, the packet is checked against a security parameter index (SPI) flow with zero source and destination IP.
4. If the SPI flow lookup fails, the packet is dropped.
5. If an SPI flow match is found, a decrypt flow is created to avoid the SPI flow lookup for subsequent packets.

Configuring a Routing Instance for Group VPN

Routing instances are supported for both control and data traffic. To enable routing instance support on control plan traffic for a group member to reach the GC/KS in a given VRF routing instance, add the routing-instance statement at the [edit security group-vpn member ike gateway gateway-name local-address address] hierarchy level.

No additional CLI input is required to support a routing instance for data plane packets, because it is determined based on the media interface on which the service set is applied.

Establishing Multiple Groups, Policies, and SAs

Junos OS provides support for one group VPN per service set. However, multiple service sets can be created to support multiple groups in a routing instance. Multiple SAs can be configured per group. However, multiple policies for the same traffic key/SPI is not supported. If the server sends two policies for the same TEK, then they must be paired to be accepted; for instance, A-B and B-A, where A and B are IP addresses or subnets. If multiple unpaired policies for a given TEK are received, registration fails and a system log message is generated.

Connecting with Multiple Cooperative GC/KS

For a group member to work with a GC/KS in the cooperative mode, the configuration is extended to allow a maximum of four servers in the server list.

During rekeying, the group member tries to connect to the GC/KS. When the connection to the GC/KS fails, the group member tries to reconnect to the GC/KS. After three retries with an interval of 10 seconds, if the connection to the GC/KS is not restored, the group member tries to establish a connection with the next available server on the server list. This process is repeated until the group member connects to a GC/KS. During this time, the unexpired GDOI IPsec SAs on the group members are not cleaned up, so group VPN traffic is not affected. The time gap between rekeying and hard lifetime expiry provides sufficient time for the group members to connect to the next available server, in such cases.

Changing a Group VPN Configuration

Most group VPN configuration changes result in deleting existing IKE SA and GDOI SA and re-registration, which triggers both phase 1 and SA download with traffic keys.

Bypassing a Group VPN Configuration

The service filter needs to be configured on the interface on which the service set is applied if certain traffic like a routing protocol needs to bypass a group VPN. The packet matching service filter will not come to the PIC for service processing and is directly forwarded to the Routing Engine.

The following is a sample service set filter configuration:

Supported GDOI IPsec Parameters

Every GDOI group has a unique ID. It is used as a common base between GC/KS and the group member to communicate about GSAs and group keys.

During the registration process, the GC/KS sends Security Association Transport Encryption Keys (SATs) to the group members. All parameters regarding the whole group security policy are configured on the GC/KS. The SAT is used by the group members to protect the traffic exchanged among each other. Table 2 shows the parameters of the SAT.

Besides the cryptographic algorithms, the traffic, which should be encrypted by the group members, is part of the SAT policy (traffic selector).

The following statements can be used on a Juniper Networks group member. Thus, the addresses have to be specified under the IKE hierarchy level. The enumeration is also prioritized. Thus, in the following example configuration, KS1 is contacted before KS2.

The following is a sample GDOI IPsec parameters configuration:

Supported GDOI IKEv1 Parameters

The group members use only IKEv1 during the registration process in the group VPN environment. Table 3 provides an overview of the defined parameters of the IKEv1 SA.

The following is a sample IKEv1 configuration with the above-mentioned IKEv1 standards:

Applying Dynamic Policies

The input and output options under the ipsec-group-vpn statement specify if the dynamic policies received from the server are used when the interface on which the service set is applied is the incoming or outgoing interface. This provides flexibility to specify different rules in the incoming and outgoing directions.

Supporting TOS and DSCP

Type of service (TOS) and DiffServ Code Points (DSCP) bits are copied from the inner packet to the ESP packet.

Interoperability of Group Members

Cisco’s implementation of GDOI is called Group Encryption Transport (GET) VPN. While group VPN in Junos OS and Cisco's GET VPN are both based on RFC 6407, The Group Domain of Interpretation, there are some implementation differences that you need to be aware of when deploying GDOI in a networking environment that includes both Juniper Networks security and routing devices and Cisco routers. For more information, see the current Junos OS release notes.

• Junos OS provides minimal interoperability support with Cisco IOS GC/KS support.

• The MX Series group member is able to communicate with the SRX Series group member and Cisco group member.

• Junos OS does not provide support for group VPN interoperability with the SRX Series group VPN server.

• The unicast groupkey-push message does not work because the proprietary ACK is expected by the Cisco GC/KS following unicast push.

  As a workaround, the groupkey-pull is used for rekey.

• The deny policy is used on a Cisco server to add an exception to the group policy.

  As a workaround, an exception to the group policy can be added by configuring firewall rules on an MX Series group member. Also, Junos OS group members can work with the deny policy by not failing the negotiation and simply ignoring the contents. This allows system administrators to easily manage networks where both Cisco group members and Junos OS group members co-exist.

Group VPN Limitations

• GDOI groupkey-push exchange. Hence, both unicast and multicast push are not supported.

• Multicast traffic

• Post-fragmentation of packets

• GDOI SNMP MIBs

• Anti-replay

• GAP payload

• Protocol and port in the policies sent by the server. The group member honors only the IP address/subnet specified in the policy.

• Multiple unpaired policies for the same traffic key/SPI

• Overlapping of both local and remote IP across routing instances in an IKE gateway configuration

• Overlapping group VPN policies that can result in mismatched SAs

• IPv6 for control and data traffic

• Co-existence of IPsec and group VPN on the same service set

• Co-existence of services like NAT and ALG on the same service set. NAT and group VPN can co-exist on different service sets. However, they cannot co-exist on the same service set.

• Site To Site (S2S) VPN and Dynamic End Point (DEP) VPN can co-exist with group VPN on different service sets. However, they cannot co-exist on the same service set.

• Multiple groups on same service set

• Group member support with SRX GC/KS

• Logical Key Hierarchy (LKH)

• Graceful restart

• High availability

• Unified ISSU

• Private key IPsec (PKI) support for authentication

• Aggregated multiservices (AMS) interface and load balancing support

• Multiple groups per service set

• Same gateway for multiple groups, wherein the same local and remote address pair cannot be used for multiple groups.