WO2005048553A1

WO2005048553A1 - A METHOD ON EMBEDDING IPSec PROTOCOL STACK

Info

Publication number: WO2005048553A1
Application number: PCT/CN2003/001077
Authority: WO
Inventors: Kaiqu Chen; Zhuoming Li; Jie Zhao; Haibin Chen; Yahui Li; Yong Ding; Zhiwei Peng
Original assignee: Zte Corporation
Priority date: 2003-11-13
Filing date: 2003-12-17
Publication date: 2005-05-26
Also published as: CN1545292A; CN100512278C; AU2003292854A1

Abstract

The invention discloses a method on embedding IPSEC IP protocol stack, including the embedding method when inputs IP packet and outputs IP packet; wherein, the embedding method when IP packet inputs including: deal the inputting IP packet with the IP inputting process basically; deal the said IP packet with inputting process; deal the IP packet processed by IPSec inputting process with other process; the embedding method when IP packet outputs including: deal the IP packet with the IP inputting process basically; deal the said IP packet with outputting process; deal the IP packet processed by IPSec outputting process with other process. Use the method provided by the invention, overcome the shortcoming about the embedding manner of the FreeSWAN and KAME, realize the integrate function of the IPSEC, for example, check the forwarding IP packet security policy; check the non-IPSEC packet of the local computer security policy; support nesting security policy; support high security granularity; process the thing which IP is subsection after decapsulating the IPSEC.

Description

Method for embedding IPSec in IP protocol stack

The invention belongs to information security technology in the field of information technology, and relates to a method for implementing Internet Protocol Security (IPSec for short), in particular to a method for embedding 4 bar IPSec into an IP protocol stack.

Background technique

In the following, IP refers to the Internet communication protocol Internet Protocol, and IPSec refers to the protocol that provides security protection for IP, IP Security.

Generally, the IP protocol itself is an insecure protocol, and IP packets may be attacked by eavesdropping, tampering, and retransmission during the transmission process. To overcome these weaknesses, the IETF (Internet Standards Organization) designed the IPSEC protocol family to provide security protection for IPv4 and IPv6 messages, including data source authentication, connectionless data integrity, anti-replay protection, data confidentiality, and limited Confidentiality of business flow, etc.

The IPSec protocol family can provide security services for the IP layer, enabling the system to select the required security protocol and determine the algorithm and key used by the service. The IPSec protocol family can be used to protect the path between one or more hosts, between security gateways, and between a security gateway and a host. A security gateway refers to an intermediate system that implements the IPSec protocol, such as a router or a firewall that implements IPSec.

The security services that IPSec can provide include connectionless data integrity, data source authentication, anti-replay protection, data confidentiality, and limited data flow confidentiality. Since these security services are provided at the IP layer, any high-level protocol, such as TCP, User Datagram Protocol UDP, Internet Control Message Protocol ICMP, Border Gateway Protocol BGP, etc., can be used.

Two protocols are used in the IPSec protocol suite to provide transmission security: the Authentication Header (AH) protocol and the Encapsulating Security Payload protocol, ESP for short). The Authentication Header (AH) protocol is used to provide connectionless integrity verification, data source authentication, and selective anti-replay services; the Encapsulated Security Payload (ESP) protocol is used to provide encryption and encryption of limited data streams, and it can also provide connectionlessness Integrity verification, data source authentication and anti-replay services. For key-based data flow management, both AH and ESP can be used as carriers for access control.

The AH protocol or ESP protocol can be used independently or in combination to provide the required set of security services in IPv4 and IPv6 environments. Both protocols support two modes: transport mode and tunnel mode. The transmission mode is used to provide security protection for higher-level protocols; the tunnel mode is used to protect IP packets transmitted in the tunnel. The difference between the original IP packet, the IP packet in the transmission mode, and the IP packet in the tunnel mode is shown in Figure 1. Figure 1 (a) is the composition of the original IP packet, including the IP header, TCP header, and data; the IP packet in the transmission mode is shown in Figure 1 (b), which is added between the IP header and the TCP header of the original IP packet IPSec header; IP packets in tunnel mode are shown in Figure 1 (c), then an IPSec header is added before the IP header of the original IP packet, and a new IP header is generated before the IPSec header.

