CN100488204C - Method for enquiring IPSec tunnel state - Google Patents

Abstract

The invention discloses a method for inquiring the state of the IPSec tunnel. According to the characteristic parameters of the IPSec tunnel to be inquired, the state of the IPSec tunnel is inquired to determine the state of the IPSec tunnel. The method provided by the present invention avoids indirect inquiry, that is, reflects the state of the current IPSec tunnel by inquiring about other states, and causes the state of the IPSec tunnel to be determined incorrectly, interrupting communication, delaying the system, reducing the quality of customer service, problems such as decreased communication reliability. The method provided by the invention can accurately, quickly and reliably query the current real state of the IPSec tunnel, reduces system delay, improves communication reliability, and effectively guarantees the normal operation of the communication network.

Description

A Method of Querying the State of IPSec Tunnel

technical field

The invention relates to a network security detection technology, in particular to a method for querying the state of an IP security (IPSec) tunnel.

Background technique

IPSec is an open IP layer security framework protocol formulated by the Internet Engineering Task Force (IETF), and it is a three-layer tunneling protocol. IPSec works at the network layer, can provide security protection for sensitive data transmission, and protect and authenticate IP data packets transmitted between devices participating in IPSec. With IPSec, when data is transmitted through the public network, there is no need to worry about being monitored, tampered with and forged by attackers.

The protection of data by the IPSec protocol is realized through a Security Association (SA). IPSec SA defines the agreement between the two parties on certain elements in the communication process, such as which protocol to use, the operating mode of the protocol, the cryptographic algorithm, the shared key for protecting data in a specific flow, and the life cycle of the key. IPSec SA is uniquely identified by a triplet, which includes: Security Parameter Index (SPI), destination IP address, and security protocol.

After the communication parties establish the IPSec tunnel, the communication parties must keep the SA of the IPSec tunnel consistent and exist at the same time, so as to ensure the normal encryption and decryption of negotiation messages and data messages, that is, to ensure that the communication parties can normally use the IPSec tunnel for data communication. Therefore, a certain mechanism is needed to query the IPSec tunnel, that is, after the IPSec tunnels of both communication parties are established, query whether the IPSec SAs of both communication parties exist at the same time, so as to trigger deletion of the original IPSec tunnel when the IPSec SAs of both communication parties do not exist at the same time. Re-establish a new IPSec tunnel to ensure the normal communication of data.

In the prior art, querying the status of an IPSec tunnel is usually implemented through Dead Peer Detection (DPD) in the Internet Key Exchange Protocol (IKE).

The DPD determines the state of the IPSec SA by detecting the state of the IKE SA corresponding to the IPSec SA, and then determines the state of the IPSec to be queried. Here, the state of the IKE SA or the IPSec SA is: whether the IKE SA or the IPSec SA exists; the state of the IPSec tunnel is: whether the IPSec tunnel is available. However, in the prior art, the state of the IKE SA cannot represent the state of the corresponding IPSecSA, that is, even if the IKE SA exists, the IPSecSA corresponding to the IKE SA does not necessarily exist. Therefore, it is unreasonable to confirm the status of the IPSec tunnel by querying the status of the IKE SA. If the status of the IPSec tunnel is incorrectly determined, this detection mechanism will be ineffective, and the data communication will be interrupted, so that the data communication cannot be automatically restored for a long time. Bring adverse effects to the actual operation of the network.

Contents of the invention

In view of this, the main purpose of the present invention is to provide a method for inquiring about the state of the IPSec tunnel, which can accurately and reliably inquire about the current state of the IPSec tunnel.

In order to achieve the above object, technical solution of the present invention is achieved in that way:

A method for querying the state of an IPSec tunnel, the method comprising the following steps:

A. The query direction sends an IPSec tunnel query message to the responding party, and the IPSec tunnel query message carries at least one characteristic parameter of the IPSec tunnel to be queried;

B. The responding party obtains the characteristic parameter carried in the IPSec tunnel query message, inquires whether the same characteristic parameter exists in itself, and returns the query result to the inquiring party;

C. According to the query result returned by the responding party, when the responding party has the same characteristic parameter, it is determined that the IPSec tunnel corresponding to the same characteristic parameter is available; when the responding party does not have the same characteristic parameter, it is determined that the corresponding The IPSec tunnel that does not have the same characteristic parameters as above is unavailable.

