Reprint IPSec-related knowledge-unknown source

Directory

Ipsec

Introduction to IPSec

Protocol implementations of IPSec

Basic IPSec Concepts

Encryption Card

IPSec Virtual Tunnel interface

Protecting IPV6 routing protocols with IPSec

IKE

IKE Introduction

Security mechanisms for IKE

The exchange process of IKE

The role of IKE in IPSec

The relationship between IPSec and Ike

IPSECIPSEC Introduction

IPsec (IP Security) is a three-layer tunneling encryption protocol developed by the IETF that provides high-quality, interoperable, cryptography-based security assurances for data transmitted over the Internet. The following security services are provided by the specific communication parties in the IP layer through encryption and data source authentication, and so on:

L Data Confidentiality (confidentiality): The IPSec sender encrypts the packet before transmitting it over the network.

Data Integrity: The IPSec receiver authenticates the packets sent by the sender to ensure that the data has not been tampered with during transmission.

• Data authentication: IPSec can authenticate the sender of the sending IPSec message at the receiving end.

L Anti-Replay (anti-replay): IPSec receivers can detect and refuse to receive outdated or duplicated messages.

IPSec has the following advantages:

L Support IKE (Internet Key exchange, Internet Keys Exchange), can realize the auto-negotiation function of key, reduce the cost of key negotiation. The services of SA can be established and maintained through IKE, simplifying the use and management of IPSec.

All applications and services that use the IP protocol for data transfer can use IPSec without having to make any modifications to these application systems and services themselves.

The encryption of data is in the packet, not in the whole data flow unit, which is not only flexible but also helps to further improve the security of IP packets, which can effectively prevent network attacks.

Protocol implementations of IPSec

The IPSec protocol is not a separate protocol, it gives a complete set of architectures applied to network data security on the IP layer, including network authentication protocol AH (Authentication header, authentication header), ESP (Encapsulating Security Payload, encapsulated security payload), IKE (Internet Key exchange, Internet Key exchange) and some algorithms for network authentication and encryption. Where the AH protocol and the ESP protocol are used to provide security services, the IKE protocol is used for key exchange. For more information about Ike, see "2 ike Configuration", which is not covered in this section.

IPSec provides two security mechanisms: Authentication and encryption. The authentication mechanism enables the data receiver of the IP communication to verify the true identity of the sender of the data and whether the data has been tampered with during transmission. The encryption mechanism ensures the confidentiality of data by encrypting the data to prevent the data from being bugged during transmission.

The AH protocol in the IPSec protocol defines the authentication application method, provides the data source authentication and the Integrality guarantee, the ESP protocol defines the encryption and the optional authentication application method, provides the data reliability assurance.

The L-AH Protocol (IP protocol number 51) provides data source authentication, data integrity checking, and anti-message replay, which protects communications from tampering, but does not prevent eavesdropping and is suitable for transmitting non-confidential data. Ah works by adding an authentication header to each packet, which is inserted behind the standard IP header to provide integrity protection for the data. The optional authentication algorithms are MD5 (Message Digest), SHA-1 (Secure Hash algorithm), and so on.

The ESP protocol (IP protocol number 50) provides encryption, data source authentication, data integrity check, and anti-message replay function. ESP works by adding an ESP header behind the standard IP header of each packet and appending an ESP tail to the packet. Unlike the AH protocol, ESP encrypts user data that needs to be protected before it is encapsulated in an IP packet to ensure the confidentiality of the data. The common encryption algorithms are DES, 3DES, AES and so on. At the same time, as an option, the user can choose MD5, SHA-1 algorithm to ensure the integrity and authenticity of the message.

In the actual IP communication, you can use either of these protocols or choose one of them depending on the actual security requirements. Both AH and ESP can provide authentication services, but the authentication service provided by AH is better than esp. When using both AH and ESP, the device supports the use of AH and ESP in the same way: first the packet is ESP encapsulated, then the message is in the AH package, the package after the message from the inside to the outside of the original IP packet, ESP header, AH header and external IP header.

IPSec basic concept 1. Safety Alliance (Security Association,sa)

IPSec provides secure communication between two endpoints, which is called an IPSec peer.

SA is the foundation of IPSec and the nature of IPSec. An SA is a contract between communication peers for certain features, such as which protocol to use (AH, ESP, or both), the encapsulation mode of the Protocol (transport mode and tunnel mode), the encryption algorithm (DES, 3DES, and AES), the shared key that protects the data in a particular stream, and the lifetime of the key. There are two ways to set up SA, manual configuration and IKE auto-negotiation.

The SA is unidirectional, with two-way communication between two peers, requiring a minimum of two SAS to secure each data stream in two directions. Also, if two peers want to use both AH and ESP for secure communication, each peer will build a separate SA for each protocol.