IPSec allows users or system administrators to control the granularity of security services. For example, users can use a single encrypted tunnel to transmit all information between two security gateways, or create a separate encrypted tunnel for each TCP connection between hosts that pass through the gateway. In IPSec management, it is necessary to specify which security services are used and in which combination these security services are used; specify the granularity that security protection should use; and the encryption and authentication algorithms used for security protection.

Because the above security services need to use shared keys for authentication, integrity verification, and encryption, the IPSec protocol relies on a set of independent mechanisms to issue these keys. The IPSec protocol supports both manual and automatic key distribution methods. For automatic key management, a special public key-based method is defined-Internet Key Exchange (IKE for short). Other automatic key distribution technologies can also be used, such as KDC-based Kerberos system or other public keys. Key system, such as SKIP.

IPSec can be implemented on the host or at the connection of a router or firewall (creating a secure gateway). Here are some common implementations:

One is to implement IPSec in the IP layer. This method requires obtaining IP source code, which is applicable to hosts and gateways.

The second is achieved through "Bump-in-the-s tack" (BITS). IPSec is implemented at the lower end of the original IP protocol stack, between the IP layer and the network device driver layer. This method does not need to obtain the source code of the IP protocol stack, so it is suitable for legacy systems and is mostly used for hosts.

The third method is to use an external encryption processing device. This is a network security system design scheme commonly used by the military and financial systems. It is also called "Bump-in-the-wire" (BITW). This implementation is used for hosts or gateways or both.

In practical applications, it is often not implemented in accordance with the three methods described above, but in part, or in a mixture of multiple methods.

According to the protocol requirements, the IPSec embedding method must support the following functions: 1) Daily encapsulation and decapsulation, including: Encapsulating IPSec on the output data packet, and segmenting it if it exceeds the maximum transmission length of the network interface; Encapsulating the input data packet IPSec decapsulation is performed. If the data packet is fragmented, it is reorganized before decapsulation. If the decapsulated data packet is still fragmented, it is reorganized before being transmitted to the upper layer protocol. 2) Checking the security policy of the input data packet, that is, comparing whether the security policy specified for the data packet in the security policy database is consistent with the actual IPSec protection implemented on the data packet; Data packets need to be verified, and data packets destined to the machine without IPSec protection and forwarded data packets passing through the machine need to be verified to determine whether these data packets are allowed to pass. 3) Support high security granularity, that is, as described above, an independent encrypted tunnel is created for each TCP connection between the hosts passing through the gateway. This requires reading the TCP port in the data packet after decapsulating the input and verifying the security policy. If the new packet after decapsulation is fragmented, it should be reorganized first. In addition, for the output, you need to Before exporting the package, In the full policy, the TCP port in the data packet is read. If the data packet is fragmented, it should be reassembled. 4) Supporting nested security policies, that is, implementing multiple IPSec protections on data packets. When data packets are output, IPSec encapsulation should be repeated; when data packets are input, IPSec decapsulation should be repeated.

Because the IP protocol stack itself has input, forwarding, and output processes, it can also perform reorganization and segmentation in the middle. This is a very complicated process. Therefore, embedding IPSec into the IP protocol stack is also a very complicated problem. The point selection must be able to implement the basic functions of IPSec without affecting the normal flow of the IP protocol stack.

This complexity makes some IPSec protocol stacks use a simple embedded design, but sacrifices some functions. For example, the FREESWAN protocol stack uses a BITS embedding method, and it loses some IPSec defects, such as the inability to forward IP packets. Perform security policy verification; For IP packets whose destination is the local machine, IPSec is not applied, security policy verification cannot be performed; Cannot handle the situation where IP packets are still fragmented after IPSec decapsulation; Upper-layer protocol ports are not supported as security Policy selectors cannot support high security granularity. .

