Endpoint state management using initial packet sequence number

Abstract

The invention relates to endpoint state management using a starting packet sequence number. A destination node receives a connection request packet indicating a start packet sequence number (PSN) associated with a source node. In response to the originating PSN being valid, the destination node accepts a first connection corresponding to the connection request packet. In response to the source node closing the first connection, the destination node: sets an expected incoming PSN associated with the destination node to the larger of a current value of the expected incoming PSN and a starting PSN incremental one associated with the source node; sending a shutdown response message comprising the expected incoming PSN to the source node; and allowing the source node to set the starting PSN to the larger of a current value of the starting PSN incrementing by one and an expected incoming PSN associated with the destination node.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims the benefit of U.S. Provisional Application No. 63 / 553,240 (Attorney Docket No. P174253USPRV), filed on February 14, 2024, by inventors Keith D. Underwood and Robert L. Alverson, entitled “Managing Starting PSN to Achieve Anti-Replay Protection.” BRIEF DESCRIPTION OF THE DRAWINGS

[0003] Figure 1 An environment is illustrated that uses a starting packet sequence number (PSN) to facilitate endpoint state management according to an aspect of the present application.

[0004] Figure 2A A diagram illustrating communications and tables for facilitating endpoint state management using PSN according to an aspect of the present application.

[0005] Figure 2B A diagram illustrating communications and tables that facilitate endpoint state management using an originating PSN according to an aspect of the present application.

[0006] Figure 2C A diagram illustrating communications and tables that facilitate endpoint state management using an originating PSN according to an aspect of the present application.

[0007] Figure 3 A flow chart illustrating a method of facilitating endpoint state management using an originating PSN is presented in accordance with an aspect of the present application.

[0008] Figure 4A A flow chart illustrating a method of using an originating PSN to facilitate endpoint state management, including opening a connection and checking for a valid originating PSN, is presented in accordance with an aspect of the present application.

[0009] Figure 4B A flow chart illustrating a method of using an originating PSN to facilitate endpoint state management, including closing a connection, is presented in accordance with an aspect of the present application.

[0010] Figure 5 A computer system is illustrated that facilitates endpoint state management using an originating PSN according to an aspect of the present application.

[0011] Figure 6 Illustrated is a computer-readable medium for facilitating endpoint state management using an originating PSN according to an aspect of the present application.

[0012] Throughout the drawings, like reference numerals refer to like drawing elements. DETAILED DESCRIPTION

[0013] Various aspects of the present application can protect nodes in a distributed system from replay attacks by managing "packet sequence numbers" (PSNs) and reducing the cost associated with tracking the next starting PSN for each peer node. In the described aspects, each node can maintain two fields for a commonly installed key: a "starting PSN" (or "startPSN"), which will be used when the node opens a connection; and an "expected incoming PSN" (or "eiPSN"), which will be used when the node determines whether to accept a connection request.

[0014] Anti-replay protection refers to preventing network attacks in which valid data transmissions between a source and a destination (i.e., a pair of endpoints) are maliciously or fraudulently repeated or delayed, for example, to prevent an attacker from capturing data that was previously known to be valid and reusing the captured data. Packet sequence numbers (PSNs) can be used to prevent replay attacks on established connections (e.g., in the path between a pair of endpoints or nodes). PSNs can be encrypted, which can make it difficult for an attacker to know when a packet is being replayed. If the path is idle for a long time, an attacker can infer that the connection may be broken and capture the starting packet of the next message. To prevent this, the starting PSN used for a connection should not be reused for keys between a given pair of endpoints. While the same PSN can be used as a non-starting PSN during one connection and as the starting PSN during another connection, in a distributed system with a large number of nodes, tracking the next starting PSN for each peer node can incur significant costs.

[0015] Aspects described herein can address the cost of tracking the starting PSN of each peer node by providing endpoint state management based on a forced monotonically increasing starting PSN, which can be maintained and updated by each node or endpoint when opening and closing connections between nodes. This can protect nodes or endpoints from replay attacks.

[0016] During the startup or installation process of a key to be used for secure communication, participating nodes in a distributed system can each set two fields for the key. The first field can be the "starting PSN" ("startPSN") used with the key, and the second field can be the "expected incoming starting PSN" ("eiPSN") for the key. The initial value can be set to any value, such as 0, which is the same for all users of the key. Each node can track the values of these two fields (startPSN and eiPSN) and increment or change these values based on the opening and closing of connections.

[0017] For example, given a pair of endpoints (e.g., source node A and destination node B), node A can open a connection with node B based on a key and A's starting PSN. If A's starting PSN is valid (i.e., if A's starting PSN is greater than or equal to B's expected incoming starting PSN), node B can accept the connection using A's starting PSN. Subsequently, node A can close the connection with node B. Node B can set B's expected incoming starting PSN to the greater of B's current expected incoming starting PSN and A's starting PSN incremented by one. Node B can also send a close response to node A that includes B's expected incoming starting PSN, which can cause node A to then set A's starting PSN to the greater of A's own current starting PSN incremented by one and B's expected incoming starting PSN. By only incrementing the expected starting PSN by one when a connection is closed, the system can minimize the rate at which the expected incoming PSN increases. The higher the rate at which the expected incoming PSNs increase, the greater the likelihood of a "round-trip failure," where a source node attempts to open a connection using a starting PSN that is less than the expected incoming PSN maintained by the destination node, and the destination node must send a rejection message with a correct or valid PSN to use. Round-trip failures can cause unnecessary traffic in the system, as discussed below with respect to Figures 2A to 2C described.

[0018] Thus, in the various aspects described, each node can manage its own expected incoming PSN to be greater than the maximum starting PSN used to start a connection with a node that has been closed. Each node can also maintain its own starting PSN to be greater than or higher than the value that other nodes may expect, i.e., by dynamically increasing the node's own starting PSN based on feedback from its peer nodes so that the node's own starting PSN is always greater than the value that the peer nodes have informed the node to use.

[0019] The terms "starting PSN," "starting PSN," and "startPSN" are used interchangeably in this disclosure and refer to the value of the packet sequence number to be used when a node begins a connection. The startPSN may increase monotonically based on receipt of a "close response" message (e.g., in response to a request sent by a node to close a connection). The notation "X.startPSN" refers to the startPSN associated with and tracked by node X.

[0020] The terms "expected incoming PSN" and "eiPSN" are used interchangeably in this disclosure and refer to the packet sequence number that a node expects to receive when a connection request is sent to the node. The eiPSN may be incremented when a request is received to close a connection with another node and may be based on the startPSN used to open the connection. The notation "X.eiPSN" refers to the eiPSN associated with and tracked by node X.

[0021] The terms "node" and "endpoint" are used interchangeably in this disclosure and refer to a device, component, or hardware component that can operate as a source or destination for data, including, for example, control packets, connection request packets (including opening or closing a connection), and data packets.