In addition, when more than one IPSec tunnel is to be queried, in step B, the query result is returned to the query party as follows:

Return the query results of more than one IPSec tunnel to the querying party in one message; or

For each IPSec tunnel, return a query result to the querying party.

Wherein, in step B, the query result returned to the query party is:

When the answering party has the same feature parameter, then return the IPSec tunnel query success message to the query side for the same feature parameter; The queryer failed to respond.

Wherein, the response failure is: the responder returns an IPSec tunnel query failure message to the inquiring party.

In addition, the waiting timer and the waiting time are further set, and when the inquiring party sends an IPSec tunnel query message, the waiting timer is started;

In step B, the response failure is: when the responding party does not have the characteristic parameters to query the IPSec tunnel, the query result is not returned to the querying party;

In step C, when the responding party has the same characteristic parameter, it is determined that the IPSec tunnel corresponding to the same characteristic parameter can be used as follows: when the waiting timer reaches the waiting time, the inquiring party receives the query result, then determines that the IPSec tunnel corresponding to the same characteristic parameter is: The IPSec tunnel corresponding to the query result is available; when the responder does not have the same characteristic parameter, then determining that the IPSec tunnel corresponding to the same characteristic parameter does not exist is unavailable: when the waiting timer reaches the waiting time, query If the party does not receive the query result, it is determined that the IPSec tunnel corresponding to the query result is unavailable.

In addition, the query timer and the query cycle are further set. In step A, when the inquiring party sends an IPSec tunnel query message, the query timer is started; when the query timer reaches the query cycle, it is judged whether the status of the IPSec tunnel to be inquired is determined at present, If so, the query timer stops counting; otherwise, the querying party sends an IPSec tunnel query message to the IPSec tunnel with no definite state.

In addition, further set the maximum number of queries, count the IPSec tunnel query messages sent by the query party, and further judge whether the currently sent IPSec tunnel query messages are less than or equal to The maximum number of queries, if yes, execute the sending of the IPSec tunnel query message; otherwise, end the current processing flow.

In addition, before step C, further include:

Determine whether the query result returned by the responding party is the response to the query message sent by the querying party in the current query period, and if so, perform step C; otherwise, refuse to process the query result returned by the current responding party.

Wherein, step A is performed when the inquiring party needs to send data to the responding party or when the query period is reached.

Wherein, the characteristic parameters are: the security parameter index, the destination IP address, and the security protocol of the security association of the outgoing direction of the IPSec tunnel; or the security parameter index, the destination IP address, and the security protocol of the security association of the incoming direction of the IPSec tunnel; or the IPSec tunnel The security parameter index, destination IP address, and security protocol of the outbound SA, and the security parameter index, destination IP address, and security protocol of the inbound SA.

The method for inquiring the state of the IPSec tunnel provided by the present invention is to inquire the state of the IPSec tunnel according to the characteristic parameters of the IPSec tunnel to be inquired, and determine the state of the IPSec tunnel. The method provided by the present invention avoids that due to indirect query, that is, reflecting the state of the current IPSec tunnel by inquiring about other states, the state of the IPSec tunnel is incorrectly determined, communication is interrupted, system delay, customer service quality is reduced, problems such as decreased communication reliability. The method provided by the invention can accurately, quickly and reliably query the current real state of the IPSec tunnel, reduces system delay, improves communication reliability, and effectively guarantees the normal operation of the communication network.

Description of drawings

Fig. 1 is the flowchart of the method of embodiment one of the present invention;

Fig. 2 is a flow chart of the method in Embodiment 2 of the present invention.

Detailed ways

In the present invention, it is determined whether the IPSec tunnel established by the communication parties is available by inquiring whether the communication parties establishing the IPSec tunnel have the same IPSec SA. When an IPSec tunnel is established, two IPSec SAs will be generated at the same time. Here, it is assumed that the two parties establishing the IPSec tunnel are: A and B, and the two generated IPSec SAs are 1 and 2 respectively; if IPSec SA1 is the outbound direction SA of A , IPSec SA2 is the inbound SA of A; then IPSec SA1 is the inbound SA of B, and IPSec SA2 is the outbound SA of B. Here, the difference between the outbound SA and the inbound SA of the communication party of each IPSec tunnel is that the communication party uses the key in the outbound SA to encrypt the sent data; uses the key in the inbound SA to decrypt the received data. Here, the existence of the same IPSec SA between the two communicating parties means that both communicating parties simultaneously have two IPSec SAs corresponding to the IPSec tunnel.