The KAME protocol stack is fully integrated at the IP layer. Although it can realize the function of IPSec, there are still some defects: If the destination is a local IP packet and IPSec is not applied, security policy verification cannot be performed; upper layers cannot be used As a security policy selector, the protocol port cannot support high security granularity. In addition, because KAME and the IP protocol stack are designed together, the IPSec processing flow and the IP processing flow are very closely combined and are scattered in various parts of the IP protocol stack, so it is difficult to maintain. In general, the IP protocol stack is often ready-made and cannot be changed so much.

Summary of the invention

The technical problem to be solved by the present invention is to propose a method for embedding IPSec in the IP protocol stack. In the existing IPSec embedding method of Keyueliang, the problems that the complete functions of IPSec cannot be realized and the problems that are difficult to achieve arise.

The method for embedding IPSec in an IP protocol stack according to the present invention comprises: performing basic IP input processing on an input IP packet; performing IPSec input processing on the IP packet; and performing other IP input processing on an IP packet that has undergone IPSec input processing.

The IP basic input processing includes: data packet length and checksum check; converting three fields of length, ID identifier and offset into machine byte order;

The other IP input processing includes: IP option processing; judging whether the destination address of the IP packet is the local machine; if it is, reassembling the IP packet segment and invoking the input processing of the upper layer protocol; if not, performing the forwarding processing.

The IPSec input processing includes: judging whether the IP packet is a multicast data packet, if yes, the IPSec input processing ends; if not, judging whether the IP packet is a local IPSec packet, and if so, then Perform IPSec decapsulation processing; if not, determine whether the IP packet is a segmented IP packet, and if so, reassemble the IP packet; perform security policy verification; if it is not a segmented IP packet, directly perform security policy verification .

The IPSec decapsulation processing includes:

1) determine whether the IP packet is a segmented IP packet, and if so, perform step 2); if not, perform step 3);

2) reorganizing the IP packet;

3) converting the three fields of length, ID identifier and offset in the header of the IP packet into a network byte order;

4) Obtain a security parameter guide from the IP packet, query a security parameter database, and obtain corresponding security parameters; 5) Perform IPSec input verification, decryption, and decapsulation operations;

6) The three fields of length, ID identifier and offset in the header of the IP packet are converted into native byte order. The method for embedding IPSec in an IP protocol stack according to the present invention includes: performing IP basic output processing on IP packets; performing IPSec output processing on the IP packets; and performing other IP output processing on IP packets that have undergone IPSec output processing.

The IP basic output processing includes: initializing an IP packet header; selecting a route; setting a source address; the other IP output processing includes: segmenting an IP packet; and invoking an interface layer to send an IP packet.

The IPSec output processing includes: judging whether the IP packet is a multicast data packet, and if yes, the IPSec output processing ends; if not, obtaining a security policy selector from the IP packet, and querying a security policy database to obtain a security policy; The corresponding processing is performed according to different security policies: If the security policy is PASS, the IPSec output processing ends; if the security policy is DROP, IP packets are directly discarded; if the security policy is IPSEC, IP packets are encapsulated by IPSec.

The IPSec encapsulation includes:

1) Converting the length and offset fields in the IP packet header into network byte order;

2) obtaining the security parameters specified by the security policy;

3) IPSec encapsulation, encryption and authentication using security parameters;

4) Determine if there is still a security policy, if there is, go to step 2); if not, go to step 5);

5) The length and offset fields of the IP packet header are converted into native byte order.

Compared with the prior art, the embedding method described in the present invention overcomes the shortcomings of the two embedding modes of FREESWAN and KAME, and can completely realize all the functions of the IPSec protocol, including: performing security policy verification on the forwarded IP packets; Check the security policy of the local non-IPSEC packet; Handle the case where the IPSec packet is decapsulated to be a fragmented IP packet; Support nested security policies; Support high security granularity. this invention It only needs to make simple changes to the IP protocol stack, which is very easy to implement.

BRIEF DESCRIPTION OF THE DRAWINGS

Figure 1 is the schematic diagram of IPSec;

FIG. 2 is a flowchart of IPSec input processing in the embedding method of the present invention;

FIG. 3 is a flowchart of IPSec output processing in the embedding method of the present invention.

