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).
IPSec Working Mechanisms

IPSec Working Mechanisms

IPSec establishes a pair of security associations between IPSec peers to form an IPSec tunnel, transmits the defined IPSec-protected data flows over the tunnel, and uses a security protocol to encrypt and authenticate the data passing through the tunnel. This implementation ensures secure data transmission over the Internet.

IPSec SAs can be manually established or established through IKEv1 or IKEv2 negotiation. The following describes how to define IPSec-protected data flows and how to establish IPSec SAs through IKE negotiation.

Defining IPSec-Protected Data Flows

You can define the data to be protected by IPSec using either of the following methods:
  • Using an ACL

    An ACL can be used to define data flows to be protected by an IPSec tunnel established manually or through IKE negotiation. The packets matching permit clauses in the ACL are protected, and those matching no permit clause are not protected. The ACL can define packet attributes such as the IP address, port number, and protocol type, which provide flexibility in defining IPSec policies.

  • Configuring a route

    A route can be configured to define data flows to be protected by an IPSec tunnel established through IPSec virtual tunnel interfaces. All packets routed to these interfaces are protected. IPSec virtual tunnel interfaces are Layer 3 logical interfaces.

    This method has the following advantages:

    • Simplifies the IPSec configuration: IPSec-protected data flows are routed to virtual tunnel interfaces, without the need to use an ACL to define characteristics of traffic to be encrypted or decrypted.

    • Supports dynamic routing protocols.

    • Protects multicast traffic through GRE over IPSec.

Establishing SAs Through IKEv1 Negotiation

IKEv1 goes through two phases to establish SAs. In phase 1, two peers negotiate and establish a secure tunnel, which is an IKE SA. In phase 2, the peers establish a pair of IPSec SAs for secure data transmission through the secure tunnel established in phase 1.

IKEv1 Phase 1

IKEv1 phase 1 needs to establish an IKE SA. After an IKE SA is established, all the ISAKMP messages transmitted between two IPSec peers are encrypted and authenticated. The secure tunnel established in phase 1 enables IPSec peers to communicate securely in phase 2.

IKEv1 phase 1 can use either main mode or aggressive mode.

The main mode requires three exchanges between the peers, totaling six ISAKMP messages, as shown in Figure 5-9. The three exchanges are described as follows:
  1. Messages (1) and (2) are used for proposal exchange.

    The initiator sends one or more IKE proposals to the responder. The responder then searches for IKE proposals and sends the first matched proposal to the initiator. IKE proposals of the initiator and responder match if they have the same encryption algorithm, authentication algorithm, authentication method, and DH group identifier.

  2. Messages (3) and (4) are used for key information exchange.

    The initiator and responder exchange the DH public value and nonce value to generate the IKE SA authentication key and encryption key.

  3. Messages (5) and (6) are used for exchanging identity and authentication information. The initiator and responder use the generated keys to authenticate each other and the information exchanged in main mode.
NOTE:
  • An IKE proposal is a set of algorithms used to secure IKE negotiation, including the encryption algorithm, authentication algorithm, DH group, and authentication method.

  • A nonce value is a random number that is used to check whether the IKE SA is alive and to protect against replay attacks.

The aggressive mode requires only two exchanges, totaling three messages. Messages (1) and (2) are used to negotiate an IKE proposal and exchange the DH public value, mandatory auxiliary information, and identity information. Message (2) also contains the identity information sent by the responder to the initiator for authentication. Message (3) is used by the responder to authenticate the initiator. Figure 5-9 shows IKEv1 phase 1.

Figure 5-9  IKEv1 phase 1

Compared with the main mode, the aggressive mode reduces the number of exchanged messages and speeds up the negotiation. However, the aggressive mode does not encrypt identity information.

IKEv1 Phase 2

IKEv1 phase 2 establishes IPSec SAs and generates keys for securely transmitting data. This phase uses the quick mode. This mode uses the keys generated in phase 1 to verify the integrity of ISAKMP messages and identities of the initiator and responder, and to encrypt ISAKMP messages, ensuring exchange security. Figure 5-10 shows IKEv1 phase 2.

Figure 5-10  IKEv1 phase 2

