Group VPNv2 Overview

Understanding Group VPNv2

Group VPN is a trusted group to eliminate point-to-point tunnels and their associated overlay routing. All group members share a common security association (SA), known as a group SA (GSA). The GSA enables group members to decrypt traffic that was encrypted by any other group member. Starting in Junos OS Release 18.2R1, we confirm the Group VPN redundancy with service redundancy protocol [SRD] running on MX routers. MX routers with redundancy between them acts as Group VPN members. For more details on service redundancy protocol see Service Redundancy Daemon Overview.

Starting in Junos OS Release 15.1, Junos OS supports Group VPNv2. Group VPNv2 is a 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 unicast traffic over a private WAN that originates on or flows through a router.

Group VPNv2 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. This enables group members to decrypt traffic that was encrypted by any other group member.

Group VPNv2 provides the following advantages:

• 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.

• Reduces the number of endpoint changes that need to be made due to group member change or policy change.

• 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.

• Allows encryption and decryption of traffic among all group members defined in the group policy.

• 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 traffic replication, avoiding packet replication at each individual peer site.

Group VPNv2 and Standard IPsec VPN

Group VPNv2 is built on standards-based technologies that integrate routing and encryption together in the network. An IPsec security 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 end points. Group VPNv2 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 SA) with authenticated group members, key distribution and management are greatly simplified.

Group VPNv2 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, the tunnel endpoint addresses are used as a new packet source and destination. The packet is then routed over the IP infrastructure, using the encrypting end point source IP address and the decrypting end point destination IP address. In the case of Group VPN, IPsec-protected data packets preserve the original source and destination addresses of the host in the outer IP header in order to preserve the IP address. This is known as tunnel header preservation. The biggest advantages of tunnel header preservation is the ability to route encrypted packets using the underlying network routing infrastructure.

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 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.

GDOI introduces two different encryption keys:

• 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 (SA TEK).

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.

The group SAs and key management are handled through two types of GDOI exchanges:

• 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 group SAs 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 initiated by the GC/KS to all registered members of the group. Table 2 shows the payloads that the MX Series group member expects to receive in groupkey-push messages.

  Table 2: groupkey-push Message Payloads

  Payload	Description
  group associated policy (GAP)	A GAP payload allows for the distribution of group-wide policy, such as instructions as to when to activate and deactivate SAs. This payload contains values for activation time delay (ATD) and deactivation time delay (DTD) for the traffic encryption key (TEK) as well as IP-Delivery Delayed Detection Protocol window type and window size for the IPsec traffic.
  Security Association Transport Encryption Key (SA TEK)	Traffic selectors.
  Security Association Key Encryption Key (SAK) (Optional)	The security association (SA) for the key encryption key (KEK). Also known as SA KEK. Note: groupkey-push messages that do not include the optional payloads are still valid messages.
  traffic encryption key (TEK) (Optional)	Key for encrypting the data traffic between group members.
  key encryption key (KEK) (Optional)	Used to protect the TEK.

  The groupkey-push 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.

In some cases, the GC/KS may want to receive group key push acknowledgment messages from group members. The push acknowledgment messages from group members confirms that the member received the message and has taken action on their policy. The GC/KS can also use the acknowledgment to determine which group members are receiving the current group policy and which group members are no longer participating in the group. Starting in Junos OS 19.2R1, Junos OS sends an acknowledgment message with SHA-256 checksum when it receives a groupkey push message with a standard KEK_ACK_REQUESTED value of 9 in the SA KEK payload as defined in RFC 8263 or a KEK_ACK_REQUESTED value of 129 that is used is older key servers.

GDOI Protocol and Group VPNv2

Group VPNv2 is the name of the security technology implemented on the MX5, MX10, MX40, MX240, MX480, MX960 routers from Juniper Networks. Group VPNv2 uses the GDOI protocol (RFC 6407) as a base, in addition to other functionalities.