[0022] The term "distributed system" may refer to a system in which each of a plurality of nodes may communicate with one or more other nodes, including communications that open or close connections and transfer data between a pair of nodes or endpoints.

[0023] Figure 1Figure 100 illustrates an exemplary network architecture according to an aspect of the present application. Figure 100 may include a network 110 of switches (which may be referred to as a "switch fabric") and may include switches 112, 114, 116, 118, and 120. Each switch may have a unique address or identifier within the switch fabric 110. Various types of devices and networks may be coupled to the switch fabric. For example, a storage array 130 may be coupled to the switch fabric 110 via switch 112; a high performance computing (HPC) network (e.g., InfiniBand, Slingshot, or any other high performance network) 132 may be coupled to the switch fabric 110 via switch 114; multiple end hosts (such as host 136 and host 138) may be coupled to the switch fabric 110 via switch 118; and an Internet Protocol (IP) / Ethernet network 134 may be coupled to the switch fabric 110 via switch 120. An HPC network may include multiple networked computers and storage devices running programs simultaneously to complete different complex and performance-intensive tasks. An IP / Ethernet network can include application layer protocols between physical Ethernet cabling and IP-based network devices, including communication via Transport Protocol (TCP) / IP and User Datagram Protocol (UDP) packets. Typically, a switch can have edge ports and fabric ports. An edge port can be coupled to a device outside the fabric. A fabric port can be coupled to another switch within the fabric via a fabric link. Typically, traffic can be injected into the switch fabric 110 via an ingress port of an edge switch and can leave the switch fabric 110 via an egress port of another (or the same) edge switch. An ingress link can couple a NIC of an edge device (e.g., an HPC end host) to an ingress edge port of an edge switch. The switch fabric 100 can then send the traffic to an egress edge switch, which in turn can pass the traffic to a destination edge device via another NIC.

[0024] Figure 2AFigure 200 illustrates communications and tables using PSN to facilitate endpoint state management in accordance with one aspect of the present application. Figure 200 depicts communications between multiple nodes (including nodes A through F and other nodes G) that may participate in a distributed system. During the key startup or installation process, each participating node may set two fields for the key: a "starting PSN" ("startPSN"); and an "expected incoming starting PSN" ("eiPSN"). The initial values must be the same for all participating nodes (e.g., users that have installed the same key) and may be set to any value, such as 0. Each node may track the values of these two fields (startPSN and eiPSN) and increment or change these values based on the opening and closing of connections. For example, node A may maintain two fields 281.1, wherein "A.startPSN" and "A.eiPSN" are initialized to a value of "0"; node B may maintain two fields 282.1, wherein "B.startPSN" and "B.eiPSN" are initialized to a value of "0"; node C may maintain two fields 283.1, wherein "C.startPSN" and "C.eiPSN" are initialized to a value of "0"; node F may maintain two fields 284.1, wherein "F.startPSN" and "F.eiPSN" are initialized to a value of "0"; and other nodes G may also each maintain two fields initialized to a value of "0" (not shown). Updates to these two fields may be indicated by the dashed arrows between the values of each maintained field.

[0025] During operation, node A may open a connection with node B by sending a connection request packet indicating node A's startPSN ("0") (201). Node B may determine whether the startPSN is valid by checking whether node A's startPSN is greater than or equal to node B's eiPSN (202). If the check result is yes, this indicates that node A's startPSN is valid (203). If the check result is no, this indicates that node A's starting PSN is invalid (204), resulting in a "round trip failure." Figure 2B The round trip failure is described by the communication 240 to 243. In this case, the check 202 indicates that 0 is greater than or equal to 0, which causes Node B to accept the connection (203) with the startPSN ("0") of Node A. The connection from Node A to Node B can remain open for a period of time (205).

[0026] Node A may then open a connection with node C by sending a connection request packet indicating node A's startPSN ("0") (206). Node C may determine whether the startPSN is valid by checking whether node A's startPSN is greater than or equal to node B's eiPSN (207). If the check is yes, this indicates that node A's startPSN is valid (208). If the check is no, this indicates that node A's starting PSN is invalid (209) (i.e., a round trip failure). In this case, check 207 indicates that 0 is greater than or equal to 0, which causes node C to accept the connection with A's startPSN ("0") (208). The connection from node A to node C may remain open for a period of time (210).

[0027] Node A may determine to close a connection to node B (the connection being opened with a startPSN of "0") by sending a close request to node B (211). Upon receiving the close request, node B may set its eiPSN to the greater of the current value of its eiPSN and the startPSN of node A (used to open the connection) incremented by one: MAX(B.eiPSN, A.startPSN+1)=MAX(0,0+1)=1 (212, and as indicated by the update of B.eiPSN from a value of "0" to a value of "1" in field 282.1). Node B may send a close response message to node A including B.eiPSN ("1") (213). Upon receiving the Close Response message, node A may set its startPSN to the larger of the current value of its starting PSN incremented by one and node B's eiPSN: MAX(A.startPSN+1, B.eiPSN)=MAX(0+1,1)=1 (214, and as indicated in the update of A.startPSN from value "0" to value "1" in field 281.1).

[0028] Next, node A can open a connection with node F by sending a connection request packet indicating node A's startPSN ("1") (215). Node F can determine whether the startPSN of node A is valid by checking whether it is greater than or equal to the eiPSN of node F (216). If the check result is yes, this indicates that node A's startPSN is valid (217). If the check result is no, this indicates that node A's starting PSN is invalid (218) (i.e., a round trip failure). In this case, the check 216 indicates that 1 is greater than or equal to 0, which causes node F to accept the connection with node A's startPSN ("1") (217). The connection from node A to node F can remain open for a period of time (218).

[0029] Node A may then determine to close the connection to node F (which was opened with startPSN being "1") by sending a close request to node F (219). Upon receiving the close request, node F may set its eiPSN to the greater of the current value of its eiPSN and the startPSN (of node A used to open the connection) incremented by one: MAX(F.eiPSN, A.startPSN+1) = MAX(0, 1+1) = 2 (220, and as indicated by the update of F.eiPSN from a value of "0" to a value of "2" in field 284.1). Node F may send a close response message to node A including F.eiPSN ("2") (221). Upon receiving the close response message, node A may set its startPSN to the larger of the current value of its starting PSN incremented by one and the eiPSN of node F: MAX(A.startPSN+1, F.eiPSN) = MAX(1+1, 2) = 2 (222, and as indicated in the update of A.startPSN from value "1" to value "2" in field 281.1).

[0030] Figure 2B Figure 230 illustrates a communication and table that uses an originating PSN to facilitate endpoint state management according to an aspect of the present application. The communication in figure 230 may occur after the communication in figure 200. The originating values of fields 281.2, 282.2, 283.2, and 284.2 reflect the latest originating values of the corresponding fields 281.1, 282.1, 283.1, and 284.1 at the end of the communication in figure 200.

