IPSec can be configured to operate in two different modes, Tunnel and Transport mode. Use of each mode depends on the requirements and implementation of IPSec. IPSec tunnel mode is the default mode. Tunnel mode is most commonly used between gateways Cisco routers or ASA firewalls , or at an end-station to a gateway, the gateway acting as a proxy for the hosts behind it.
The client connects to the IPSec Gateway. Traffic from the client is encrypted, encapsulated inside a new IP packet and sent to the other end. The AH does not protect all of the fields in the New IP Header because some change in transit, and the sender cannot predict how they might change. The IPSec receiver discards any packets that fail the authentication and decrypts only those that pass the authentication. 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.
MD5 and SHA1 are not recommended because they are insecure and pose security risks. 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:. 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. 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. Subsequently, data is encrypted and transmitted between the peers in an IPSec tunnel. After a key is generated, identity data is encrypted using the key to ensure secure transmission.
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. The more secure AES algorithm is recommended.
In phase 2, the peers establish a pair of IPSec SAs through the secure channel established in phase 1. Security Low High Applicable scenario Small-sized networks Large-, medium-, and small-sized networks. Figure AH header format. Figure ESP header format. Sequence Number 32 bits This field is a counter that monotonically increments from 1. Payload data - This field contains the protected variable-length data content in the original IP packet.
Padding - This field extends the payload data to a size that fits the encryption's cipher block size. Pad Length 8 bits This field specifies the length of the Padding field. The value 0 indicates no padding. Authentication Data Integral multiple of 32 bits. It is 96 bits in common cases. Figure Packet encapsulation in transport mode. Figure Packet encapsulation in tunnel mode.
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. Encryption and Authentication IPSec provides two security mechanisms: encryption and authentication. Encryption IPSec uses symmetric encryption algorithms to encrypt and decrypt data. Figure Data encryption and decryption process.
Figure Authentication process. 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.
Comparison between the transport mode and the tunnel mode is as follows:. The tunnel mode is more secure than the transport mode. In tunnel mode, the original IP packet can be authenticated and encrypted completely. Besides, the internal IP address, protocol type, and port are hidden. The tunnel mode occupies more bandwidth because of an extra IP diver.
Encryption is a process in which plain text data is transformed into unreadable cipher text. The responder can decrypt the data only by using the correct key.
In this way, encryption ensures the data confidentiality. ESP can encapsulate content of IP packets to protect them during transmission. IPsec uses symmetric encryption algorithms to encrypt and decrypt data. When a symmetric encryption algorithm is used, the initiator and responder use the same key to encrypt and decrypt the data. The symmetric key can be manually configured, or generated through the DH algorithm and shared by both devices.
IPsec uses the following encryption algorithms:. Protocol message encryption is used in IKE negotiation. The symmetric key used for encryption is generated through the DH algorithm. HMAC uses the hash function, with the symmetric key and data packet as the hash input.
The receiver compares the ICV digital signature generated on the local end with that sent by the peer end to check the integrity and authenticity of the data.
Authentication contains data source check and data integrity authentication because the two security services are provided as a suite. Data integrity authentication is implemented on the basis of each IP packet, in which the data integrity authentication key sent from the peer end is calculated to provide data source check indirectly.
Although the encrypted data can be decrypted only by using the key used for encryption, the authenticity of the decrypted data still cannot be verified. Besides, the encryption and decryption processes consume much CPU resources.
Malicious users may take advantage to send spoofed packets to overload CPU resources. The HMAC function checks the data integrity and authenticity by comparing the digital signatures. The whole process is efficient and occupies few CPU resources.
Therefore, encryption and authentication are used together in devices that initiate IPsec VPN connections. The encrypted packet is processed through HMAC to generate a digital signature. For details, see Security Protocol.
The responder device compares the digital signature to check data integrity and authenticity. Packets that fail to pass the authentication are discarded, and those that pass the authentication are decrypted. MD5: generates a bit message summary for an input message of any length. SHA generates a bit message summary for an input message of less than 2 64 bits. SHA generates a bit message summary for an input message of less than 2 bits. In IKE, key exchange needs to be performed between both ends of a tunnel to ensure that they use the same key to encrypt and decrypt data.
In encryption and authentication using symmetric key, how to share keys securely is an important problem. The following methods can be used to resolve the problem:. Out-of-band key sharing. Manually configure static encryption and authentication keys on the initiator and responder devices. The consistency of keys on both ends can be ensured through out-of-band key sharing through telephone calls or emails.
The method does not provide much scalability. The workload increases by multiple times in site-to-multisite networking. Besides, to enhance network security, the key requires periodic changes, which is difficult to implement in this method. Key delivery using a secure connection. IPsec implements secure key negotiation between the initiator and responder devices using the IKE protocol. IKE uses the DH algorithm to exchange key information on insecure networks and generates encryption and authentication keys.
This method provides simple configuration and high scalability, which becomes more remarkable on large-scale dynamic networks. IKE provides services such as key exchange and the establishment of SAs through automatic negotiation. ISAKMP provides methods for security service negotiation, information exchange during key exchange, and authentication of peers.
The essence of IKE is that it never transmits the key directly on insecure networks, but calculates the key by exchanging a series of data. Even if a third party intercept all the exchanged data used for key calculation, it cannot figure out the real key. The core technology is Diffie Hellman DH switching technology.
DH, also called the public key exchange method, is used to generate key materials. Then, the devices at both ends calculate the same symmetric key. The symmetric key is used for the calculation of encryption and authentication keys. The two devices do not exchange the real key in any cases.
Each party for exchanging the DH keys generates a random number, for example, a or b. Based on base number g and mode number p, power arithmetic and modular arithmetic are performed using random numbers a and b to obtain results c and d. The calculation formula is as follows:. Calculation results c and d are exchanged. This formula can be proved mathematically. The public DH value is the key for both parties. The DH key exchange process is implemented by exchanging two packets:. If a third party on the network intercepts c and d, the third party needs to obtain a and b to calculate the public DH value g ab mod p.
However, a and b are not transmitted directly on the network. If the third party intends to calculate a or b using c and d, discrete logarithm operation is required. However, p is a prime number. When p is large enough generally, a binary number with more than bits , the calculation is extremely complex, proved mathematically. It is considered that it is impossible to calculate a or b in this method. Therefore, the DH key exchange technology ensures that both parties securely obtain key information.
The DH defines the length of a generated key using the key group. The longer the key length, the more secure the key.
However, the calculation time prolongs with the key length increase. IPsec provides secure communication between IPsec peers two communication ends. An SA functions as a convention for some elements of IPsec peers, and is used to protect protocol packets, providing IPsec with essential functions.
It defines the security protocol to be applied, encapsulation mode, authentication mode, and shared key for protocol packets protection. SAs are protocol-specific. Two SAs one for incoming protocol packets and one for outgoing protocol packets are configured for AH and the other two SAs one for incoming protocol packets and one for outgoing protocol packets are configured for ESP. Similarly, four SAs with equivalent relationships are required on Device B. In manual configuration mode, you can set some parameters on both ends.
After parameters on both ends match and the negotiation is successful, an IPsec SA is established. The manual configuration mode is complex, because all information required for establishing an IPsec SA needs to be manually configured. Specific advanced features such as periodic key update of IPsec are not supported. However, the advantage of the manual configuration mode is that IPsec functions can be implemented without relying on IKE.
The automatic negotiation mode is initiated and maintained by IKE. Both parties establish an SA after matching and negotiation based on respective security policy library, without user intervention.
IKE is a hybrid protocol. DH key exchange. Perfect Forward Secrecy PFS : If a key is cracked, security of other keys is not affected because these keys do not have a legacy relationship. PFS is ensured by the DH algorithm. This feature is implemented by adding the key exchange mechanism to IKE phase-2 negotiation.
Authentication: Authentication is used to verify identities of both communication parties. In the pre-shared key PSK method, an authenticator is used to generate a key for a party. If authenticators are different, the generated keys are different. The authenticator is a key factor used to verify identifies of both parties. Identity protection: Identity data is encrypted for transmission after a key is generated, thereby protecting the identity data.
That is, two messages can accomplish the task. IKEv2 defines three types of exchange, namely, initial exchange, creating Child SA exchanges, and notification exchange.
Initial exchange. The two exchanges usually involve four messages. The number may increase in certain scenarios. All communications that use IKE consist of requests and replies. The details are as follows:. The message pair is responsible for the negotiation of IKE SA parameters, including the encryption and authentication algorithm negotiation, and Nonce and DH exchange. Other related keys can be derived from the shared key material. During the exchange of the two packets, identity authentication is implemented and a Child SA is established.
For RSA signature authentication and pre-shared key authentication, the calculation methods of the authentication payloads AUTH payloads are different. Creating Child SA exchanges. Creating a Child SA exchange involves an exchange and two messages. The exchange must be implemented after IKE initial exchange is completed. The initiator of the exchange can be the initiator or responder of IKE initial exchange. The two messages in the exchange need to be protected by the key negotiated in IKE initial exchange.
After the key material is generated, all keys of the Child SA can be derived from the key material. Notification exchange. The two ends involved in IKE negotiation sometimes send certain control messages such as error messages or notification messages. Such messages are transferred in notification exchange in IKEv2. That is, notification exchange must come after initial exchange. Because a network entity can create multiple pairs of SAs, a database is required to store and manage the SAs.
IP connectivity between the peers may be lost due to routing problems or peer reloading. The IKE protocol has no peer detection function. If an IKE peer is unreachable, no measure can be taken other than waiting for the expiration of the SA lifetime. The SA remains until its lifetime expires. Unreachable SA peers can result in a black hole, resulting in data dropping. Generally, you need to identify and detect the black hole to restore IPsec communications.
The keepalive mechanism can address the preceding issue. According to the keepalive mechanism, IKE peers periodically exchange the Hello or ACK messages to inform the peers that they are active. In such circumstances, the keepalive mechanism is limited. When an IKE peer needs to learn whether the peer end is online, the IKE peer can send the request at any time instead of at the specified time interval.
When normal IPsec traffic is transmitted between peers, the peer end is online. Therefore, it is unnecessary to send an extra detection message to detect whether the peer end is online. If no IPsec traffic is transmitted within a period of time, the local end can send a DPD message to detect the state of the peer end. DPD provides two mode parameters: interval and on-demand. If the local end does not receive traffic from the peer end within an interval specified by check-interval , the local end sends DPD packets at the interval.
If the local end does not receive a response packet from the peer end, the local end retransmits DPD packets. If the local end still does not receive a response packet from the peer end after the retransmission is complete, the local end deletes the local SA entries and performs the tunnel establishment process again.
If the local end does not send any encrypted traffic, it does not send DPD packets. If the local end sends encrypted traffic but does not receive traffic from the peer end within an interval specified by check-interval , the local end sends DPD packets at the interval. IKEv2 security is analyzed here. The following describes the security of IKEv2. Defense against man-in-the-middle attacks. The man-in-the-middle attack is a kind of proactive attack.
During the attack, the attacker eavesdrops on the communications parties to capture the messages. After inserting data into the messages, or deleting or changing the information in the messages, the attacker returns the changed messages to the sender, or replays or redirects the original messages. This is the most harmful attack. In IKEv2, the mechanism and methods for defending against man-in-the-middle attacks is as follows:.
Modes for generating key materials. The key materials of IKEv2 are different from those of IKE in that the encryption key and the authentication key used for follow-up interactions are different. Therefore, it is more difficult for the attacker to guess the keys. As a result, the keys are less likely to be disclosed, transmission becomes safer, and to a certain extent, man-in-the-middle attacks are prevented. IKEv2 performs authentication by using pre-shared keys and digital signatures.
The authentication is two-way authentication. The negotiation parties authenticate each other. In addition, the authentication is symmetrical.
The negotiation parties use the same mechanism and method to authenticate each other. The two-way authentication can effectively defend against man-in-the-middle attacks.
In addition, IKEv2 defines extended authentication. That is, the negotiation parties authenticate each other through the method described in EAP. The extended authentication supports asymmetrical two-way authentication, further improving the flexibility of authentication and expansibility of negotiations. Message exchange. So, the messages contain the nonce values. When an attacker returns the messages to their senders, the senders can decide whether the messages are real.
This can prevent replay attacks to a certain extent. Each IKEv2 message diver contains a message ID, which is used for matching the corresponding request and reply messages, and identifying replay attacks. When a request is sent or received, the message ID must be increased in number order. IKEv2 introduces the sliding window mechanism so that interactions can effectively resist replay attacks.
Defense against DoS attacks. SPI value. Only one of the requests with the same SPI value is processed, excluding retransmission messages. Other requests are discarded as repeated data. This mechanism can prevent DoS attacks to a certain extent. Interactions with cookies. IKEv2 defends against DoS attacks through auxiliary exchanges during which the Notify payload carries cookies.
During communications, when the responder deems that it is suffering from DoS attacks, it can request a stateless cookie from the initiator.
0コメント