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 Framework

IPSec Framework

Security Association

A Security Association (SA) is an agreement between two peers on certain elements. It describes how to use security services (such as encryption) between peers for secure communication. The elements include the security protocol, characteristics of data flows to be protected, encapsulation mode of data transmitted between peers, encryption and authentication algorithms, and lifetimes of keys (used for secure data conversion and transmission) and SAs.

IPSec SAs need to be established for secure data transmission between IPSec peers. An IPSec SA is identified by three parameters: security parameter index (SPI), destination IP address, and security protocol number (AH or ESP). The SPI is a 32-bit value generated to uniquely identify an SA, and is encapsulated in an AH or ESP header.

IPSec SAs are unidirectional and are generally established in pairs (inbound and outbound). Therefore, at least one pair of IPSec SAs are established between two IPSec peers to form a secure IPSec tunnel that protects data flows in both directions, as shown in Figure 5-1.

Figure 5-1  IPSec SA

In addition, the number of IPSec SAs required also depends on the security protocols used to protect traffic between two peers. If either AH or ESP is used, two SAs are required to protect incoming and outgoing traffic. If both AH and ESP are used, four SAs are required, two for each protocol.

IPSec SAs can be established manually or through the Internet Key Exchange (IKE) protocol. Table 5-1 compares the two IPSec SAs establishment modes.

Table 5-1  Comparisons between two IPSec SAs establishment modes
Item Manually Establishing IPSec SAs Automatically Establishing IPSec SAs Through IKE
Configuration and update of keys used for encryption and authentication

Manually configured and updated; prone to errors

High key management cost

Generated by the Diffie-Hellman (DH) algorithm and dynamically updated

Low key management cost

SPI value Manually configured Randomly generated
Lifetime of an IPSec SA Valid permanently Negotiated by two peers (SAs are dynamically updated.)
Security Low High
Applicable scenario Small-sized networks Large-, medium-, and small-sized networks

Security Protocols

AH and ESP are the two IP-based transport-layer protocols used by IPSec to provide security services such as authentication and encryption.

  • AH

    AH is used to authenticate, but not encrypt, IP traffic. An AH header is appended to the standard IP header in each data packet, as described in Encapsulation Modes. AH provides data origin authentication and data integrity check that is performed on an entire IP packet. The sender performs hash calculation on data packets and the authentication key. Upon receipt of data packets carrying the calculation result, the receiver also performs hash calculation and compares the calculation result with that received from the sender. Any changes to the data during transmission will invalidate the calculation result.

  • ESP

    ESP provides encryption and optional authentication. An ESP header is appended to the standard IP header in each data packet, and an ESP trailer and ESP Authentication Data are appended to each data packet, as described in Encapsulation Modes. ESP encrypts the IP payload and then encapsulates it into a data packet to ensure data confidentiality. ESP protects the IP header only in tunnel mode.

Table 5-2 compares AH and ESP.

Table 5-2  Comparisons between AH and ESP
Security Feature AH ESP
Protocol number 51 50
Data integrity check Supported (checking the entire IP packet) Supported (not checking the IP header in transport mode; checking the entire IP packet in tunnel mode)
Data origin authentication Supported Supported
Data encryption Not supported Supported
Anti-replay Supported Supported
IPSec NAT traversal (NAT-T) Not supported Supported

AH and ESP can be used together when high security is required.

AH Header and ESP Header

AH header

Figure 5-2 shows the format of an AH header, and Table 5-3 describes fields in the AH header.

Figure 5-2  AH header format

Table 5-3  Fields in an AH header

Field

Length

Description

Next Header

8 bits

This field identifies the type of the payload following the AH header. In transport mode, the Next Header field is the number of the protected upper-layer protocol (TCP or UDP) or ESP. In tunnel mode, the Next Header field is the number of the IP or ESP protocol.

NOTE:

When AH and ESP are used together, the Next Header following an AH header is an ESP header.

Payload Len

8 bits

This field specifies the length of the AH header in 32-bit words (4-byte units) minus 2. The default value is 4.

Reserved

16 bits

This field is reserved for future use and defaults to 0.

SPI

32 bits

This field uniquely identifies an IPSec SA.

Sequence Number

32 bits

This field is a counter that monotonically increments from 1. It uniquely identifies a packet to prevent replay attacks.

Authentication Data

Integral multiple of 32 bits. It is 96 bits in common cases.

This field contains the result of Integrity Check Value (ICV) calculation, which is used by the receiver for data integrity check. Authentication algorithms include MD5, SHA1, and SHA2.

NOTE:

The MD5 and SHA1 authentication algorithms have security risks. The SHA2 algorithm is recommended.

ESP header

Figure 5-3 shows the format of an ESP header, and Table 5-4 describes fields in the ESP header.

Figure 5-3  ESP header format

