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

S12700 V200R011C10 Configuration Guide - VPN

This document describes the VPN configuration procedures and provides 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).
Basic Concepts of IPSec

Basic Concepts of IPSec

A security association (SA) needs to be established between IPSec peers (two IPSec endpoints) before IPSec can implement secure data transmission. An SA defines a set of parameters for data transmission between two IPSec peers, including the security protocol, characteristics of data flows to be protected, data encapsulation mode, encryption algorithm, authentication algorithm, Key Exchange, IKE, and SA lifetime.

Security Association

An SA is identified by three parameters: security parameter index (SPI), destination IP address, and security protocol ID (AH or ESP). The SPI is a 32-bit value generated for uniquely identifying an SA, and is transmitted in an AH or ESP header. The SPI needs to be specified when an SA is manually configured. When an SA is generated during IKE negotiation, an SPI is generated randomly.

Because SAs are unidirectional, at least two SAs are required to protect incoming and outgoing data flows. In Figure 2-2, two SAs need to be established if an IPSec tunnel needs to be established between IPSec peers A and B. SA1 defines the protection mode for data sent from Peer A to Peer B, and SA2 defines the protection mode for data sent from Peer B to Peer A.

Figure 2-2  IPSec SAs

How many SAs are required also depends on the security protocol used. If you use either AH or ESP to protect traffic between two peers, two SAs are required to protect incoming and outgoing flows. If you use both AH and ESP to protect traffic between two peers, four SAs are required, two for each protocol.

Security Protocol

IPSec uses two security protocols, Authentication Header (AH) and Encapsulating Security Payload (ESP), to transmit and encapsulate data. The security protocols provide security services such as authentication and encryption.

AH

AH is an IP-based transport-layer protocol with protocol number 51. According to the AH protocol, an AH header is appended to the standard IP header in each packet, as shown in Encapsulation Mode. The sender performs hash calculation on packets and the authentication key. When the packets carrying the calculation result arrive at the receiver, the receiver also performs hash calculation and compares the calculation result with the received calculation result. Any changes to the data during transmission will make the calculation result invalid. AH provides data origin authentication and data integrity check in this way. An integrity check is performed on an entire IP packet.

Figure 2-3 shows the AH header format.

Figure 2-3  AH header format

Table 2-1 describes the fields in an AH header.

Table 2-1  AH header fields

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 both AH and ESP are used, the next header following an AH header is an ESP header.

Payload Length

8 bits

The value of this field is the AH packet length in 32-bit words minus 2. The default value is 4.

Reserved

16 bits

This field is reserved and defaults to 0.

SPI

32 bits

This field uniquely identifies an IPSec security association (SA).

Sequence Number

32 bits

This field is a counter that monotonically increases 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 Integrity Check Value (ICV) and 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

ESP is an IP-based transport-layer protocol, with the protocol number 50. According to the ESP protocol, an ESP header is appended to the standard IP header in each packet, and an ESP tail and ESP Auth data are appended to each packet, as shown in Encapsulation Mode. Unlike AH, ESP encrypts the valid payload and then encapsulates it to a packet to ensure data confidentiality. However, ESP does not protect an IP header.

Figure 2-4 shows the ESP header format.

Figure 2-4  ESP header format

Table 2-2 describes the fields in an ESP header.

Table 2-2  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 increases from 1. It uniquely identifies a packet to prevent replay attacks.

Payload Data

-

This field contains variable-length data identified by the Next Header field.

Padding

-

This field extends the size of an ESP header. The Padding field length depends on the payload data length and algorithm. If the plaintext length of the packet to be encrypted does not comply with the encryption algorithm, the Padding field is used.

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 IP protocol number.

Authentication Data

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

This field contains the Integrity Check Value (ICV) and is used by the receiver for data integrity check. Authentication algorithms which 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.

Comparisons Between AH and ESP

Table 2-3 compares AH and ESP.

Table 2-3  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)
Data origin authentication Supported Supported
Data encryption Not supported Supported
Anti-replay Supported Supported
IPSec NAT-T (NAT traversal) Not supported Supported

According to Table 2-3, AH does not provide data encryption and ESP does not check an IP header. Therefore, use both AH and ESP when high security is required.

Encapsulation Mode

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

Transport Mode

In transport mode, an AH or ESP header is added between an IP header and a transport-layer protocol header to protect the TCP, UDP, or ICMP payload. The transport mode does not change the IP header, so the source and destination addresses of an IPSec tunnel must be the same as those in the IP header. This encapsulation mode applies only to communication between two hosts or between a host and a VPN gateway.

Figure 2-5 shows an example of TCP packet encapsulation in transport mode.

Figure 2-5  Packet encapsulation in transport mode

