Group Domain Virtual Private Network (group domain VPN) provides a point-to-multipoint tunnel-less VPN solution. It is mainly used to protect multicast traffic.

Group domain VPN uses a group-based IPsec model. Members in a group use a common IPsec policy, which includes security protocols, algorithms, and keys.

Benefits of group domain VPN

Compared with IPsec VPN, group domain VPN has the following features:

· Better network scalability—Conventional IPsec VPNs require that each pair of communication peers establishes independent IKE SAs and IPsec SAs. In group domain VPNs, members in a group use the same pair of IPsec SAs, simplifying network management and improving scalability.

· Without routing re-deployment—Conventional IPsec VPNs establish connections over tunnels that encapsulate new IP headers for packets. You must reconfigure routes to forward tunneled packets. In group domain VPNs, the outer IP header is the same as the inner IP header. You do not need to change the existing route configuration.

· Better QoS—In conventional IPsec VPNs, you must reconfigure QoS policies because a new IP header is added before the original IP header. Group domain VPN keeps the original IP header, simplifying QoS deployment.

· Higher multicast efficiency—Conventional IPsec VPNs use point-to-point tunnels. A tunnel-end device must send an encrypted multicast packet to each tunnel peer in the multicast group. Group domain VPNs use tunnel-less connections. A tunnel-end device sends only one encrypted packet to all members in a group.

· Any-to-any connectivity—In a group domain VPN, all members in a group share the same pair of IPsec SAs. Any two members in the same group can encrypt and de-encrypt packets of each other, implementing any-to-any connectivity.

Group domain VPN structure

As shown in Figure 1, a typical group domain VPN contains a key server (KS) and group members (GMs).

Figure 1 Group domain VPN structure

KS

The KS maintains security policies for groups, and creates and maintains key information. It responds to registration requests from GMs and sends rekey messages to GMs.

After a GM registers with the KS, the KS sends the IPsec policy and keys to the GM. The keys are periodically updated. Before the key lifetime expires, the KS notifies all GMs to update keys by sending rekey messages.

Rekey messages include the following types:

· Traffic encryption key—TEK messages are shared by all GMs in a group and used to encrypt traffic between GMs.

· Key encryption key—KEK messages are shared by all GMs in a group and used to encrypt rekey messages sent from the KS to GMs.

You can configure multiple KSs to achieve high availability and load sharing.

GM

GMs are a group of network devices that use the same IPsec policy to communicate with each other. A GM provides a group ID during registration with the KS. The KS assigns the corresponding IPsec policy and keys to the GM according to the group ID.

Group domain VPN establishment

Group domain VPN establishment includes the following phases:

· Registration—GMs register with the KS.

· Data protection—GMs protect data.

· Rekey—The KS updates keys.

Registration

After you apply an IPsec policy for group domain VPN to an interface on a GM, the GM registers with the KS. The registration includes two negotiations: IKE negotiation (phase 1) and Group Domain of Interpretation (GDOI) negotiation (phase 2).

· IKE negotiation—The GM and the KS negotiate keys, perform mutual identity authentication, and if the authentication succeeds, establish an IKE SA used to protect GDOI negotiation.

· GDOI negotiation—The GM obtains the IPsec policy from the KS by using the GDOI protocol. For more information, see GROUPKEY-PULL in RFC 3547.

As shown in Figure 2, a registration process is as follows:

1. The GM and the KS perform IKE negotiation.

2. The GM sends its group ID to the KS.

3. The KS sends an IPsec policy to the GM according to the group ID.

The IPsec policy includes information about the protected data flows, encryption algorithms, authentication algorithms, and encapsulation modes.

4. The GM verifies the IPsec policy. If the IPsec policy settings are acceptable, for example, the security protocols and encryption algorithms are supported, the GM sends an acknowledge message to the KS.

5. After the KS receives the acknowledge message, it sends KEK and TEK messages to the GM.