Table 5-4  ESP header fields

Field

Length

Description

SPI

32 bits

This field uniquely identifies an IPSec SA.

Sequence Number

32 bits

This field is a counter that monotonically increments from 1. It uniquely identifies a packet to prevent replay attacks.

Payload data

-

This field contains the protected variable-length data content in the original IP packet. The type of content protected by ESP is identified by the Next Header field.

Padding

-

This field extends the payload data to a size that fits the encryption's cipher block size. The Padding field length depends on the payload data length and algorithm.

Pad Length

8 bits

This field specifies the length of the Padding field. The value 0 indicates no padding.

Next Header

8 bits

This field identifies the type of the payload following the ESP header. In transport mode, the Next Header field is the number of the protected upper-layer protocol (TCP or UDP). In tunnel mode, the Next Header field is the number of the IP protocol.

Authentication Data

Integral multiple of 32 bits. It is 96 bits in common cases.

This field contains the result of ICV calculation, which is used by the receiver for data integrity check. Authentication algorithms are the same as those of AH.

The authentication function of ESP is optional. If data check is enabled, an ICV value is appended to encrypted data.

Encapsulation Modes

Encapsulation is a process of adding AH or ESP fields to original IP packets for packet authentication and encryption. This process is implemented in either transport or tunnel mode.

Transport Mode

IPSec transport mode works by inserting an AH or ESP header between an IP header and a transport-layer protocol header to protect the TCP, UDP, or ICMP payload. Because no additional IP header is added, IP addresses in the original packets are visible in the IP header of the post-encrypted packet. Figure 5-4 shows an example of TCP packet encapsulation in transport mode.

Figure 5-4  Packet encapsulation in transport mode

In transport mode, AH protects the IP header, but ESP does not.

Tunnel Mode

IPSec tunnel mode works by encrypting and authenticating an entire IP packet, including the IP header and payload. In this mode, an AH or ESP header is added before the raw IP header, and a new IP header is added before the AH or ESP header. Figure 5-5 shows an example of TCP packet encapsulation in tunnel mode.

Figure 5-5  Packet encapsulation in tunnel mode

In tunnel mode, AH protects the new IP header, but ESP does not.

Comparisons Between the Transport Mode and Tunnel Mode

The main differences between the transport mode and tunnel mode are as follows:

  • The tunnel mode is more secure because original IP packets are completely authenticated and encrypted. This mode hides the IP address, protocol type, and port number in an original IP packet.

  • The tunnel mode generates an additional IP header, occupying more bandwidth than the transport mode.

  • The transport mode is mainly used for communication between two hosts or between a host and a VPN gateway. The tunnel mode is mainly used for communication between two VPN gateways or between a host and a VPN gateway.

When both AH and ESP are used to protect traffic, they must use the same encapsulation mode.

Encryption and Authentication

IPSec provides two security mechanisms: encryption and authentication. The encryption mechanism ensures data confidentiality and prevents data from being intercepted during transmission. The authentication mechanism ensures data integrity and reliability and prevents data from being forged or tampered with during transmission.

Encryption

IPSec uses symmetric encryption algorithms to encrypt and decrypt data. Figure 5-6 shows the process of encrypting and decrypting data through the same key (that is, a symmetric key) between two IPSec peers.

Figure 5-6  Data encryption and decryption process

A symmetric key used for encryption and decryption can be configured manually or generated automatically through IKE negotiation.

Common symmetric encryption algorithms include Data Encryption Standard (DES), Triple Data Encryption Standard (3DES), and Advanced Encryption Standard (AES). DES and 3DES are not recommended because they are insecure and pose security risks.

Authentication

IPSec uses the Keyed-Hash Message Authentication Code (HMAC) function to compare digital signatures to check integrity and authenticity of data packets.

Encryption and authentication are often used together. As shown in Figure 5-7, the IPSec sender encrypts an IP packet, generates a digital signature through an authentication algorithm and a symmetric key, and then sends both the encrypted IP packet and digital signature to the IPSec receiver. The digital signature is included in the Integrity Check Value (ICV) field of an AH or ESP header. For details, see Security Protocols. The IPSec receiver processes the encrypted packet using the same authentication algorithm and symmetric key, and compares the received digital signature with the locally generated one to check integrity and authenticity of data in the received IP packet. The IPSec receiver discards any packets that fail the authentication and decrypts only those that pass the authentication.

Figure 5-7  Authentication process

Similar to a symmetric key used for encryption, a symmetric key used for authentication can be configured manually or generated automatically through IKE Protocol negotiation.

Common authentication algorithms include Message Digest 5 (MD5), Secure Hash Algorithm 1 (SHA1), and SHA2. MD5 and SHA1 are not recommended because they are insecure and pose security risks.

Key Exchange