In transport mode, AH checks the integrity of the entire IP packet. ESP checks the integrity of the ESP header, transport layer protocol header, data, and ESP tail, excluding the IP header. Therefore, ESP cannot protect the IP header. ESP encrypts the transport-layer protocol header, data, and ESP tail.

Tunnel Mode

In tunnel mode, an AH or ESP header is added outside the raw IP header, and a new IP header added outside the AH or ESP header to protect the IP header and payload. The tunnel mode applies to communication between two VPN gateways or between a host and a VPN gateway.

Figure 2-6 shows an example of TCP packet encapsulation in tunnel mode.

Figure 2-6  Packet encapsulation in tunnel mode

In tunnel mode, AH checks the integrity of the entire IP packet including the new IP header. ESP checks the integrity of the ESP header, raw IP header, transport layer protocol header, data, and ESP tail, excluding the new IP header. Therefore, ESP cannot protect the new IP header. ESP encrypts the raw IP header, transport-layer protocol header, data, and ESP tail.

Comparisons Between the Transport Mode and Tunnel Mode

The two encapsulation modes differ in the following:

  • The tunnel mode is more secure because original IP packets can be completely authenticated and encrypted in tunnel mode. 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.

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

Encryption

Encryption is a process of converting plaintext data into ciphertext data using an algorithm. The receiver can decrypt ciphertext data only when it has the correct key. The encryption mechanism ensures data confidentiality and prevents data from being eavesdropped during transmission. IPSec involves data encryption and protocol message encryption.

Data Encryption

IPSec uses symmetric encryption algorithms to encrypt and decrypt data. Symmetric encryption algorithms require that the sender and receiver use the same key to encrypt and decrypt data.

Figure 2-7 shows the process of using a symmetric encryption algorithm to encrypt and decrypt data.

Figure 2-7  Data encryption and decryption

The symmetric key can be manually configured or generated through IKE auto-negotiation.

Common symmetric encryption algorithms include:

  • Data Encryption Standard (DES)

    DES was developed by the National Institute of Standards and Technology (NIST). It uses a 56-bit key to encrypt a 64-bit plaintext block.

  • Triple Data Encryption Standard (3DES)

    3DES is an enhancement to DES and uses three different 56-bit keys (168 bits in total) to encrypt a plaintext block.

    Compared with DES, 3DES is slower but more secure.

  • Advanced Encryption Standard (AES)

    AES is designed to replace 3DES and is faster and more secure than 3DES. AES supports three types of keys: AES-128, ES-192, and AES-256, which have key lengths of 128 bits, 192 bits, and 256 bits, respectively.

    The encryption algorithm with a longer key is more secure but slower. In general, AES-128 can meet security requirements.

Protocol Message Encryption

Protocol message encryption occurs in IKE negotiation. Symmetric encryption algorithms, such as DES, 3DES, and AES, are used to encrypt protocol messages. The symmetric key used for protocol message encryption is generated through IKE auto-negotiation.

Authentication

Authentication is an operation that a receiver performs to verify the identity of the sender (source origin authentication) and whether data has been tampered with during transmission data integrity check. IPSec ensures data reliability using source origin authentication and data integrity check together.

Although encrypted data can only be decrypted using the original encryption key, the decrypted data cannot be proved to be the original data. Additionally, data encryption and decryption consume many CPU resources, and malicious users may send spoofing packets to consume CPU resources. Keyed-Hash Message Authentication Code (HMAC) compares digital signatures to check data integrity and authenticity. This process consumes only a few CPU resources and is very efficient. Therefore, IPSec uses HMAC for authentication.

Encryption and authentication are often used together on the IPSec sender. The sender encrypts IP packets, generates a digital signature during HMAC authentication, and then sends both the encrypted IP packets and digital signature to the receiver. The digital signature is included in the Integrity Check Value (ICV) field in an AH or ESP header. For details, see Security Protocol. The receiver compares the received digital signature with the locally generated one to check data integrity and authenticity in the received IP packets. The receiver discards the packets that fail the authentication and decrypts those that pass the authentication. Figure 2-8 shows the process of encryption and HMAC authentication.

Figure 2-8  Encryption and HMAC authentication

Like an encryption key, a symmetric authentication key can be manually configured or generated through IKE auto-negotiation.

Common authentication algorithms include:

  • MD5

    MD5 is defined in RFC 1321. It generates a 128-bit signature based on a message of any length.

    MD5 is faster but less secure than Secure Hash Algorithm (SHA).

  • SHA1

    SHA was developed by the National Institute of Standards and Technology (NIST). SHA1 is a revision to SHA and was published in 1994. Defined in RFC 2404, SHA1 converts a message of a length less than 264 bits into a 160-bit message digest.

    SHA1 is slower but more secure than MD5. SHA1 generates a long signature to prevent key cracking, and discovers the shared key efficiently.

  • SHA2

    SHA2 is an enhancement to SHA1. It has a larger key length and is much more secure than SHA1. SHA2 includes SHA2-256, SHA2-384, and SHA2-512, with 256-bit, 384-bit, and 512-bit key lengths, respectively.

    The authentication algorithm with a longer key is more secure but slower. In general, SHA2-256 can meet security requirements.

  • AES-XCBC-MAC-96 is a type of AES-based message authentication algorithm and is described in RFC 3566.

