No relevant resource is found in the selected language.

This site uses cookies. By continuing to browse the site you are agreeing to our use of cookies. Read our privacy policy>Search

Reminder

To have a better experience, please upgrade your IE browser.

upgrade

CLI-based Configuration Guide - VPN

AR100, AR120, AR150, AR160, AR200, AR1200, AR2200, AR3200, and AR3600 V200R010

This document describes VPN features on the device and provides configuration procedures and configuration examples.
Rate and give feedback:
Huawei uses machine translation combined with human proofreading to translate this document to different languages in order to help you better understand the content of this document. Note: Even the most advanced machine translation cannot match the quality of professional translators. Huawei shall not bear any responsibility for translation accuracy and it is recommended that you refer to the English document (a link for which has been provided).
Implementation

Implementation

GM Registering with the KS

After GDOI policies of A2A VPN are applied to an interface of a GM, the GM registers with the KS. The registration process consists of two stages: IKE negotiation and GDOI negotiation.
  1. IKE negotiation (first stage): The GM and KS negotiate with each other to authenticate the peer's identity and to establish an IKE SA after identity authentication succeeds.

    For details on the IKE negotiation process, see "IKE" in Huawei AR Series V200R010 Configuration Guide - IPSec.

  2. GDOI negotiation (second stage): After the IKE SA is established in the first stage, the GM uses the GDOI protocol to negotiate with the KS and download keys (KEK and TEK) from the KS.

    Figure 6-2 outlines the detailed GDOI negotiation process.

    Figure 6-2  GDOI negotiation process

    1. The GM obtains the group ID configured by an administrator and sends the group ID to the KS.

    2. The KS authenticates the received group ID. After the authentication succeeds, the KS delivers GDOI policies (including information about the data flows to be protected, authentication algorithm, encryption algorithm, and encapsulation mode) to the GM based on the group ID.

    3. The GM authenticates the received GDOI polices. If the policies are acceptable (for example, the authentication and encryption algorithms are supported by the GM), the GM sends a Confirm message to the KS.

    4. After receiving the Confirm message, the KS sends keys (KEK and TEK) to the GM.

    After the negotiation process completes, the GM obtains GDOI policies and keys from the KS, saves the information locally, and generates the TEK SA and KEK SA. The TEK SA protects data flows between GMs, and the KEK SA protects rekey messages between the GM and KS.

GM Data Protection

After a GM registers with the KS, it uses the obtained TEK SA to protect packets matching the GDOI policies. The protected packets can be unicast or multicast packets.

A2A VPN uses a data encapsulation mode similar to that used in IPSec. However, A2A VPN can only use the Encapsulating Security Payload (ESP) protocol to encrypt packets, and supports only the tunnel encapsulation mode. The encapsulation and encryption modes are configured on the KS and delivered to the GMs.

In tunnel mode, the device adds an ESP header to the raw IP header and then adds a new IP header that is the same as the raw IP header to the ESP header. In this way, the encrypted packets retain the raw IP header information, including the source and destination addresses and protocol type. Using a TCP packet as an example, Figure 6-3 shows the structure of the IP packet generated after the encapsulation.

Figure 6-3  A2A VPN tunnel encapsulation mode

In an A2A VPN solution, encapsulated packets contain raw IP header information; therefore, the packets can be forwarded using the existing routing architecture, making full use the existing network structure.

Apart from the encapsulation mode, the data processing method of A2A VPN is of great importance. A2A VPN supports three SA modes:
  • Receive_Only: After a GM successfully registers with the KS, the GM can receive both ciphertext and plaintext packets but can send only plaintext packets.

  • Receive_Option: After a GM successfully registers with the KS, the GM can receive both ciphertext and plaintext packets but can send only ciphertext packets.

  • Normal: After a GM successfully registers with the KS, the GM can send or receive ciphertext packets only.

If SA modes cannot be configured in stages when you deploy the A2A VPN on an existing network (such as the MPLS VPN), services will be interrupted because a GM that joins a group can send and receive only ciphertext packets but the GM that has not joined the group can send and receive only plaintext packets. In this case, you can deploy the A2A VPN in stages in SA mode to solve this issue. The process is as follows:
  1. Deploy the KS and set the SA mode to Receive_Only on the KS. The KS will deliver this SA mode to the GMs.

  2. Deploy GMs on the A2A VPN network one by one. The registered GMs work in Receive_Only mode, so they can communicate with the newly deployed GMs before they register with the KS.

  3. After all the GMs are deployed, set the SA mode to Receive_Option on the GMs. A GM in Receive_Option mode can still communicate with a GM in Receive_Only mode.

  4. After all the GMs are switched to Receive_Option mode, set the SA mode to Normal on the KS.

Rekey

The KS not only creates and encrypts GDOI polices and keys, but also updates keys and allocates keys to GMs. After GMs register with the KS, the KS periodically sends new TEK SAs or KEK SAs to GMs through rekey messages to improve security. A rekey message carries information about the data flows to be protected, authentication algorithm, encryption algorithm, encapsulation mode, and the lifetime of keys and SAs. A rekey message is protected by the current KEK SA. GMs will receive rekey messages from the KS periodically. If a GM does not receive any rekey message within the lifetime of the TEK SA or KEK SA, it needs to register with the KS again to download GDOI policies and keys.

Two rekey modes are available: multicast rekey and unicast rekey.

Multicast Rekey

In multicast rekey mode, the KS multicasts rekey messages to members in a multicast group. After successfully registering with the KS, GMs join a specific multicast group. All GMs in the group will receive the rekey messages. If the GDOI policies on the KS are modified, the KS sends rekey messages to all GMs in the multicast group.

In addition, after sending rekey messages, the KS periodically retransmits the rekey messages until the number of retransmissions reaches the specified number. By default, the number of retransmissions of rekey messages is 3 and the retransmission interval is 10 seconds.

Unicast Rekey

In unicast rekey mode, the KS unicasts rekey messages to each GM. The KS sends a rekey message carrying the same new TEK SA or KEK SA to all the GMs before the old SA expires. After receiving the rekey message, each GM sends an ACK message to the KS. The KS updates the current active GM list based on the received ACK message. The KS sends rekey messages only to active GMs.

In addition, if the KS does not receive ACK messages from the GM within a certain length of time after sending rekey messages, the KS retransmits the rekey messages. If the KS does not receive ACK messages from the GM after retransmitting the rekey messages for a given number of times, the KS removes the GM from the current active list and stops sending rekey messages to the GM. If the GM wants to receive rekey messages, it must register with the KS again. By default, the number of retransmissions of rekey messages is 3 and the retransmission interval is 10 seconds.

Translation
Download
Updated: 2019-08-07

Document ID: EDOC1100033725

Views: 154384

Downloads: 372

Average rating:
This Document Applies to these Products
Related Version
Related Documents
Share
Previous Next