The GM uses the obtained IPsec policy and keys to encrypt and de-encrypt data.

Figure 2 Registration process

A GM starts a GDOI registration timer when it initiates a registration to the KS. If the GM does not successfully register with the KS before the timer expires, the current registration fails and the GM re-registers to the KS. This timer is not configurable. After the registration succeeds, the GM updates the timer according to the received rekey SA and IPsec SA lifetime.

Data protection

After registration, a GM uses the IPsec SAs to protect data that matches the IPsec policy. GMs can protect unicast data and multicast data.

Group domain VPN supports two encapsulation modes: tunnel mode and transport mode. The KS determines the encapsulation mode to be used and assigns it to the GMs.

· Tunnel mode—Adds a security protocol header before the original IP packet, and then adds an IP header (the same as the original IP header) before the security protocol header. The security protocol header can be an AH or ESP header. Group domain VPN does not support AH. Figure 3 shows the format of an ESP-encapsulated IP packet.

Figure 3 Tunnel mode encapsulation of group domain VPN

· Transport mode—Inserts a security protocol header between the original IP header and the payload data. No change is made to the original IP header.

Group domain VPN also supports protection of MPLS L3VPN data. For more information about MPLS L3VPN, see MPLS Configuration Guide.

Rekey

If rekey parameters are configured on the KS, the KS periodically unicasts or multicasts (the default) rekey messages to registered GMs to update their IPsec SAs or rekey SAs. The rekey messages are protected by the current rekey SA on the KS. GMs authenticate the rekey messages by using the public key received from the KS during registration. If a GM does not receive any rekey messages before its IPsec SA or rekey SA expires, the GM re-registers to the KS. For more information about rekey messages, see GROUPKEY-PUSH in RFC 3547.

GDOI IPsec policy

A GDOI IPsec policy is a set of GDOI IPsec policy entries that have the same name but different sequence numbers. Each GDOI IPsec policy has a GDOI GM group specified. GMs use GDOI IPsec policies to implement registration and data protection.

A GM obtains information used for registration (such as the KS address and group ID) from the GDOI GM group specified for the GDOI IPsec policy.

A GM identifies the packets to be forwarded, encrypted, or decrypted by using the following ACLs:

· Downloaded ACL—ACL downloaded from the KS.

· Local ACL—ACL specified in the GDOI IPsec policy.

Identifying packets by using the downloaded ACL

After a GM successfully registers with a KS, the KS assigns an IPsec policy that contains an ACL to the GM. The GM uses this assigned ACL (called downloaded ACL) to determine packet encryption as follows:

· For outgoing packets, the GM encrypts the packets matching a permit rule of the downloaded ACL and forwards the encrypted packets. The GM forwards the packets matching a deny rule in plain text.

· For incoming packets in cipher text, the GM decrypts the packets matching a permit rule, and forwards the packets matching a deny rule in cipher text.

· For incoming packets in plain text, the GM discards the packets matching a permit rule, and forwards the packets matching a deny rule in plain text.

· The GM forwards the packets that do not match any rule in plain text.

Identifying packets by using the local ACL

Packets matching a permit rule of the local ACL are discarded, and packets matching a deny rule are forwarded in plain text.

The local ACL is optional for a GDOI IPsec policy. If both a local ACL and a downloaded ACL exist on a GM, the GM uses the ACLs as follows:

· During packet encryption, the GM first uses the local ACL to match packets. If a packet does not match the local ACL, the GM uses the downloaded ACL to match the packet. Packets that fail to match both ACLs are forwarded in plain text.

· During packet decryption:

¡ For packets in cipher text, the GM first uses the downloaded ACL to match packets. If a packet does not match the downloaded ACL, the GM uses the local ACL to match the packet.

¡ For packets in plain text, the GM first uses the local ACL to match packets. If a packet does not match the local ACL, the GM uses the downloaded ACL.

Packets that fail to match both the local and downloaded ACLs are forwarded in plain text.