The algorithms have their own strengths and weaknesses. MD5 is faster than SHA1, but less secure. SHA2 has a longer key than SHA1, which means that SHA2 is more difficult to defeat, and therefore more secure.

Key Exchange

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

  • Out-of-band key sharing

    The encryption key and authentication key are manually configured on the sender and receiver. The two parties ensure key consistency in out-of-band mode (through phones or mails for example). This mode has poor scalability and multiplies the workload in configuring the key in point-to-multipoint networking. In addition, this mode is difficult to implement because the keys need to be changed periodically to improve network security.

  • Using a secure key distribution protocol

    The key is generated through IKE auto-negotiation. The Internet Key Exchange (IKE) protocol uses DH (Diffie-Hellman) algorithm to implement secure key distribution over an insecure network. This mode is easy to configure and has high scalability, especially on a large dynamic network. Two communicating parties exchange key materials to calculate the shared key. Even through a third party obtains all the exchanged data used to calculate the shared key, it cannot calculate the shared key.

IKE

Internet Key Exchange (IKE) is a User Datagram Protocol (UDP)-based application-layer protocol built on the Internet Security Association and Key Management Protocol (ISAKMP) framework. It implements automatic key negotiation and IPSec Security Association setup, to simplify IPSec use and management, and facilitate IPSec configuration and maintenance.

Figure 2-9 shows the relationship between IKE and IPSec. The two peers establish an IKE SA for identity authentication and key information exchange. Protected by the IKE SA, the peers negotiate a pair of IPSec SAs using the Authentication Header (AH) or Encapsulating Security Payload (ESP) protocol and other parameters configured. Subsequently, data is encrypted and transmitted between the peers in an IPSec tunnel.

Figure 2-9  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 an insecure network:
  • Identity authentication

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

    NOTE:

    Efficient VPN only supports Pre-shared key authentication.

    • Pre-shared key authentication: An authentication key is used to generate a key. The two peers compute the hash value of packets using a shared key and check whether they obtain the same hash value. If they obtain the same hash value, the authentication succeeds. Otherwise, the authentication fails.
    • RSA signature authentication: The two peers use a certificate issued by a certificate authority (CA) to verify 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. If the computed hash value is the same as that decrypted from the digital signature, the authentication succeeds. Otherwise, the authentication fails.

    When a peer has multiple peers, PSK authentication requires that the same pre-shared key be configured on all peers. This authentication method can be easily implemented on small-scale networks but has low security. 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 to ensure secure transmission.

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

  • DH

    Diffie-Hellman (DH) is a public key exchange mechanism that generates key materials and uses ISAKMP messages to exchange key materials between the initiator and responder. Then the devices at both ends calculate the same symmetric key to generate the encryption key and authentication key. The two devices do not exchange the real key in any cases. DH key exchange is the core part of IKE.

    The MD5, SHA1, DES, 3DES and AES algorithms can use the DH algorithm to enable sharing of a symmetric key between two parties.

    DH uses key groups to define the key length. A longer key indicates a stronger key.

    Table 2-4  DH key group
    Key Group Key Length
    1 768 bits
    2 1024 bits
    5 1536 bits
    14 2048 bits
  • PFS

    Perfect Forward Secrecy (PFS) is a security feature that protects security of other keys in case a key is deciphered, because these keys are independent of one another. The key used in an IPSec SA is derived from the key used in an IKE SA. An IKE SA generates one or more pairs of IPSec SAs through negotiation. After obtaining the IKE key, an attacker may collect enough information to calculate the key used in the IPSec SA. To ensure security of the key, PFS performs an additional DH key exchange.

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.

Comparison Between IKEv1 and IKEv2

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 SAs for IPSec. In phase 1, two IKE peers negotiate to establish a secure channel, IKE SA. In phase 2, IKE peers establish a pair of IPSec SAs using the secure channel established in phase 1. IKEv2 generates the key and establishes SAs for IPSec in just one negotiation, simplifying the negotiation process. For details about IKEv1 negotiation and IKEv2 negotiation, see Establishing an SA Through IKEv1 Negotiation and Establishing an SA Through IKEv2 Negotiation.

  • Fixes many cryptographic vulnerabilities, enhancing security.

Translation
Download
Updated: 2019-04-01

Document ID: EDOC1000178118

Views: 157530

Downloads: 157

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