How to securely share a symmetric key is an important issue during encryption and authentication using the key. Two methods are available to address this issue:

  • Out-of-band key sharing

    An encryption key and an authentication key are manually configured on the IPSec sender and receiver. The two parties ensure key consistency in out-of-band mode, for example, by exchanging phone calls or emails. This mode not only has poor security and scalability, but also multiplies the workload in configuring keys in point-to-multipoint networking. In addition, this mode is difficult to implement because the keys need to be modified periodically for security purposes.

  • Using a secure key distribution protocol

    Keys are generated through IKE negotiation. The IKE protocol uses the DH algorithm to implement secure key distribution over an insecure network. This mode is easy to configure and provides high scalability, especially on a large dynamic network. Two communicating parties exchange keying materials to calculate shared keys. Even if a third party obtains all the exchanged data used to calculate the shared keys, it cannot calculate the shared keys. Therefore, this mode greatly improves security.

IKE Protocol

IKE is a UDP-based application-layer protocol built on the Internet Security Association and Key Management Protocol (ISAKMP) framework. IPsec uses the IKE protocol for key auto-negotiation and IPSec SA establishment, simplifying IPSec configuration and maintenance.

Figure 5-8 shows the relationship between IKE and IPSec. Two peers establish an IKE SA for identity authentication and key exchange. Protected by the IKE SA, the peers negotiate a pair of IPSec SAs using the AH or ESP protocol and other configured parameters. Subsequently, data is encrypted and transmitted between the peers in an IPSec tunnel.

An IKE SA is bidirectional, so only one IKE SA needs to be established between two peers.

Figure 5-8  Relationship between IKE and IPSec

IKE security mechanisms

IKE defines a series of self-protection mechanisms that can securely authenticate identities, distribute keys, and establish IPSec SAs on a network. The mechanisms include the following:
  • Identity authentication

    Two peers authenticate the identity (IP address or name) of each other, using pre-shared key (PSK) authentication or Rivest-Shamir-Adleman (RSA) signature authentication.

    • PSK authentication: Two peers compute the hash value of packets using the PSK and check whether they obtain the same hash value. If the peers obtain the same hash value, the authentication succeeds. Otherwise, authentication fails. For a peer that has multiple remote IPSec peers, PSK authentication requires each pair of peers to have the same PSK. This authentication method can be easily implemented on small-scale networks but has low security.
    • RSA signature authentication: Two peers use a certificate issued by a certificate authority (CA) to verify the validity of a digital certificate. Each peer has a public key (transmitted over the network) and a private key (possessed by itself). The sender computes a hash value for original packets, and then encrypts the hash value using its private key to generate a digital signature. The receiver decrypts the digital signature using the public key received from the sender, and then computes a hash value for packets. If the computed hash value is the same as that decrypted from the digital signature, the authentication succeeds. Otherwise, authentication fails. RSA signature authentication provides high security but requires digital certificates issued by a CA. This authentication method is applicable to large-scale networks.

    IKE supports the following authentication algorithms: MD5, SHA1, SHA2-256, SHA2-384, and SHA2-512.

  • Identity protection

    After a key is generated, identity data is encrypted using the key to ensure secure transmission.

    IKE supports the following encryption algorithms: DES, 3DES, AES-128, AES-192, and AES-256.

  • DH

    DH is a public key exchange method that generates keying materials and uses ISAKMP messages to exchange keying materials between the sender and receiver. The two devices compute the same symmetric key and generate an encryption key and an authentication key based on this symmetric key. The encryption key and authentication key are never exchanged between the two devices. DH key exchange is central to IKE.

  • Perfect Forward Secrecy (PFS)

    If PFS is enabled, an additional DH key exchange is performed when keys used in IPSec SAs are generated based on the keys used in the IKE SA. This ensures that the keys used in IPSec SAs remain indecipherable even if a key used in the IKE SA is deciphered.

NOTE:
  • The MD5 and SHA1 authentication algorithms are insecure. The more secure SHA2-256, SHA2-384, or SHA2-512 algorithm is recommended.
  • The DES and 3DES encryption algorithms are insecure. The more secure AES algorithm is recommended.

IKE versions

IKE has two versions: IKEv1 and IKEv2. IKEv2 has the following advantages over IKEv1:

  • Simplifies SA negotiation and improves negotiation efficiency.

    IKEv1 goes through two phases to negotiate the key and establish IPSec 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 through the secure channel established in phase 1. IKEv2 generates the key and establishes IPSec SAs in just one negotiation, simplifying the negotiation process. For details, see Establishing SAs Through IKEv1 Negotiation and Establishing SAs Through IKEv2 Negotiation.

  • Fixes many cryptographic vulnerabilities, enhancing security.

Translation
Download
Updated: 2019-08-07

Document ID: EDOC1100033725

Views: 154324

Downloads: 372

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