Protocols and standards

· RFC 2408, Internet Security Association and Key Management Protocol (ISAKMP)

· RFC 3547, The Group Domain of Interpretation(GDOI)

· RFC 3740, The Multicast Group Security Architecture

· RFC 5374, Multicast Extensions to the Security Architecture for the Internet Protocol

· RFC 6407, The Group Domain of Interpretation(GDOI)

Restrictions: Hardware compatibility with group domain VPN

Hardware	Group domain VPN compatibility
MSR810, MSR810-W, MSR810-W-DB, MSR810-LM, MSR810-W-LM, MSR810-10-PoE, MSR810-LM-HK, MSR810-W-LM-HK, MSR810-LM-CNDE-SJK, MSR810-CNDE-SJK	Yes
MSR810-LMS, MSR810-LUS	No
MSR810-LMS-EA, MSR810-LME	Yes
MSR2600-6-X1, MSR2600-10-X1	Yes
MSR 2630	Yes
MSR3600-28, MSR3600-51	Yes
MSR3600-28-SI, MSR3600-51-SI	No
MSR3600-28-X1, MSR3600-28-X1-DP, MSR3600-51-X1, MSR3600-51-X1-DP	Yes
MSR3610-I-DP, MSR3610-IE-DP, MSR3610-IE-ES, MSR3610-IE-EAD, MSR3610-I-IG, MSR3610-IE-IG	Yes
MSR3610-X1, MSR3610-X1-DP, MSR3610-X1-DC, MSR3610-X1-DP-DC	Yes
MSR 3610, MSR 3620, MSR 3620-DP, MSR 3640, MSR 3660	Yes
MSR3610-G, MSR3620-G	Yes

‌

Hardware	Group domain VPN compatibility
MSR810-W-WiNet, MSR810-LM-WiNet	Yes
MSR830-4LM-WiNet	Yes
MSR830-5BEI-WiNet, MSR830-6EI-WiNet, MSR830-10BEI-WiNet	Yes
MSR830-6BHI-WiNet, MSR830-10BHI-WiNet	Yes
MSR2600-6-WiNet, MSR2600-10-X1-WiNet	Yes
MSR2630-WiNet	Yes
MSR3600-28-WiNet	Yes
MSR3610-X1-WiNet	Yes
MSR3610-WiNet, MSR3620-10-WiNet, MSR3620-DP-WiNet, MSR3620-WiNet, MSR3660-WiNet	Yes

‌

Hardware	Group domain VPN compatibility
MSR2630-XS	Yes
MSR3600-28-XS	Yes
MSR3610-XS	Yes
MSR3620-XS	Yes
MSR3610-I-XS	Yes
MSR3610-IE-XS	Yes

‌

Hardware	Group domain VPN compatibility
MSR810-LM-GL	Yes
MSR810-W-LM-GL	Yes
MSR830-6EI-GL	Yes
MSR830-10EI-GL	Yes
MSR830-6HI-GL	Yes
MSR830-10HI-GL	Yes
MSR2600-6-X1-GL	Yes
MSR3600-28-SI-GL	No

‌

FIPS compliance

The device supports the FIPS mode that complies with NIST FIPS 140-2 requirements. Support for features, commands, and parameters might differ in FIPS mode (see "Configuring FIPS") and non-FIPS mode.

Restrictions and guidelines: Group domain VPN configuration

The device can act only as a GM and cannot act as a KS.

For a successful phase-1 IKE negotiation, make sure the IKE settings on the KSs and GMs match. The IKE settings mainly include an IKE proposal and an IKE profile for phase-1 IKE negotiation. For information about IKE configuration, see "Configuring IKE."

GDOI GM tasks at a glance

To configure a GDOI GM, perform the following tasks:

1. Configuring a GDOI GM group

2. Configuring a GDOI IPsec policy

3. Applying a GDOI IPsec policy to an interface