Since the two IPSec SAs generated for establishing an IPSec tunnel exist simultaneously, in the present invention, it is possible to determine whether two identical IPSec SAs exist at both parties by determining whether there is one IPSec SA at the same time at both parties of communication, and then determine Whether the IPSec tunnel established by the communication parties is available.

Because, IPSec SA is uniquely identified by the triplet composed of Security Parameter Index (SPI), destination IP address and security protocol. Therefore, the meaning of the same IPSec SA here is: both communication parties have IPSec SAs with the same triplet. Since two IPSec SAs corresponding to the same IPSec tunnel are generated, exist at the same time, and are bound to each other, these two IPSec SA triples can uniquely identify the IPSec tunnel alone, so the triplets of these two IPSec SAs Each group can be called a characteristic parameter of the IPSec tunnel.

In order to make the object, technical solution and advantages of the present invention clearer, two embodiments are listed in the invention, and the present invention is further described in detail.

The main difference between these two embodiments is that the first embodiment is: only one IPSec tunnel established by both communication parties is inquired in a query process; the second embodiment is: more than one IPSec tunnel established by both communication parties is inquired in a query process. tunnel. The two embodiments are described in detail below respectively.

Embodiment one

When the IPSec tunnel established by the communication parties has no data traffic for a long time, the communication party must first confirm whether the IPSec tunnel from itself to the peer end is available before initiating data transmission. Here, for the convenience of description, the initiator of the communication, which is the initiator of the query in the present invention, is called the inquiring party; the opposite end to which the communication initiator intends to transmit data, that is, the responder of the query, is called the responding party. In an actual application process, before each time the inquiring party initiates communication, it may also inquire whether the IPSec tunnel it currently needs to use is available. The process of specifically querying whether an IPSec tunnel is available is shown in Figure 1:

Step 101: The queryer sends an IPSec tunnel query message to the responder, and the IPSec tunnel query message carries characteristic parameters of the IPSec tunnel that it will use currently.

The characteristic parameter here may be the SA triplet in the outbound direction of the inquiring party, or the SA triplet in the inbound direction of the inquiring party. In order to simplify the description, the two IPSec SAs of the IPSec tunnel are collectively referred to as the IPSec tunnel SA in the following. If the characteristic parameter used in the IPSec tunnel query message is an outbound SA triplet, the corresponding IPSec tunnel SA is the outbound SA; If the characteristic parameter used in the IPSec tunnel query message is an inbound SA triplet, then the corresponding IPSec tunnel SA is an inbound SA.

The data format of the IPSec tunnel query message can inherit the format of the IKE DPD message, or can adopt a self-defined format. If the IKE DPD message format is inherited, the format shown in Table 1 can be used.

Table 1

The message format shown in Table 1 follows the message format architecture of the IKE DPD query message. Among them, the meaning and function of each field are the same as the original IKE DPD query message, and will not be repeated here. Since the present invention determines the state of the corresponding IPSec tunnel by querying the state of the IPSec SA, the query message needs to carry information for querying the state of the IPSec SA, and then in the corresponding field of the query message, there will also be different content , the details are as follows:

The standard code filled in the domain of interpretation (Domain of Interpretation, DOI) is used to explain the meaning of various numbers in the message field. The meaning of each number in the message is determined according to different standards. In the IPSec protocol There are two standards in the stack, one is the isakmp standard, that is, the IKE standard, and the code is 0, and the other is the IPSec standard, that is, the standard that complies with RFC 2407, and the code is 1. Since in this embodiment, it is for the IPSec tunnel, therefore Fill in 1 here. Fill in the length of the current query message in the Payload Length field, excluding the message header corresponding to the message. Fill in the protocol number (Protocol-ID) field to fill in the security protocol supported by the current query IPSec tunnel, authentication header protocol (AH) or encapsulating security payload (ESP), that is, carry the security protocol in the IPSec SA triplet through the protocol number field . Fill in the SPI length, the length of the SPI is 4 bytes. In the message type field, fill in the message type of this message, if it is an IPSec tunnel query message, fill in IPSec-DPD-Request, if it is an IPSec tunnel response message, fill in IPSec-DPD-Response. In the SPI field, fill in the SPI of the current IPSec tunnel to be queried, that is, carry the SPI in the IPSec SA triplet through the SPI field. The Next Payload (Next Payload) field is filled with zeros, indicating that there is only one payload in this message. The reserved field (RESERVED) is filled with zeros, indicating that the reserved bits are not used temporarily. In the Notification Data field, fill in the serial number of this message.