The SA is uniquely identified by a ternary group that includes the SPI (Security Parameter index, safety parameter indexes), destination IP address, security protocol number (AH or ESP).

The SPI is a 32-bit numeric value that uniquely identifies the SA, which is transmitted in the AH and ESP headers. When you manually configure the SA, you need to manually specify the value of the SPI. When an SA is generated using IKE negotiation, the SPI is randomly generated.

The SA established through IKE negotiation has a life cycle, and the manually established SA never ages. The lifetime of the SA established by IKE negotiation is defined in two ways:

L The time-based life cycle defines the time when an SA is established to expire;

L defines the maximum amount of traffic that an SA allows to process, based on the lifetime of the traffic.

The life cycle reaches the specified time or the specified traffic, and the SA is invalidated. Before the SA expires, IKE will establish a new SA for IPSec negotiation, so that the new SA is ready before the old SA expires. Continue to use the old SA protection communication until the new SA starts negotiation and does not negotiate well. After the new SA is negotiated, the new SA protection communication is applied immediately.

2. Package mode

There are two modes of operation for IPSec:

L Tunnel (Tunnel) mode: The user's entire IP packet is used to calculate the AH or ESP header, AH or ESP header, and ESP encrypted user data is encapsulated in a new IP packet. Typically, tunnel mode is used for communication between two security gateways.

L Transfer (transport) mode: Only the transport layer data is used to calculate the AH or ESP header, AH or ESP header, and ESP encrypted user data is placed behind the original IP header. Typically, transport mode is applied to communication between two hosts, or between a host and a secure gateway.

Different security protocols are shown in the data package form 1-1 in the tunnel and transport modes, and data is the transport layer.

Figure 1 Secure Protocol Data Encapsulation format

3. Authentication algorithm and encryption algorithm

(1) Authentication algorithm

The implementation of the authentication algorithm is mainly through the hash function. A hash function is an algorithm that can accept any long message input and produce a fixed-length output called a message digest. The IPSec peer calculates the digest, and if the two digests are the same, the message is intact and unaltered. IPSec uses two authentication algorithms:

L MD5:MD5 generates a 128bit message digest by entering a message of any length.

L Sha-1:sha-1 generates a 160bit message digest by inputting a message with a length of 64 bits less than 2.

The MD5 algorithm is faster than the SHA-1 algorithm, while the SHA-1 algorithm has higher security strength than MD5 algorithm.

(2) Encryption algorithm

The implementation of encryption algorithm mainly through symmetric key system, it uses the same key to encrypt and decrypt data. The current device IPSec implementation of three encryption algorithms:

L-DES (Data Encryption Standard): A 64bit plaintext block is encrypted using a 56bit key.

L 3DES (Triple des): PlainText is encrypted using three 56bit DES keys (a total of 168bit keys).

AES (Advanced encryption): PlainText is encrypted using the AES algorithm with 128bit, 192bit, or 256bit key lengths.

The security of the three encryption algorithm from high to low in order is: AES, 3DES, DES, security High encryption algorithm implementation mechanism is complex, the operation speed is slow. For common security requirements, the DES algorithm can meet the needs.

4. Modalities for Consultation

There are two types of negotiation methods to establish SA:

The manual (manual) configuration is complex, and all the information required to create the SA must be configured manually, and some advanced features, such as a timed update key, are not supported, but the advantage is that IPSec functionality can be implemented independently of IKE.

The IKE auto-negotiation (ISAKMP) approach is relatively straightforward and requires only the information of the IKE negotiation security policy to be configured and the SA to be created and maintained by IKE Auto-negotiation.

When the number of peer devices to communicate with is low, or in a small static environment, it is possible to manually configure the SA. For medium and large dynamic network environments, it is recommended to use IKE negotiation to establish an SA.

5. Safe Tunnel

A secure tunnel is a channel that can be interconnected between the local and the peer, consisting of one or more pairs of SAS.

Encryption Card

IPSec can be implemented via software on the device, and also through an encryption card. Through the software implementation, because of the complex encryption/decryption, authentication algorithm will occupy a large amount of CPU resources, thus affecting the overall processing efficiency of the device, and through the encryption card, complex algorithm processing on the hardware, thereby improving the processing efficiency of the equipment.

Encryption card for the process of encryption/decryption processing is: The device will need to add/decrypt processing data to the encryption card, encryption card processing data, and then the encryption card will be processed after the data sent back to the device, and then forwarded by the device for processing.

IPSec virtual Tunnel interface 1. Overview

The IPSec virtual tunnel interface is a three-layer logical interface that supports routing, which can support dynamic routing protocols, and all messages routed to the IPSec virtual tunnel interface will be IPSec protected while supporting multicast traffic protection. Establishing an IPSec tunnel using the IPSec Virtual tunneling interface has the following advantages:

L Simplified Configuration: route to determine which traffic is IPSec protected. This simplifies the configuration of the IPSec security policy when the user is deployed in a way that is not affected by network planning, enhances network planning scalability, and reduces network maintenance costs, as compared to specifying the range of data streams through ACLs.

• Reduce overhead: In a networking application that protects remote access user traffic, packet encapsulation at the IPSec virtual tunnel interface eliminates the need for additional encapsulation of GRE headers or L2T for incoming tunnel traffic compared to IPSec over GRE or IPSec over L2TP tunnel encapsulation The P-header reduces the level of packet encapsulation and saves bandwidth.

More flexibility in business applications: IPSec virtual Tunnel interface in the implementation of the clear areas of the "pre-encryption" and "post-encryption" two phases, users can flexibly choose other services (such as NAT, QoS) implementation phase according to different networking requirements. For example, if the user wishes to apply QoS to messages before the IPSec encapsulation, the QoS policy can be applied on the IPSec virtual Tunnel interface, and QoS policies can be applied on the physical interface if you want QoS to be applied to the IPSec encapsulated message.

2. Working principle

The packet encapsulation/unpacking of the IPSec virtual tunnel interface takes place on the tunnel interface. After the user traffic reaches the device that implements the IPSec configuration, messages that require IPSec processing are forwarded to the IPSec virtual Tunnel interface for encapsulation/unpacking.

As shown in 1-2, the IPSec virtual tunneling interface encapsulates the message as follows:

Figure 2 IPSec Virtual Interface tunnel Plus package schematic diagram

(1) The router will send the IP plaintext received from the incoming interface to the forwarding module for processing;

(2) The forwarding module sends IP plaintext to the IPSec virtual tunnel interface for encapsulation according to the routing query result: The original IP packet is encapsulated in a new IP packet, and the source address and destination address in the new IP header are the source and destination addresses of the tunnel interface, respectively.

(3) After the IPSec virtual tunnel interface completes the encapsulation processing of the IP plaintext, the IP ciphertext is sent to the forwarding module for processing.

(4) After the second routing query, the IP cipher is forwarded through the actual physical interface of the tunnel interface.

As shown in 1-3, the IPSec virtual tunneling interface encapsulates the message as follows:

Figure 3 schematic diagram of the IPSec Virtual Interface Tunnel solution Encapsulation

(1) Router will send the IP ciphertext received from the incoming interface to the forwarding module for processing;

(2) The forwarding module identifies the destination of this IP cipher as the tunnel interface address of this device and the IP protocol number is AH or ESP, the IP cipher will be sent to the corresponding IPSec virtual tunnel interface for the solution encapsulation: the IP ciphertext of the outer IP header is removed, the internal layer of IP messages to decrypt processing.

(3) After the IPSec virtual tunnel interface completes the encapsulation of the IP ciphertext, the IP plaintext is sent back to the forwarding module for processing;

(4) After the forwarding module makes a second routing query, the IP plaintext is forwarded out from the actual physical interface of the tunnel.

As can be seen from the encapsulation/unpacking process described above, the IPSec virtual tunneling interface divides the IPSec processing area of the message into two phases: before encryption and after encryption. Services that need to be applied to plaintext before encryption, such as NAT, QoS, can be applied to the tunnel interface, and services that need to be applied to encrypted ciphertext can be applied to the corresponding physical interface of the tunnel interface.

Protecting IPV6 routing protocols with IPSec

The support of this feature is related to the type of equipment, please take the actual situation of the equipment as the subject.

The use of IPSec to protect the IPV6 routing protocol refers to the use of the AH/ESP protocol to add/unpack the IPV6 routing protocol packets, and provide them with authentication and encryption security services, currently supports OSPFV3, IPv6 BGP, ripng routing protocol.

The way IPSec handles the protection of IPV6 routing protocol messages differs from the current interface-based approach to IPSec, which is service-based IPSec, that is, IPSec protects all messages for a business. In this way, all the IPV6 routing protocol messages that the device generates that require IPSec protection are encapsulated, and the IPV6 routing protocol messages received by the device that are not protected by IPSec and that fail to encapsulate (decrypt or verify) are discarded.

In the case of interface-based IPSec processing, each message sent by the device to an interface configured with IPSec security is judged whether IPSec is being processed. At present, there are two implementations of this approach, one is ACL-based IPSec, as long as the message that arrives at the interface matches the ACL rules in the IPSec security policy of the interface, it is protected by IPSec, and the other is route-based IPSec, the IPSec virtual tunnel interface, Packets routed to the virtual tunnel interface are protected by IPSec.

In contrast to interface-based IPSec, business-based IPSec does not require ACLs to qualify the scope of the stream to be protected, nor does it need to specify the start and end of the IPSec tunnel, and IPSec security policy is only tied to the specific business, which is protected by IPSec regardless of which interface the business message is sent from the device.