[0031] Node C can open a connection with node F by sending a connection request packet indicating node C's startPSN ("0") (240). Node F can determine whether the startPSN is valid by checking whether node C's startPSN is greater than or equal to node F's eiPSN (241). If the check result is yes, this indicates that node C's startPSN is valid (242). If the check result is no, this indicates that node C's starting PSN is invalid (243) (i.e., a round trip failure). In this case, check 241 indicates that 0 is not greater than or equal to 1, which causes node F to send a negative acknowledgement (NACK) packet with a valid PSN to node C (243). The valid PSN can be the current value of node F's eiPSN or the maximum starting PSN on all open connections on node F. Figure 2C The operation 277 of FIG. 24 is used to describe the determination of which value to use as the effective PSN. In this case, F sends its current eiPSN ("2"). Communications 240 to 243 indicate a round trip failure, which may reduce the efficiency of the entire system.

[0032] Upon receiving a valid PSN from node F, node C may set its C.startPSN to the received valid F.eiPSN ("2"), as long as the current value of its C.startPSN is not less than or equal to the received valid F.eiPSN. For example, if between the time node C sends communication 240 and the time node C receives communication 243, node C has updated its C.startPSN to a current value greater than 2 (e.g., "3"), then node C will not set its C.startPSN to the received valid F.eiPSN ("2"), but will instead maintain that current value ("3") as its C.startPSN. Node C may then resend a connection request packet indicating node C's current startPSN (i.e., send a new connection request packet) (244). In the depicted example, the current value of C.startPSN has been updated to "2" in response to receiving the NACK (244, and as indicated in the update of C.startPSN from the value "2" to the value "10" in field 283.2), so a connection request packet is sent with the startPSN being "2" (244). Node F can determine whether the startPSN is valid by checking whether node C's startPSN is greater than or equal to node F's eiPSN (245). If the check result is yes, this indicates that node C's startPSN is valid (246). If the check result is no, this indicates that node C's starting PSN is invalid (247) (i.e., a round trip failure). In this case, check 241 indicates that 2 is greater than or equal to 2, which causes node F to accept the connection with C's startPSN ("2") (246). The connection from node C to node F can remain open for a period of time (248).

[0033] In some aspects, node C or node F can track that the new connection request packet (244) is a retransmission (i.e., part of a round trip failure) of a previously sent connection request packet (240) and use this information when determining which eiPSN to use (as described below with respect to Figure 2C of the examination described in 277).

[0034] Subsequently, other nodes G may open and close connections with node F until the eiPSN of node F is incremented to a value of, for example, "10" (249).

[0035] Node C may determine to close the connection to node F (which was opened with a startPSN of "2") by sending a close request to node F (250). Upon receiving the close request, node F may set its eiPSN to the greater of the current value of its eiPSN and the startPSN (of node C used to open the connection) incremented by one: MAX(F.eiPSN, C.startPSN+1)=MAX(10,2+1)=10 (251, and as indicated in the update of F.eiPSN from a value of "2" to a value of "10" in field 284.2). Node F may send a close response message to node C including F.eiPSN ("2") (252). Upon receiving the close response message, node C may set its startPSN to the larger of the current value of its starting PSN incremented by one and the eiPSN of node F: MAX(C.startPSN+1, F.eiPSN) = MAX(2+1, 10) = 10 (253, and as indicated in the update of C.startPSN from the value "2" to the value "10" in field 283.2).

[0036] Next, node A can determine to close the connection to node C by sending a close request to node C (in Figure 2A 206, the connection is opened with startPSN "0") (254). Upon receiving the close request, node C may set its eiPSN to the larger of the current value of its eiPSN and the startPSN (of node A used to open the connection) incremented by one: MAX(C.eiPSN, A.startPSN+1)=MAX(0,0+1)=1 (255, and as indicated in the update of C.eiPSN from value "0" to value "1" in field 283.2). Node C may send a close response message (252) to node A including C.eiPSN ("1"). Upon receiving the Close Response message, node A may set its startPSN to the greater of the current value of its starting PSN incremented by one and the eiPSN of node C: MAX(A.startPSN+1, C.eiPSN) = MAX(2+1, 1) = 3 (257, and as indicated in the update of A.startPSN from a value of "2" to a value of "3" in field 281.2). Alternatively, since the starting PSN of "2" has never been used to initiate a connection from node A to node C, the system does not need to increment A.startPSN by 1. That is, when C sends the Close Response, node A does not need to increment its starting PSN; instead, node A may keep its starting PSN at the value of "2."

[0037] Figure 2CFigure 260 illustrates a communication and table that uses an originating PSN to facilitate endpoint state management according to an aspect of the present application. The communication in figure 260 may occur after the communication in figure 230. The originating values of fields 281.3, 282.3, 283.3, and 284.3 reflect the latest originating values of the corresponding fields 281.2, 282.2, 283.2, and 284.2 at the end of the communication in figure 230.

[0038] Node C can open a connection with node F by sending a connection request packet indicating node C's startPSN ("10") (270). Node F can determine whether the startPSN of node C is valid by checking whether it is greater than or equal to the eiPSN of node F (271). If the check result is yes, this indicates that node C's startPSN is valid (272). If the check result is no, this indicates that node C's starting PSN is invalid (273) (i.e., a round trip failure). In this case, check 271 indicates that 10 is greater than or equal to 10, which causes node F to accept the connection with C's startPSN ("10") (272). The connection from node C to node F can remain open for a period of time (274).

[0039] Subsequently, other nodes G may open and close connections with node F until the eiPSN of node F is incremented to a value of, for example, "15" (275).

[0040] Node C may determine to close the connection to node F (which was opened with a startPSN of "10") by sending a close request to node F (276). Upon receiving the close request, node F may determine whether to use its current eiPSN ("15") or, if node F determines that the maximum PSN it has seen on all open connections to node F is greater than the current eiPSN, use the maximum PSN (e.g., "45") (277). For example, one of the other nodes G may have opened a connection to node F (not shown) using a starting PSN of 45, but has not yet closed the connection to F, i.e., has not yet triggered an update of F.eiPSN to 45. Node F may determine whether to use its current eiPSN or the maximum PSN based on heuristics or conditions, including, for example, information collected as part of increasing its own eiPSN by closing connections with other nodes, a predetermined maximum threshold for the difference between its current eiPSN and the maximum PSN on all open connections to node F, a number of previously occurring round-trip failures with the same initiating node, and one or more preconfigured conditions.