Here, the query message filled with IPSec SA information is called IPSec DPD message. It can be seen from Table 1 that the IPSec DPD message does not obviously carry the necessary destination IP address information in the IPSec SA triplet. It carries the destination IP address to which the message is sent, so from the aspect of saving resources, IPSec DPD does not need to additionally set the destination IP address field, which is used to carry the destination IP address in the IPSec SA triplet.

The IPSec tunnel query message can also adopt a self-defined message format, no matter what format structure the self-defined message format adopts, as long as the self-defined message format carries the SA triplet that needs to query the IPSec tunnel. If you use a custom format, you need to set this format in advance on the devices of both parties in the communication, so that the devices of both parties in the communication support the custom message format, so that after receiving the custom message, the message can be identified and parsed .

Step 102: The answering party receives the IPSec tunnel query message sent to itself by the querying party, and obtains the carried IPSec SA triplet from the received IPSec tunnel query message. According to the obtained IPSec SA triplet, search in the database of its own device to determine whether there is the same IPSec SA triplet, and if it exists, return the IPSec tunnel query success message to the inquiring party; otherwise, respond to the IPSec tunnel query to the inquiring party failure message. Here, the IPSec tunnel query success message and the IPSec tunnel query failure message are collectively referred to as an IPSec tunnel query response message.

The answering party obtains the IPSec SA triplet from the received IPSec tunnel query message as follows: the responding party first parses the message type field in the received message, and judges whether it is an IPSec tunnel query message, and if so, according to the words occupied by each field According to the method in the prior art, the IPSec tunnel query message is parsed to obtain the SPI and security protocol carried therein and the destination IP address carried in the IPSec tunnel query message header; otherwise, according to the type of the obtained message, the receiving Received messages are processed accordingly.

The IPSec tunnel query response message returned by the responding direction to the inquiring party may also adopt the format shown in Table 1, specifically:

When responding to the IPSec tunnel query success message returned by the inquiring party, the message type in the received IPSec tunnel query message sent by the inquiring party is changed to IPSec-DPD-Response, and then sent to the inquiring party.

When the IPSec tunnel query failure message returned by the responding direction to the inquiring party, the message type in the IPSec tunnel query message sent by the received inquiring party is changed to IPSec-DPD-Response, and the SPI and/or security protocol fields in it are changed to IPSec-DPD-Response After the content of is deleted, it is sent to the querying party.

Here, the answering party may also return an IPSec tunnel query response message to the inquiring party in other ways, for example, may return an instruction to the inquiring party, and the instruction only needs to carry an indication of success or failure.

Step 103: According to the IPSec tunnel query response message returned by the responding party, the querying party judges whether the responding party has the same IPSec SA, that is, judges whether it has received the IPSec tunnel query success message or the IPSec tunnel query failure message, and if it exists, then determine the querying party The currently queried IPSec tunnel is available, and the inquiring party can use the IPSec tunnel to securely communicate with the responding party; otherwise, it is determined that the IPSec tunnel currently inquired by the inquiring party is unavailable, and the inquiring party cannot use the IPSec tunnel to securely communicate with the responding party. For data communication, the inquiring party can delete the IPSec tunnel in order to re-establish the IPSec tunnel with the responding party.

Usually, due to a bad network environment, an attack by an attacker, and other factors, the inquiring party may not be able to or delay receiving the response message returned by the responding party. In this way, it is necessary to set the waiting timer and waiting time on the querying side. When the waiting timer reaches the waiting time, it is considered that the responding side does not have the same IPSec SA as the querying side, and the querying side determines that the IPSec tunnel to be queried is currently unavailable. The specific implementation process can be as follows:

When the inquiring party sends the IPSec tunnel query message, it starts the waiting timer; when the waiting timer reaches the waiting time, the inquiring party judges whether it has received the IPSec tunnel querying response message returned by the responding party. The received IPSec tunnel query response message determines the status of the IPSec tunnel to be queried; otherwise, the inquiring party determines that the IPSec tunnel to be queried is unavailable, and ends the processing flow of currently querying the IPSec tunnel status, that is, no further processing of subsequent received IPSec tunnel query response message.