detailed description

The technical solution of the present invention is described in further detail below with reference to the drawings and embodiments.

In FIG. 1, as described above, the IP packet is still an IP packet after being encapsulated by IPSec, and is still processed by the IP processing flow on the network as an IP packet. Therefore, IPSec processing is a part of IP processing. In order to realize the IPSec processing, the IPSec input processing flow must be embedded in the IP input processing flow, and the IPSec output processing flow must be embedded in the IP output processing flow. After embedding, the IPSEC output processing flow is called by the IP output processing flow, and the IP input processing flow calls the IPSEC input processing flow. Therefore, an IPSec embedding method needs to solve four problems: one is the embedding point of IPSec input processing; the other is the flow of IPSec input processing; the third is the embedding point of IPSec output processing; the fourth is the flow of IPSec output processing.

The technical solution of the present invention will be described in detail from these four aspects.

First you need to select the embedding point for IPSec input processing. The IPSec input processing is embedded in the front end of the IP input processing. The present invention chooses to insert the IPSec input processing after IP basic input processing has been completed for the IP packet and before other IP input processing is performed. The basic IP input processing refers to data packet length and checksum (checksum, please provide Chinese meaning) check and conversion of the length, ID identifier and offset three fields in the IP packet header into machine byte order; and Other input processing includes IP option processing; for the forwarding processing when the destination address is not the local machine, and for the input processing of reassembling IP fragment packets and calling upper layer protocols such as TCP and UDP when the destination address is the local machine. Figure 2 shows the flow of IPSEC input processing. First, it is necessary to determine whether the input IP packet is a multicast data packet. If it is a multicast data packet, subsequent processing is not performed and the process is exited. If the IP packet is not a multicast data packet, it is determined whether the IP packet is an IPSec packet whose destination address is the local IPSec packet. If it is, the IPSec decapsulation process is performed. If the IP packet is not the local IPSec packet, it is determined whether the IP packet is Fragment IP packets. If yes, perform IP packet reassembly, and then check security policies. If the IP packet is not a segmented IP packet, the security policy is directly checked.

The IPSec decapsulation process includes the following steps: First, determine whether the IP packet is a segmented IP packet. If it is a segmented IP packet, reorganize the IP packet first, and then perform subsequent processing; if it is not a segmented IP packet, directly follow up deal with. The three fields of length, ID identifier and offset in the IP packet header are converted into network byte order, and then the security parameter index is obtained from the IP packet, and the security parameter database is queried according to the security parameter index to obtain the corresponding security parameter. Use security parameters for IPSec input verification, decryption, and decapsulation. Finally, the length, ID identifier and offset fields in the IP packet header are converted into native byte order. The above steps can complete the decapsulation of the IPSec packet. It is repeatedly judged whether the next IP packet is an IPSec packet whose destination address is the local IPSec packet and subsequent processing.

The embedding point of the IPSec output processing is selected at the back end of the IP output processing, that is, after the IP basic output processing has been completed for the IP packets, the IPSec output processing is inserted before other IP output processing. The IP basic output processing includes: initializing the IP packet header, selecting a route, and setting the source address; other IP output processing refers to segmenting the IP packet and calling the interface layer to send the IP packet.

Referring to the flow of the IPSec output processing shown in FIG. 3, first determine whether the IP packet is a multicast data packet, and if it is, exit the IPSec output processing flow directly, that is, the IPSec output processing is only for non-multicast data packets. After determining that the IP packet is a non-multicast data packet, the security policy selector is obtained from the IP packet, and then the security policy database is queried to obtain the security policy of the IP packet. If the security policy is PASS, exit the IPSec output processing; if the security policy is DROP, discard the IP packet; if the security policy For IPSec, perform IPSec output encapsulation. First, the length and offset fields in the IP packet header are converted into network byte order, the specified security parameters are obtained according to the security policy, and then the security parameters are used for IPSec encapsulation, encryption, and authentication. This completes the encapsulation of a security policy. If there is a next nested security policy, the specified security parameters are obtained again, and subsequent encapsulation operations are repeated. After all the security policies are processed, the length and offset fields in the IP packet header are converted into machine byte order.