Configuring a GDOI GM group

About this task

A GDOI GM group includes the following information that the GM uses to register with a KS:

· Group name—Identifies the GDOI GM group on the GM. It is used only for local management and reference.

· Group ID—Identifies the GDOI GM group in the group domain VPN. The KS uses the group ID to identify the GDOI GM group that the requesting GM wants to join.

· KS address—IP address of a KS with which the GM registers. A GDOI GM group can have a maximum of 16 KS addresses. The GM first sends a registration request to the first-specified KS. If the registration fails before the registration timer expires, the GM registers with other KSs one by one in the order they are configured until the registration succeeds. If all registration attempts fail, the GM repeats the registration process.

· Registration interface—The GM uses the registration interface to send packets to the KS. By default, the registration interface of a GM is the output interface of the route from the GM to the KS. You can specify the interface to which the GDOI IPsec policy for the GDOI GM group is applied as the registration interface. You can also specify another interface (a physical interface or a logical interface) as the registration interface to process registration packets and IPsec packets on different interfaces.

· Supported KEK encryption algorithms—During GM registration, the GM terminates the negotiation with the KS if the KEK encryption algorithm sent by the KS is not supported by the GM, and the registration fails. During rekey, the GM discards rekey messages received from the KS if the KEK encryption algorithm sent by the KS is not supported by the GM.

· Supported IPsec transform sets—During GM registration, the GM terminates the negotiation with the KS if the IPsec transform set sent by the KS is not supported by the GM, and the registration fails. During rekey, the GM discards rekey messages received from the KS if the IPsec transform set sent by the KS is not supported by the GM.

Restrictions and guidelines

You can configure multiple GDOI GM groups on a GM.

Different GDOI GM groups cannot have both the same group ID and the same KS address.

Procedure

1. Enter system view.

system-view

2. Create a GDOI GM group and enter GDOI GM group view.

gdoi gm group [ ipv6 ] group-name

3. Configure the GDOI GM group ID.

identity { address ip-address | number number }

By default, no GDOI GM group ID is configured.

You can configure only one type of ID (either an IP address or a number) for a GDOI GM group. A newly configured group ID overwrites the previous one.

4. Specify a KS address.

server address host [ vrf vrf-name ]

By default, no KS address is specified.

5. (Optional.) Specify a registration interface for the GM.

client registration interface interface-type interface-number

By default, a GM uses the output interface of the route to the KS as the registration interface.

6. Specify KEK encryption algorithms supported by the GM.

In non-FIPS mode:

client rekey encryption { des-cbc | 3des-cbc | aes-cbc-128 | aes-cbc-192 | aes-cbc-256 } *

By default, a GM supports DES-CBC, 3DES-CBC, AES-CBC-128, AES-CBC-192, and AES-CBC-256 in non-FIPS mode.

In FIPS mode:

client rekey encryption { aes-cbc-128 | aes-cbc-192 | aes-cbc-256 } *

By default, a GM supports AES-CBC-128, AES-CBC-192, and AES-CBC-256 in FIPS mode.

7. Specify IPsec transform sets supported by the GM.

client transform-sets transform-set-name&<1-6>

By default, a GM supports the following IPsec transform settings:

¡ The ESP security protocol.

¡ The tunnel and transport encapsulation modes.

¡ The DES-CBC, 3DES-CBC, AES-CBC-128, AES-CBC-192, and AES-CBC-256 encryption algorithms.

¡ The MD5 and SHA1 authentication algorithms.

Configuring a GDOI IPsec policy

1. Enter system view.

system-view

2. Create a GDOI IPsec policy entry and enter GDOI IPsec policy view.

ipsec { ipv6-policy | policy } policy-name seq-number gdoi

In the same GDOI IPsec policy, a GDOI IPsec policy entry with a smaller sequence number has a higher priority.

For more information about this command, see Security Command Reference.

3. Specify a GDOI GM group for the GDOI IPsec policy.