In full consideration of the harshness of the network environment and the existence of network attacks, in this embodiment, under the condition of fully considering the effectiveness and reliability of the current query IPSec tunnel, the query timer, query cycle and maximum number of queries can also be set to repeat Inquire. Wherein, when the query timer reaches the query period every time, the querying party determines whether to send the IPSec tunnel query message again according to the current situation of querying the IPSec tunnel. Here, the maximum number of queries is used to specify the total number of times that the query party can send IPSec tunnel query messages. The specific implementation process of repeated query can be in the following form:

While sending the IPSec tunnel query message, the queryer starts the query timer and starts counting the query messages sent from the query to the responder. When the query timer reaches the query period, the inquiring party judges whether it has determined to query the status of the IPSec tunnel. If it is determined, the query timer stops timing and ends the current query process; Whether the number of times the IPSec tunnel query message has been sent is less than or equal to the set maximum number of queries, if not, the query timer stops counting, and the current query process ends, if yes, the IPSec tunnel query message is sent to the responder again, and after the Add 1 to the number of query messages sent.

In the case of setting the query timer and query period, when the query party receives the IPSec tunnel query response message returned by the responder, it can further judge whether the currently received response message is the response message of the query message sent in the current period , if yes, process the currently received response message; otherwise, do not process the currently received response message. To simplify the description, the IPSec tunnel query message is referred to as query message for short in this document; the IPSec tunnel query response message is referred to as response message for short.

Here, judging whether the currently received response message is a response message for sending a query message in the current period can be performed according to the following method: each query message is numbered, the number can uniquely identify the query message, and the query message number and There is a one-to-one relationship between query times. When the responder responds to the query message, it carries the number of the corresponding query message in the response message; after receiving the response message returned by the responder, the query party judges the number of Whether the number corresponds to the current number of queries, and if so, process the currently received response message; otherwise, do not process the currently received response message. Wherein, the query message number may be carried in the notification data field in Table 1. Here, the number of the query message may be the number of queries currently recorded.

Here, it is also possible to process only the IPSec tunnel query success message returned by the inquiring party to the responder, and not to process the IPSec tunnel query failure message returned by the inquiring party to the responder, because even if the IPSec tunnel query failure message is forged by an attacker , the two sides of the communication only need to re-establish the IPSec tunnel, and the communication quality and security of the communication will not be greatly affected. Therefore, under this implementation mode, when the message received by the inquiring party is an IPSec tunnel query success message, it is further judged whether the currently received IPSec tunnel query success message is a response message to the query message sent in the current period, if If yes, process the currently received IPSec tunnel query success message; otherwise, do not process the currently received IPSec tunnel query success message.

In step 102, when the responding party does not have the same IPSec SA triple, it may also not return any message to the querying party, that is, to indicate to the querying party that it does not have the same IPSec SA triple by not returning a message. Then in this case, the inquiring party needs to start the waiting timer while sending the IPSec tunnel query message; when the waiting timer reaches the waiting time, the inquiring party judges whether it has received the IPSec tunnel query returned by the responding party. If the response message is received, it is determined that the tunnel corresponding to the message is available according to the received IPSec tunnel query response message; otherwise, the inquiring party determines that the current IPSec tunnel to be queried is unavailable, and ends the current processing flow of querying the IPSec tunnel status.

When the answering party indicates to the inquiring party that it does not have the same IPSecSA triplet by not returning a message, it can also set the query timer, query cycle and maximum query times to perform repeated queries. The process of repeated query is as described above, and will not be repeated here.

In this embodiment, in addition to triggering the inquiring party to inquire about the state of the IPSec tunnel between itself and the responding party before the inquiring party needs to use the IPSec tunnel with the responding party, it is also possible to perform periodic inquiries, that is, to set a timer , when the timer reaches the trigger period, the IPSec tunnel between the inquiring party and the responding party is triggered.

In the present invention, the periodic query of the IPSec tunnel and the query of the IPSec tunnel before a message needs to be sent are referred to as the timing of querying the IPSec tunnel.

Embodiment two

This embodiment introduces that: the inquiring party queries the status of more than one IPSec tunnel between itself and the responding party through an IPSec tunnel query message. The specific process is shown in Figure 2:

Step 201: The queryer sends an IPSec tunnel query message to the responder, and the IPSec tunnel query message carries more than one IPSec tunnel SA triplet currently to be queried.