Several specific embodiments are given below.

Example 1: policy verification for local non-IPSec packets

Assume that a non-IPSec packet whose destination is the local machine is received, and after the IP input processing flow processes it to a certain extent, the IPSec input processing flow is called. Because it is a non-multicast data packet and a local non-IPSec packet, the IPSec decapsulation process is not performed, and the IP packet is directly judged whether it is a segmented IP packet. If it is, it is reassembled first, and then the security policy verification of the stack is performed. ; ¹ If not, directly perform security policy inspection. Since the fragmented IP packet has been reorganized, the port can be included as a security policy selector for verification, which can support high security granularity at the port level.

Example 2: decapsulation and policy verification of the local IPSec packet

Assume that an IPSEC packet whose destination is the local machine is received. After the IP input processing flow processes it to a certain extent, the IPSec input processing flow is called. Since the IP packet is a non-multicast data packet and a local IPSec packet, IPSec decapsulation processing is performed. If the IP packet is a segmented IP packet, reassembly is performed first, and then the length, ID identifier, and offset fields in the IP packet header are converted into network byte order. An index of security parameters is obtained from the IP packet, and the security parameter database is queried to obtain the corresponding security parameters. Then use security parameters for IPSec input verification, decryption, and decapsulation. Finally, the length, ID, and offset fields in the IP packet header are converted into machine byte order.

After the IPSec packet is verified and decapsulated by IPSec, it becomes a non-IPSec packet, and then the packet is determined to be If it is not, the packet is fragmented. If it is, it is reassembled, and then the security policy verification is performed on the stack; if not, the security policy verification is performed directly.

Because segmented IP packets are reorganized during the decapsulation process, even if the IP packet is a segmented data packet before decapsulation, the correct IPSec decapsulation can still be performed. After decapsulation, the segmented IP packets are also reorganized. Therefore, even if the IP packets are decapsulated, they can still include ports as security policy selectors for verification, so they can support high security at the port level. granularity.

Example 3: policy check for forwarding IP packets

Assume that an IP packet whose destination is non-local and needs to be forwarded is received. After the IP input processing flow processes it to a certain extent, the IPSec input processing flow is called. Since the IP packet is a non-multicast data packet and a non-native IPSec packet, no IPSec decapsulation processing is performed, and the IP packet is directly judged whether it is a segmented IP packet. If it is, it is reassembled first, and then the security of the stack is entered. Policy check; if not, directly check the security policy. Since fragmented IP packets have been reorganized, ports can be included as security policy selectors for verification, so high security granularity at the port level can be supported.

Example 4: Encapsulation and Segmentation of Output Packets

It is assumed that a data packet is to be output now, and after the IP output processing flow processes it to a certain extent, the IPSec output processing is called to flow out. Since the IP packet is not a multicast data packet, processing continues. Obtain the security policy selector from the IP packet and query the security policy database. If the IP packet is a data packet sent by the local machine, it has not been segmented, and a security policy selector including a port can be obtained; if the IP packet is an IP packet to be forwarded received from another network interface, Then the IP packet has undergone IP input and IPSec input processing, and if it is a segmented IP packet, it has also been reorganized, so the security policy selector including the port can also be obtained. Because IPSec encapsulation is performed, the queried security policy should be IPSec. Then perform IPSec output encapsulation processing. The length and offset fields in the IP packet header are first converted into network byte order, and the security parameters specified by the security policy are obtained. Then Use security parameters for IPSec encapsulation, encryption, and authentication. If there are multiple nested security policies, repeat the above steps to complete all security policies. Finally, the length and offset fields in the IP packet header are converted into local byte order.

Therefore, after the above steps, whether it is a forwarded IP packet or an IP packet sent by the local machine, it can obtain the security policy selector including the port, so it can support high security granularity at the port level.

After the IPSec output processing ends, the IP output process continues with the remaining processing. If the length of the packet after IPSec encapsulation exceeds the maximum transmission length of the network interface, it is segmented first, and then the interface layer is called to send the packet.