group group-name

By default, no GDOI GM group is specified for a GDOI IPsec policy.

You can specify only one GDOI GM group for a GDOI IPsec policy. The specified GM group must already exist and use the same IP protocol version (IPv4 or IPv6) as that used by the GDOI IPsec policy.

4. Specify an ACL for the GDOI IPsec policy.

security acl [ ipv6 ] acl-number

By default, no ACL is specified for a GDOI IPsec policy.

Typically, there is no need to specify an ACL unless you need to filter traffic.

For more information about this command, see Security Command Reference.

Applying a GDOI IPsec policy to an interface

About this task

After you apply a GDOI IPsec policy to an interface, the interface performs the following operations:

· Uses the group ID and KS addresses in the GDOI GM group specified for the policy to perform registration.

· Uses the local ACL and the downloaded ACL for packet filtering and encryption.

Procedure

1. Enter system view.

system-view

2. Enter interface view.

interface interface-type interface-number

3. Apply a GDOI IPsec policy to the interface.

ipsec apply { ipv6-policy | policy } policy-name

By default, no GDOI IPsec policy is applied to an interface.

For more information about this command, see Security Command Reference.

Display and maintenance commands for GDOI GM

Execute display commands in any view, and execute reset commands in user view.

Task	Command
Display GDOI GM group information.	display gdoi gm [ group group-name ]
Display IPsec SA information obtained by GMs.	display gdoi gm ipsec sa [ group group-name ]
Display brief information about GMs.	display gdoi gm members [ group group-name ]
Display ACL information for GMs.	display gdoi gm acl [ download \| local ] [ group group-name ]
Display rekey information for GMs.	display gdoi gm rekey [ verbose ] [ group group-name ]
Display public key information received by GMs.	display gdoi gm pubkey [ group group-name ]
Display GDOI IPsec policy information.	display ipsec policy [ policy-name [ seq-number ] ]
Clear GDOI information for GMs and trigger the GMs to re-register with the KS.	reset gdoi gm [ group group-name ]

For more information about the display ipsec policy command, see Security Command Reference.

Group domain VPN configuration examples

Example: Configuring a group domain VPN

Network configuration

As shown in Figure 4, set up a group domain VPN on the network to protect traffic between subnets as follows:

· Add GM 1, GM 2, and GM 3 to the GDOI GM group 12345, and configure them to register with the KS that manages the group.

· Use the IPsec ESP security protocol, AES-CBC-128 encryption algorithm, and SHA1 authentication algorithm to protect the data.

· Configure IPsec to protect traffic between subnets 10.1.1.0/24 and 10.1.2.0/24, and between subnets 10.1.1.0/24 and 10.1.3.0/24.

· Use pre-shared key authentication for IKE negotiation between the KS and the GMs.

· Configure the KS to multicast rekey messages to the GMs.

· Configure KS 1 and KS 2 to back up each other. KS 1 and KS 2 use pre-shared key authentication for IKE negotiation.

Figure 4 Network diagram

‌

Prerequisites and guidelines

Before configuration, make sure each GM (GM 1, GM 2, and GM 3) and each KS can reach each other, and the two KSs can reach each other.

Make sure the multicast packets between the GMs and the multicast rekey messages between the KS and GMs can be forwarded correctly.

By default, the KS multicasts rekey messages. To unicast rekey messages, use the rekey transport unicast command.

KS 1 and KS 2 in this example are Comware 5 devices.

Procedure

1. Configure KS 1:

# Configure IP addresses for interfaces. (Details not shown.)

# Create IKE proposal 1.

<KS1> system-view

[KS1] ike proposal 1

# Specify the encryption algorithm as AES-CBC-128 for the IKE proposal.

[KS1-ike-proposal-1] encryption-algorithm aes-cbc-128

# Specify the authentication algorithm as SHA1 for the IKE proposal.

[KS1-ike-proposal-1] authentication-algorithm sha