Group VPNv2 technology is based on the GDOI protocol to handle the most important functionality. This protocol is specified in RFC 6407 and defines an ISAKMP Domain of Interpretation (DOI) to manage group SAs 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 group SAs and group keys are centralized and performed by the GC/KS. Figure 2 provides a brief overview of the Group VPNv2 functionality using GDOI.

Figure 2: Group VPNv2 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 group SAs 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 (SA TEK), as well as the information to successfully decrypt the rekeying messages (SAK). The GC/KS sends out rekeying messages before either the SA TEK or SAK lifetime expires. It is also possible to send an SA TEK 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 VPNv2 Traffic

Group VPNv2 traffic includes:

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

• Data-plane-traffic—Traffic between the group members in the Group VPNv2 deployment with the ESP protocol only which is already known from IPsec.

Group Security Association

Unlike traditional IPsec encryption solutions, Group VPN uses the concept of group security association. A group SA is similar to an SA in terms of functionality. Group SAs 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 group SA. With a common encryption policy and a shared group SA, there is no need to negotiate IPsec between group members. This reduces the resource load on the group members. Traditional IPsec scalability issues (number of tunnels and associated SAs) do 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 VPNv2 control plane. It is responsible for creation and distribution of group SAs 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.

Group Member

A group member is an IPsec endpoint 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 successful registration. Each group member then determines whether incoming and outgoing traffic should be decrypted or encrypted (using its SA) based on its group membership.

From a functionality point of view, a group member is similar to an IPsec gateway. However, the SAs in normal IPsec exist between two IPsec gateways. In GDOI, the group member registers with the GC/KS in order to participate in the Group VPN. During registration, the group member provides the group ID to the GC/KS to get the respective policies, SAs, and keys needed for this group. Rekeying is accomplished by the group members through the groupkey-pull method (re-registration) or by the GC/KS through the groupkey-push method.

Anti-Replay Protection for Group VPNv2 Traffic

Since Group VPN communication is essentially any-to-any communication over the same shared security association, the use of sequence numbers for anti-replay protection does not work. Because of this, Junos OS supports an IETF draft specification for a time-based anti-replay mechanism, draft-weis-delay-detection-01. It is available at http://tools.ietf.org/html/draft-weis-delay-detection-01 .

To implement this feature, MX Series member routers make use of a new IP Delivery Delay Detection Protocol time-stamp header within the packet. See Implementing IP Delivery Delay Detection Protocol (Time-Based Anti-Replay Protection) for details.

Partial Fail-Open on MX Series Member Routers

Group members in a Group VPN rely on the GC/KS to generate keying material for the shared SA. Therefore, connectivity between the group members and GC/KSs is required to initially protect traffic and to continually protect traffic over rekey events. In the event of communication failure between the group member and the GC/KS, the default behavior of the group members is to stop forwarding traffic. This is known as fail-closed.

A nondefault configuration option is available to permit some specifically defined traffic to flow through the group member without being encrypted until such time as the member is able to contact the GC/KS and retrieve the active SA. This is known as partial fail-open.

The partial fail-open feature requires a policy configuration option that creates a rule on the applicable MX Series group member for a particular Group VPNv2 defined by source and destination addresses. This fail-open rule is active only when group SA is in disabled state because of connectivity failure with the key server. Traffic that would normally pass through the Group VPN but does not match the fail-open rule is dropped. More than one fail-open rule can be defined for the Group VPN object. If no fail-open rules are configured, then the fail-open feature is disabled.

Enabling Group VPNv2

A service set is used to enable Group VPNv2 on a particular interface on applicable MX Series routers.

[edit services]
service-set service-set-name {
    interface-service {
        service-interface service-interface-name;
    }
}
ipsec-group-vpn vpn-name;

[edit interfaces]
interface-name {
    unit 0 {
        family inet {
            service {
                input {
                    service-set service-set-name;
                }
                output {
                    service-set service-set-name;
                }
            }
            address 10.0.30.2/30;
        }
    }
}

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 group SAs associated with this interface are cleared, and no registration is triggered for these Group VPNs until the interface 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 (groupkey-push Method)

The GC/KS will send out a unicast groupkey-push message to registered group members in order to:

• Send new key encryption keys (KEKs) or traffic encryption keys (TEKs).

  The push messages can contain all or only some of the payload elements shown in Table 2. When the GAP payload contains both old SAs and new replacement SAs, the group member router will apply the ATD and DTD values as a normal rekey by means of push. If there is no ATD value in the update, the member router installs the new SAs immediately. If there is no DTD value, the old SAs will remain in place until their expiration.

• Update group associated policy (GAP) for an existing SA.

  A GC/KS can send a unicast push message to update the configuration to group members at any time. The GAP payload can include configuration changes to the IP Delivery Delay Detection Protocol, encryption algorithm, lifetime, and so on. The updated configuration is either applied immediately or with a delay. ATD and DTD values are used to achieve the timing for the activation of the new TEK and deletion of the existing TEK, respectively. If the existing TEK lifetime has to be reduced, then the DTD value is set accordingly in the push message. The new TEK in the push message is activated based on the ATD value in the payload.

• Send delete key notifications for TEK or KEK.

  The GC/KS can send the optional delete notification payload in the push message for deleting keys and SAs on the member. The push message contains the protocol ID that indicates whether the delete notification is for TEK or KEK. The group member router deletes the key based on the group ID and SPI value contained in the payload. Deleting a specific TEK or KEK can be done with a delay value specified in the DTD attribute. If the delay value is 0, and the payload contains a specific SPI, then the matching TEK or KEK is deleted immediately. If all the TEKs or KEKs (or both) need to be deleted in the group, then the SPI value is set to 0 for the corresponding protocol ID in the payload.

• Remove a member router from the Group VPN in Group VPNv2.

  The push messages are used to allow the GC/KS to delete members from the Group VPN. In one case, the GC/KS sends a rekey message with only the old SAs and a smaller DTD value. The group member router installs the new, smaller DTD value. Since it did not receive new SA keys, the member router tries to re-register using the groupkey-pull method. This re-registration attempt is rejected by the GC/KS, thus deleting the member from the Group VPN. In the second case, the GC/KS sends a delete payload for the SPI of the old SA. The group member router deletes the SA immediately and attempts to re-register using the groupkey-pull method. This re-registration attempt is rejected by the GC/KS, thus deleting the member from the Group VPN.

Registered MX Series group members send a unicast PUSH ACK message back to the GC/KS to acknowledge the receipt of the original push message.

Rekeying a Group Member (groupkey-pull Method)

For group member rekeying, using the groupkey-pull method, the group members typically re-register with the GC/KS when there is between 7 percent and 5 percent remaining in the existing TEK or KEK soft lifetime. If the existing IKE SA is available, it is used in the pull message. After the GC/KS responds with a new key, 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. If the existing IKE SA is not available, the pull message results in new IKE negotiations between the group member and the GC/KS.

Upon receiving the pull message regarding a specific Group VPN from the group member, the GC/KS responds with all the TEKs and the KEK for that group.

If any existing SA is not included in the response from the GC/KS, then the missing SAs are deleted by the group member.

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 VPN in Group VPNv2. As a result, pre-shared keys are used for group member authentication.

Fragmenting Group VPNv2 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 VPNv2 configuration.

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

[edit]
security {
    group-vpn {
        member {
            ipsec {
                vpn group-vpn-name {
                    df-bit clear;
                }
            }
        }
    }
}

Encrypting Group VPNv2 Traffic

Group members encrypt traffic based on the group SAs and keys provided by the GC/KS. The Group VPNv2 encryption path is as follows:

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 VPNv2 Traffic

After registration is successful and Group VPN SAs are installed, an ESP session is created. Group VPNv2 creates the ESP session with a zero source and destination IP. Because the ESP session is already created at SA installation, packets are expected to match the existing ESP session.

The Group VPNv2 decryption path is as follows:

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 an 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 VPNv2

Routing instances are supported for both control and data traffic. To enable routing instance support on control plane 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 is required to support a routing instance for data-plane packets, as 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 in Group VPNv2. 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/KSs

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 when using the groupkey-pull method, 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 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.

