IPSec security policy and implementation

Chen Xinwang

(School of Mathematics and Computer, Fuzhou University, Fujian 350002, China) (Fuzhou 350003, Fujian Science and Technology Information Research Institute)

Abstract The relevant protocols and principles of IPsec have clarified the architecture of the security policy system and the definition and representation of security strategies and security alliances. Finally, the processing flow of the IPSec data stream is introduced. Keyword IPSec Security Security Alliance 1 IPSec Protocol Introduction For Internet Security, the Internet Engineering Task Group (IETF) issued IP layer security standard IPSec. IPSec is high-intensity security processing on the IP layer to provide access control, unconnected integrity, data source authentication, anti-replay protection (sequence integrity), confidential Services and limited transport stream confidentiality. These services are based on IP layers, providing protection for IP and its upper level protocols. 2 IPSec System Agreement is shown in Figure 1. The IPSec security architecture includes the following aspects: Figure 1 IPSec Security Architecture IP Security Structure (SA): RFC2401, general concept, security objectives, security services, constituent elements and Key mechanisms, etc., the basis and guidance of the entire protocol stack. IP certification header (AH): RFC2402 provides several functions of data source identity authentication, data integrity, and playback attack protection. IP package safety load (ESP, ENCAPSULATING PAYLOAD): RFC2406, provides data confidential, data source identity authentication, data integrity, and playback attack protection, and the subject of the protocol stack together with the AH protocol. Internet Security Alliance and Key Management Protocol (ISAKMP): RFC2408 and Internet Key Exchange (IKE) -RFC 2409, the standard process of describing the generating, negotiation, and exchange of keys. Encryption and Verification Algorithm: RFC2403, RFC 2404, RFC 2405 and RFC 2410 describe various encryption and authentication algorithms in the AH and ESP protocols, providing specific algorithm descriptions for security protocols. IP Security Doi (Domain of Interpretation) Document: RFC2407 provides standard code for other documents. PF_KEY Key Management API: RFC2367 provides an interface between IKE modules and IPSec cores. 3 Overall The IPSec uses two protocols to provide transfer security-certification headers (AH), package safety load (ESP). The IPSec implementation is the purpose of reaching IP data encryption and authentication by adding an insertion AH or ESP header in the original IP packet. The location where the IPSec protocol in the Internet can be considered to be parallel to the IP layer, in the specific packet out of processing, generally in the original IP package to add an insertion IPsec header (AH & ESP). Therefore, it is clear that the IPSec layer is between the IP layer and the data link layer, more biased to the IP layer. The IPSec security system can be used to protect a complete IP package, or protect the upper level protocol of an IP package. Both protection are provided by two different "modes" of IPsec. Among them, the transfer mode is used between two hosts, protects the upper layer protocol, inserts an IPsec header between the IP head and the upper protocol head, such as [IP head] [IPsec head] [upper protocol]; tunnel mode ( Tunnel protects the entire IP package, as long as the security alliance is a safety gateway, tunnel mode must be used. Add IPsec heads outside, encrypt the original IP package, and then encapsulate the entire handled packet with an external IP header. Such as: [external IP head] [IPsec head] [internal IP head] [upper layer agreement]. In addition, if different security protocols are applied, the content range of the protected packets is also different. For ESP, the security service provided by the Transfer Mode SA protects only the upper protocol, and does not provide protection for the IP header and the extension header.

The tunnel mode SA is not protected by the outer head; and the security services provided by the transmission mode SA can also protect some of the contents of IP headers, extensions, and certain options. The tunnel mode SA can provide protection on a portion of its outer head. In IPsec, the Security Alliance (SA) is a one-way logic connection between two IPSec systems, which is the specificity and instantiation of security policies, which provides specific details of communication. Usually use a three-way group unique representation: . SA specifies a set of security parameters for confidential communication, including: authentication algorithm, encryption algorithm, protocol mode, security alliance source address, SA's survival (TTL), and serial number counter. By using one of AH or ESP, SA provides security services for data communication it carries. IPSec's implementation needs to maintain two databases related to SA, security policy database SPD, and security alliance database SAD. The security policy database is to provide security policy configurations for IPSec, including sources, destination IP addresses, mask, ports, transport layer protocols, action (discard, bypassing,), input flags, identifiers, SA, and policy pointers. SAD is a collection of SA, its contents (RFC requirements) include destination IP addresses, security protocols, SPI, serial number counters, serial number overflow signs, anti-replay windows, SA life, and IPSec Protocol mode (transmission or tunnel), encryption algorithm and verification algorithm related projects. 3.1 SPD For an IPSec implementation point, enter the package and outbound packs require reference to the Security Policy Database (SPD). There are three possible options for each packet that enters or out: discard, bypasses IPsec or application IPSec. Discard means that you don't allow you to leave the host, pass through the security gateway, or eventually passed to an application. Bypassing means that it is allowed to pass without transmission of additional IPsec protection. Applications refer to the transmission of IPSec protection and must specify the security services provided by such transmission SPDs, the protocols, algorithms, and the like used. SPD includes an ordered list of policy portals. Each policy entry is identified by one or more selectors, which defines the IP transfer included by this policy entry. These selectors define the particle size of the policy or IPSec processing. Each entry includes an identifier that identifies the transmission of this policy that allows pass, discard, or IPSec processing. If IPSec is used, the entry should include the specification of the SA (or SA). This specification lists the algorithms of IPsec protocol, mode and use, including any nested demand. For each IPsec implementation, you must be managed interfaces. It allows users or system administrators to manage SPDs. In particular, each input or output package is based on the processing of IPsec, and the SPD must be defined in each case what behavior will be accepted. So the interface available must allow the user (or system administrator) to define security processing, which is applied to any package of entering and exit system. 3.2 The particle size of the selector SA depends on the selector. For example, all transmission between the two hosts can be transmitted through single SA and give a unified secure service set. In addition, the transmission between the host can provide different security services through multiple SAS, and different SASs provide different security services, which depends on the application (as defined in the next-generation protocol and port domain). 3.3 The record items in the SAD SAD define the parameters related to SA. Each SA should have a record item in SAD. For entering processing, SAD records use triple group ID. For outgoing processing, you should look for a pointer to SA in the SAD in the SPD to find the corresponding SA or SA bundle.

If SA is not established, SA should be established and the items in the SPD are associated with the SAD record items. 3.4 Process of AH and ESP AH Process: AH header format and content see RFC2402. There are two hosts or gateways configured for IPsec, handling the transmission and reception of IPSec packets. In the sender, the process selects the appropriate protocol mode and verification algorithm according to SPD and SAD. The AH head is then inserted into the IP packet, cleared the extinction in the packet, verifying the data packet after the verification algorithm and key abstract (default HMAC_MD5_96), send the summary data to the AH header verification Data fields. Finally, the IPSec layer forwards the packet to the data link layer. Finally send a secure packet to the recipient. At the receiver, the process is configured with the corresponding SPD and SAD. After receiving the secure packet sent by the sender, select sequence number check and anti-replay check. Then, the different fields of the packet are also cleared, and the contents of the verification data field are saved and cleared. The verification result and the saved verification data are compared to the verification result and the saved verification data, and the verification is successful. Then, peel off the AH head and the external IP head (tunnel mode). Finally, a policy check is performed. AH processing is only responsible for the integrity check of data without encrypting data. Also pay attention to the problem of PMTU. In general, try to prevent segmentation of the packet, we consider the maximum number of bytes of the AH head and ESP heads tail in the nested mode, and ensure that the original number of IPSec layers The IP package is less than the maximum number of bytes tail of the AH head and the ESP header, so that the function and burden of IPSec is not caused by segmentation processing of the IPSec layer. ESP processing: The format and content of the ESP header and the end of the RFC2406. ESP processing is similar to AH processing. ESP processing completes all the features of AH processing and provides data encryption. For output data packet processing, first, encryption processing is performed according to SPD and SAD (the default encryption algorithm is 3DES, encryption key IKE negotiation generation, or manual negotiation). For transmission mode, encryption items include upper protocol headers (such as TCP headers), data content, and ESP tail. For tunnel mode, encryption items also include internal IP headers (IP-IP). Then, it is the verification of the packet. It must be noted that the verification item does not include the IP header outside the ESP header. The final step of the ESP out of the packet processing is to recalculate the checksum of the IP header in front of the ESP. Other processes are processed with AH. For input packet processing, the processing flow is basically the same AH. It should be noted that the decryption must be verified first. The algorithm and key are determined by the SA negotiated by communication. After the policy is checked, you have to recalculate the IP checksum. 3.5 IPsec Data Stream Processing Data Stream Input Process: 1) Module Receives an IP Package; AH or ESP, if not, according to its address check SPD, if there is a correspondence policy, discard the packet is bypassed; (IPsec is only responsible for the processing of IPsec package) 4) Check the three-way group to obtain the SAID pointer;