# Specify DH group 2 for the IKE proposal.

[KS1-ike-proposal-1] dh group2

[KS1-ike-proposal-1] quit

# Create IKE peer toks2 for IKE negotiation with KS 2.

[KS1] ike peer toks2

# Specify IKE proposal 1 for the IKE peer.

[KS1-ike-peer-toks2] proposal 1

# Configure the pre-shared key as tempkey1 in plain text.

[KS1-ike-peer-toks2] pre-shared-key simple tempkey1

# Specify the IP address of the IKE peer as 200.2.2.200.

[KS1-ike-peer-toks2] remote-address 200.2.2.200

[KS1-ike-peer-toks2] quit

# Create IKE peer togm for IKE negotiation with GMs.

[KS1] ike peer togm

# Specify IKE proposal 1 for the IKE peer.

[KS1-ike-peer-togm] proposal 1

# Configure the pre-shared key as tempkey1 in plain text.

[KS1-ike-peer-togm] pre-shared-key simple tempkey1

[KS1-ike-peer-togm] quit

# Create an IPsec transform set named fortek.

[KS1] ipsec transform-set fortek

# Specify the security protocol as ESP for the IPsec transform set.

[KS1-ipsec-transform-set-fortek] transform esp

# Specify the encryption algorithm as AES-CBC-128 for the IPsec transform set.

[KS1-ipsec-transform-set-fortek] esp encryption-algorithm aes-cbc-128

# Specify the authentication algorithm as SHA1 for the IPsec transform set.

[KS1-ipsec-transform-set-fortek] esp authentication-algorithm sha1

[KS1-ipsec-transform-set-fortek] quit

# Create an IPsec profile named fortek.

[KS1] ipsec profile fortek

# Specify IPsec transform set fortek for IPsec profile fortek.

[KS1-ipsec-profile-fortek] transform-set fortek

[KS1-ipsec-profile-fortek] quit

# Create an ACL named fortek.

[KS1] acl number 3000 name fortek

# Configure ACL rules to identify the bidirectional traffic to be protected.

[KS1-acl-adv-3000-fortek] rule 0 permit ip source 10.1.1.0 0.0.0.255 destination

10.1.2.0 0.0.0.255

[KS1-acl-adv-3000-fortek] rule 1 permit ip source 10.1.2.0 0.0.0.255 destination

10.1.1.0 0.0.0.255

[KS1-acl-adv-3000-fortek] rule 2 permit ip source 10.1.1.0 0.0.0.255 destination

10.1.3.0 0.0.0.255

[KS1-acl-adv-3000-fortek] rule 3 permit ip source 10.1.3.0 0.0.0.255 destination

10.1.1.0 0.0.0.255

[KS1-acl-adv-3000-fortek] quit

# Create an ACL named forrekey.

[KS1] acl number 3001 name forrekey

# Configure a rule to permit rekey traffic destined for 225.0.0.1.

[KS1-acl-adv-3001-forrekey] rule 0 permit ip destination 225.0.0.1 0

[KS1-acl-adv-3001-forrekey] quit

# Create a local RSA key pair named rsa1.

[KS1] public-key local create rsa name rsa1

The range of public key modulus is (512 ~ 2048).

NOTES: If the key modulus is greater than 512,

It will take a few minutes.

Press CTRL+C to abort.

Input the bits of the modulus[default = 1024]:

Generating Keys...

++++++++++++++++

+++++++

+++++++++

+++

# Export local RSA key pair rsa1 by using 3DES CBC and password 12345678. Copy the key or key pair as needed, which will be used in RSA key import on KS 2.

[KS1] public-key local export rsa name rsa1 pem 3des-cbc-128 12345678

-----BEGIN PUBLIC KEY-----

MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC6Ne4EtnoKqBCL2YZvSjrG+8He

sae5FWtyj9D25PEkXagpLqb3i9Gm/Qbb6cqLLPUIgDS8eK7Wt/dXLeFUCDc0lY8V