The data format of the IPSec tunnel query message can inherit the format of the IKE DPD message or adopt a self-defined format. If the IKE DPD message format is inherited, the format shown in Table 2 can be used.

Table 2

The meaning of each field in Table 2 is the same as that of each field in Table 1, and will not be repeated here. Compared with Table 1, Table 2 only adds the protocol number field, SPI length field, reserved field and SPI field to carry more IPSec tunnel SA information. number is determined. Wherein, the added reserved fields may be filled with zeros or removed. Here, in the message type field, you need to fill in IPSec-DPD-Multi-Request, which is used to indicate that the inquiring party is querying for multiple IPSec tunnels; correspondingly, the responding party returns a response message to the inquiring party using the same message format , you need to fill in IPSec-DPD-Multi-Response in the message type field.

Step 202: The answering party receives the IPSec tunnel query message sent to itself by the inquiring party, and obtains triplets of multiple IPSec SAs carried in the received IPSec tunnel query message. Search in its own database according to the triplets of each IPSec SA, judge whether there is the same IPSec SA triplet for each IPSec SA triplet, and return the IPSec tunnel to the query party for the existence of the same IPSec SA triplet Query success message; return IPSec tunnel query failure message to the query party if there is no identical IPSec SA triple.

The process of parsing the received message by the responding party may follow the method described in step 102 in the first embodiment.

Here, the IPSec tunnel query success message is returned to the inquiring party for the existence of the same IPSec SA triple; and the IPSec tunnel query failure message is returned to the inquiring party for the absence of the same IPSec SA triple. The tuple returns the success or failure message of the IPSec tunnel query to the querying party respectively. For example, the inquiring party currently inquires 6 IPSec tunnels between itself and the responding party, and the responding party finds the same IPSec SA triplet for the 1st, 2nd and 3rd IPSec tunnels; The same IPSec SA triplet was not queried for the six IPSec tunnels. Then, at this time, the responding party returns IPSec tunnel query success messages to the querying party for the 1st, 2nd and 3rd IPSec tunnels respectively, and simultaneously returns IPSec tunnel querying failure messages to the responding party respectively for the 4th, 5th and 6th IPSec tunnels.

The answering party may also return the current inquiry status of each IPSec tunnel between the inquiring party and the responding party to the inquiring party through a message. When the inquiring party receives the response message returned by the responding party, the inquiring party can determine the status of each IPSec tunnel to be queried according to the content carried in the response message.

The format in which the responding party returns a response message to the querying party through a message may also be in the format shown in Table 2. The specific method can be to add another field after each SPI field to indicate whether the IPSec SA corresponding to the previous SPI field is successfully queried; it is also possible to reserve the SPI and protocol number for the IPSec SA that is queried successfully, and for the IPSec SA that fails to query IPSec SA removes SPI or protocol number.

Step 203: the inquiring party receives the response message returned by the responding party, and determines the status of each IPSec tunnel that needs to be queried currently according to the query status of each IPSec tunnel in the response message.

For example, if the responder returns a response message to the inquiring party through a message, the 1st, 2nd and 3rd IPSec tunnels all query the same IPSec SA triplet in themselves, but for the 4th, 5th and 6th IPSec tunnels, none If the same IPSec SA triple is queried; the inquiring party determines according to the content of the message, the responding party succeeds in inquiring about IPSec tunnels 1, 2 and 3, but fails in inquiring about IPSec tunnels 4, 5 and 6, then the inquiring party determines that IPSec tunnels 1, The statuses of 2 and 3 are available, and IPSec tunnels 4, 5, and 6 are unavailable.

If the responding party returns a response message for each IPSec tunnel, the querying party determines the status of the IPSec tunnel corresponding to the message according to each response message. In this case, refer to step 103 in the first embodiment.

In the second embodiment, when the responding party returns a response message to the querying party through a message, it can also set the waiting timer and the waiting time length in the same way as in the first embodiment. When the waiting timer reaches the waiting time, it judges whether it has received If the IPSec tunnel query response message returned by the responding party is received, the status of each IPSec tunnel is determined according to the query status of each IPSec tunnel in the IPSec tunnel response message; otherwise, the querying party determines that the IPSec tunnel to be queried is currently unavailable to end the current process of querying the status of the IPSec tunnel.