[0041] If node F determines to use the maximum PSN ("45") based on a heuristic or condition, and because the maximum PSN ("45") is greater than its current eiPSN ("15"), node F may send a Close Response message with F.eiPSN equal to the maximum PSN incremented by 1: F.eiPSN = (45 + 1 = 46). Although node F may send this value ("46") to node C (which is based on the maximum PSN), node F may not have set its F.eiSPN to this value ("46"). Instead, node F may anticipate that it may set its F.eiSPN to this maximum PSN at some time in the future. The described aspects may provide for more efficient use of PSNs by ensuring that nodes do not spontaneously increase their own eiPSNs because other nodes may not have updated their own startPSNs yet. Therefore, node C may subsequently use "46" to open a connection with node F, even though node F may have only expected "15". Alternatively, in some aspects, node F may set its eiPSN to the maximum PSN incremented by one: F.eiPSN = (45 + 1 = 46) (278, and as indicated in the update of F.eiPSN from a value of "15" to a value of "46" in field 284.3). Node F may determine to set its eiPSN to "46" based on one or more conditions (e.g., a trigger condition when the difference between the maximum startPSN and the current iePSN is less than some predetermined threshold). Node F may send a close response with its current F.eiPSN ("46") (278). Upon receiving the Close Response message, node C may set its startPSN to the greater of the current value of its starting PSN incremented by one and node F's eiPSN: MAX(C.startPSN+1, F.eiPSN) = MAX(10+1, 46) = 46 (280, and as indicated in the update of C.startPSN from a value of "10" to a value of "46" in field 283.3). If node F determines to use the current value of its eiPSN ("15") (279), node F may send a Close Response with the current eiPSN value (278), and node C may set its startPSN based on that eiPSN (not depicted).

[0042] The total PSN space can be based on a selected PSN size, e.g., 32 bits. When the startPSN reaches its limit and needs to wrap, the system can perform a rekey operation before the startPSN needs to wrap, e.g., based on a predetermined maximum threshold of the total PSN space or another configurable condition.

[0043] Additionally, for a given encryption key, the system can segment the total PSN space into multiple segments or multiple starting PSN spaces. On the one hand, the source node can segment the startPSN, and the destination node can segment the eiPSN. On the other hand, the target can maintain sole control over managing the eiPSN and ensure eiPSN correctness by segmenting the eiPSN, which can limit cross-pollination between source nodes that may be caused by the destination node. When using a segmented PSN space, the system only needs to ensure that a given pair of nodes (i.e., the source node and the destination node) never uses the same startPSN multiple times. This segmentation can result in isolating the impact of one segment group from another segment group and can further reduce the impact of rapid eiPSN increases caused by other destination nodes for a given destination node that the source node is currently communicating with.