It can be seen from Embodiments 2 and 4 that both the IPSec input decapsulation and the IPSec output encapsulation can obtain the security policy selector including the port, thereby supporting high security granularity.

Example 5: handling of nested security policies

It is assumed that a two-layer nested security policy is to be implemented on an output IP packet. After the IP output processing process has processed it to a certain extent, the IPSec output processing process is invoked. First, the IP packet is not a multicast data packet, and subsequent processing is continued. Obtain the security policy selector from the IP packet and query the security policy database. If the IP packet is a data packet sent by the local machine and has not been fragmented, then a security policy selector including a port can be obtained. If the IP packet is received from another network interface, it has undergone IP input and IPSec input processing, and has been reorganized, so the security policy selector including the port can also be obtained. Because it is a nested security policy, the queried security policy should be IPSec. Then perform IPSec output encapsulation processing. The length and offset fields in the IP packet header are converted into network byte order to obtain the security parameters specified by the security policy. Then use security parameters for IPSec encapsulation, encryption, and authentication. Since two layers of nested security policies are required, the above steps need to be repeated: Obtain the security parameters specified by the security policy, and then use the security parameters for IPSec encapsulation, encryption, and authentication. Finally, the length and offset fields in the IP packet header are converted into machine byte order. It is assumed that a data packet encapsulated with a two-layer nested security policy is received, and after the IP input processing flow processes a certain amount of it, the IPSec input processing flow is called. Since the data packet is a non-multicast data packet and a local IPSec packet, decapsulation processing is performed. If the data packet is a fragmented IP packet, reassembly is performed first. The three fields of length, ID identifier and offset in the header of the IP packet are converted into network byte order, a security parameter index is obtained from the IP packet, and a security parameter database is queried according to the index to obtain the corresponding security parameter. Then use security parameters to perform IPSec input verification, decryption, and decapsulation, and then convert the length, ID identifier, and offset fields in the IP packet header into native byte order. Since the data packet is encapsulated by two layers of nested security policies, the IPSec packet obtained after one decapsulation still needs to be decapsulated again. After decapsulation of the two-layer security policy, the new data packet obtained is already a non-IPSec data packet, and then it is judged whether it is a segmented IP packet. If so, the IP packet is reassembled to perform a stack security policy check. If not, the security policy verification is performed directly.

For nested security policies with more than two layers, the encapsulation and decapsulation processes are similar. Therefore, the IPSec embedding method of the present invention can support nested security policies.

Finally, it should be noted that the above embodiments are only used to illustrate the technical solution of the present invention and not limiting. Although the present invention has been described in detail with reference to the preferred embodiments, those skilled in the art should understand that the technology of the present invention can be Modifications or equivalent replacements of the solutions without departing from the spirit and scope of the technical solutions of the present invention should be covered by the claims of the present invention.

Claims

Claim

1. A method for embedding IPSec into an IP protocol stack, comprising: performing IP basic input processing on an input IP packet; performing IPSec input processing on the above IP packet; performing IP processing on the IP packet subjected to IPSec input processing Other input processing.

2. The method for embedding IPSec in an IP protocol stack according to claim 1, wherein the basic IP input processing comprises: packet length and checksum check; length, ID identification and offset three Field conversion into machine byte order;

3. The method for embedding IPSec into an IP protocol stack according to claim 1 or 1, wherein the IPSec input processing comprises: determining whether the IP packet is a multicast data packet, and if so, the IPSec input processing End; if not, determine whether the IP packet is a local IPSec packet, and if yes, perform IPSec decapsulation processing; if not, determine whether the IP packet is a segmented IP packet, and if so, Then reassemble IP packets; perform security policy verification; if it is not a segmented IP packet, directly perform security policy verification.

4. The method for embedding IPSec in an IP protocol stack according to claim 3, wherein the IPSec decapsulation processing comprises:

1) determine whether the IP packet is a segmented IP packet, and if so, perform step 2); if not, perform step 3); 2) reorganizing the IP packet;