Implementing IP Delivery Delay Detection Protocol (Time-Based Anti-Replay Protection)

There is no configuration needed to implement the IP Delivery Delay Detection Protocol. MX Series group members get the replay window size to use as a part of the GAP payload in push or pull messages from the key server. If the received window size is 0, time-based anti-replay protection is disabled.

If IP Delivery Delay Detection Protocol is enabled, the sender adds its current timestamp and encrypts the packet. The receiver decrypts the packet and compares its current time with the timestamp in the packet. Packets that fall outside of the window size are dropped. Because of this, all group members should have their clocks synchronized using Network Time Protocol (NTP).

IP Delivery Delay Detection Protocol times are measured in seconds. See IP Delivery Delay Detection Protocol-draft-weis-delay-detection-01 for more information.

Changing Group VPNv2 Configuration

Most Group VPNv2 configuration changes result in deleting both existing SAs and re-registration. This triggers both phase 1 and SA download with new traffic keys.

Bypassing Group VPNv2 Configuration

If certain traffic like a routing protocol needs to bypass a Group VPN in Group VPNv2, a service filter needs to be configured on the interface on which the service set is applied. Packets matching the service filter do not come to the PIC for service processing and are directly forwarded to the Routing Engine.

[edit interfaces]
interface-name {
    unit 0 {
        family inet {
            service {
                input {
                    service-set service-set-name service-filter filter-name;
                }
                output {
                    service-set service-set-name service-filter filter-name;
                }
            }
        }
    }
}

Implementing Partial Fail-open on MX Series Member Routers

By default, packets are dropped if a group member router is unable to get SAs from the GC/KS due to loss of connectivity. If you want to allow some traffic to pass unencrypted in the event of a communication failure between the group member and the GC/KS, you must configure a fail-open rule at the [edit security group-vpn member ipsec vpn vpn-name] hierarchy level.

Fail-open rules will be applied to the traffic only in the event of loss of server connectivity. Fail-open rules will be deactivated once connectivity is restored and keys are received from the GC/KS.

[edit security group-vpn member ipsec vpn vpn-name]
fail-open {
    rule rule-name{
        source-address source-ip-address
            destination-address destination-ip-address}
        }
    }

A maximum of 10 fail-open rules can be configured for any given group.

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 group SAs and group keys.

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

Besides the cryptographic algorithms, the traffic, which should be encrypted by the group members, is part of the SA TEK 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.

[edit security]
group-vpn {
    member {
        ike {
            gateway gateway-name {
                ike-policy policy-name;
                server-address <IP_KS1> <IP_KS2> <IP_KS3> <IP_KS4>;
                local-address <IP_GM> routing-instance routing-instance-name;
            }
        }
        ipsec {
            vpn vpn-group-name {
                ike-gateway gateway-name;
                fail-open {
                    rule rule-name {
                    source-address 198.51.100.1/24 
                    destination-address 192.0.2.1/24 
                    }
                }
                group group-ID;
                match-direction output;
            }
        }
    }
}

Supported GDOI IKEv1 Parameters

The above-mentioned IKEv1 standards are configured as follows:

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 VPNv2 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.

Group VPNv2 interoperability is as follows:

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

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

  Table 5: Group VPNv2 Interoperability

  Group Member	SRX Group Member	MX Group VPNv2 Member	Cisco Group Member	SRX GC	SRX KS	Cisco GC/KS
  MX Group VPNv2 Member	No	Yes	Yes	No	Yes	Yes
  SRX Group Member	Yes	No	No	Yes	Yes	Yes

Junos OS does not support the deny policy used on a Cisco GC/SK server to add an exception to the group policy. As a workaround, this can be done 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 VPNv2 Limitations

Junos OS Group VPNv2 does not provide support for the following:

• Multicast push messages

• Multicast traffic

• GDOI SNMP MIBs

• 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 VPNv2 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 Series GC/KS

• Group member support with SRX Series group member

• Logical Key Hierarchy (LKH)

• Graceful restart

• High availability

• Unified ISSU

• PKI support for authentication