[0044] When determining the segment space and using the appropriate startPSN and eiPSN within a given segment space, a pair of nodes can use the same or different hash functions, but to ensure consistency within each node, each node must use the same hash function for itself. That is, nodes can use different hash functions between each other, but each node must use the same hash function to maintain consistency within that particular node. The hash function can be performed based on one or more fields associated with the source node (in the case of determining the current value of the destination node's eiPSN) or associated with the destination node (in the case of determining the startPSN associated with the source node). These fields may include, for example, the IP address of the source or destination node and an identifier based on the connection of the source or destination node.

[0045] Certain situations may result in multiple round trip failures. For example, the destination node B may be experiencing a lot of activity, such as multiple on / offs, which may cause the eiPSN to increase rapidly and multiple round trip failures to occur when the source node A attempts to open a connection using its current (and not yet updated) startPSN. In this case, the destination node may determine to use a different eiPSN. For example, node A may attempt to open a connection with node B by sending a connection request packet indicating A.startPSN=80. Node B can determine whether A.startPSN is valid by checking whether A.startPSN is greater than or equal to B.eiPSN. Assuming the result is no (e.g., current B.eiPSN=120), this indicates that A.startPSN is invalid (i.e., round trip failure). As described above for check 277, node B may determine to send its current eiPSN ("120") or the maximum starting PSN it has seen on all its connections incremented by one (e.g., 199+1=200). As a result of a round-trip failure, node B may also track which eiPSN (e.g., current or maximum) and the corresponding value (e.g., "120" or "200") node B sent back to node A. In response to receiving a subsequent connection request packet from A, if another round-trip failure occurs, node B may send the tracked and previously sent eiPSN back to node A, incremented by one (e.g., "201"). While this functionality may require the node to maintain a certain amount of state, the system can achieve a reduced rate of increase in the expected incoming PSN by tracking the most recently sent eiPSN at the time of connection establishment or round-trip failure.

[0046] In another aspect of the present application for resolving multiple round-trip failures, the source node may determine to use a different startPSN. For example, node A may attempt to open a connection with node B using A.startPSN=80. Node B may respond with a NACK indicating B.eiPSN=200. Node A may attempt to open a connection with node B again using A.startPSN=200. However, B.eiPSN may have increased in the meantime, and node B may respond with a NACK indicating B.eiPSN=210. At this point, instead of using A.startPSN=210 in the next connection request packet, node A may determine a "safe guess" for its startPSN by increasing its startPSN in advance based on, for example, one or more of the following: the number of round-trip failures; the difference between the eiPSN received as a result of the first round-trip failure (e.g., "200") and the eiPSN received as a result of the second round-trip failure ("210"); a scaling number based on the difference; and any other heuristics or conditions based on information tracked, maintained, or analyzed by the node. For example, node A may determine a safe guess to be A.startPSN=220 based on the difference ("10") between the eiPSN received in the first round-trip failure and the eiPSN received in the second round-trip failure (220-210=10).

[0047] Therefore, to resolve multiple round trip failures, both the source node and the destination node may decide which eiPSN or startPSN to use in case of a round trip failure, and these decisions may be based on factors as listed above.

[0048] Figure 3 A flowchart 300 is presented that illustrates a method for facilitating endpoint state management using a starting PSN according to an aspect of the present application. During operation, the system receives, by a destination node, a connection request packet indicating a starting packet sequence number (PSN) associated with a source node (operation 302). For example, node A (the source node) opens a connection with node B (the destination node), and node B (the destination node) receives a connection request packet with A's startPSN equal to a value of "0" (as described above with respect to FIG. Figure 2A201). Each participating node may maintain two fields (startPSN and eiPSN) that are set to the same value when each node initializes or installs a key to be used for communication between nodes. The starting value may be, for example, 0. In some aspects, the starting value may be initialized by segmenting the encryption key into a plurality of different starting PSN values. The source node and the destination node in each source / destination node pair may hash one or more fields of the connection request packet or other control packet to determine the starting PSN space. The one or more fields may include, for example, but not limited to, at least one of the following: the IP address of the source node; the IP address of the destination node; an identifier based on the connection of the source node; an identifier based on the connection of the destination node.

[0049] The system may accept the first connection corresponding to the connection request packet by the destination node in response to the startPSN being valid (operation 304). The destination node may determine whether the startPSN is valid by comparing the startPSN associated with the source node and the eiPSN associated with the destination node. If the startPSN is greater than or equal to the eiPSN of the destination node, the startPSN is valid. For example, in Figure 2A , node B may receive a connection request packet from node A (201) and perform a check (202) to determine if A.startPSN>=B.eiPSN. Since this is true (because 0>=0), node B may accept the connection (203).

[0050] If the source node does not close the first connection (decision 306), then operations continue until the source node closes the first connection. While the first connection remains open, other nodes may open and close connections with the destination node, which may increase the value of the expected incoming PSN associated with the destination node, as described above with respect to Figure 2C If the source node does close the first connection (decision 306), the source node sends a close message to the destination node (not shown). The system sets the expected incoming PSN associated with the destination node to the greater of the current value of the expected incoming PSN and the starting PSN associated with the source node, incremented by one (operation 308). For example, in Figure 2AIn the example, node A may send a close request message to node B (211), and node B may set its B.eiPSN to the larger of its B.eiPSN and A.startPSN incremented by one upon receiving the close request message: B.eiPSN = MAX(B.eiPSN, A.startPSN+1) = 1 (212). The value of A.startPSN used in this maximum operation is the value used to open the connection, and is not the current value of A.startPSN (although the same term "A.startPSN" is used in 211 and 212). That is, the startPSN used by the destination node in the maximum operation when receiving a request to close the connection is the startPSN used to open the connection, rather than the current value of the startPSN of the source node.

[0051] The system sends a close response message including the expected incoming PSN to the source node via the destination node (operation 310), and then allows the source node to set the starting PSN to the greater of the current value of the starting PSN incremented by one and the expected incoming PSN associated with the destination node (operation 312). Figure 2A In the example in FIG. 2 , node B (destination node) may send a close response message (213) to node A (source node) including its expected incoming PSN as B.eiPSN=1. In response, node A (source node) may receive the eiPSN from node B (destination node) and may set its startPSN to the larger of its current startPSN value incremented by one and the eiPSN received from node B: MAX(A.startPSN+1, B.eiPSN)=MAX(0+1,1)=1( Figure 2B 214). Although Figure 2A , flowchart 300 and the various aspects described indicate that the source node (A) can set its starting PSN by selecting the result of this "max" operation (i.e., the greater of its current startPSN incremented by one and the eiPSN received from the destination node (B)), but the source node (A) can set its starting PSN to any value equal to or greater than the result of the max operation. The described max operation (including the incrementing value "1") can be used to help minimize the rate of increase of the PSN in order to reduce the frequency of rekey operations.

[0052] Figure 4AA flowchart 400 is presented according to an aspect of the present application that illustrates a method for facilitating endpoint state management using a starting PSN, including opening a connection and checking for a valid starting PSN. During operation, in a system having multiple nodes, a respective node installs a key to be used when transmitting packets between the nodes (operation 402). The respective node maintains a starting PSN (startPSN) associated with the respective node and an expected incoming PSN (eiPSN) associated with the respective node (operation 404). Each participating node may maintain two fields (startPSN and eiPSN) that are set to the same value when each node initializes or installs a key. Thus, for a given key, startPSN and eiPSN may have the same initial value (e.g., 0) on all nodes (e.g., in Figures 2A to 2C ), and the starting space may be segmented as described above for operation 302 .

[0053] The system receives, by the destination node, a connection request packet indicating a starting packet sequence number (PSN) associated with the source node (operation 406, similar to operation 302). For example, node A (the source node) opens a connection with node B (the destination node), and node B (the destination node) receives a connection request packet with A's startPSN equal to a value of "0" (as described above with respect to Figure 2A 201 described in the communication).

[0054] The system can determine, via the destination node, whether the starting PSN associated with the source node is greater than or equal to the expected incoming PSN associated with the destination node (operation 408), i.e., whether the starting PSN of the source node is valid. When installing the key and initializing a pair of fields (startPSN and eiPSN) for each participating node, the starting PSN associated with the source node and the expected incoming PSN associated with the destination node can be equal. If the source node opens and closes more connections than the destination node (which can increase the starting PSN associated with the source node), the starting PSN of the source node may be greater than the expected incoming PSN associated with the destination node. The converse is also true, i.e., if the destination node opens and closes more connections than the source node, the starting PSN of the source node may be less than the expected incoming PSN associated with the destination node.

[0055] If the originating PSN of the source node is valid (decision 410), the destination node accepts the first connection corresponding to the connection request packet (operation 412) and operates on Figure 4B4. If the originating PSN of the source node is invalid (decision 410), the destination node rejects the first connection by sending a NACK packet with a valid PSN (operation 414), and the destination node subsequently receives a new connection request packet indicating a valid PSN as the originating PSN associated with the source node (operation 416). Operations continue as described at operation 408.

[0056] For example, in Figure 2A In the example above, node B may receive a connection request packet from node A (201) and perform a check (202) to determine if A.startPSN >= B.eiPSN. Since this is true (because 0 >= 0), node B may accept the connection (203). However, in the case where the source node's starting PSN is invalid, as described above in conjunction with Figure 2B As described in operations 241 and 243, destination node F may send a NACK with its current eiPSN being 2, and subsequently receive a new connection request from source node A including a startPSN of "2" (244). Node B may then perform a check (245) to determine if A.startPSN >= B.eiPSN. Since this is true (because 2 >= 2), node B may accept the connection (246, and as in operation 416). Operations in Figure 4B In some aspects, instead of sending a NACK with its current eiPSN, the destination node may send the maximum originating PSN of all open connections on the destination node, as described above with respect to Figure 2C Operations 277 / 278 are described.

[0057] Figure 4B A flowchart 430 is presented that illustrates a method for facilitating endpoint state management using an originating PSN, including closing a connection, according to an aspect of the present application. Following the operations of flowchart 400, the source node may determine to close the first connection and send a close message ( Figure 4B 4. The destination node receives the request to close the first connection (operation 432) and sets the expected incoming PSN associated with the destination node to the greater of the current value of the expected incoming PSN and the starting PSN associated with the source node incremented by one (operation 434, similar to operation 308). Figure 2A, node A may send a close request message to node B (211), and node B may, upon receiving the close request message, set its B.eiPSN to the larger of its B.eiPSN and A.startPSN incremented by one: B.eiPSN = MAX(B.eiPSN, A.startPSN+1) = 1 (212). Alternatively, the destination node, upon receiving the close request message, may determine that the maximum starting PSN across all open connections on the destination node is greater than the expected incoming PSN associated with the destination node, and may, based on a condition or heuristic, set its expected incoming PSN to the maximum starting PSN incremented by one. For example, in Figure 2C , node F (destination node) may determine that the maximum PSN it has seen (“45”) is greater than its F.eiPSN (“15”), and may set its F.eiPSN to the maximum PSN incremented by one (45+1=46) based on a condition or heuristic (277 and 278).

[0058] The destination node sends a close response message including the expected incoming PSN to the source node (operation 436, similar to operation 310). Figure 2A In the example, node B (destination node) may send a close response message to node A (source node) including its expected incoming PSN as B.eiPSN=1 ( Figure 2A In another example, node F (destination node) may send a close response message to node C (source node) including its expected incoming PSN as F.eiPSN=46 ( Figure 2C 278). The system then allows the source node to set the starting PSN to the greater of the current value of the starting PSN incremented by one and the expected incoming PSN associated with the destination node (operation 438, similar to operation 312). Continue Figure 2A In the example of , node A (source node) may receive an eiPSN from node B (destination node) and may set its startPSN to the larger of its current startPSN value incremented by one and the eiPSN received from node B: MAX(A.startPSN+1, B.eiPSN)=MAX(0+1,1)=1(214). Figure 2C In the example of , node C (source node) may receive an eiPSN from node F (destination node) (278) and may set its startPSN to the greater of its current startPSN value incremented by one and the eiPSN received from node F: MAX(C.startPSN+1, F.eiPSN) = MAX(10+1, 46) = 46 (280). The operation returns.

[0059] Figure 5A computer system 500 is illustrated that facilitates endpoint state management using an initiated PSN according to one aspect of the present application. The computer system 500 includes a processor 502, a memory 504, and a storage device 506. The memory 504 may include volatile memory (e.g., random access memory (RAM)) that functions as managed memory and may be used to store one or more memory pools. Additionally, the computer system 500 may be coupled to peripheral I / O user devices 510 (e.g., a display device 511, a keyboard 512, and a pointing device 513). The storage device 506 includes a non-transitory computer-readable storage medium and stores an operating system 516, a content processing system 518, and data 532. The computer system 500 may include, for example, a processor 502, a memory 504, and a storage device 506. Figure 5 Fewer or more entities or instructions may be shown.

[0060] The content processing system 518 may include instructions that, when executed by the computer system 500, may cause the computer system 500 to perform the methods and / or processes described in the present disclosure. Specifically, the content processing system 518 may include instructions 520 for receiving, by the computer system 500 operating as a destination node among a plurality of nodes, a connection request packet indicating a starting packet sequence number (PSN) associated with a source node, as described above with respect to, for example, the following: Figure 2A Communications 201, 206 and 215; Figure 2B Communications 240 and 244; and Figure 2C Communication 270. The content processing system 518 may include instructions 522 for determining whether the originating PSN is valid, as described above with respect to, for example, the following: Figure 2A Operations 202, 207 and 216; Figure 2B Operations 241 and 245; and Figure 2C Operation 271 of . The content processing system 518 may include instructions 524 for accepting a connection corresponding to the connection request packet in response to the originating PSN being valid, as described above with respect to, for example, the following: Figure 2A communications 203, 208 and 217; Figure 2B Communications 246; and Figure 2C Communication 272.

[0061] Content processing system 518 may include instructions 526 for receiving a request to close the first connection, as described above with respect to, for example: Figure 2A Communications 211 and 219; Figure 2B Communications 250 and 254; and Figure 2CCommunication 277. The content processing system 518 may include instructions 528 for setting the expected incoming PSN associated with the destination node to the greater of the current value of the expected incoming PSN and the starting PSN associated with the source node incremented by one, as described above with respect to, for example, the following: Figure 2A Operations 212 and 220; Figure 2B Operations 251 and 255; and Figure 2C Operation 279. The content processing system 528 may include instructions 530 for sending a close response message including the expected incoming PSN to the source node, as described above with respect to, for example, the following: Figure 2A Communications 213 and 221; Figure 2B Communications 252 and 256; and Figure 2C Communication 278. Instruction 530 (i.e., send a close response message) may allow or cause the source node to set the start PSN to the greater of the current value of the start PSN incremented by one and the expected incoming PSN associated with the destination node, as described above with respect to, for example, the following: Figure 2A Operations 214 and 222; Figure 2B Operations 253 and 257; and Figure 2C Operation 280.

[0062] Content processing system 518 may include Figure 5 For example, the content processing system 518 may include instructions for performing the operations described above with respect to: Figure 1 environment; Figures 2A to 2C communications and operations; Figure 3 and Figures 4A to 4B The operations depicted in the flowchart of ; and Figure 6 Instructions for the CRM 600.

[0063] Data 532 may include any data required as input or generated as output by the methods, operations, communications, and / or processes described in this disclosure. Specifically, data 532 may store at least: a packet; a connection request packet; a connection response message or packet; a close request message or packet; a close response message or packet; an indicator of a first connection; a PSN; an initial value of a PSN; a starting PSN; an expected incoming PSN; an updated starting PSN; an updated expected incoming PSN; a maximum starting PSN; one or more fields maintained by a source node or a destination node; an identifier of a source node or a destination node; an indicator of accepting or rejecting a connection request message or packet; a negative acknowledgement (NACK) packet; a key; an encryption key; a segmented PSN space; a plurality of different starting PSN values; the result of a hash function; an IP address of a source node or a destination node; and an identifier of a connection based on a source node or a destination node.

[0064] Figure 6 A computer-readable medium 600 is illustrated for facilitating endpoint state management using an originating PSN according to an aspect of the present application. The CRM 600 may be a non-transitory computer-readable medium or device storing instructions that, when executed by a computer or processor, cause the computer or processor to perform a method. The CRM 600 may store instructions 610 for receiving a first connection request packet indicating an originating packet sequence number (PSN) associated with a source node, as described above with respect to, for example, the following: Figure 2A Communications 201, 206 and 215; Figure 2B Communications 240 and 244; and Figure 2C The CRM 600 may store instructions 612 for accepting a first connection corresponding to the first connection request packet in response to the originating PSN being valid, as described above with respect to, for example, the following: Figure 2A Correspondence 202 / 203, 207 / 208 and 216 / 217; Figure 2B Communications 245 / 246; and Figure 2C Correspondence 271 / 272.

[0065] The CRM 600 may further store instructions 614 for determining that the source node requests closing of the first connection, as described above with respect to, for example: Figure 2A Communications 211 and 219; Figure 2B Communications 250 and 254; and Figure 2C The CRM 600 may store instructions 616 for setting the expected incoming PSN associated with the destination node to the greater of the current value of the expected incoming PSN and the starting PSN associated with the source node incremented by one in response to the source node closing the first connection, as described above with respect to, for example, the following: Figure 2A Operations 212 and 220; Figure 2B Operations 251 and 255; and Figure 2C Operation 279 of . The CRM 600 may store instructions 618 for sending a close response message including the expected incoming PSN to the source node, as described above with respect to, for example, the following: Figure 2A Communications 213 and 221; Figure 2B Communications 252 and 256; and Figure 2C The CRM 600 may also store instructions 620 for allowing the source node to set the starting PSN to the greater of the current value of the starting PSN incremented by one and the expected incoming PSN associated with the destination node, as described above with respect to, for example, the following: Figure 2A Operations 214 and 222; Figure 2B Operations 253 and 257; and Figure 2C Operation 280.

[0066] CRM 600 may include Figure 6 For example, the CRM 600 may also store instructions for performing the operations described above with respect to: Figure 1 environment; Figures 2A to 2C communications and operations; Figure 3 and Figures 4A to 4B The operations depicted in the flowchart of ; and Figure 5 Instructions of the content processing system 518 of the computer system 500.

[0067] In general, the disclosed aspects provide a method, computer system, and computer-readable medium for facilitating endpoint state management using a starting packet sequence number (PSN). During operation, the system receives, by a destination node, a connection request packet indicating a starting packet sequence number (PSN) associated with a source node. In response to the starting PSN being valid, the system accepts, by the destination node, a first connection corresponding to the connection request packet. In response to the source node closing the first connection, the system: sets, by the destination node, an expected incoming PSN associated with the destination node to the greater of a current value of the expected incoming PSN and a starting PSN associated with the source node incremented by one; sends, by the destination node, a close response message including the expected incoming PSN to the source node; and allows the source node to set the starting PSN to the greater of a current value of the starting PSN incremented by one and an expected incoming PSN associated with the destination node.

[0068] In a variation of this aspect, the expected incoming PSN associated with the destination node corresponds to the expected originating PSN associated with the source node.

[0069] In a further variation, the system determines, by the destination node, whether the originating PSN associated with the source node is valid by comparing the originating PSN associated with the source node with an expected incoming PSN associated with the destination node. The system accepts the first connection in response to the originating PSN associated with the source node being greater than or equal to the expected incoming PSN associated with the destination node.

[0070] In a further variation, in response to the originating PSN associated with the source node being less than the expected incoming PSN associated with the destination node, the system rejects the first connection by sending a negative acknowledgement packet with a valid PSN by the destination node to the source node.

[0071] In a further variation, the system receives, by the destination node, a new connection request packet indicating a valid PSN as the originating PSN associated with the source node.

[0072] In another variant, the effective PSN comprises at least one of: the current value of the expected incoming PSN associated with the destination node; or the maximum starting PSN over all open connections on the destination node, incremented by one.

[0073] In another variant, the starting PSN of a respective connection between a pair of nodes is unique to a key and is not reused for subsequent connections between the pair of nodes for that key.

[0074] In another variation, the system maintains, by a corresponding node among the plurality of nodes, a starting PSN associated with the corresponding node and an expected incoming PSN associated with the corresponding node. The starting PSN and the expected incoming PSN include the same initial value on all nodes that have installed the encryption key.

[0075] In another variation, in response to the source node closing the first connection, the system performs the following operations: the system determines that the maximum starting PSN of all open connections on the destination node is greater than an expected incoming PSN associated with the destination node. The system sets the expected incoming PSN associated with the destination node to the maximum starting PSN incremented by one based on a condition. The system sends, via the destination node, a close response message to the source node that includes the previously set expected incoming PSN associated with the destination node.

[0076] In another variation, the system segments a total space of PSN values for the encryption key into a plurality of starting PSN spaces. The system determines a current value of an expected incoming PSN associated with a destination node based on a first hash performed on one or more fields associated with the source node, wherein a result of the first hash corresponds to a first starting PSN space.

[0077] In a further variation, the starting PSN associated with the source node indicated in the connection request packet is obtained from a second hash performed on one or more fields associated with the destination node, and the result of the second hash corresponds to a second starting PSN space.

[0078] In a further variation, one or more fields associated with the destination node include an Internet Protocol (IP) address of the source node and at least one of an identifier based on the first connection of the source node, and one or more fields associated with the source node include an IP address of the destination node and at least one of an identifier based on the first connection of the destination node.

[0079] In another aspect, a computer system includes a processor and a storage device storing instructions. The instructions are for receiving, by a computer system operating as a destination node among a plurality of nodes, a connection request packet indicating a starting packet sequence number (PSN) associated with a source node. The instructions are further for accepting a first connection corresponding to the connection request packet in response to the starting PSN being valid. The instructions are further for receiving a request to close the first connection and setting an expected incoming PSN associated with the destination node to the greater of a current value of the expected incoming PSN and a starting PSN associated with the source node incremented by one. The instructions are further for sending a close response message including the expected incoming PSN to the source node, wherein sending the close response message causes the source node to set the starting PSN to the greater of a current value of the starting PSN incremented by one and an expected incoming PSN associated with the destination node. The computer system may include a content processing system including instructions for performing the operations described herein, including with respect to: Figure 1 environment; Figures 2A to 2C communications and operations; Figure 3 and Figures 4A to 4B The operations depicted in the flowchart of ; and Figure 6 Instructions for the CRM 600.

[0080] In another aspect, a non-transitory computer-readable storage medium (or CRM) stores instructions for receiving, by a destination node, a first connection request packet indicating a starting packet sequence number (PSN) associated with a source node. The instructions are further for accepting, by the destination node, a first connection corresponding to the first connection request packet, in response to the starting PSN being valid. The instructions are further for closing the first connection, in response to the source node: setting, by the destination node, an expected incoming PSN associated with the destination node to the greater of a current value of the expected incoming PSN and a starting PSN associated with the source node incremented by one; sending, by the destination node, a close response message including the expected incoming PSN to the source node; and allowing the source node to set the starting PSN to the greater of a current value of the starting PSN incremented by one and an expected incoming PSN associated with the destination node. The CRM may also store instructions for performing the operations described above with respect to: Figure 1 environment; Figures 2A to 2C communications and operations; Figure 3 and Figures 4A to 4B The operations depicted in the flowchart of ; and Figure 5 Instructions of the content processing system 518 of the computer system 500.

[0081] The foregoing description is presented to enable any person skilled in the art to make and use the various aspects and examples, and is provided in the context of a specific application and its requirements. Various modifications to the disclosed aspects will be apparent to those skilled in the art, and the general principles defined herein may be applied to other aspects and applications without departing from the spirit and scope of the present disclosure. Therefore, the aspects described herein are not limited to those shown, but are intended to be accorded the widest scope consistent with the principles and features disclosed herein.

[0082] Furthermore, the foregoing description of the various aspects has been presented for purposes of illustration and description only. These descriptions are not intended to be exhaustive or to limit the various aspects described herein to the disclosed forms. Accordingly, numerous modifications and variations will be apparent to those of ordinary skill in the art. Furthermore, the above disclosure is not intended to limit the various aspects described herein. The scope of the various aspects described herein is defined by the appended claims.

Claims

1. A method comprising: receiving, by the destination node, a connection request packet indicating a starting packet sequence number (PSN) associated with the source node; accepting, by the destination node, a first connection corresponding to the connection request packet in response to the originating PSN being valid; and In response to the source node closing the first connection: setting, by the destination node, an expected incoming PSN associated with the destination node to the greater of a current value of the expected incoming PSN and the starting PSN associated with the source node incremented by one; sending, by the destination node to the source node, a close response message including the expected incoming PSN; and The source node is allowed to set the starting PSN to the greater of the current value of the starting PSN incremented by one and the expected incoming PSN associated with the destination node.

2. The method according to claim 1, in, The expected incoming PSN associated with the destination node corresponds to an expected originating PSN associated with the source node.

3. The method according to claim 1, further comprising: determining, by the destination node, whether the originating PSN associated with the source node is valid by comparing the originating PSN associated with the source node and the expected incoming PSN associated with the destination node; and In response to the originating PSN associated with the source node being greater than or equal to the expected incoming PSN associated with the destination node, accepting the first connection.

4. The method according to claim 3, further comprising: In response to the originating PSN associated with the source node being less than the expected incoming PSN associated with the destination node, rejecting the first connection by sending, by the destination node, a negative acknowledgement packet with a valid PSN to the source node.

5. The method according to claim 4, further comprising: A new connection request packet is received by the destination node indicating the valid PSN as the originating PSN associated with the source node.

6. The method according to claim 4, wherein: The valid PSN includes at least one of the following: the current value of the expected incoming PSN associated with the destination node; or The maximum starting PSN across all open connections on the destination node is incremented by one.

7. The method according to claim 1, in, The starting PSN for a respective connection between a pair of nodes is unique to a key and is not reused for subsequent connections between the pair of nodes for the key.

8. The method according to claim 1, further comprising: maintaining, by a respective node of the plurality of nodes, an originating PSN associated with the respective node and an expected incoming PSN associated with the respective node, Wherein, the starting PSN and the expected incoming PSN include the same initial value on all nodes where encryption keys have been installed.

9. The method according to claim 1, wherein In response to the source node closing the first connection, the method further comprises: determining that a maximum originating PSN across all open connections on the destination node is greater than the expected incoming PSN associated with the destination node; setting the expected incoming PSN associated with the destination node to the maximum starting PSN incremented by one based on a condition; and The close response message is sent by the destination node to the source node including a previously set expected incoming PSN associated with the destination node.

10. The method according to claim 1, For encryption keys, segmenting the total space of PSN values into a plurality of starting PSN spaces; and The current value of the expected incoming PSN associated with the destination node is determined based on a first hash performed on one or more fields associated with the source node, wherein The result of the first hashing corresponds to a first starting PSN space.

11. The method according to claim 10, in, obtaining the originating PSN associated with the source node indicated in the connection request packet from a second hash performed on one or more fields associated with the destination node, and The result of the second hash corresponds to a second starting PSN space.

12. The method according to claim 11, in, The one or more fields associated with the destination node include at least one of an Internet Protocol (IP) address of the source node and an identifier based on the first connection of the source node; and The one or more fields associated with the source node include at least one of an IP address of the destination node and an identifier based on the first connection of the destination node.

13. A computer system comprising: processor; as well as A storage device storing instructions for: receiving, by the computer system operating as a destination node among the plurality of nodes, a connection request packet indicating a starting packet sequence number (PSN) associated with a source node; In response to the starting PSN being valid, accepting a first connection corresponding to the connection request packet; receiving a request to close the first connection; setting an expected incoming PSN associated with the destination node to the greater of a current value of the expected incoming PSN and the starting PSN associated with the source node incremented by one; and sending a close response message including the expected incoming PSN to the source node, Wherein, sending the close response message causes the source node to set the starting PSN to the greater of a current value of the starting PSN incremented by one and the expected incoming PSN associated with the destination node.

14. The computer system of claim 13, wherein the instructions are further configured to: determining whether the originating PSN associated with the source node is valid by comparing the originating PSN associated with the source node to the expected incoming PSN associated with the destination node; and In response to the originating PSN associated with the source node being greater than or equal to the expected incoming PSN associated with the destination node, accepting the first connection.

15. The computer system of claim 13, wherein the instructions are further configured to: determining that the originating PSN associated with the source node is less than the expected incoming PSN associated with the destination node; In response to determining that the originating PSN associated with the source node is less than the expected incoming PSN associated with the destination node, rejecting the first connection by sending a negative acknowledgement packet with a valid PSN to the source node; and A new connection request packet is received indicating the valid PSN as the originating PSN associated with the source node.

16. The computer system of claim 14, wherein: The valid PSN includes at least one of the following: the current value of the expected incoming PSN associated with the destination node; or The maximum starting PSN across all open connections on the destination node is incremented by one.

17. The computer system according to claim 13, in, the starting PSN for a respective connection between a pair of nodes is unique to a key and is not reused for subsequent connections between the pair of nodes for the key, and The instructions are further for maintaining, by the corresponding node, a starting PSN associated with the corresponding node and an expected incoming PSN associated with the corresponding node, wherein the starting PSN and the expected incoming PSN include the same initial value on all nodes that have installed the encryption key.

18. The computer system of claim 13, wherein the instructions are further configured to: determining that a maximum originating PSN across all open connections on the destination node is greater than the expected incoming PSN associated with the destination node; determining whether to send the maximum starting PSN incremented by one as the expected incoming PSN included in the close response message based on one or more conditions; and The maximum starting PSN is incremented by one and included as the expected incoming PSN in the close response message to the source node.

19. A non-transitory computer-readable medium storing instructions for: receiving, by the destination node, a first connection request packet indicating a starting packet sequence number (PSN) associated with the source node; accepting, by the destination node, a first connection corresponding to the first connection request packet in response to the originating PSN being valid; and In response to the source node closing the first connection: setting, by the destination node, an expected incoming PSN associated with the destination node to the greater of a current value of the expected incoming PSN and the starting PSN associated with the source node incremented by one; sending, by the destination node to the source node, a close response message including the expected incoming PSN; and The source node is allowed to set the starting PSN to the greater of the current value of the starting PSN incremented by one and the expected incoming PSN associated with the destination node.

20. The non-transitory computer readable medium of claim 19, the instructions further configured to: In response to the originating PSN associated with the source node being greater than or equal to the expected incoming PSN associated with the destination node, accepting the first connection; and in response to the originating PSN associated with the source node being less than the expected incoming PSN associated with the destination node, rejecting the first connection by sending, by the destination node, a negative acknowledgment packet with a valid PSN to the source node, in, In response to the source node closing the first connection, the instructions are further configured to: The destination node sends the close response message to the source node, including the maximum starting PSN of all open connections on the destination node increased by one, wherein the expected incoming PSN associated with the destination node comprises the maximum starting PSN incremented by one; and The source node is allowed to set the starting PSN associated with the source node to the maximum starting PSN included in the close response message sent to the source node, incremented by one.

Images