4) Obtaining a security parameter guide from the IP packet, querying a security parameter database, and obtaining corresponding security parameters;

5) Perform IPSec input verification, decryption, and decapsulation operations;

6) The three fields of length, ID identifier and offset in the header of the IP packet are converted into machine words.

5. A method for embedding IPSec in an IP protocol stack, comprising: performing IP basic output processing on IP packets; performing IPSec output processing on the above IP packets; and performing other IP output on IP packets subjected to IPSec output processing deal with.

6. The method for embedding IPSec into an IP protocol stack according to claim 5, wherein the basic output processing of the IP comprises: initializing an IP packet header; selecting a route; setting a source address; the IP other The output processing includes: segmenting the IP packet; calling the interface layer to send the IP packet.

7. The method for embedding IPSec in an IP protocol stack according to claim 5 or 6, wherein the IPSec output processing comprises: determining whether the IP packet is a multicast data packet, and if so, IPSec The output processing ends; if not, obtain the security policy selector from the IP packet and query the security policy database to obtain the security policy; perform the corresponding processing according to the different security policies: If the security policy is PASS, the IPSec output processing ends; if If the security policy is DROP, IP packets are directly discarded; if the security policy is IPSEC, IP packets are encapsulated by IPSec.

8. The method for embedding IPSec in an IP protocol stack according to claim 7, wherein the IPSec encapsulation comprises:

2) obtaining the security parameters specified by the security policy;

9. A method for embedding IPSec in an IP protocol stack, comprising: an embedding method when an IP packet is input and an embedding method when an IP packet is output; wherein

The embedding method when the IP packet is input includes: performing IP basic input processing on the input IP packet; performing IPSec input processing on the IP packet; performing IP other input processing on the IP packet that has undergone IPSec input processing;

The embedding method when the IP packet is output includes: performing IP basic output processing on the IP packet; performing IPSec output processing on the IP packet; and performing other IP output processing on the IP packet that has undergone the IPSec output processing.

10. The method for embedding IPSec into an IP protocol stack according to claim 9, wherein the basic IP input processing comprises: packet length and checksum check; length, ID identification and offset Field conversion into machine byte order;

The other IP input processing includes: IP option processing; judging whether the destination address of the IP packet is local; if it is, reassembling the IP packet segment and invoking the input processing of the upper layer protocol; if not, proceeding to Line forwarding processing.

11. The method for embedding IPSec in an IP protocol stack according to claim 9 or 10, wherein the IPSec input processing comprises: determining whether the IP packet is a multicast data packet, and if so, IPSec The input processing ends; if not, it is determined whether the IP packet is a local IPSec packet, and if it is, the IPSec decapsulation process is performed; if not, it is determined whether the IP packet is a segmented IP packet. If yes, then reassemble IP packets; perform security policy verification; if it is not a segmented IP packet, directly perform security policy verification.

12. The method for embedding IPSec in an IP protocol stack according to claim 11, characterized in that the IPSec decapsulation processing includes:

2) reorganizing the IP packet;

5) Perform IPSec input verification, decryption, and decapsulation operations;

6) The three fields of length, ID identifier and offset in the header of the IP packet are converted into native byte order.

13. The method for embedding IPSec in an IP protocol stack according to claim 9, wherein the IP basic output processing comprises: initializing an IP packet header; selecting a route; setting a source address; The other IP output processing includes: segmenting the IP packet; and invoking the interface layer to send the IP packet.

14. The method for embedding IPSec into an IP protocol stack according to claim 9 or 13, wherein the IPSec output processing comprises: determining whether the IP packet is a multicast data packet, and if so, the IPSec output processing End; if not, obtain the security policy selector from the IP packet, query the security policy database to obtain the security policy; and perform corresponding processing according to different security policies: If the security policy is PASS, the IPSec output processing ends; if the security policy If it is DROP, IP packets are directly discarded; if the security policy is IPSEC, IP packets are encapsulated by IPSec.

15. The method for embedding IPSec in an IP protocol stack according to claim 14, wherein the IPSec encapsulation comprises:

2) obtaining the security parameters specified by the security policy;