Security level and status exchange between TCP/UDP client(s) and server(s) for secure transactions

• US 9,661,005 B2
• Filed: 01/09/2014
• Issued: 05/23/2017
• Est. Priority Date: 01/09/2014
• Status: Active Grant

• Current Assignee: Kyndryl Incorporated
• Original Assignee: International Business Machines Corporation
• Inventors: Pandya, Vaishali V., Kamble, Keshav G., Pandey, Vijoy A.
• Primary Examiner(s): Powers, William
• Assistant Examiner(s): WYSZYNSKI, AUBREY H
• Application Number:
  US14/151,537
• Publication Number:
  US 20150195293A1
• Time in Patent Office: 1,230 Days
• Field of Search: 726 22
• CPC Class Codes: H04L 63/1408 by monitoring network traffic monitoring network traffic per se H04L43/00
• CPC Class Codes: H04L 69/16 Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]

Abstract

According to one embodiment, a system includes a processor and logic integrated with and/or executable by the processor, the logic being configured to identify a security issue affecting a first peer in one or more secure transmission control protocol/user datagram protocol (TCR/UDP) sessions, inform a second peer about the security issue using the first peer of the one or more TCP/UDP sessions, and perform at least one action in response to identifying and/or being informed about the security issue. In another embodiment, a method for providing a secure TCP/UDP session includes identifying a security issue affecting a first peer in one or more TCP/UDP sessions, informing a second peer about the security issue using the first peer of the one or more TCP/UDP sessions, and performing at least one action in response to identifying and/or being informed about the security issue.

Claims

1. A system, comprising a processor and logic integrated with and/or executable by the processor, the logic being configured to:

identify a security issue affecting a first peer in one or more secure transmission control protocol/user datagram protocol (TCP/UDP) sessions;

inform a second peer about the security issue using the first peer of the one or more TCP/UDP sessions by causing the first peer to send a packet from the first peer to the second peer, the first peer being aware of the security issue prior to informing the second peer about the security issue, and the packet comprising an indication of the security issue in a TCP header of the packet;

receive a second packet at the first peer indicating that the security issue has been acknowledged by the second peer, the second packet comprising a second TCP header having a security acknowledgement flag set therein to indicate that the security issue has been acknowledged by the second peer, wherein the security acknowledgement flag is stored within a reserve field of the second TCP header; and

perform at least one action to resolve and/or avoid the security issue in response to identifying and/or being informed about the security issue at the first peer, the at least one action comprising informing, via a socket call or an extension of a socket call, one or more applications operating on the second peer via the one or more TCP/UDP sessions to limit information exchange based on a severity of the security issue.

2. The system as recited in claim 1, wherein the logic is further configured to establish the one or more TCP/UDP sessions between a server and a client which are peers on the one or more TCP/UDP sessions, and wherein the second peer is informed about the security issue on a per-session basis.

3. The system as recited in claim 1, wherein the second packet identifies one or more actions that have been taken in response to the security issue being relayed to the first.

4. The system as recited in claim 1, wherein the packet is sent from the first peer to the second peer within the one or more TCP/UDP sessions, and wherein the TCP header comprises:

a source port;

a destination port; and

a security flag set to indicate the security issue at the first peer.

5. The system as recited in claim 4, wherein the security flag is stored within a reserve field of the TCP header.

6. The system as recited in claim 5, wherein the TCP header further comprises one or more type-length-value (TLV) elements indicating the severity of the security issue.

7. The system as recited in claim 6, wherein the one or more TLV elements are stored within an options field of the TCP header.

8. The system as recited in claim 1, wherein the at least one action is also performed at the second peer to resolve and/or avoid the security issue.

9. The system as recited in claim 1, wherein the logic is further configured to perform a handshake operation between the first peer and the second peer in the one or more TCP/UDP sessions to establish what level each TLV value represents for the security issue prior to informing the second peer about the security issue.

10. The system as recited in claim 9, wherein the security acknowledgement flag is stored within a reserve field of the second TCP header.

