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


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


S600-E V200R012C00 Configuration Guide - VPN

This document describes the configurations of VPN, including IPSec, MCE.
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 Fundamentals

IPSec Fundamentals

IPSec establishes bidirectional security associations between IPSec peers to form a secure IPSec tunnel, imports data flows to be protected to the tunnel, and then uses security protocols to encrypt and authenticate the data passing through the tunnel to securely transmit the data over the Internet.

IPSec SAs can be established through IKEv1 or IKEv2 auto-negotiation.

Defining IPSec Protected Data Flows

An ACL can be used to define IPSec protected data flows on an IPSec tunnel. The packets matching permit clauses in the ACL are protected, and those matching the deny clauses 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.

Establishing an SA Through IKEv1 Negotiation

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

IKEv1 Negotiation Phase 1

Phase 1 needs to establish an IKE SA. After an IKE SA is established, all the Internet Security Association and Key Management Protocol (ISAKMP) messages transmitted between the two IPSec peers will be encrypted and authenticated. The secure tunnel established in phase 1 enables IPSec peers to communicate securely in phase 2. An IKE SA is bidirectional, so only one IKE SA needs to be established between two IPSec peers.

Phase 1 supports two negotiation modes: main mode and aggressive mode.

The main mode uses six ISAKMP messages to implement three bidirectional exchanges, as shown in Figure 2-10. The three exchanges are as follows:
  1. Messages (1) and (2) are used for policy exchange.

    The initiator sends one or multiple IKE proposals to the responder. The responder searches for the first matching IKE proposal and then sends the matching proposal to the initiator. IKE proposals of the initiator and responder match if they have the same encryption algorithm, authentication algorithm, authentication method, and Diffie-Hellman group identifier.

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

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

  3. Messages (5) and (6) are used for identity and authentication information exchange.

    The initiator and responder use the generated key to authenticate each other and the information exchanged in main mode.

  • Efficient VPN only supports aggressive mode.

  • An IKE proposal is a set of algorithms used to secure IKE negotiation, including encryption algorithm, authentication algorithm, Diffie-Hellman group, and authentication method.

  • A nonce value is a random number that guarantees IKE SA liveness and protects against replay attacks.

The aggressive mode uses only three messages. Messages (1) and (2) are used to negotiate IKE proposal and exchange the Diffie-Hellman 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 2-10 shows IKEv1 negotiation phase 1.

Figure 2-10  IKEv1 negotiation phase 1

Compared with the main mode, the aggressive mode reduces the number of exchanged messages and speeds up the negotiation, but it does not encrypt identity information. Although the aggressive mode does not provide identity protection, it applies to the following scenarios:

  • If the IP address of the initiator is variable or unknown, and both the initiator and responder need to use a pre-shared key to establish an IKE SA, only the aggressive mode can be used.
  • If the initiator already knows the IPSec policy used by the responder, it is faster to establish an IKE SA in aggressive mode.
IKEv1 Negotiation Phase 2

Phase 2 establishes IPSec SAs used to securely transmit data and generates the key for data transmission. The quick mode is used in phase 2. This mode uses the key 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 2-11 shows IKEv1 negotiation phase 2.

Figure 2-11  IKEv1 negotiation phase 2

Phase 2 establishes two IPSec SAs 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 IPSec proposal. Identity authentication information includes the key generated in phase 1 and key materials generated in phase 2, and can be used to authenticate the peer again.


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

  2. The responder sends confirmed security parameters and identity authentication information, and generates a new key.

    The encryption key and authentication key used for IPSec SA data transmission are generated based on the key generated in phase 1 and parameters such as SPI and protocols, to ensure that each IPSec SA has a unique key.

    If Perfect Forward Secrecy (PFS) needs to be enabled, the shared key calculated through DH algorithm needs to be used again to generate the encryption key and authentication key. During parameter negotiation, a DH key group needs to be negotiated for PFS.

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

Establishing an SA Through IKEv2 Negotiation

The process of establishing an SA through IKEv2 negotiation is much simpler than that through IKEv1 negotiation. To establish a pair of IPSec SAs, IKEv1 requires two phases: main mode (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 can establish a pair of IPSec SAs only through four messages in two exchanges. 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 can establish the first pair of IPSec SAs through Initial Exchanges. Mapping phase 1 in IKEv1 negotiation, Initial Exchanges involves four messages in two exchanges, as shown in Figure 2-12.

Figure 2-12  Initial Exchanges process

Messages (1) and (2) are used in exchange 1 (called IKE_SA_INIT) to negotiate IKE SA parameters in plain text, including the encryption key and authentication key, random number, and DH key. After IKE_SA_INIT is complete, a shared key material is generated, from which all IPSec SA keys 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 in encryption mode. IKEv2 supports authentication modes including the RSA signature, pre-shared key, and Extensible Authentication Protocol (EAP). EAP authentication is implemented in IKE as an additional IKE_AUTH exchange. The initiator does not set the authentication payload in message (3) to indicate that EAP authentication is required.

Create_Child_SA Exchange

When an IKE SA requires multiple pairs of IPSec SAs, Create_Child_SA Exchange is performed to negotiate these 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 maps phase 2 in IKEv1 negotiation. The initiator can be the initiator or responder in Initial Exchanges. Create_Child_SA Exchange can be performed only after Initial Exchanges are complete. Exchange messages in Create_Child_SA Exchange are protected by keys negotiated in Initial Exchanges.

Similar to IKEv1, if PFS is enabled, Create_Child_SA Exchange requires an additional DH exchange to generate a new key material. All keys of child SAs are derived from this key material.

Informational Exchange

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

Informational Exchange must be performed with IKE SA protection, that 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 that generates the child SA accordingly.

Figure 2-13  Informational Exchange process

Updated: 2018-09-01

Document ID: EDOC1100037956

Views: 2901

Downloads: 7

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