In IKEv1 phase 2, two IPSec SAs are established through three ISAKMP messages:

  1. The initiator sends local security parameters and identity authentication information to the responder.

    Security parameters include protected data flows and parameters to be negotiated, such as the IPSec proposal. Identity authentication information includes the keys generated in phase 1 and keying materials generated in phase 2, and can be used to authenticate the peer again.

    NOTE:

    An IPSec proposal is a set of protocols and algorithms used for negotiation, including the security protocol, encryption algorithm, and authentication algorithm.

  2. The responder sends acknowledged security parameters and identity authentication information, and generates new keys.

    The encryption key and authentication key used for secure data transmission over IPSec SAs are generated based on the keys generated in phase 1 and parameters such as the SPI and protocol. This ensures that each IPSec SA has unique encryption and authentication keys.

    If PFS is enabled, the DH algorithm is used again to generate shared keys, based on which the encryption key and authentication key are calculated. Therefore, during parameter negotiation, a DH key group needs to be negotiated for PFS.

  3. The initiator sends acknowledged information to communicate with the responder. IKEv1 negotiation then ends.

Establishing SAs Through IKEv2 Negotiation

The process of establishing SAs through IKEv2 negotiation is much simpler than that through IKEv1 negotiation. To establish a pair of IPSec SAs, IKEv1 requires two phases: main or aggressive mode + quick mode. At least nine messages are exchanged in main mode + quick mode, and at least six messages are exchanged in aggressive mode + quick mode. In normal cases, IKEv2 requires only two exchanges, totaling four messages, to establish a pair of IPSec SAs. One additional Create_Child_SA Exchange can be used to establish another pair of IPSec SAs if required, during which only two messages are exchanged.

IKEv2 defines three exchanges: Initial Exchanges, Create_Child_SA Exchange, and Informational Exchange.

Initial Exchanges

In normal cases, IKEv2 establishes the first pair of IPSec SAs through Initial Exchanges. Corresponding to IKEv1 phase 1, Initial Exchanges involve four messages in two exchanges, as shown in Figure 5-11.

Figure 5-11  Initial Exchanges process

Messages (1) and (2) are used in exchange 1 (called IKE_SA_INIT) to negotiate IKE SA parameters in plaintext, including the encryption key, authentication key, random number, and DH key. After IKE_SA_INIT is complete, shared keying material is generated, from which all keys used by IPSec SAs are derived.

Messages (3) and (4) are used in exchange 2 (called IKE_AUTH) to authenticate identities of the two parties and the first two messages, and to negotiate IPSec SA parameters. The two messages are encrypted. IKEv2 supports RSA signature authentication, PSK authentication, and EAP authentication. The initiator does not set the authentication payload in message (3) to indicate that EAP authentication is required.

Create_Child_SA Exchange

After one pair of IPSec SAs is established based on an IKE SA, Create_Child_SA Exchange can be performed to negotiate more pairs of IPSec SAs. In addition, Create_Child_SA Exchange can be performed for IKE SA re-negotiation.

Create_Child_SA Exchange involves two messages in one exchange and corresponds to IKEv1 phase 2. The initiator in Create_Child_SA Exchange can be the initiator or responder in Initial Exchanges. Create_Child_SA Exchange can be performed only after Initial Exchanges are complete. Messages transmitted in Create_Child_SA Exchange are protected by keys negotiated in Initial Exchanges.

Similar to IKEv1, when PFS is enabled, Create_Child_SA Exchange requires an additional DH exchange to generate new keying material. All keys used by child SAs are derived from this keying material.

Informational Exchange

IKEv2 peers perform Informational Exchange to exchange control information, including error information and notifications, as shown in Figure 5-12.

Informational Exchange must be performed under the protection of an IKE SA. Specifically, Informational Exchange is performed after Initial Exchanges are complete. Control information may belong to an IKE SA or a child SA. Therefore, Informational Exchange must be protected by the IKE SA or the IKE SA based on which child IPSec SAs are established accordingly.

Figure 5-12  Informational Exchange process

Translation
Download
Updated: 2019-08-07

Document ID: EDOC1100033725

Views: 144369

Downloads: 361

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