Because the key exchange mechanism for IPSec is only applicable to communication protection between two o'clock, IPSec cannot implement automatic exchange of keys in a one-to-many broadcast network, so you must use manual configuration of keys. Similarly, because of the one-to-many features of the broadcast network, each device is required to use the same SA parameter (the same SPI and key) for incoming and outgoing messages. Therefore, only the SA generated by the manual security Policy is currently supported to protect the IPV6 routing protocol packets.

Ikeike Introduction

During IPSec implementation, you can use the IKE (Internet Key exchange, Internet Keys Exchange) protocol to establish the SA, which is established by ISAKMP (Internet Security Association and key Management Protocol, Internet Security Alliance and Key Management Protocol) are defined on the framework. IKE provides IPSec with the ability to automatically negotiate Exchange keys, establish SA services, simplify the use and management of IPSec, and greatly simplify the configuration and maintenance of IPSec.

IKE does not transmit the key directly on the network, but rather through the exchange of a series of data, which ultimately computes the shared secret between the two parties, and is not sufficient to compute the true key even if the third party intercepts all the exchanged data used to compute the key.

Security mechanisms for IKE

IKE has a set of self-protection mechanisms that can securely authenticate identities, distribute keys, and establish IPSec SAS on unsecured networks.

1. Data authentication

Data authentication has the following two concepts:

L Identity Authentication: Identity authentication confirms the identity of both parties to the communication. Two authentication methods are supported: Pre-shared Key (Pre-shared-key) authentication and PKI-based digital signature (rsa-signature) authentication.

Identity protection: Identity data is encrypted and transmitted after the key is generated, which realizes the protection of identity data.

2. DH

DH (Diffie-hellman, Exchange and Key distribution) algorithm is a public key algorithm. A shared key is computed by exchanging some data without transmitting the key. Even if a third party (such as a hacker) intercepts all the exchange data used to compute the key, it is not enough to compute a real key because of its high complexity. Therefore, DH Exchange technology can ensure that both parties can secure access to public information.

3. PFS

PFS (Perfect Forward Secrecy, the perfect forward security) feature is a security feature that means that a key is cracked and does not affect the security of other keys because there is no derivation between these keys. For IPSec, this is achieved by adding a key exchange during the IKE Phase 2 negotiation. The PFS feature is guaranteed by the DH algorithm.

The exchange process of IKE

IKE uses two phases for key negotiation for IPSec and establishes SA:

(1) In the first phase, the communication parties have established a channel of identity authentication and security protection, that is to establish a ISAKMP SA. The first stage has two IKE switching methods, main mode and Savage mode (aggressive modes).

(2) In the second phase, the security tunnel established in the first phase is used to negotiate security services for IPSec, that is, to negotiate a specific SA for IPSec, and to establish an IPSec SA for the eventual secure transfer of IP data.

Figure 4 Main Mode Exchange process

As shown in 2-1, the IKE negotiation process for the first stage main mode contains three pairs of messages:

L The first pair is called SA exchange, is to negotiate the process of confirming the relevant security policy;

The second pair of messages called key exchange, Exchange Diffie-hellman common values and auxiliary data (such as: random number), the key material is generated at this stage;

The last pair of messages is ID information and authentication data exchange, identity authentication and authentication of the entire first phase of the exchange content.

The main difference between Savage mode switching and main mode switching is that brute mode does not provide identity protection and only exchanges 3 messages. In situations where the requirement for identity protection is low, the use of brute mode with less exchange messages can increase the speed of negotiation, and the main mode should be used in situations where the requirement for identity protection is high.

The role of IKE in IPSec

l Because of the ike,ipsec many parameters (such as: key) can be automatically established, reducing the complexity of manual configuration.

The DH exchange process in the IKE protocol is not correlated with each calculation and the resulting results. The DH exchange process is run every time the SA is established, ensuring that the keys used by each SA are not relevant.

L IPSec uses the serial number in the AH or ESP header to enable anti-replay. This serial number is a 32-bit value, after which the SA needs to be re-established for anti-replay, and this process requires a mate of the IKE protocol.

• Authentication and management of the identity of all parties to secure communications will affect the deployment of IPSec. For large-scale use of IPSec, there must be involvement of CAS (Certificate authority, certification authorities) or other agencies that centrally manage identity data.

L IKE provides dynamic authentication between end and end.

The relationship between IPSec and Ike

Figure 5 Diagram of IPSec vs ike

From Figure 2-2 we can see the relationship between Ike and IPSec:

IKE is an application-layer protocol above UDP and is a signaling protocol for IPSec;

IKE establishes SA for IPSec negotiation and gives IPSec the established parameters and the generated key;

IPSec uses IKE-established SA to encrypt or authenticate IP packets.

Accessories download

• Introduction to IPSec technology. PDF (222.96 KB)

Reprint IPSec-related knowledge-unknown source