WO2010075685A1 - 会话上下文的处理方法、装置和*** - Google Patents
会话上下文的处理方法、装置和*** Download PDFInfo
- Publication number
- WO2010075685A1 WO2010075685A1 PCT/CN2009/073064 CN2009073064W WO2010075685A1 WO 2010075685 A1 WO2010075685 A1 WO 2010075685A1 CN 2009073064 W CN2009073064 W CN 2009073064W WO 2010075685 A1 WO2010075685 A1 WO 2010075685A1
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- verification
- reset
- peer device
- information
- notification message
- Prior art date
Links
- 238000003672 processing method Methods 0.000 title abstract description 4
- 238000000034 method Methods 0.000 claims abstract description 45
- 238000012795 verification Methods 0.000 claims description 183
- 230000004044 response Effects 0.000 claims description 68
- 238000012545 processing Methods 0.000 claims description 50
- 238000012790 confirmation Methods 0.000 claims description 13
- 230000009466 transformation Effects 0.000 claims description 6
- 230000003993 interaction Effects 0.000 claims description 3
- 230000003213 activating effect Effects 0.000 claims description 2
- 208000001970 congenital sucrase-isomaltase deficiency Diseases 0.000 description 14
- 230000008569 process Effects 0.000 description 9
- 238000004891 communication Methods 0.000 description 8
- 238000012217 deletion Methods 0.000 description 6
- 230000037430 deletion Effects 0.000 description 6
- 238000010586 diagram Methods 0.000 description 5
- 238000004140 cleaning Methods 0.000 description 4
- 230000001960 triggered effect Effects 0.000 description 2
- 230000005641 tunneling Effects 0.000 description 2
- 230000005540 biological transmission Effects 0.000 description 1
- 238000004364 calculation method Methods 0.000 description 1
- 230000008859 change Effects 0.000 description 1
- 238000006243 chemical reaction Methods 0.000 description 1
- 238000005516 engineering process Methods 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 230000003287 optical effect Effects 0.000 description 1
- 230000011664 signaling Effects 0.000 description 1
- 238000006467 substitution reaction Methods 0.000 description 1
- 230000001131 transforming effect Effects 0.000 description 1
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/1066—Session management
- H04L65/1083—In-session procedures
- H04L65/1093—In-session procedures by adding participants; by removing participants
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/12—Applying verification of the received information
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
Definitions
- the present invention relates to the field of communications technologies, and in particular, to a method, apparatus, and system for processing a session context. Background technique
- a context for the transmission channel on multiple devices, and data of the control plane or the user plane is between the devices.
- the identifier of the corresponding context on the destination device is carried.
- the destination device finds the corresponding context according to the identifier of the context, and determines subsequent processing according to the parameters in the context, for example: forwarding, quality of service (Quality of Service, referred to as QoS) control, billing, etc.
- QoS quality of service
- Session contexts established on different devices for the same session are called each other
- a device may have an overall or partial module failure. In this case, the number of associated contexts affected on other devices may be very large. In the prior art, an overall reset notification or a partial reset notification is used to delete the associated context from other devices.
- a counterfeit source address attack may occur, that is, a reset (global or partial) notification message is applied by a method of spoofing the source address.
- the attacker can use the obtained identification information of the legal device node, for example: the IP address of the node, spoofing a reset notification message (in whole or in part) to other device nodes, and the other device node receives the counter notification message (for the counter Or partially) may be mistaken for a legitimate device node to send, and then delete all or part of the session context according to the counterfeit reset notification message (in whole or in part), resulting in a large number of session contexts being deleted by mistake, making the device impossible. Normal communication.
- the embodiment of the present invention provides a method, a device, and a system for processing a session context, so as to avoid erroneous deletion of an associated context on the device, ensure correctness of the context processing after receiving the reset notification message, and ensure normal communication of the device. Improve the security of the system.
- An embodiment of the present invention provides a method for processing a session context, including:
- the embodiment of the invention further provides a processing device for a session context, including:
- a receiving module configured to receive a reset notification message carrying device identification information
- a confirmation module configured to confirm that the peer device identified by the device identification information generates a reset event corresponding to the reset notification message
- a processing module configured to delete an association context related to the reset event.
- the embodiment of the present invention further provides a processing system for a session context, including a peer device and a local device;
- the reset device After the reset device is configured to send a reset notification message carrying the device identification information to the local device,
- the local device is configured to receive a reset notification message carrying the device identification information, confirm that the peer device identified by the device identification information generates a reset event corresponding to the reset notification message, and delete the association related to the reset event. Context.
- the local device in the embodiment of the present invention receives the reset notification message of the peer device, and needs to confirm with the peer device before deleting the association context related to the reset event of the peer device on the local device.
- the authenticity of the above-mentioned reset notification message avoids the erroneous deletion of the associated context on the device, ensures the correctness of the associated context processing after receiving the reset notification message, ensures the normal communication of the local device, and improves the security of the system. .
- FIG. 1 is a schematic flowchart of a method for processing a session context according to Embodiment 1 of the present invention
- FIG. 2 is a schematic flowchart of a method for processing a session context according to Embodiment 2 of the present invention
- FIG. 3 is a flowchart of a session according to Embodiment 3 of the present invention
- FIG. 4 is a schematic structural diagram of a session context processing apparatus according to Embodiment 4 of the present invention
- FIG. 5 is a schematic structural diagram of a session context processing apparatus according to Embodiment 5 of the present invention
- FIG. 7 is a schematic structural diagram of a processing system of a session context according to Embodiment 7 of the present invention.
- FIG. detailed description is a schematic flowchart of a method for processing a session context according to Embodiment 1 of the present invention
- FIG. 2 is a schematic flowchart of a method for processing a session context according to Embodiment 2 of the present invention
- FIG. 3 is
- FIG. 1 is a schematic flowchart of a method for processing a session context according to Embodiment 1 of the present invention.
- Step 101 Receive a reset notification message carrying device identification information.
- Step 102 Confirm that the peer device identified by the device identifier information generates a reset event corresponding to the reset notification message.
- Step 103 Delete an association context related to a reset event that occurs on the peer device.
- the reset notification message may be a global reset notification message, or may be a local reset notification message.
- the local device in this embodiment receives the reset notification message of the peer device, and needs to confirm the authenticity of the reset notification message with the peer device before deleting the association context related to the reset event of the peer device on the local device.
- the erroneous deletion of the association context on the device is prevented by the spoofing source address attack, which ensures the correctness of the processing of the associated context after receiving the reset notification message, and ensures that the local device performs normal communication.
- the method for applying the reset notification message to the device by using the method of counterfeiting the source address attack is more difficult to implement, and the imitation is reduced.
- the source address implements a reset notification to attack the risk, thereby improving the security of the system.
- step 201 the local device, that is, the device B, receives an overall reset notification message carrying the device identifier of the peer device, that is, the device A;
- the overall reset notification message in this embodiment may be an independent message. After receiving the overall reset notification message as an independent message, the local device initially determines that an overall reset event (restart) event has occurred on the peer device.
- the overall reset notification message in this embodiment may also be an existing message in other protocol messages, and is not specifically used to notify a message that an overall reset event occurs, for example, may be in a GPRS tunneling protocol (GPRS tunneling protocol,
- the message such as the Create Session Request message and the Echo Request message in the GTP is further carried with the restart count value cell to notify the peer local device that an overall reset event has occurred.
- the local device determines whether the peer device has an overall reset event (restart) by comparing whether the restart count value of the peer device carried in the received message is compared with the original restart count value of the previously stored peer device. event.
- the device ID of the device A may be the IP address of the device A, that is, the source address of the overall reset notification message is the IP address of the device A;
- Step 202 After the device B is notified that the device A has an overall reset event (restart) event, it sends an authentication request message carrying the verification parameter to the device A, for example, an echo request message in the GTP.
- an authentication request message carrying the verification parameter for example, an echo request message in the GTP.
- the verification parameter therein can directly use the sequence number of the GTP header, and is allocated by the sender's device B and set in the GTP header of the echo request message.
- the verification parameter in this embodiment may also be any other form of additional verification parameter.
- Step 203 The device A receives the verification request message, and sends an authentication response message to the device B according to the preset processing policy, for example, sending an echo response (Echo Response) message in the GTP, where the verification response message carries the verification parameter. Information and the current restart count value of device A.
- Echo Response echo response
- the sequence number of the GTP header in the echo response message returned by the device A to the device B should be filled in as the serial number of the corresponding echo request message GTP header, therefore, if the device B receives the device A returns an echo response message and the sequence number in the echo response message matches the sequence number in the echo request message, indicating that the echo response message is a response message from device A.
- the device A should simultaneously carry the additional verification parameter in the verification response message when returning the verification response message.
- the result of the above-mentioned additional verification parameter being transformed by the preset certain transformation algorithm negotiated by the device A and the device B transformation verification parameter
- transformation verification parameter may be carried in the verification response message, and the corresponding transformation algorithm may be using the device A and the device.
- the key after B negotiation (automatic negotiation or manual negotiation) is encrypted or hashed. If the overall reset notification message in step 201 is indeed sent by device A, the current restart count value of device A in this step should be the same as the restart count value in step 201.
- the device B may also send the verification parameter to the device A without passing the verification request message, but set the verification parameter on the device A by negotiating with the device A, and the device A returns the verification.
- the information of the set verification parameter should be carried in the verification response message at the same time;
- Step 204 The device B receives the verification response message.
- the information about the verification parameter carried in the verification response message can be trusted to verify that the verification response message is from the device A. Therefore, the current restart count value of the device A carried in the response message is verified. It can be trusted that device B compares the current restart count value of device A carried in the verification response message with the stored original restart count value. If the two are inconsistent, and confirm that the peer device actually has an overall reset event, delete device A. Corresponding association context.
- the device B compares the current restart count value of the device A carried in the verification response message with the previously stored device A original restart count value: The restart count value does change, then device B confirms Device A does have an overall reset event, and the garbage context cleaning process is started to delete the association context corresponding to device A.
- Device B further saves the current restart count value of device A carried in the verification response message as the latest restart of device A. Count value; if the two values are the same, it means that the restart count value of device A has not changed, that is to say, the overall reset notification message received by device B is counterfeit, and the restart count value carried in the overall reset notification message is It is not the latest restart count value of device A.
- Device B ignores the overall reset notification message and does not start the garbage context cleanup process.
- the processing method of the session context in this embodiment is applied because the information of the verification parameter carried in the verification response message in step 203 needs to match the verification parameter carried in the verification request message in step 202.
- the attacker successfully performs the attack it is required to be able to intercept the verification request message sent by the device B to the device A in step 202 to obtain the verification parameter carried therein.
- the message carrying the latest restart count value of the device A in step 201 is a response message, for example, a Create Session Response message, an Echo Response message, and the like in the GTP. Since the information of the verification parameter carried in the response message must be the same as the verification parameter allocated by the request message corresponding to the device B, the verification function of the step 202 and the step 203 has been performed to some extent, and therefore, the response message is received. If the current restart count value of the carried device A is changed from the previously stored device A original restart count value, the verification process of step 202 and step 203 of this embodiment may not be performed. In fact, in this embodiment, the overall reset notification message that is actively sent by the peer device is not trusted. When the overall reset notification message sent by the peer device is received, the interaction with the peer device is triggered to confirm the whole. The authenticity of the body reset event.
- a response message for example, a Create Session Response message, an Echo Response message, and the like in the GTP. Since the information of the verification parameter carried in the response message
- the device A may also carry the latest restart count value of the device B or other identification information generated by the device B in advance in the message of step 201 or 203 to verify The peer device that previously sent the overall reset notification message has indeed received the authentication request message of the local device. It should be noted that, if the device A is required to carry the latest restart count value of the device B or other identification information generated by the device B in advance, the embodiment may further skip the verification process of step 202 and step 203. Step 204 is directly executed, that is, the step of performing active verification in this case is optional.
- the device B after receiving the overall reset notification message about the device A, the device B sends an authentication request message to the device A to verify the authenticity of the device A restart count value before starting the scan cleanup garbage context processing. After the confirmation of device A is obtained, the scan cleanup garbage context processing is started.
- the verification parameter sent by the device B to the device A in step 202 may set a valid time range, that is, the verification parameter should be returned from the device A to the device B only within a certain period of time (for example: 10 seconds) ) is valid.
- a certain period of time for example: 10 seconds
- Device B discards the received verification response message directly, and does not initiate the deletion step of the associated context associated with device A.
- the device B may start a verification response message returned by the device A after the device sends the verification request message carrying the verification parameter to the device A.
- the device B may also directly send the verification request message to the device A.
- the local timestamp information is used as part of the verification parameter.
- the device B After receiving the verification response message returned by the device A, the device B compares the timestamp information in the verification parameter carried in the verification response message with the current local time, according to the difference. Whether the value is within the valid time range, determine whether to delete the associated context associated with device A.
- the device is not an overall fault, but a part of the module inside the device (for example, a board) has failed. At this time, what is affected needs to be cleaned up is a part of the associated context related to the module, not all.
- a session context in the device is established on a resource combination composed of multiple resource modules, so the situation is more complicated.
- the resource modules in the device are functionally identical, and do not affect the description of the solution of the present invention.
- Device A consists of N resource modules with the same function, for example: a board.
- FIG. 3 is a schematic flowchart of a method for processing a session context according to Embodiment 3 of the present invention. As shown in FIG. 3, the method for processing a session
- Step 301 The local device, that is, the device B, receives the local reset notification message carrying the device identifier and the CSID of the peer device, that is, the device A.
- the local reset notification message in this embodiment may be an independent message, for example, a Delete Public Data Network Connection Set Request message in the GTP, to notify the peer local device that a local reset event has occurred. .
- the local device After receiving the local reset notification message as an independent message, the local device initially determines that a local reset event (restart) event has occurred on the peer device.
- the local reset notification message in this embodiment may also be an existing message in other protocol messages, and is not specifically used to notify a message that a local reset event occurs.
- the device ID of device A may be the IP address of device A, that is, the source address of the local reset notification message is the IP address of device A. It is assumed that a certain number of associated sessions are pre-established between the device A and the device B. During the session establishment process, the CSIDs assigned to the session are exchanged between the devices, and the CSID assigned by the peer device is stored in the intra-device session context.
- the device A has a local resource module fault, and the device A sends a local reset notification message to the device B.
- the local reset notification message may also carry the CSID corresponding to the resource module of the device A fault, for notifying the local device that the fault occurs.
- Step 302 After the device B is notified that the device A has a local reset event (restart) event, it sends an authentication request message carrying the verification parameter to the device A, for example: the deleted PDN in the GTP.
- the Delete PDN Connection Set Response message, the cause value (Cause) in the Delete PDN Connection Set Reply message is set to "requires verification".
- the verification parameter may be any form of verification parameter, for example: a verification key allocated by device B, which may be a 64-bit verification parameter;
- Step 303 The device A receives the verification request message, and sends an authentication response message to the device B according to the preset processing policy, for example: resending the delete PDN connection set request message, which is different from the message in step 301, the verification response
- the message also carries information of the verification parameter carried by the device B in step 302 to the device A for verifying the authenticity of the local reset. If the local reset notification message in the step 301 does not contain the CSID corresponding to the resource module that is faulty, the verification response message in this step should also carry the CSID corresponding to the resource module of the device A fault, for notifying the local end. a resource module in which the device has failed;
- the information about the verification parameter carried in the verification response message may be the original verification parameter carried in the verification request message, or may be a transformation algorithm after the original verification parameter is negotiated by the device A and the device B.
- the method for transforming the verification parameter may be an encryption or hash (hash) operation using a key negotiated between device A and device B (automatic negotiation or manual negotiation).
- the device B may also send the verification parameter to the device A without passing the verification request message, but set the verification parameter on the device A in advance by negotiating with the device A. Similarly, the device A is in the return verification. When the message is answered, the set verification parameter should be carried in the verification response message at the same time;
- Step 304 The device B receives the verification response message, and according to the information of the verification parameter carried in the verification response message, it is confirmed that the received local reset notification message is from the device A, and then the local reset event can be confirmed. Then, the associated context corresponding to the CSID of the resource module that is partially failed by the device A is deleted.
- the processing method of the session context in this embodiment is applied because the information of the verification parameter carried in the verification response message in step 303 must match the verification parameter carried in the verification request message in step 302.
- the attacker needs to be able to intercept the verification request message sent by the device B to the device A in step 302 to obtain the verification parameter carried therein.
- An attacker can send a local reset notification message to device B by using the IP address of device A as the source address and successfully reach device B.
- the verification request message in the message is usually mixed in a massive data stream, so even if the verification request message in step 302 passes the attacker's attack location, the attacker must be in a short time (must hit the real device) Before A returns the verification response message normally, the amount of calculation of the verification request message in step 302 is also filtered out from the mass data.
- the setting has been greatly narrowed, and the difficulty of attack has been greatly improved.
- the message received by the device B in step 301 may also be a request to delete the public data network connection set in the GTP carrying the information that the device B carries to the device A to verify the authentication parameters of the local reset authenticity.
- the message has been verified to a certain extent by the steps 302 and 303, and the verification process of step 302 and step 303 of this embodiment may not be performed.
- the local reset notification message that is actively sent by the peer device is not trusted.
- the interaction with the peer device is triggered to verify the authenticity of the local reset event.
- the device A may further carry the latest restart count value of the device B or other identifier information generated by the device B in advance in the message of step 301 or 303.
- the peer device that sends the local reset notification message before the verification does receive the authentication request message of the local device. It should be noted that, if the device A is required to carry the latest restart count value of the device B or other identification information generated by the device B in advance, the embodiment may further skip the verification process of step 302 and step 303. Step 304 is directly executed, that is, the step of performing active verification in this case is optional.
- the device B after receiving the local reset notification message about the device A, the device B sends an authentication request message to the device A to verify the authenticity of the device A local resource module failure before starting the scan cleaning garbage context processing. After the confirmation of the device A is obtained, the garbage context processing corresponding to the scan cleaning CSID is started.
- the verification parameter sent by the device B to the device A can be set to a valid time range.
- the processing device of the session context of this embodiment may include a receiving module 41, a confirming module 42, and a processing module 43.
- the receiving module 41 receives the reset notification message carrying the device identification information
- the confirmation module 42 confirms that the peer device identified by the device identification information has a reset event corresponding to the reset notification message received by the receiving module 41, and the processing module 43 deletes the opposite end.
- the associated context associated with the device's reset event may be used to be set to a valid time range.
- the reset notification message received by the receiving module 41 may be a global reset notification message, or may be a local reset notification message.
- the verification module 42 and the peer device can confirm that the authenticity of the reset notification message received by the receiving module 41 can be obtained by acquiring the verification parameter allocated by the peer device, and the verification parameter can be sent by the local device to the pair through the verification message.
- the end device can also be preset on the peer device.
- the receiving module in this embodiment receives the reset notification message of the peer device, and the processing module needs to confirm the reset notification message with the peer device before deleting the association context related to the reset event of the peer device on the local device.
- the authenticity avoids the erroneous deletion of the association context on the device due to the attack of the spoofing source address, ensuring the correctness of the processing of the associated context after receiving the reset notification message, and ensuring that the local device performs normal communication.
- the method for applying the reset notification message to the device by using the method of the counterfeit source address attack is more difficult to implement, and the risk of implementing the reset notification attack by the counterfeit source address is reduced, thereby improving the security of the system.
- the acknowledgment module in the processing device of the session context of the embodiment may be configured to perform mutual authentication with the peer device to confirm that the reset notification message is from the peer device.
- the confirmation module 42 in this embodiment may further include a first request verification unit 421, a first response verification unit 422, and a first confirmation unit 423.
- the first request verification unit 421 sends the verification request message carrying the verification parameter to the peer device
- the first response verification unit 422 receives the verification response message returned by the peer device according to the verification request message, where the verification response message carries the verification.
- the information of the parameter, the first confirming unit 423 confirms that the reset event occurs by the peer device according to the information of the above-mentioned verification parameter.
- the receiving module after receiving the reset notification message about the peer device, the receiving module, before the processing module starts the scan cleanup garbage context processing, confirms that the first request verification unit of the module sends the verification parameter carrying the verification parameter to the peer device. Verifying the request message to verify the authenticity of the reset (restart) event of the peer device, after the first response verification unit receives the verification response message returned by the peer device carrying the information of the above verification parameter, the first confirmation unit may The acknowledgment that the reset notification message received by the receiving module is from the peer device, to trigger the processing module to restart the scan cleanup garbage context processing.
- FIG. 6 is a schematic structural diagram of a device for processing a session context according to Embodiment 6 of the present invention.
- the verification parameter obtained by the peer device in this embodiment may also be
- the acknowledgment module 42 in this embodiment may further include a second request verification unit 424, a second response verification unit 425, and a second acknowledgment unit. 426.
- the second request verification unit 424 sends an authentication request message to the peer device, and the second response verification unit 425 receives the verification response message returned by the peer device according to the verification request message, where the verification response message carries a preset setting in the peer device.
- the information of the verification parameter on the second verification unit 426 confirms that the reset event occurs on the peer device according to the information of the verification parameter.
- the receiving module after receiving the reset notification message about the peer device, sends the verification request message to the peer device to verify the second request verification unit of the module before starting the scan cleaning garbage context processing.
- the authenticity of the reset (restart) event of the peer device after the second response verification unit receives the verification response message returned by the peer device and carrying the information of the verification parameter preset on the peer device, the second confirmation unit Then, it can be confirmed that the reset notification message received by the receiving module is from the peer device, to trigger the processing module to restart the scan cleanup garbage context processing.
- the reset notification message received by the receiving module in the embodiment may further carry the information of the verification parameter, and the confirmation module may specifically confirm that the reset event occurs by the peer device according to the information of the verification parameter.
- FIG. 7 is a schematic structural diagram of a processing system of a session context according to Embodiment 7 of the present invention.
- the processing system of the session context in this embodiment may include a peer device 71 and a local device 72.
- the peer device 71 is configured to send a reset notification message carrying the device identification information to the local device 72 after the reset event occurs.
- the local device 72 is configured to receive a reset notification message carrying the device identification information, confirm that the peer device 71 identified by the device identification information generates a reset event corresponding to the reset notification message, and delete the associated context related to the reset event.
- the method in the first embodiment and the functions of the device B in the second and third embodiments can be implemented by the local device 72 in the session context processing system provided by the embodiment of the present invention.
- the local device in this embodiment receives the reset notification message of the peer device, and needs to confirm the authenticity of the reset notification message with the peer device before deleting the association context related to the reset event of the peer device on the local device.
- the erroneous deletion of the association context on the device is prevented by the spoofing source address attack, which ensures the correctness of the processing of the associated context after receiving the reset notification message, and ensures that the local device performs normal communication.
- the method for applying the reset notification message to the device by using the method of counterfeiting the source address attack is more difficult to implement, and the risk of implementing the reset notification attack by the counterfeit source address is reduced, thereby improving the security of the system.
- the foregoing embodiment of the present invention does not limit the network system to be applied.
- the embodiment of the present invention is only described by taking GTP as an example.
- the idea of the invention can also be applied to other protocol messages.
- the overall reset notification message may be a heartbeat message carrying a restart count value, and the receiving device can also pass Sending a heartbeat request message and receiving a heartbeat response message of the peer device to verify the authenticity of the overall reset event of the peer device;
- the local reset notification message may be a binding revocation indication carrying the CSID option (Binding Revocation Indication) Message, and the receiving device can return the Binding Revocation Acknowledgement message with a special reason value (for example: "requires verification”) and the verification parameter and ask the peer to resend the binding with the verification parameter.
- An indication message is used to verify the authenticity of the local reset event of the peer device.
- the foregoing storage medium includes: a medium that can store program codes, such as a ROM, a RAM, a magnetic disk, or an optical disk.
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Security & Cryptography (AREA)
- Business, Economics & Management (AREA)
- General Business, Economics & Management (AREA)
- Multimedia (AREA)
- Computer Hardware Design (AREA)
- Computing Systems (AREA)
- General Engineering & Computer Science (AREA)
- Computer And Data Communications (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Description
会话上下文的处理方法、 装置和*** 技术领域
本发明涉及通信技术领域, 特别涉及一种会话上下文的处理方法、 装置 和***。 背景技术
在通信网络***中, 为了在***中多个设备之间建立传输数据的通道, 通常需要在多个设备上为该传输通道分别建立上下文(Context ), 控制面或 者用户面的数据在设备之间传输时, 携带目的端设备上对应上下文的标识, 目的端设备接收到数据后, 根据该上下文的标识查找到对应的上下文, 根据 上下文中的参数确定后续处理, 例如: 转发、 服务质量(Quality of Service, 简称 QoS )控制、 计费等等。
为同一个会话 ( Session )在不同设备上建立的会话上下文彼此之间称为
被清除掉。 一个设备可能整体或者局部模块失效, 此时其他设备上受影响的 关联上下文的数量就可能非常多, 现有技术中采用整体复位通知或局部复位 通知向其他设备删除关联上下文。
在现有的整体复位通知和局部复位通知流程中, 可能会出现仿冒源地址 攻击现象, 即通过仿冒源地址的方法应用复位(整体或局部)通知消息。 攻 击者可以利用获取的合法设备节点的标识信息, 例如: 该节点的 IP地址, 仿 冒一条复位通知消息 (整体或局部) 向其他设备节点发送, 其他设备节点接 收到该仿冒的复位通知消息 (整体或局部)会误认为是合法设备节点所发送 的, 则会根据该仿冒的复位通知消息 (整体或局部)删除全部或部分会话上 下文, 从而导致了大量的会话上下文被误删除, 使得设备无法进行正常的通 信。 发明内容
本发明实施例提供一种会话上下文的处理方法、 装置和***, 用以避免 错误删除设备上的关联上下文, 确保接收到复位通知消息之后对关联上下文 处理的正确性, 保证设备进行正常的通信, 提高***的安全性。
本发明实施例提供了一种会话上下文的处理方法, 包括:
接收携带有设备标识信息的复位通知消息;
确认所述设备标识信息标识的对端设备发生所述复位通知消息对应的复 位事件;
删除与所述复位事件相关的关联上下文。
本发明实施例还提供了一种会话上下文的处理装置, 包括:
接收模块, 用于接收携带有设备标识信息的复位通知消息;
确认模块, 用于确认所述设备标识信息标识的对端设备发生所述复位通 知消息对应的复位事件;
处理模块, 用于删除与所述复位事件相关的关联上下文。
本发明实施例又提供了一种会话上下文的处理***, 包括对端设备和本 端设备;
所述对端设备用于发生复位事件后, 向所述本端设备发送携带有设备标 识信息的复位通知消息;
所述本端设备用于接收携带有设备标识信息的复位通知消息, 确认所述 设备标识信息标识的对端设备发生所述复位通知消息对应的复位事件, 并删 除与所述复位事件相关的关联上下文。
由上述技术方案可知, 本发明实施例中的本端设备接收到对端设备的复 位通知消息, 在删除本端设备上与对端设备的复位事件相关的关联上下文之 前, 需要与对端设备确认上述复位通知消息的真实性, 避免了错误删除设备 上的关联上下文, 确保了接收到复位通知消息之后对关联上下文处理的正确 性, 保证了本端设备进行正常的通信, 提高了***的安全性。 附图说明 施例或现有技术描述中所需要使用的附图作简单地介绍, 显而易见地, 下面
描述中的附图仅仅是本发明的一些实施例, 对于本领域普通技术人员来讲, 在不付出创造性劳动的前提下, 还可以根据这些附图获得其他的附图。
图 1为本发明实施例一提供的会话上下文的处理方法的流程示意图; 图 2为本发明实施例二提供的会话上下文的处理方法的流程示意图; 图 3为本发明实施例三提供的会话上下文的处理方法的流程示意图; 图 4为本发明实施例四提供的会话上下文的处理装置的结构示意图; 图 5为本发明实施例五提供的会话上下文的处理装置的结构示意图; 图 6为本发明实施例六提供的会话上下文的处理装置的结构示意图; 图 7为本发明实施例七提供的会话上下文的处理***的结构示意图。 具体实施方式
下面将结合本发明实施例中的附图, 对本发明实施例中的技术方案进行 清楚、 完整地描述, 显然, 所描述的实施例仅仅是本发明一部分实施例, 而 不是全部的实施例。 基于本发明中的实施例, 本领域普通技术人员在没有做 出创造性劳动前提下所获得的所有其他实施例, 都属于本发明保护的范围。
图 1 为本发明实施例一提供的会话上下文的处理方法的流程示意图, 如 步骤 101、 接收携带有设备标识信息的复位通知消息;
步骤 102、 确认上述设备标识信息标识的对端设备发生上述复位通知消 息对应的复位事件;
步骤 103、 删除与对端设备发生的复位事件相关的关联上下文。
其中的复位通知消息可以为全局复位通知消息, 还可以为局部复位通知 消息。
本实施例中的本端设备接收到对端设备的复位通知消息, 在删除本端设 备上与对端设备的复位事件相关的关联上下文之前, 需要与对端设备确认上 述复位通知消息的真实性, 避免了由于受到仿冒源地址攻击而错误删除设备 上的关联上下文, 确保了接收到复位通知消息之后对关联上下文处理的正确 性, 保证了本端设备进行正常的通信。 本实施例能够使得通过仿冒源地址攻 击的方法应用复位通知消息对设备进行攻击的实施难度增加, 减少了通过仿
冒源地址实施复位通知攻击的风险, 从而提高了***的安全性。
图 2为本发明实施例二提供的会话上下文的处理方法的流程示意图, 如 步骤 201、 本端设备即设备 B接收到携带有对端设备即设备 A的设备标 识的整体复位通知消息;
本实施例中的整体复位通知消息可以为一个独立消息, 本端设备接收到 作为一个独立消息的整体复位通知消息之后, 初步判断对端设备发生了整体 复位事件(重启)事件。
可选地, 本实施例中的整体复位通知消息还可以为其他协议消息中的现 有消息,并不是专门用于通知发生整体复位事件的消息,例如:可以在 GPRS 隧道协议( GPRS tunneling protocol, 简称 GTP )中的建立会话请求( Create Session Request ) 消息、 回声请求 ( Echo Request ) 消息等消息中进一步 携带重启计数值信元, 以通知对端本端设备发生了整体复位事件。 本端设备 通过将接收到的消息中所携带的对端设备的重启计数值与之前存储的对端设 备的原重启计数值进行比较是否改变来判断对端设备是否发生了整体复位事 件(重启) 事件。
其中的设备 A的设备标识可以为设备 A的 IP地址, 即该整体复位通知 消息的源地址为设备 A的 I P地址;
步骤 202、设备 B被通知设备 A发生了整体复位事件 (重启 )事件之后, 向设备 A发送携带有验证参数的验证请求消息, 例如: GTP中的回声请求消 息;
本步骤中, 在使用回声请求消息作为验证请求消息时, 其中的验证参数 可以直接使用 GTP头部的序列号( Sequence Number ), 由发送方的设备 B 分配并设置在回声请求消息的 GTP头部中。 可选地, 除序列号之外, 本实施 例中的验证参数也可以为其他任何形式的附加验证参数。 如果之前设备 B没 有存储设备 A的原重启计数值,则在存储步骤 201的消息中携带的设备 A最 新的重启计数值之前也需要执行本步骤; 如果步骤 201的消息中携带的设备 A最新的重启计数值与设备 B存储的设备 A的原重启计数值一致, 则设备 B 不发送验证请求消息, 不再进行后续处理;
步骤 203、 设备 A接收到验证请求消息, 按照预设的处理策略向设备 B 发送验证应答消息,例如:发送 GTP中的回声应答( Echo Response )消息, 该验证应答消息中携带有上述验证参数的信息和设备 A的当前重启计数值。
本步骤中,设备 A向设备 B返回的回声应答消息中 GTP头部的序列号, 按照 GTP的规定, 应该填写为对应的回声请求消息 GTP头部的序列号, 因 此, 如果设备 B接收到了设备 A返回的回声应答消息并且回声应答消息中的 序列号与回声请求消息中的序列号匹配, 则说明回声应答消息是真实来自设 备 A的应答消息。
如果设备 B发送到设备 A的验证请求消息中除了 GTP头部的序列号以 外还携带了其他附加验证参数, 则设备 A在返回验证应答消息时应同时将附 加验证参数携带在验证应答消息中, 也可以将上述附加验证参数通过设备 A 与设备 B协商后的预设某种变换算法进行变换后的结果(变换验证参数)携 带在验证应答消息中, 相应的变换算法可以是利用设备 A与设备 B协商(自 动协商或者人工协商)后的密钥进行加密或者散列 (哈希)运算等。 如果步 骤 201 中的整体复位通知消息的确是设备 A发送的,则本步骤中的设备 A的 当前重启计数值应该与步骤 201 中的重启计数值相同。
可选地, 步骤 202中设备 B也可以不通过验证请求消息将验证参数下发 到设备 A, 而是通过与设备 A进行协商预先将验证参数设置在设备 A上, 同 样, 设备 A在返回验证应答消息时应同时将该设置的验证参数的信息携带在 验证应答消息中;
步骤 204、 设备 B接收到验证应答消息, 由于根据该验证应答消息中所 携带的验证参数的信息可以相信验证应答消息真实的来自设备 A, 因此验证 应答消息中携带的设备 A的当前重启计数值可以信任, 设备 B比较该验证应 答消息中所携带的设备 A的当前重启计数值与存储的原重启计数值, 如果两 者不一致, 确认对端设备真实发生了整体复位事件, 则删除与设备 A对应的 关联上下文。
本步骤中, 设备 B接收到验证应答消息之后, 将该验证应答消息中所携 带的设备 A的当前重启计数值与之前存储的设备 A的原重启计数值进行比 较: 如果两个数值不一致, 说明重启计数值确实发生了变化, 则设备 B确认
设备 A确实发生了整体复位事件, 启动垃圾上下文清理处理以删除与设备 A 对应的关联上下文, 设备 B还进一步将验证应答消息中所携带的设备 A的当 前重启计数值保存为设备 A最新的重启计数值; 如果两个数值一致, 说明设 备 A的重启计数值没有发生了变化, 也就是说设备 B接收到的整体复位通知 消息是仿冒的, 该整体复位通知消息中所携带的重启计数值并不是设备 A最 新的重启计数值, 设备 B则忽略该整体复位通知消息, 不会启动垃圾上下文 清理处理。
本实施例中, 由于步骤 203中的验证应答消息中所携带的验证参数的信 息需要与步骤 202中验证请求消息中所携带的验证参数相匹配, 因此在应用 本实施例的会话上下文的处理方法后, 攻击者要成功实施攻击, 需要能够截 获到步骤 202中设备 B向设备 A发送的验证请求消息以获取其中所携带的验 证参数。 这对攻击者提出了更高的要求, 因为在其发起攻击的网络位置, 也 许攻击者可以假冒设备 A的 IP地址作为源地址向设备 B发送整体复位通知 消息并成功达到设备 B, 但并不能保证其一定能够截获目的地址为设备 A的 IP地址的消息; 同时由于步骤 202中的验证请求消息通常是夹杂在海量的数 据流中的, 因此即使步骤 202中的验证请求消息经过了攻击者发起攻击的位 置, 攻击者要在很短的时间内 (必须赶在真实的设备 A正常返回验证应答消 息之前 )从海量数据中过滤出步骤 202中的该验证请求消息运算量也 4艮大。 置被大大收窄了, 同时攻击难度也大大提高了。
需要说明的是: 如果步骤 201 中携带有设备 A最新的重启计数值的消息 是一条响应消息,例如: GTP中的建立会话响应( Create Session Response ) 消息、 回声响应 (Echo Response ) 消息等。 由于上述响应消息中携带的验 证参数的信息必须与由设备 B为对应的请求消息分配的验证参数相同, 一定 程度上已经起到了步骤 202和步骤 203的验证作用, 因此对接收到响应消息 中所携带的设备 A的当前重启计数值与之前存储的设备 A的原重启计数值发 生改变的情况, 可以不执行本实施例步骤 202和步骤 203的验证过程。 实际 上, 本实施例是不信任对端设备主动发送的整体复位通知消息, 在接收到对 端设备主动发送的整体复位通知消息时, 触发与对端设备交互验证以确认整
体复位事件的真实性。
进一步地, 为了增加攻击者攻击的难度, 本实施例中设备 A还可以在步 骤 201 或者 203的消息中将设备 B最新的重启计数值或其他预先由设备 B 生成的标识信息携带上, 以验证之前发送整体复位通知消息的对端设备确实 曾经接收过本端设备的验证请求消息。 需要说明的是: 如果要求设备 A在步 骤 201将设备 B最新的重启计数值或其他预先由设备 B生成的标识信息携带 上, 则本实施例还可以跳过步骤 202和步骤 203的验证过程, 直接执行步骤 204, 即这种情况下执行主动验证的步骤是可选的。
在本实施例中, 设备 B在接收到关于设备 A的整体复位通知消息之后, 在启动扫描清理垃圾上下文处理之前, 向设备 A发送验证请求消息以验证设 备 A的重启计数值发生变化的真实性, 在得到设备 A的确认之后, 再启动扫 描清理垃圾上下文处理。
进一步地,步骤 202中设备 B向设备 A下发的验证参数可以设置一有效 时间范围, 也就是说, 该验证参数应该只在一段时间范围之内从设备 A返回 给设备 B (例如: 10秒)才有效, 超过该时间范围的时限后, 设备 B会将接 收到的验证应答消息直接丟弃, 不会发起与设备 A相关的关联上下文的删除 步骤。 在具体实现中, 设备 B可以在向设备 A发送携带有验证参数的验证请 求消息之后启动一个定时器等待设备 A返回的验证应答消息; 设备 B还可以 直接将向设备 A发送验证请求消息时的本地时间戳信息作为验证参数的一部 分, 当接收到设备 A返回的验证应答消息之后, 设备 B对该验证应答消息中 所携带的验证参数中的时间戳信息与当前本地时间进行比较, 根据其差值是 否在有效时间范围之内, 确定是否删除与设备 A相关的关联上下文。
有时候设备并不是整体故障, 而是设备内部部分模块(例如: 单板)发 生了故障, 此时受影响需要清理的则是与该模块相关的一部分关联上下文, 而非全部。 可以理解的是, 实际设备实现中通常设备内有多种功能不同的资 源模块, 设备内的一个会话上下文是建立在由多种资源模块构成的资源组合 上, 因此情况会更复杂些。 本发明实施例中, 为了简单起见, 假设设备内只 有一种类型的资源, 即设备内的资源模块是功能相同的, 不影响本发明的方 案描述。 例如: 设备 A由 N块功能相同的资源模块组成, 例如: 单板。 设备
A可以选择在任意一块资源模块上创建会话上下文。 设备 A为每个资源模块 (当存在多种功能不同的资源模块时, 为资源模块的组合)分配一个资源模 块标识 ( PDN Connection Set Identifier, 简称 CSID )。在创建会话的过程中 , 本端设备, 例如: 设备 A, 选择其某个资源模块建立会话上下文, 则设备 A 会将该资源模块对应的 CSID随会话创建信令携带给对端设备,例如:设备 B; 类似地, 设备 B也选择其一个资源模块建立会话上下文, 在会话上下文中保 存设备 A为该会话分配的 CSID, 同时把本端建立该会话上下文所选择的资 源模块对应的 CSID返回给设备 A, 设备 A也在其上会话上下文中保存设备 B为该会话分配的 CSID。图 3为本发明实施例三提供的会话上下文的处理方 法的流程示意图, 如图 3所示, 本实施例的会话上下文的处理方法可以具体 包括以下步骤:
步骤 301、 本端设备即设备 B接收到携带有对端设备即设备 A的设备标 识和 CSID的局部复位通知消息。
本实施例中的局部复位通知消息可以为一个独立消息, 例如: GTP中的 删除公共数据网连接集合请求( Delete Public Data Network Connection Set Request ) 消息, 以通知对端本端设备发生了局部复位事件。 本端设备接收 到作为一个独立消息的局部复位通知消息之后, 初步判断对端设备发生了局 部复位事件(重启) 事件。
可选地, 本实施例中的局部复位通知消息还可以为其他协议消息中的现 有消息, 并不是专门用于通知发生局部复位事件的消息。
其中的设备 A的设备标识可以为设备 A的 IP地址, 即该局部复位通知 消息的源地址为设备 A的 IP地址。 假设设备 A与设备 B之间预先建立了一 定数量关联会话,在会话建立过程中,设备之间交换了为该会话分配的 CSID, 在设备内会话上下文中存储了对端设备为之分配的 CSID, 设备 A发生了局 部资源模块故障, 设备 A向设备 B发送局部复位通知消息, 该局部复位通知 消息中还可以携带有设备 A故障的资源模块对应的 CSID, 以供通知本端设 备发生故障的资源模块;
步骤 302、设备 B被通知设备 A发生了局部复位事件(重启)事件之后, 向设备 A发送携带有验证参数的验证请求消息, 例如: GTP中的删除 PDN
连接集合应答 ( Delete PDN Connection Set Response )消息, 该删除 PDN 连接集合应答消息中的原因值(Cause )设置为 "需要验证"。
其中的验证参数可以为任何形式的验证参数, 例如: 设备 B分配的一个 验证字, 可以为一个 64比特的验证参数;
步骤 303、 设备 A接收到验证请求消息, 按照预设的处理策略向设备 B 发送验证应答消息, 例如: 重新发送删除 PDN 连接集合请求消息, 与步骤 301 中的消息不同之处是, 该验证应答消息中还携带有步骤 302中设备 B携 带给设备 A用于验证局部复位真实性的验证参数的信息。 如果步骤 301 中的 局部复位通知消息中没有携带设备 A故障的资源模块对应的 CSID, 则本步 骤中的验证应答消息中还应该携带有设备 A故障的资源模块对应的 CSID, 以供通知本端设备发生故障的资源模块;
本步骤中, 上述验证应答消息中所携带的验证参数的信息可以为验证请 求消息中所携带的原始验证参数, 也可以为上述原始验证参数经过设备 A与 设备 B协商后的某种变换算法变换后的变换验证参数, 对验证参数进行变换 的方法可以是利用设备 A与设备 B协商(自动协商或者人工协商)后的密钥 进行加密或者散列 (哈希)运算等。
可选地, 步骤 302中设备 B也可以不通过验证请求消息将验证参数下发 到设备 A, 而是通过与设备 A进行协商预先将验证参数设置在设备 A上, 同 样, 设备 A在返回验证应答消息时应同时将该设置的验证参数携带在验证应 答消息中;
步骤 304、 设备 B接收到验证应答消息, 根据该验证应答消息中所携带 的验证参数的信息确认所接收到的局部复位通知消息真实的来自设备 A, 则 可以确认对端真实发生了局部复位事件, 则删除与设备 A局部故障的资源模 块的 CSID对应的关联上下文。
本实施例中, 由于步骤 303中的验证应答消息中所携带的验证参数的信 息必须与步骤 302中验证请求消息中所携带的验证参数相匹配, 因此在应用 本实施例的会话上下文的处理方法后, 攻击者要成功实施攻击, 需要能够截 获到步骤 302中设备 B向设备 A发送的验证请求消息以获取其中所携带的验 证参数。 这对攻击者提出了更高的要求, 因为在其发起攻击的网络位置, 也
许攻击者可以假冒设备 A的 IP地址作为源地址向设备 B发送局部复位通知 消息并成功达到设备 B, 但并不能保证其一定能够截获目的地址为设备 A的 IP地址的消息; 同时由于步骤 302中的验证请求消息通常是夹杂在海量的数 据流中的, 因此即使步骤 302中的验证请求消息经过了攻击者发起攻击的位 置, 攻击者要在很短的时间内 (必须赶在真实的设备 A正常返回验证应答消 息之前)从海量数据中过滤出步骤 302中的该验证请求消息运算量也很大。 置被大大收窄了, 同时攻击难度也大大提高了。
与上一实施例相似, 步骤 301 中设备 B接收到的消息还可以为携带有设 备 B携带给设备 A用于验证局部复位真实性的验证参数的信息的 GTP中的 删除公共数据网连接集合请求消息, 一定程度上已经起到了步骤 302和步骤 303的验证作用, 可以不执行本实施例步骤 302和步骤 303的验证过程。 本 实施例是不信任对端设备主动发送的局部复位通知消息, 在接收到对端设备 主动发送的局部复位通知消息时, 触发与对端设备交互验证以确认局部复位 事件的真实性。
进一步地, 为了进一步增加攻击者攻击的难度, 本实施例中设备 A还可 以在步骤 301或者 303的消息中将设备 B最新的重启计数值或其他预先由设 备 B生成的标识信息携带上, 以验证之前发送局部复位通知消息的对端设备 确实曾经接收过本端设备的验证请求消息。 需要说明的是: 如果要求设备 A 在步骤 301将设备 B最新的重启计数值或其他预先由设备 B生成的标识信息 携带上, 则本实施例还可以跳过步骤 302和步骤 303的验证过程, 直接执行 步骤 304, 即这种情况下执行主动验证的步骤是可选的。
在本实施例中, 设备 B在接收到关于设备 A的局部复位通知消息之后, 在启动扫描清理垃圾上下文处理之前, 向设备 A发送验证请求消息以验证设 备 A局部资源模块发生故障的真实性, 在得到设备 A的确认之后, 再启动扫 描清理 CSID对应的垃圾上下文处理。
进一步地,步骤 302中设备 B向设备 A下发的验证参数可以设置一有效 时间范围, 具体实现方式与上一实施例相同, 本实施例不再赘述。
图 4所示, 本实施例的会话上下文的处理装置可以包括接收模块 41、 确认模 块 42和处理模块 43。接收模块 41接收到携带有设备标识信息的复位通知消 息, 确认模块 42确认设备标识信息标识的对端设备发生接收模块 41所接收 到的复位通知消息对应的复位事件,处理模块 43删除与对端设备的复位事件 相关的关联上下文。
其中, 接收模块 41所接收到的复位通知消息可以为全局复位通知消息, 还可以为局部复位通知消息。 确认模块 42与对端设备确认接收模块 41所接 收到的复位通知消息的真实性可以通过获取对端设备所分配的验证参数来实 现, 该验证参数可以是本端设备通过验证消息下发到对端设备, 还可以通过 预先设置在对端设备上。
本实施例中的接收模块接收到对端设备的复位通知消息, 处理模块在删 除本端设备上与对端设备的复位事件相关的关联上下文之前, 确认模块需要 与对端设备确认上述复位通知消息的真实性, 避免了由于受到仿冒源地址攻 击而错误删除设备上的关联上下文, 确保了接收到复位通知消息之后对关联 上下文处理的正确性, 保证了本端设备进行正常的通信。 本实施例能够使得 通过仿冒源地址攻击的方法应用复位通知消息对设备进行攻击的实施难度增 加, 减少了通过仿冒源地址实施复位通知攻击的风险, 从而提高了***的安 全性。
上述实施例二、 三中设备 B的功能均可以由本发明实施例提供的会话上 下文的处理装置实现。 图 5所示, 进一步地, 本实施例的会话上下文的处理装置中的确认模块具体 可以通过与所述对端设备进行交互验证, 确认所述复位通知消息来自所述对 端设备。相应地, 本实施例中的确认模块 42具体可以进一步包括第一请求验 证单元 421、 第一响应验证单元 422和第一确认单元 423。 第一请求验证单 元 421向对端设备发送携带有验证参数的验证请求消息, 第一响应验证单元 422接收对端设备根据该验证请求消息返回的验证应答消息, 该验证应答消 息中携带有上述验证参数的信息, 第一确认单元 423根据上述验证参数的信 息确认对端设备发生上述复位事件。
在本实施例中, 接收模块在接收到关于对端设备的复位通知消息之后, 处理模块在启动扫描清理垃圾上下文处理之前, 确认模块的第一请求验证单 元向对端设备发送携带有验证参数的验证请求消息以验证对端设备发生复位 (重启) 事件的真实性, 在第一响应验证单元接收到对端设备返回的携带有 上述验证参数的信息的验证响应消息之后, 第一确认单元则可以确认接收模 块所接收到的复位通知消息来自所述对端设备, 以触发处理模块再启动扫描 清理垃圾上下文处理。
图 6为本发明实施例六提供的会话上下文的处理装置的结构示意图, 如 图 6所示, 与上一实施例相比, 本实施例中的对端设备所获取的验证参数还 可以为本端设备与对端设备进行协商预先设置在对端设备上的, 相应地, 本 实施例中的确认模块 42具体可以进一步包括第二请求验证单元 424、第二响 应验证单元 425和第二确认单元 426。 第二请求验证单元 424向对端设备发 送验证请求消息, 第二响应验证单元 425接收对端设备根据该验证请求消息 返回的验证应答消息, 该验证应答消息中携带有预先设置在对端设备而上的 验证参数的信息, 第二确认单元 426根据上述验证参数的信息确认对端设备 发生上述复位事件。
在本实施例中, 接收模块在接收到关于对端设备的复位通知消息之后, 处理模块在启动扫描清理垃圾上下文处理之前, 确认模块的第二请求验证单 元向对端设备发送验证请求消息以验证对端设备发生复位(重启)事件的真 实性, 在第二响应验证单元接收到对端设备返回的携带有预先设置在对端设 备上的验证参数的信息的验证响应消息之后, 第二确认单元则可以确认接收 模块所接收到的复位通知消息来自所述对端设备, 以触发处理模块再启动扫 描清理垃圾上下文处理。
进一步地, 本实施例中的接收模块接收到的复位通知消息中还可以携带 有验证参数的信息, 确认模块具体可以根据该验证参数的信息确认所述对端 设备发生所述复位事件。
图 7为本发明实施例七提供的会话上下文的处理***的结构示意图, 如 图 7所示,本实施例的会话上下文的处理***可以包括对端设备 71和本端设 备 72; 其中,
对端设备 71用于发生复位事件后, 向本端设备 72发送携带有设备标识 信息的复位通知消息;
本端设备 72用于接收携带有设备标识信息的复位通知消息,确认该设备 标识信息标识的对端设备 71发生复位通知消息对应的复位事件,并删除与该 复位事件相关的关联上下文。
上述实施例一中的方法、 以及实施例二、 三中设备 B的功能均可以由本 发明实施例提供的会话上下文的处理***中的本端设备 72实现。
本实施例中的本端设备接收到对端设备的复位通知消息, 在删除本端设 备上与对端设备的复位事件相关的关联上下文之前, 需要与对端设备确认上 述复位通知消息的真实性, 避免了由于受到仿冒源地址攻击而错误删除设备 上的关联上下文, 确保了接收到复位通知消息之后对关联上下文处理的正确 性, 保证了本端设备进行正常的通信。 本实施例能够使得通过仿冒源地址攻 击的方法应用复位通知消息对设备进行攻击的实施难度增加, 减少了通过仿 冒源地址实施复位通知攻击的风险, 从而提高了***的安全性。
上述本发明实施例不限制所应用的网络***, 本发明实施例仅是以 GTP 为例进行说明的。 发明的思想同样可以应用在其他协议消息中, 例如在代理 移动 IPv6 ( Proxy Mobile IPv6, 简称 PMIPv6 ) 中, 整体复位通知消息可以 是携带有重启计数值的心跳消息 (Heartbeat ), 接收设备同样可以通过发送 心跳请求消息并接收对端设备的心跳响应消息来验证对端设备的整体复位事 件的真实性; 同样在 PMIPv6中, 局部复位通知消息可以是携带了 CSID选 项的绑定撤销指示 ( Binding Revocation Indication ) 消息, 而接收设备可以 通过返回带特殊原因值 (例如: "需要验证") 和验证参数的绑定撤销确认 ( Binding Revocation Acknowledgement ) 消息并要求对端重发携带验证参 数的绑定 4敎销指示消息来验证对端设备的局部复位事件的真实性。
可以理解的是, 本发明实施例中所例举的消息名称只是为了更好的说明 本发明实施例的技术方案, 在具体实现中还可以通过新增任意消息的方式来 实现, 也可以通过在已有的消息中增加信元的方式来实现。
本领域普通技术人员可以理解: 实现上述方法实施例的全部或部分步骤 可以通过程序指令相关的硬件来完成, 前述的程序可以存储于一计算机可读
取存储介质中, 该程序在执行时, 执行包括上述方法实施例的步骤; 而前述 的存储介质包括: ROM、 RAM , 磁碟或者光盘等各种可以存储程序代码的介 质。
最后应说明的是: 以上实施例仅用以说明本发明的技术方案, 而非对其 限制; 尽管参照前述实施例对本发明进行了详细的说明, 本领域的普通技术 人员应当理解: 其依然可以对前述各实施例所记载的技术方案进行修改, 或 者对其中部分技术特征进行等同替换; 而这些修改或者替换, 并不使相应技 术方案的本质脱离本发明各实施例技术方案的精神和范围。
Claims
1、 一种会话上下文的处理方法, 其特征在于, 包括:
接收携带有设备标识信息的复位通知消息;
确认所述设备标识信息标识的对端设备发生所述复位通知消息对应的复 位事件;
删除与所述复位事件相关的关联上下文。
2、 根据权利要求 1所述的方法, 其特征在于, 所述复位通知消息包括整 体复位通知消息或者局部复位通知消息。
3、 根据权利要求 2所述的方法, 其特征在于, 所述确认所述设备标识信 息标识的对端设备发生所述复位通知消息对应的复位事件包括: 与所述对端 设备进行交互验证, 确认所述对端设备发生所述复位事件。
4、 根据权利要求 3所述的方法, 其特征在于, 所述与所述对端设备进行 交互验证, 确认所述对端设备发生所述复位事件包括:
向所述对端设备发送携带有验证参数的验证请求消息;
接收所述对端设备根据所述验证请求消息返回的验证应答消息, 所述验 证应答消息中携带有所述验证参数的信息;
根据所述验证参数的信息确认所述对端设备发生所述复位事件。
5、 根据权利要求 3所述的方法, 其特征在于, 所述与所述对端设备进行 交互验证, 确认所述对端设备发生所述复位事件包括:
向所述对端设备发送验证请求消息;
接收所述对端设备根据所述验证请求消息返回的验证应答消息, 所述验 证应答消息中携带有验证参数的信息;
根据所述验证参数的信息确认所述对端设备发生所述复位事件。
6、根据权利要求 4或 5所述的方法, 其特征在于, 所述验证参数的信息 包括验证参数和 /或所述验证参数变换后的变换验证参数。
7、 根据权利要求 6所述的方法, 其特征在于, 所述验证参数包括本端设 备的当前重启计数值或所述本端设备预先生成的标识信息。
8、根据权利要求 4或 5所述的方法, 其特征在于, 所述根据所述验证参 数的信息确认所述对端设备发生所述复位事件包括: 如果有效时间范围内接
收到所述验证应答消息, 则根据所述验证参数的信息确认所述对端设备发生 所述复位事件。
9、 根据权利要求 8所述的方法, 其特征在于, 所述验证参数包括接收到 所述复位通知消息的时间信息和 /或期望接收到所述验证应答消息的时间信 息。
10、 根据权利要求 4或 5所述的方法, 其特征在于, 所述验证应答消息 中还携带有复位标识, 以供确认所述对端设备发生所述复位事件。
11、 根据权利要求 2所述的方法, 其特征在于, 所述复位通知消息中还 携带有验证参数的信息, 所述确认所述设备标识信息标识的对端设备发生所 述复位通知消息对应的复位事件包括: 根据所述验证参数的信息确认所述对 端设备发生所述复位事件。
12、根据权利要求 3或 11所述的方法, 其特征在于, 所述复位通知消息 中还携带有复位标识, 以供通知所述对端设备发生所述复位事件。
13、 根据权利要求 4、 5或 11所述的方法, 其特征在于, 所述局部复位 通知消息中还携带有资源模块标识, 所述删除与所述复位事件相关的关联上 下文包括: 删除与所述资源模块标识对应的关联上下文。
14、 一种会话上下文的处理装置, 其特征在于, 包括:
接收模块, 用于接收携带有设备标识信息的复位通知消息;
确认模块, 用于确认所述设备标识信息标识的对端设备发生所述复位通 知消息对应的复位事件;
处理模块, 用于删除与所述复位事件相关的关联上下文。
15、 根据权利要求 14所述的装置, 其特征在于, 所述确认模块包括: 第一请求验证单元, 用于向所述对端设备发送携带有验证参数的验证请 求消息;
第一响应验证单元, 用于接收所述对端设备根据所述验证请求消息返回 的验证应答消息, 所述验证应答消息中携带有所述验证参数的信息;
第一确认单元, 用于根据所述验证参数的信息确认所述对端设备发生所 述复位事件。
16、 根据权利要求 14所述的装置, 其特征在于, 所述确认模块包括:
第二请求验证单元, 用于向所述对端设备发送验证请求消息;
第二响应验证单元, 用于接收所述对端设备根据所述验证请求消息返回 的验证应答消息, 所述验证应答消息中携带有验证参数的信息;
第二确认单元, 用于根据所述验证参数的信息确认所述对端设备发生所 述复位事件。
17、 根据权利要求 14 所述的装置, 其特征在于, 所述接收模块接收到 的所述复位通知消息中携带有验证参数的信息, 所述确认模块具体根据所述 验证参数的信息确认所述对端设备发生所述复位事件。
18、 一种会话上下文的处理***, 其特征在于, 包括对端设备和本端设 备;
所述对端设备用于发生复位事件后, 向所述本端设备发送携带有设备标 识信息的复位通知消息;
所述本端设备用于接收携带有设备标识信息的复位通知消息, 确认所述 设备标识信息标识的对端设备发生所述复位通知消息对应的复位事件, 并删 除与所述复位事件相关的关联上下文。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US13/173,212 US20110258682A1 (en) | 2008-12-31 | 2011-06-30 | Method, apparatus, and system for processing session context |
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN200810247430.8 | 2008-12-31 | ||
CN200810247430.8A CN101771564B (zh) | 2008-12-31 | 2008-12-31 | 会话上下文的处理方法、装置和*** |
Related Child Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US13/173,212 Continuation US20110258682A1 (en) | 2008-12-31 | 2011-06-30 | Method, apparatus, and system for processing session context |
Publications (1)
Publication Number | Publication Date |
---|---|
WO2010075685A1 true WO2010075685A1 (zh) | 2010-07-08 |
Family
ID=42309779
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
PCT/CN2009/073064 WO2010075685A1 (zh) | 2008-12-31 | 2009-08-04 | 会话上下文的处理方法、装置和*** |
Country Status (3)
Country | Link |
---|---|
US (1) | US20110258682A1 (zh) |
CN (1) | CN101771564B (zh) |
WO (1) | WO2010075685A1 (zh) |
Families Citing this family (12)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN102065487B (zh) * | 2010-12-06 | 2014-04-02 | 大唐移动通信设备有限公司 | 复位用户的方法及设备 |
JP5845973B2 (ja) * | 2012-03-01 | 2016-01-20 | 富士通株式会社 | サービス利用管理方法、プログラム、および情報処理装置 |
JP6016456B2 (ja) * | 2012-05-30 | 2016-10-26 | クラリオン株式会社 | 認証装置、認証プログラム |
US9426132B1 (en) | 2012-09-12 | 2016-08-23 | Emc Corporation | Methods and apparatus for rules-based multi-factor verification |
US9280645B1 (en) * | 2012-11-15 | 2016-03-08 | Emc Corporation | Local and remote verification |
DE112014002747T5 (de) * | 2013-06-09 | 2016-03-03 | Apple Inc. | Vorrichtung, Verfahren und grafische Benutzerschnittstelle zum Ermöglichen einer Konversationspersistenz über zwei oder mehr Instanzen eines digitalen Assistenten |
US9535794B2 (en) * | 2013-07-26 | 2017-01-03 | Globalfoundries Inc. | Monitoring hierarchical container-based software systems |
CN103973786B (zh) | 2014-05-07 | 2017-05-24 | 惠州Tcl移动通信有限公司 | 电子设备的通知消息的同步方法及电子设备 |
CN103957150B (zh) * | 2014-05-07 | 2017-05-17 | 惠州Tcl移动通信有限公司 | 电子设备的通知消息的同步方法及服务器、电子设备 |
WO2020171765A1 (en) * | 2019-02-22 | 2020-08-27 | Telefonaktiebolaget Lm Ericsson (Publ) | Mitigating dos attacks |
US11070699B1 (en) * | 2020-03-05 | 2021-07-20 | Steven Michael Becherer | Systems and methods for facilitating determining contextual and semantic meaning from an image scan |
CN111554399B (zh) * | 2020-05-25 | 2023-07-25 | 出门问问信息科技有限公司 | 一种重置方法和装置、电子设备和计算机存储介质 |
Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN1437111A (zh) * | 2002-02-05 | 2003-08-20 | 三星电子株式会社 | 嵌入式设备和初始化该设备的方法 |
CN1711787A (zh) * | 2002-11-05 | 2005-12-21 | 艾利森电话股份有限公司 | 向无线接入网中的连接子集集体通知节点复位 |
Family Cites Families (9)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6983364B2 (en) * | 2001-06-29 | 2006-01-03 | Hewlett-Packard Development Company, Lp. | System and method for restoring a secured terminal to default status |
US7149892B2 (en) * | 2001-07-06 | 2006-12-12 | Juniper Networks, Inc. | Secure sockets layer proxy architecture |
US7472416B2 (en) * | 2004-01-09 | 2008-12-30 | Cisco Technology, Inc. | Preventing network reset denial of service attacks using embedded authentication information |
US7565694B2 (en) * | 2004-10-05 | 2009-07-21 | Cisco Technology, Inc. | Method and apparatus for preventing network reset attacks |
US7523196B2 (en) * | 2004-12-28 | 2009-04-21 | Sap Ag | Session monitoring using shared memory |
US7640338B2 (en) * | 2005-01-18 | 2009-12-29 | Microsoft Corporation | System and method for mitigation of malicious network node activity |
US8151323B2 (en) * | 2006-04-12 | 2012-04-03 | Citrix Systems, Inc. | Systems and methods for providing levels of access and action control via an SSL VPN appliance |
US8046596B2 (en) * | 2007-06-21 | 2011-10-25 | Emc Corporation | Reset-tolerant authentication device |
CN102027480B (zh) * | 2008-05-16 | 2014-12-17 | 惠普开发有限公司 | 用于提供***管理命令的***和方法 |
-
2008
- 2008-12-31 CN CN200810247430.8A patent/CN101771564B/zh not_active Expired - Fee Related
-
2009
- 2009-08-04 WO PCT/CN2009/073064 patent/WO2010075685A1/zh active Application Filing
-
2011
- 2011-06-30 US US13/173,212 patent/US20110258682A1/en not_active Abandoned
Patent Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN1437111A (zh) * | 2002-02-05 | 2003-08-20 | 三星电子株式会社 | 嵌入式设备和初始化该设备的方法 |
CN1711787A (zh) * | 2002-11-05 | 2005-12-21 | 艾利森电话股份有限公司 | 向无线接入网中的连接子集集体通知节点复位 |
Also Published As
Publication number | Publication date |
---|---|
CN101771564A (zh) | 2010-07-07 |
US20110258682A1 (en) | 2011-10-20 |
CN101771564B (zh) | 2013-10-09 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
WO2010075685A1 (zh) | 会话上下文的处理方法、装置和*** | |
Durham et al. | The COPS (common open policy service) protocol | |
KR101981229B1 (ko) | 머신-대-머신 노드 소거 절차 | |
US8285990B2 (en) | Method and system for authentication confirmation using extensible authentication protocol | |
US7421578B1 (en) | Method and apparatus for electing a leader node in a computer network | |
EP2290895B1 (en) | Method, system and device for negotiating security association (sa) in ipv6 network | |
RU2554532C2 (ru) | Способ и устройство для безопасной передачи данных | |
CN102571497B (zh) | 一种IPSec隧道故障检测的方法、装置及*** | |
KR20060030995A (ko) | 차세대 인터넷에서 자동으로 주소를 생성하고 수락하는방법 및 이를 위한 데이터 구조 | |
WO2009082889A1 (fr) | Procédé de négociation pour échange de clés internet et dispositif et système associés | |
WO2011041962A1 (zh) | 一种支持合法监听的端到端会话密钥协商方法和*** | |
WO2010000171A1 (zh) | 一种通信的建立方法、***和装置 | |
JP2012533911A (ja) | 通信ネットワークセキュリティを提供する方法 | |
Lopez et al. | Pceps: Usage of tls to provide a secure transport for the path computation element communication protocol (pcep) | |
Sakane et al. | Kerberized internet negotiation of keys (KINK) | |
EP2326137A1 (en) | Method and system for implementing group message service based on converged service system | |
EP3381208B1 (en) | Charging record authentication for anonymized network service utilization | |
Tschofenig et al. | RSVP security properties | |
JPH11161618A (ja) | 移動計算機管理装置、移動計算機装置及び移動計算機登録方法 | |
CN1881870A (zh) | 一种设备间安全通信的方法 | |
CN102469063A (zh) | 路由协议安全联盟管理方法、装置及*** | |
CN114765805A (zh) | 一种通信方法、网络设备、基站及计算机可读存储介质 | |
Mitchell et al. | Analysis of EAP-GPSK authentication protocol | |
CN108322477A (zh) | 一种开放平台的文件传输方法 | |
TWI448128B (zh) | 用於雙堆疊操作互通授權的方法及裝置 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
121 | Ep: the epo has been informed by wipo that ep was designated in this application |
Ref document number: 09835972 Country of ref document: EP Kind code of ref document: A1 |
|
NENP | Non-entry into the national phase |
Ref country code: DE |
|
122 | Ep: pct application non-entry in european phase |
Ref document number: 09835972 Country of ref document: EP Kind code of ref document: A1 |