When the answering party returns the IPSec tunnel query success or failure message to the querying party respectively for different IPSec tunnels, it can also set the waiting timer and the waiting time length in the same way as in Embodiment 1. When the waiting timer reaches the waiting time length, according to its own current The received response message determines the state of the IPSec tunnel corresponding to the response message; if the responder does not return a response message for some IPSec tunnels, it is determined that the IPSec tunnel corresponding to the response message is not returned is unavailable, and ends the current query of the IPSec tunnel state processing flow.

When the answering party returns the success or failure message of the IPSec tunnel inquiry to the inquiring party respectively for different IPSec tunnels, in embodiment two, it is also possible to repeat the same query as in embodiment one, and set the query timer, query cycle and query times. While sending the IPSec tunnel query message, the queryer starts the query timer and starts counting the query messages sent from the query to the responder. When the query timer reaches the query period, the inquiring party judges whether it has determined the status of all IPSec tunnels to be queried. If all the statuses of the IPSec tunnels to be queried have been determined, the query timer stops timing and ends the current query process; As long as there is an IPSec tunnel whose status is not confirmed in the IPSec tunnel to be queried, the inquiring party will then judge whether the number of times the IPSec tunnel query message has been sent is less than or equal to the maximum number of queries set, if not, the query timer stops counting , end the current query process, if yes, send the IPSec tunnel query message to the responder again, which carries the SA triplet of the IPSec tunnel that is currently not confirmed to be available, and add 1 to the number of query messages that have been sent.

When the query timer and query period are set, the queryer can further judge whether the currently received response message is the response message of the query message sent in the current period when receiving the IPSec tunnel query response message returned by the responder , if yes, process the currently received response message; otherwise, do not process the currently received response message.

Here, it is also possible to process only the IPSec tunnel query success message returned by the inquiring party to the responder, and not to process the IPSec tunnel query failure message returned by the inquiring party to the responder, because even if the IPSec tunnel query failure message is forged by an attacker , the two sides of the communication only need to re-establish the IPSec tunnel, and the communication quality and communication security will not be greatly affected. Therefore, in this implementation mode, when the message received by the inquiring party is an IPSec tunnel query success message, it is further judged whether the currently received IPSec tunnel query success message is a response message to the query message sent in the current cycle, if If yes, process the currently received IPSec tunnel query success message; otherwise, do not process the currently received IPSec tunnel query success message.

In Embodiment 2, when the responding party does not have an IPSec SA triple to query IPSec, the processing method in Embodiment 1 may also be used, that is, to indicate to the querying party that it does not exist to query by not returning a response message. IPSec SA triplet of the IPSec tunnel. At this time, it is necessary to set the waiting timer and the waiting time. When the answering party returns a response message to the inquiring party through a message, when the waiting timer reaches the waiting time, the inquiring party judges whether it has received the IPSec tunnel query response message returned by the responding party. The query status of each IPSec tunnel in the tunnel response message determines the current status of each IPSec tunnel; otherwise, the inquiring party determines that the current IPSec tunnel to be queried is unavailable, and ends the current processing flow of querying the IPSec tunnel status. In the case that the answering party returns IPSec tunnel query success or failure messages to the querying party for different IPSec tunnels, it also needs to set the waiting timer and the waiting time length. When the waiting timer reaches the waiting time length, according to the received The response message determines the state of the IPSec tunnel corresponding to the response message; if the responder does not return a response message for some IPSec tunnels, it is determined that the IPSec tunnel corresponding to the response message is not returned is unavailable, and ends the current processing flow of querying the state of the IPSec tunnel.

When the answering party returns an IPSec tunnel query success message or does not return a response message to the querying party for each IPSec tunnel to be queried, it can also set the query timer, query cycle and query times to perform repeated queries. The specific process is the same as in the second embodiment The repeated queries are the same, and will not be repeated here.

In the present invention, when the answering party is unsuccessful in inquiring about the IPSec SA triplet, there are two implementations, one is to return an IPSec tunnel query failure message to the inquiring party, and the other is not to return any message to the inquiring party. These two implementations can be collectively referred to as failure to respond to the inquiring party in the responding direction.

In the present invention, in addition to determining whether there is one IPSec SA in both communication parties, determine whether there are two identical IPSec SAs in both communication parties, and then determine whether the IPSec tunnel established by both communication parties is available; the same IPSecSA to determine whether the IPSec tunnel established by the communication parties is available. That is, the IPSec tunnel query message carries the inquiring party's outbound SA triplet and inbound SA triplet at the same time, and then the responder checks whether the two SA triplets exist at the same time, and then determines the IPSec tunnel established by the two communicating parties. Whether it is available or not, other processing procedures here are the same as those described in Embodiment 1 and Embodiment 2, and will not be described in detail here.