5) query SAD according to SAID

IF SA is empty

[Query strategy; (according to Selector, find the corresponding SPD, take Action in the SPD)

IF is unprocessed;

IF discards packet loss;

IF application packet loss;

IF no policy is not processed]

IF SA expires packet loss;

IF SA state abnormally packet loss;

6) Check the serial number SEQ, anti-playback;

7) According to the next protocol, the AH / ESP processing module is sent to the AH / ESP processing module, respectively, and stripped the AH head or ESP head and tail;

8) During the strategy (or SA), it is known to use transmission mode or tunnel mode; 9) If Tunnel Mode, remove the external IP header;

10) Policy check for this new IP package (if there is no policy, declaration);

11) Check the "NextProto" field of the new internal IP header. If it is not an IPsec header, the processing ends, returns.

12) If the destination address of the IP head is not himself, forward it.

13) If it is still an IPsec package, turn 4).

Data flow output processing:

1) The module takes out an IP package;

2) According to the Selector query policy database SPD, according to the Action determination or discardment, if there is no SPD, bypass;

3) Query the SA or SA bunch corresponding to the SPD (the real destination address is available)

IF no sa

Hand-building; or IKE dynamically established; or bypass;

IF has SA

SA Life Duration, State Judgment Download Adobe Reader

4) Send policies, SA, and original IP packets to AH / ESP module processing (responsible for inserting AH head (ESP header and tail) and external IP header according to transfer mode and channel mode (at this time, at this point) The address is set as the internal head)));

5) There is a gateway application in the IF strategy and there is a policy to the gateway;

6) Look for the corresponding SA according to the strategy

IF no sa

Hand-building; or IKE dynamically established; or bypass;

IF has SA

SA Life Duration, State Judgment Download Adobe Reader

7) Processing the strategy, SA (bundle) and the processed IPSec package AH ​​/ ESP module. (At this point IP header destination address is gateway);

8) The IPSec is processed.

Reference 1 S. Kent, R. Atkinson, "Security Architecture for the Internet Protocol", http://www.ietf.org/rfc/rfc2401.txt, 1998.112 S. Kent, R. Atkinson, IP Authentication Header AH) ", http://www.ietf.org/rfc/rfc2402.txt, 1998.113 S. Kent, R. Atkinson," IP Encapsulating Security Payload (ESP), http://www.ietf.org/rfc /RFC2403.TXT, 1998.114 D. McDonald, C. Metz, B. Phan, "PF_KEY Key Management API, Version 2", http://www.ietf.org/rfc/rfc2367.txt, 1998.7