gujJPvarFL4+Jn+VuL9znNbboA9IxPH2fMvew8lkPCwkXoP+52J+1LRpYkh+rIpE

Kj7FG/3/wzGsXu8WJQIDAQAB

-----END PUBLIC KEY-----

-----BEGIN RSA PRIVATE KEY-----

Proc-Type: 4,ENCRYPTED

DEK-Info: DES-EDE3-CBC,7F8FAB15399DF87C

MGaftNqe4esjetm7bRJHSpsbwZ9YUpvA9iWh8R406NGq8e+1A/ZiK23+t1XqRwaU

1FXnwbqHgW1pZ7JxQdgBuC9uXc4VQyP/xe6xCyUepdMC71fmeOaiwUFrj6LAzzBg

o3SfhX1NHyHBnr7c6SnIeUTG2g/qRdj40TD4HcRjgPaLaTGguZ553GyS6ODWAwL7

ZBTjv+vow9kfewZ74ocoBje2gLcWlbmiEKCJGV06zW4gv2AH6I8TAhv4GovIN/v1

lCsD2PscXnPOloLTE/8EDLRHNE8RpIYDWqI/YI8Yg6wlx29mf29+cj/9r4gPrDPy

c/TQ0a0g95Khdy+yl4eDKaFiQQ+Kqn4zdzDTDNq7LRtqr7lGQzVw6srfrr71ib7J

yJFdi2RXETEgOS/jE+xGtNqd38F/YzIRPax7NNMK+hAJC2MzdbN/BEoLWOqG7Plm

hvCE3LFxelExLJU+0XfAX77TI2+5LEHBi1UiGLeH08fd1XUQCefARlIxGoRJdtTu

gHP4+NF4PC9B1/GZoAYUp+171p1QwPk0vyU3TXijueqVUpQBUHGxSE0UW+SS1iwL

8vsSLHIwK4aZ77Z1o+Uw1QBoqw9jpubG4gUkX8RII8E8b13I6/QTH78E4/FgAmIQ

HTYnE2RDHXkhPGR5FGJsZnd21XLvd2BEkGGmhTk80nDeiI2XH3D48E6UahQwcam/

q/txd/KsLnp0rpJkc/WhOTprioeLQQEBayixKRWzNLsZt3L6lqYbA01Z1THho+EV

0Ng0EZKQyiRV1j7gsBYFRinbSAsIpeYlr7gDAnBCRJdSfPNBKG+ewg==

-----END RSA PRIVATE KEY-----

# Create a GDOI KS group named ks1.

[KS1] gdoi ks group ks1

# Configure the group ID as 12345.

[KS1-gdoi-ks-group-ks1] identity number 12345

# Use key pair rsa1.

[KS1-gdoi-ks-group-ks1] rekey authentication public-key rsa rsa1

# Use rekey ACL forrekey.

[KS1-gdoi-ks-group-ks1] rekey acl name forrekey

# Create an IPsec policy named 10 for the GDOI KS group.

[KS1-gdoi-ks-group-ks1] ipsec 10

# Use IPsec profile fortek.

[KS1-gdoi-ks-group-ks1-ipsec-10] profile fortek

# Use ACL fortek.

[KS1-gdoi-ks-group-ks1-ipsec-10] security acl name fortek

[KS1-gdoi-ks-group-ks1-ipsec-10] quit

# Specify the peer KS address as 200.2.2.200.

[KS1-gdoi-ks-group-ks1] peer address 200.2.2.200

# Specify the source address for sending packets as 100.1.1.100.

[KS1-gdoi-ks-group-ks1] source address 100.1.1.100

# Set the local priority to 10000.

[KS1-gdoi-ks-group-ks1] local priority 10000

# Enable KS redundancy.

[KS1-gdoi-ks-group-ks1] redundancy enable

[KS1-gdoi-ks-group-ks1] quit