The above descriptions are only preferred embodiments of the present invention, and are not intended to limit the protection scope of the present invention.

Claims (10)

1. A method for inquiring about the state of an IPSec tunnel, characterized in that the method may further comprise the steps: A. The query direction sends an IPSec tunnel query message to the responding party, and the IPSec tunnel query message carries at least one characteristic parameter of the IPSec tunnel to be queried; B. The responding party obtains the characteristic parameter carried in the IPSec tunnel query message, inquires whether the same characteristic parameter exists in itself, and returns the query result to the inquiring party; C. According to the query result returned by the responding party, when the responding party has the same characteristic parameter, it is determined that the IPSec tunnel corresponding to the same characteristic parameter is available; when the responding party does not have the same characteristic parameter, it is determined that the corresponding The IPSec tunnel that does not have the same characteristic parameters as above is unavailable. 2. The method according to claim 1, wherein when more than one IPSec tunnel is to be queried, in step B, the query result returned to the query party is: Return the query results of more than one IPSec tunnel to the querying party in one message; or For each IPSec tunnel, return a query result to the querying party. 3. The method according to claim 1, characterized in that, in step B, returning the query result to the querying party is: When the answering party has the same characteristic parameter, then return an IPSec tunnel query success message to the inquiring party for the same characteristic parameter; When the responding party does not have the same characteristic parameter, it fails to respond to the inquiring party regarding the absence of the same characteristic parameter. 4. The method according to claim 3, wherein the response failure is: the responder returns an IPSec tunnel query failure message to the inquiring party. 5. The method according to claim 3, characterized in that a waiting timer and a waiting period are further set, and when the inquiring party sends an IPSec tunnel query message, the waiting timer is started; In step B, the response failure is: when the responding party does not have the characteristic parameters to query the IPSec tunnel, the query result is not returned to the querying party; In step C, when the responding party has the same characteristic parameter, it is determined that the IPSec tunnel corresponding to the same characteristic parameter can be used as follows: when the waiting timer reaches the waiting time, the inquiring party receives the query result, then determines that the IPSec tunnel corresponding to the same characteristic parameter is: The IPSec tunnel corresponding to the query result is available; when the responder does not have the same characteristic parameter, then determining that the IPSec tunnel corresponding to the same characteristic parameter does not exist is unavailable: when the waiting timer reaches the waiting time, query If the party does not receive the query result, it is determined that the IPSec tunnel corresponding to the query result is unavailable. 6. The method according to claim 1, 3, 4 or 5, wherein a query timer and a query period are further set, and in step A, when the querying party sends an IPSec tunnel query message, the query timer is started; When the query timer reaches the query period, it is judged whether the state of the IPSec tunnel to be queried is determined, and if so, the query timer stops counting; otherwise, the querying party sends an IPSec tunnel query message for the IPSec tunnel without a certain state. 7. The method according to claim 6, characterized in that the maximum number of queries is further set to count the IPSec tunnel query messages sent by the querying party, Before the inquiring party sends the IPSec tunnel query message for the IPSec tunnel that does not have a definite state, further judge whether the currently sent IPSec tunnel query message is less than or equal to the maximum number of queries, if yes, then execute the sending IPSec tunnel query message; otherwise, end current processing flow. 8. The method according to claim 6, characterized in that, before step C, further comprising: Determine whether the query result returned by the responding party is the response to the query message sent by the querying party in the current query period, and if so, perform step C; otherwise, refuse to process the query result returned by the current responding party. 9. The method according to claim 1, characterized in that step A is performed when the inquiring party needs to send data to the responding party or the inquiry period is reached. 10. The method according to claim 1, wherein the characteristic parameters are: The security parameter index, destination IP address, and security protocol of the SA in the outbound direction of the IPSec tunnel; Or the security parameter index, destination IP address, and security protocol of the SA in the inbound direction of the IPSec tunnel; Or the security parameter index, destination IP address, and security protocol of the SA in the outbound direction of the IPSec tunnel, and the security parameter index, destination IP address, and security protocol of the SA in the inbound direction of the IPSec tunnel.

Images