11. The system as recited in claim 1, wherein the first peer further performs one or more actions selected from a group consisting of:

resetting and closing any TCP/UDP sockets affected by the security issue, re-authenticating and resetting the one or more TCP/UDP sessions affected by the security issue, waiting for a predetermined amount of time for the security issue to be resolved, adjusting a type of information exchanged across the one or more TCP/UDP sessions.

12. A method for providing a secure transmission control protocol/user datagram protocol (TCP/UDP) session, the method comprising:

identifying a security issue affecting a first peer in one or more TCP/UDP sessions;

informing a second peer about the security issue using the first peer of the one or more TCP/UDP sessions by causing the first peer to send a packet from the first peer to the second peer, the first peer being aware of the security issue prior to informing the second peer about the security issue, wherein the packet comprises one or more type-length-value (TLV) elements indicating a severity of the security issue, the one or more TLV elements being stored in a TCP header of the packet; and

performing at least one action in response to identifying and/or being informed about the security issue.

13. The method as recited in claim 12, further comprising establishing the one or more TCP/UDP sessions between a server and a client which are peers on the one or more TCP/UDP sessions, wherein the second peer is informed about the security issue on a per-session basis.

14. The method as recited in claim 12, further comprising informing the first peer that the security issue has been acknowledged by the second peer, wherein the at least one action is performed at the second peer to resolve and/or avoid the security issue.

15. The method as recited in claim 14, wherein the informing the first peer that the security issue has been acknowledged by the second peer comprises sending a second packet from the second peer to the first peer, the second packet comprising a second TCP header having a security acknowledgement flag set therein to indicate that the security issue has been acknowledged by the second peer, and wherein the security acknowledgement flag is stored within a reserve field of the second TCP header.

16. The method as recited in claim 15, wherein the second packet identifies one or more actions that have been taken in response to the security issue being relayed to the first peer.

17. The method as recited in claim 16, wherein the packet is sent from the first peer to the second peer within the one or more TCP/UDP sessions, and wherein the TCP header comprises:

a source port;

a destination port; and

a security flag set to indicate the security issue at the first peer.

18. The method as recited in claim 17, wherein the security flag is stored within a reserve field of the TCP header, wherein the one or more TLV elements are stored within an options field of the TCP header, and wherein the second peer is configured to inform, via a socket call or an extension of a socket call, one or more applications operating via the one or more TCP/UDP sessions to limit information exchange based on the severity of the security issue.

19. The method as recited in claim 12, wherein the at least one action is selected from a group consisting of:

resetting and closing any TCP/UDP sockets affected by the security issue, re-authenticating and resetting the one or more TCP/UDP sessions affected by the security issue, waiting for a predetermined amount of time for the security issue to be resolved, adjusting a type of information exchanged across the one or more TCP/UDP sessions, and performing no extraordinary action.

20. A computer program product for providing a secure transmission control protocol/user datagram protocol (TCP/UDP) session, the computer program product comprising a non-transitory computer readable storage medium having program code embodied therewith, the program code readable/executable by a processor to:

identify, using the processor, a security issue affecting a first peer in one or more TCP/UDP sessions;

inform, using the processor, a second peer about the security issue by causing the first peer to send a packet from the first peer to the second peer, the first peer being aware of the security issue prior to informing the second peer about the security issue, and the packet comprising an indication of the security issue in a TCP header of the packet;

receive, using the processor, a packet at the first peer indicating that the security issue has been acknowledged by the second peer, the packet comprising a TCP header having a security acknowledgement flag set therein to indicate that the security issue has been acknowledged by the second peer, wherein the security acknowledgement flag is stored within a reserve field of the TCP header; and

perform, using the processor, at least one action to resolve and/or avoid the security issue in response to identifying and/or being informed about the security issue at the first peer and/or the second peer, the at least one action comprising informing, via a socket call or an extension of a socket call, one or more applications operating on the second peer via the one or more TCP/UDP sessions to limit information exchange based on a severity of the security issue.