2. Configure KS 2:

# Configure IP addresses for interfaces. (Details not shown.)

# Create IKE proposal 1.

<KS2> system-view

[KS2] ike proposal 1

# Specify the encryption algorithm as AES-CBC-128 for the IKE proposal.

[KS2-ike-proposal-1] encryption-algorithm aes-cbc-128

# Specify the authentication algorithm as SHA1 for the IKE proposal.

[KS2-ike-proposal-1] authentication-algorithm sha

# Specify DH group 2 for the IKE proposal.

[KS2-ike-proposal-1] dh group2

[KS2-ike-proposal-1] quit

# Create IKE peer toks1 for IKE negotiation with KS 1.

[KS2] ike peer toks1

# Specify IKE proposal 1 for the IKE peer.

[KS2-ike-peer-toks1] proposal 1

# Configure the pre-shared key as tempkey1 in plain text.

[KS2-ike-peer-toks1] pre-shared-key simple tempkey1

# Specify the IP address of the IKE peer as 100.1.1.100.

[KS2-ike-peer-toks1] remote-address 100.1.1.100

[KS2-ike-peer-toks1] quit

# Create IKE peer togm for IKE negotiation with GMs.

[KS2] ike peer togm

# Specify IKE proposal 1 for the IKE peer.

[KS2-ike-peer-togm] proposal 1

# Configure the pre-shared key as tempkey1 in plain text.

[KS2-ike-peer-togm] pre-shared-key simple tempkey1

[KS2-ike-peer-togm] quit

# Create an IPsec transform set named fortek.

[KS2] ipsec transform-set fortek

# Specify the security protocol as ESP for the IPsec transform set.

[KS2-ipsec-transform-set-fortek] transform esp

# Specify the encryption algorithm as AES-CBC-128 for the IPsec transform set.

[KS2-ipsec-transform-set-fortek] esp encryption-algorithm aes-cbc-128

# Specify the authentication algorithm as SHA1 for the IPsec transform set.

[KS2-ipsec-transform-set-fortek] esp authentication-algorithm sha1

[KS2-ipsec-transform-set-fortek] quit

# Create an IPsec profile named fortek.

[KS2] ipsec profile fortek

# Specify IPsec transform set fortek for IPsec profile fortek.

[KS2-ipsec-profile-fortek] transform-set fortek

[KS2-ipsec-profile-fortek] quit

# Create an ACL named fortek.

[KS2] acl number 3000 name fortek

# Configure ACL rules to identify the traffic to be protected.

[KS2-acl-adv-3000-fortek] rule 0 permit ip source 10.1.1.0 0.0.0.255 destination

10.1.2.0 0.0.0.255

[KS1-acl-adv-3000-fortek] rule 1 permit ip source 10.1.2.0 0.0.0.255 destination

10.1.1.0 0.0.0.255

[KS2-acl-adv-3000-fortek] rule 2 permit ip source 10.1.1.0 0.0.0.255 destination

10.1.3.0 0.0.0.255

[KS1-acl-adv-3000-fortek] rule 3 permit ip source 10.1.3.0 0.0.0.255 destination

10.1.1.0 0.0.0.255

[KS2-acl-adv-3000-fortek] quit

# Create an ACL named forrekey.

[KS2] acl number 3001 name forrekey

# Configure a rule to permit rekey traffic destined for 225.0.0.1.

[KS2-acl-adv-3001-forrekey] rule 0 permit ip destination 225.0.0.1 0

[KS2-acl-adv-3001-forrekey] quit

# Import the RSA key or key pair that was exported on KS 1 to KS 2 by using PEM format, and name the key or key pair as rsa1. During importing, you need to paste the key or key pair copied from KS 1 on the client user interface. In this example, only private key is copied and pasted.

[KS2] public-key local import rsa name rsa1 pem

Enter PEM-formatted certificate.

End with a Ctrl+C on a line by itself.