Enhanced high availability for group VPN in broadcast environment

A light-weight resilient mechanism is used to synchronize server secure keying data with member devices in a highly-scalable distributed group virtual private network (VPN). A server device generates an initial secure keying data set, for the VPN, that includes a first version identifier, and sends, to member devices and via point-to-point messages, the secure keying data set. The server device sends, to the member devices, heartbeat push messages including the first version identifier. The server device generates an updated secure keying data set with a second version identifier and sends, to the member devices, a key push message that includes the updated data set. The server device sends, to the member devices, heartbeat push messages including the second version identifier. Member devices may use the first and second version identifiers to confirm that secure keying data sets are current and quickly identify if updates are missed.

BACKGROUND

A typical VPN (Virtual Private Network) is a network of point-to-point tunnels, where a tunnel is a security association (SA) between two security devices. A security key for the SA is negotiated between two tunnel end devices. Tunnel encapsulation adds an outer header that hides the original source and destination IP addresses. Multicast traffic is replicated and encapsulated before entering into tunnels and treated like unicast traffic within the core network. This architecture is not optimal for multicast traffic, and is not scalable for large deployment.

Group VPNs have been developed that extend current Internet Protocol Security (IPsec) architecture to support group-shared SAs. The center of a group VPN includes a group server, which can be a cluster of servers.

SUMMARY

In one implementation, a method performed by a server device may include receiving, by the server device and from a member device, a registration request for a group virtual private network (VPN); generating, by the server device, an initial secure keying data set, where the secure keying data set includes an initial version identifier; and sending, by the server device and to the member device, the initial secure keying data set with the initial version identifier. The method may further include generating, by the server device, an updated secure keying data set with an updated version identifier; sending, by the server device and to the member device, a key multicast push message including the updated secure keying data set with the updated version identifier; and sending, by the server device and to the member device, one or more heartbeat multicast push messages including the updated version identifier. The method may also include receiving, by the server device and from the member device, another registration request for the group VPN based on detection of a missing key push message or one or more missing heartbeat push messages.

In another implementation, a device may include a memory to store instructions and a processor. The processor may execute instructions in the memory to send, to a member device via a point-to-point message (e.g., upon member device registration), an initial secure keying data set for a group VPN that includes a first version identifier; send, to the member device, one or more heartbeat multicast push messages that include the first version identifier; generate an updated secure keying data set with a second version identifier; send, to the member device, a key multicast push message that includes the updated secure keying data set with the second version identifier; and send, to the member device, one or more heartbeat multicast push messages that include the second version identifier.

In a further implementation, a computer-readable memory having computer-executable instructions may include one or more instructions to generate an initial secure keying data set for a group VPN, where the secure keying data set includes a first version identifier; one or more instructions to send, to member devices of the group VPN via point-to-point messages (e.g., upon member device registration), the secure keying data set with the first version identifier; and one or more instructions to send, to the member devices, one or more heartbeat multicast push messages that include the first version identifier. The instructions may include one or more instructions to generate an updated keying data with a second version identifier; one or more instructions to send, to the member devices, a key multicast push message that includes the updated keying data with the second version identifier; and one or more instructions to send, to the member devices, one or more heartbeat multicast push messages that include the second version identifier.

In still another implementation, a method performed by a member device may include sending, by the member device and to a server device, a registration request for a group VPN; receiving, by the member device and from the server device, an initial secure keying data set, where the initial secure keying data set includes an initial version identifier; and receiving, by the member device and from the server device, a key push message including an updated secure keying data set with an updated version identifier. The method may further include comparing, by the member device, the updated version identifier with the initial version identifier; discarding, by the member device, the updated secure keying data set in the key push message when the updated version identifier has an equal or lower value than the initial version identifier; applying, by the member device, the updated secure keying data set when the updated version identifier is a next increment higher than the initial version identifier; and sending, by the member device and to the group server, another registration request for the group VPN when the updated version identifier is more than one increment higher than the initial version identifier or a generation identifier is different.

DETAILED DESCRIPTION

Systems and/or methods described herein may provide a mechanism for providing enhanced high availability for members in a group VPN. The systems and/or methods may employ version identifiers for a secure keying data set associated with the group VPN. The version identifiers may be changed each time a group VPN server updates the secure keying data set. The version identifiers may be distributed to the group VPN members with the updated data sets and, also, as part of periodic heartbeat messages. Member devices may compare version identifiers of currently stored data sets with version identifiers in the heartbeat messages to determine, for example, if the member device has a current secure keying data set.

FIG. 1is diagram of an example network100in which systems and methods described herein may be implemented. Network100may include one or more group servers110(referred to herein generically and singularly as “group server110”) and one or more member devices120(referred to herein generically and singularly as “member device120”) interconnected by a network130. Group server(s)110and member device(s)120may connect via wired and/or wireless connections. Group server(s)110and member device(s)120may be connected within a group virtual private network (VPN)140.

Group server110may include one or more server devices, or other types of computation or communication devices, that gather, process, search, store, and/or provide information in a manner similar to that described herein. For example, group server110may host an interface application that may be used to form group VPN140with member devices120. Group server110may manage secure keys and policies for group VPN140. Group server110may distribute the secure keys to member devices120and may implement procedures to ensure that secure keying updates sent from group server110are correctly received by member devices120. In one implementation, group server110may include redundancy support, such that when one group server110goes down, a backup group server110may continue to provide services for group VPN140.

Member device120may include any device that is capable of communicating with group server110and/or another member device120via network130. For example, member device120may include a laptop computer, a personal computer, a set-top box (STB), a gaming system, a personal communications system (PCS) terminal (e.g., that may combine a cellular radiotelephone with data processing and data communications capabilities), a personal digital assistant (PDA) (e.g., that can include a radiotelephone, a pager, Internet/intranet access, etc.), a wireless device (e.g., a wireless telephone), a cellular telephone, a smart phone, other types of mobile communication devices, a global positioning system (GPS) device, a content recording device (e.g., a camera, a video camera, etc.), a vehicular computing and/or communication device, etc. In one implementation, member device120may be capable of receiving (e.g., from group server110) push messages, such as multicast push messages or unicast push messages, that include updates to secure keying data. Member device120may also be capable of implementing policies to manage activation and/or confirm relevance of secure keying data. Member devices120may be referred to as group VPN members.

Network130may include a local area network (LAN), a wide area network (WAN), a metropolitan area network (MAN), a telephone network, such as the Public Switched Telephone Network (PSTN) or a cellular network, the Internet, an intranet, other networks, or a combination of networks.

Group VPN140may be implemented using security association protocols that use secure keys to permit communications among multiple group VPN members (e.g., member devices120) and between group servers110and multiple group VPN members (e.g., member devices120). In one implementation, with some properietary extension, group VPN140may use the Group Domain of Interpretation (GDOI) protocol specified in IETF RFC 3547 to encode messages between server and members. To maintain a secure communications within group VPN140, the secure keys may be changed (e.g., “re-keyed”) occasionally.

In implementations described herein, the re-keying sequence may be accomplished among group server110and member devices120in a manner that provides reduced risk of disruption to communications within group VPN140. Group servers110and member devices120may employ a light-weight resilient mechanism to synchronize secure keying data (e.g., from group server110) with member devices120in a highly-scalable, distributed group VPN (e.g., group VPN140). Instead of handling individual replies (e.g., ACK messages) from member devices120, implementations described herein may trigger member devices120to re-register with group server110when secure keying data is deemed not current or missing. By handling the exceptions (e.g., when member devices120identify a missing update), the performance of group server110may be improved and network resources may be better utilized while enhancing the availability of VPN140.

AlthoughFIG. 1shows example devices of network100, in other implementations, network100may include fewer devices, different devices, differently arranged devices, and/or additional devices than those depicted inFIG. 1. Alternatively, or additionally, one or more devices of network100may perform one or more other tasks described as being performed by one or more other devices of network100. For example, a device may function as both a group server110and a member device120.

FIG. 2is a block diagram of an example device200, which may correspond to one of group server110and/or member device120. As shown, device200may include a bus210, a processor220, a main memory230, a read only memory (ROM)240, a storage device250, an input device260, an output device270, and a communication interface280. Bus210may include a path that permits communication among the elements of the device.

Processor220may include a processor, microprocessor, or processing logic that may interpret and execute instructions. Main memory230may include a random access memory (RAM) or another type of dynamic storage device that may store information and instructions for execution by processor220. ROM240may include a ROM device or another type of static storage device that may store static information and instructions for use by processor220. Storage device250may include a magnetic and/or optical recording medium and its corresponding drive.

Input device260may include a mechanism that permits an operator to input information to the device, such as a keyboard, a mouse, a pen, voice recognition and/or biometric mechanisms, etc. Output device270may include a mechanism that outputs information to the operator, including a display, a printer, a speaker, etc. Communication interface280may include any transceiver-like mechanism that enables the device to communicate with other devices and/or systems.

As will be described in detail below, device200may perform certain operations relating to time-based secure key synchronization. Network device200may perform these operations in response to processor220executing software instructions contained in a computer-readable medium, such as main memory230. A computer-readable medium may be defined as a physical or logical memory device. A logical memory device may include memory space within a single physical memory device or spread across multiple physical memory devices. The software instructions may be read into main memory230from another computer-readable medium, such as data storage device250, or from another device via communication interface280. The software instructions contained in main memory230may cause processor220to perform processes that will be described later. Alternatively, hardwired circuitry may be used in place of or in combination with software instructions to implement processes described herein. Thus, implementations described herein are not limited to any specific combination of hardware circuitry and software.

AlthoughFIG. 2shows example components of device200, in other implementations, device200may include fewer components, different components, differently arranged components, or additional components than depicted inFIG. 2. As an example, in some implementations, input device260and/or output device270may not be implemented by device200. In these situations, device200may be a “headless” device that does not explicitly include an input or an output device. Alternatively, or additionally, one or more components of device200may perform one or more other tasks described as being performed by one or more other components of device200.

FIG. 3is a block diagram of example functional components of group server110. In one implementation, the functions described in connection withFIG. 3may be performed by one or more components of device200(FIG. 2). As illustrated, group server110may include a key generator300and a key distribution manager310.

Group server110may distribute two types of secure keys to member devices120: a key encapsulation key (KEK) and a traffic encapsulation key (TEK). A KEK may be used to protect messages between group server110and member devices120. A TEK may be used to protect messages sent between any two member devices120. A TEK may also be used to protect multicast/broadcast messages from one member device120to many other member devices120. If a KEK is not used, group server110cannot send any new KEKs and/or TEKs (secured by existing KEK) to member devices120when the existing ones expire. Group server110would then rely on member device120to re-register to obtain a new KEK and/or TEK.

Key generator300may generate and provide secure keying data (e.g., KEKs, TEKs, and related configuration data) to member devices120. Key generator300may generate secure keying data based on, for example, request/instruction from key distribution manger310or another device. Secure keys, such as KEKs and TEKs, may include any type of content that may be used as a key. For example, key generator300may provide secure keys that include a sequence of random alpha-numeric characters. Key generator300may also provide updates/changes to secure keying data based on, for example, configuration changes, expiration of existing keys, signals from key distribution manger, etc.

The configuration data for the secure keys may include, for example, expiration periods for the secure keys, heartbeat criteria, version identifiers, and/or generation identifiers. Each of the expiration periods for the secure keys, the heartbeat criteria, the version identifiers, and the generation identifiers will now be described. The expiration periods may include a time period that a KEK to TEK is to remain active for group VPN140.

The heartbeat criteria may include configurable values for periodic signals, referred to as a heartbeat, that may be used to ensure connectivity. Heartbeat criteria may include, for example, an expected signal interval (e.g., every 20 seconds) and a number of consecutive missed heartbeats (e.g., three) that can indicate a connection issue. In one implementation, heartbeat messages may be implemented using a variation of GDOI protocols specified in IETF RFC 3547.

The version identifiers may include version information for a particular secure keying data set. In implementations described herein, each secure keying data set created by key generator300may be distinguished by a server key version identifier (SKVID). The SKVID may be applicable to a particular group VPN140and may that indicate updates/changes have occurred to a secure keying data set. The SKVID may include a number, time-stamp, alpha-numeric sequence, or another type of indicator that may be used to represent a progression. For example, when the key generator300generates an initial keying data set (e.g., KEK, TEK, and configuration data) for a given group VPN140, the SKVID may be set to “1.” After the initial keying data set is created, key generator300may increment the SKVID (e.g., to “2,” “3,” etc.) whenever any piece of data in the initial data set is changed, added, or deleted. A change in the keying data set could be triggered by, for example, a KEK or TEK rekey (e.g., when an existing secure key is close to expiration and new key is generated) and/or configuration changes (e.g., a new policy is added or removed; or some secure parameter, such as a certificate or password, is changed).

The generation identifier may include information to supplement the SKVID. In implementations herein, the generation identifier may be included as part of the SKVID or set apart as a separate identifier. The generation identifier may include a value that is different after each reboot of group server110. In other words, each generation identifier may be associated with a particular re-boot event of group server120. Thus, the generation identifier may help member devices120to compare a received SKVID with its most recent SKVID during, for example, a re-registration process. For example, if group server120resets an SKVID back to 1 after each re-boot, a member device may distinguish between an older SKVID and a new SKVID with the same version number based on the generation identifier.

In one implementation, the generation identifier may be a randomly generated number. In another implementation, the generation identifier may be a number externally stored in some form of permanent storage (e.g., main memory230or storage device250) that is incremented every time that group server110reboots. In some implementations, the generation identifier may be an optional element.

In one implementation, updates/changes to secure keying data from key generator300may include only new/changed information from the initial secure keying data. Because member devices120can detect any missing pushed data from group server110, key generator300may send the difference (or delta) between the expiring secure keying data and the updated secure key data. For example, instead of the complete secure keying data set (e.g., including all policies, corresponding keys, and other data), key generator300may include as updates only portions that have been changed. For instance, if there is only one out of many TEKs that are about to expire, un-expired keys and their policies would not have to be included in the updated secure keying data set.

Key distribution manager310may distribute secure keying data sets to enable uninterrupted communications between group server110and member devices120and/or between member devices120. Key distribution manager310may also manage re-transmissions of the secure keying data set. Key distribution manager310may distribute initial secure keying data sets to member devices120as part of a group VPN registration. For example, key distribution manager310may provide initial secure keying data to member device120as a point-to-point message (e.g., as a pull reply in response to a pull request from member device120). Key distribution manager310may then provide updates to the secure keying data sets via multicast messages (e.g., KEK-encrypted multicast push messages). Key distribution manager310may distribute secure keying data sets, as generated by key generator300, whenever key generator300provides a secure keying data set with a new SKVID. For example, key distribution manager310may initiate a TEK and/or KEK re-key sequence for group VPN140, based on an upcoming expiration time for an existing TEK or KEK. As another example, key distribution manager310may provide a secure keying data set based on a configuration change.

Key distribution manager310may also provide heartbeat messages (e.g., at configured intervals) that include the SKVID and/or generation identifier for the current (e.g., most recently pushed) secure keying data set. Generally, key distribution manager310may initially provide secure keying data sets to member devices120using a point-to-point connection (e.g. a pull request/response) as part of a group VPN registration (or re-registration) process. Subsequent updates to the secure keying data sets and/or heartbeats may be simultaneously sent via a multicast push message to multiple member devices120.

AlthoughFIG. 3shows example functional components of group server110, in other implementations, group server110may include fewer functional components, different functional components, differently arranged functional components, or additional functional components than depicted inFIG. 3. Alternatively, or additionally, one or more functional components of group server110may perform one or more other tasks described as being performed by one or more other components of group server110.

FIG. 4is a block diagram of example functional components of a member device120. In one implementation, the functions described in connection withFIG. 4may be performed by one or more components of device200(FIG. 2). As illustrated, member device120may include a push key distribution client400and a heartbeat monitor410.

Key distribution client400may manage re-key sequencing for a member device120. Key distribution client400may receive an initial secure keying data set (e.g., with a SKVID and/or generation identifier) from key distribution manager310upon registration for group VPN140. After registration, when receiving a multicast push message (e.g., from key distribution manager310) with a new secure keying data set, key distribution client400may compare the SKVID of the new secure keying data set with the SKVID of the initial (or most recently received) secure keying data set. If the new SKVID is equal to or older than the one key distribution client400already has, key distribution client400may discard the new secure keying data set, as it may be a retransmission from group server110or obsolete data struck in the network (e.g., network130). If the new SKVID is newer than the one key distribution client400already has, key distribution client400may cause member device120to act on the new secure keying data set. Performing this check of SKVIDs may prove especially useful when the normal behavior is to send multiple copies of the secure keying data set push message (e.g., pushed from group server110to member devices120in an unacknowledged multicast scenario). The check would not only save resource of member devices120to process the message but also make the process more robust.

Heartbeat monitor410may monitor heartbeat messages from group server110. More particularly, heartbeat monitor410may monitor the frequency of received heartbeat messages (e.g., based on configuration settings, such as the heartbeat criteria, from group server110) and the SKVID/generation identifier for each heartbeat message. For example, when heartbeat monitor410misses some configurable number of heartbeats, heartbeat monitor410may cause member device120to re-register with group server110to get a copy of the latest secure keying data set. When heartbeat monitor410receives a heartbeat message from group server110, heartbeat monitor410may also compare the SKVID number in the heartbeat message with the most recent SKVID (e.g., from the most recent secure keying data set). If the SKVID in the heartbeat message is of higher (e.g., more recent) value, heartbeat monitor410may determine that the member device120has missed a push update from group server110. Heartbeat monitor410may then trigger a re-registration to get the latest data set from group server110. In all cases, member devices120will not need to reply (e.g., via an ACK message) to the heartbeat message received from group server110. Thus, accuracy/currency of secure keying data sets may be monitored while reducing the load on group server110.

AlthoughFIG. 4shows example functional components of member device120, in other implementations, member device120may include fewer functional components, different functional components, differently arranged functional components, or additional functional components than depicted inFIG. 4. Alternatively, or additionally, one or more functional components of member device120may perform one or more other tasks described as being performed by one or more other components of member device120.

FIG. 5is a diagram of example interactions among components of an example portion500of network100. As illustrated, example network portion500may include group server110and two member devices120(referred to individually inFIG. 5as member device120-1and member device120-2). Group server110and member devices120may include the features described above in connection with, for example,FIGS. 1-4.

As further shown inFIG. 5, member device120-1and member device120-2may each conduct a separate registration process (e.g., to register as part of group VPN140) with group server110, as indicated by reference numbers510. As part of the registration process, group server110may receive an initial pull request from each member device120-1and120-2and separately provide initial secure keying data (e.g., a KEK, TEKs with configuration data) to each member device120-1and120-2. In implementations described herein, the initial secure keying data set may include a version identifier (e.g., a SKVID) and, optionally, a generation identifier for the secure keying data set.

After the initial registration process between group server110and member devices120, group server110may provide a secure keying update520for the secure keying data set using push messages (e.g., multicast push messages to all member devices120of group VPN140, including each of member devices120-1and120-2). Securing keying update520may include an updated secure keying data set with a different version identifier (e.g., SKVID) and/or a different generation identifier. Assume, as shown inFIG. 5, that member device120-1successfully receives secure keying update520and that member device120-2does not receive secure keying update520.

Group server110may also provide heartbeats530to member devices120using, for example, multicast push messages. For example, in one implementation, member devices120may not be required to acknowledge receipt of heartbeats530. Heartbeats530may be KEK-encrypted and may include a SKVID that corresponds to the most recent secure keying data set provided by group server110(e.g., the same SKVID as provided in secure keying update520). In one implementation, heartbeats530may also include a generation identifier. Assume, as shown inFIG. 5, that member device120-2successfully receives heartbeat530and that member device120-1does not receive heartbeats530.

In the example ofFIG. 5, member device120-1may receive secure keying update520and compare the SKVID in secure keying update520with the SKVID from the initial secure keying data set. Since the SKVID in secure keying update520will have a higher value than the SKVID from the initial secure keying data set, member device120-1may act on the information in secure keying update520. If, as shown inFIG. 5, member device120-1receives heartbeats530after receiving secure keying update520, heartbeats530received by member device120-1will have the same SKVID as the SKVID stored in member device120-1(e.g., the SKVID from secure keying update520). As long as the SKVID in heartbeats530matches (or is lower than) the SKVID stored in member device120-1, member device120-1may take no action based on heartbeats530.

Because, in the example ofFIG. 5, member device120-2did not receive secure keying update520, heartbeats530received by member device120-2will have a different (e.g., higher) SKVID than the SKVID stored in member device120-2(e.g., the SKVID from the initial secure keying data set). Member device120-2may receive one of heartbeats530and may compare the SKVID in heartbeat530with the SKVID from the initial secure keying data set. Since the SKVID in heartbeats530will have a higher value than the SKVID from the initial secure keying data set, member device120-2may initiate re-registration540with group server110to obtain the current secure keying data set from group server110(e.g., via a pull request/response). Similarly, if member device120-2fails to receive heartbeat message for a consecutive number of intervals (not shown), member device120-2may also initiate re-registration540with group server110to obtain the current secure keying data set from group server110.

AlthoughFIG. 5shows example components of network portion500, in other implementations, network portion500may include fewer components, different components, differently arranged components, and/or additional components than depicted inFIG. 5. Alternatively, or additionally, one or more components of network portion500may perform one or more other tasks described as being performed by one or more other components of network portion500.

FIG. 6is a flow diagram illustrating an example process600for providing secure keying updates to a member device according to an implementation described herein. In one implementation, process600may be performed by group server110. In another implementation, process600may be performed by another device or group of devices including or excluding group server110.

Process600may include generating an initial secure keying data set with an initial version identifier (ID) and/or generation identifier (block610), receiving, from a member device, a group VPN registration request (block620), and sending, to the member device, the initial secure keying data set with the initial version identifier and/or generation identifier (block630). For example, as referring to communications inFIG. 5, member device120may conduct a registration process (e.g., to register as part of group VPN140) with group server110, as indicated by reference numbers510. As part of the registration process, group server110may receive an initial pull request from member device120and may separately provide initial secure keying data (e.g., a KEK, TEKs with configuration data) to member device120. In implementations described herein, the initial secure keying data set may include a version identifier (e.g., a SKVID) and, optionally, a generation identifier for the secure keying data set. The SKVID may be applicable to a particular group VPN140and may that indicate updates/changes have occurred to a secure keying data set.

Process600may further include obtaining an update for the initial secure keying data set and changing the version identifier and/or the generation identifier (block640), and sending, via a key push message, the update for the initial secure keying data set with the changed version identifier and/or the generation identifier (block650). For example, group server110(e.g., key generator300) may also provide updates/changes to a secure keying data set based on, for example, configuration changes, expiration of existing keys, signals from key distribution manger310or another device, etc. Configuration data for the updated secure keying data set may include a version identifier and/or generation identifier. Group server110(e.g., key distribution manager310) may provide the updates to the secure keying data sets (e.g., secure keying update520ofFIG. 5) via a key push message (e.g., KEK-encrypted multicast push messages). Key distribution manager310may distribute updated secure keying data sets, as generated by key generator300, whenever key generator300provides a secure keying data set with a new SKVID.

Heartbeats with the updated version identifier and/or generation identifier may be sent via a heartbeat push message (block660) and a re-registration request, from the member device, may be received based on one or more of missed heartbeats, a version identifier mismatch or a generation identifier mismatch (block670). For example, group server110(e.g., key distribution manager310) may provide heartbeat messages (e.g., at configured intervals) that include the SKVID and/or generation identifier for the current (e.g., most recently pushed) secure keying data set. Heartbeat messages (e.g., heartbeats530ofFIG. 5) may be simultaneously sent via a heartbeat multicast push message to multiple member devices120. Member devices120may receive secure keying update520and/or heartbeats530. If the generation identifier in secure keying update520or the SKVID in heartbeats530have a different/higher value than the generation identifier or SKVID from the initial secure keying data set, member device120may initiate re-registration540with group server110to obtain the current secure keying data set from group server110(e.g., via a pull request/response). Similarly, if a member device120fails to receive heartbeats signal for a particular consecutive number of intervals, member device120may also initiate re-registration540with group server110to obtain the current secure keying data set from group server110.

FIG. 7is a flow diagram illustrating an example process700for enacting secure keying updates from a server according to an implementation described herein. In one implementation, process700may be performed by member device120. In another implementation, process700may be performed by another device or group of devices including or excluding member device120.

Process700may include registering with a server for a group VPN (block705), and receiving, from the server, an initial secure keying data set with an initial version identifier (ID) and/or generation identifier (block710). For example, member device120(e.g., key distribution client400) may receive an initial secure keying data set (e.g., with a SKVID and/or generation identifier) from group server110(e.g., key distribution manager310) upon registration for group VPN140.

Process700may include monitoring heartbeat messages from the server (block715), and determining if a number of missed heartbeats exceeds a threshold value (block720). For example, member device120(e.g., heartbeat monitor410) may monitor heartbeat messages from group server110. More particularly, heartbeat monitor410may monitor the frequency of received heartbeat messages (e.g., based on configuration settings, such as the heartbeat criteria, from group server110). Heartbeat criteria may include, for example, an expected signal interval (e.g., every 20 seconds) and a number of consecutive missed heartbeats (e.g., three) that can indicate a connection problem.

If the monitoring results in detection of a number of missed heartbeats over a threshold value (block720—YES), process700may return to block705to register with the server. When a new secure keying data set from group server110is received (e.g., based on the registration initiated due to the missed heartbeats), member device120may compare its current SKVID/generation identifier with that in the newly received data. If they are the same, member device120may determine that member device120may has missed some heartbeats but that the secure keying data set from group server120has not been changed. In this case, member120may simply drop the new secure keying data set. Otherwise, it will smoothly transition to use the new secure keying set data.

If the monitoring does not result in detection of a number of missed heartbeats over a threshold value (block720—NO), it may be determined if one of the heartbeats includes a new version identifier (block725). For example, when member device120(e.g., heartbeat monitor410) misses some configurable number of heartbeats, heartbeat monitor410may cause member device120to re-register with group server110to get a copy of the latest secure keying data set. When heartbeat monitor410receives a heartbeat message from group server110, heartbeat monitor410may compare the SKVID number in the heartbeat message with the most recent SKVID (e.g., from the most recent secure keying data set).

If one of the heartbeats includes a new version identifier (block725—YES), process700may return to block705to register with the server. If none of the heartbeats includes a new version identifier (block725—NO), process700may include receiving, via a key push message from the server, an update for the secure keying data set with an updated version identifier and/or generation identifier (block730). For example, if the SKVID in the heartbeat is of higher (e.g., newer) value, member device120(e.g., heartbeat monitor410) may determine that the member device120has missed a push update from group server110. Member device120may then trigger a re-registration to get the latest secure keying data set from group server110. Member device120(e.g., key distribution client400) may receive a key multicast push message (e.g., from key distribution manager310of group sever110) with a new secure keying data set. The new secure keying data set may include new SKVID and/or generation ID corresponding to the new secure keying data set.

If the updated generation identifier is different than the initial generation identifier (block735—YES), process700may return to block705to register with the server. If the updated generation identifier is not different than the initial generation identifier (block735—NO), it may be determined if the updated version identifier is newer than the initial version identifier (block740). For example, if the generation identifier is included as part of the SKVID, member device120(e.g., key distribution client400) may compare the generation identifier portion of the SKVID of the new secure keying data set with the generation identifier portion of the SKVID of the initial (or most recently received) secure keying data set. If the generation identifier is included as a separate identifier in the secure keying data set, member device120may compare the separate generation identifier of the new secure keying data set with the separate generation identifier of the initial (or most recently received) secure keying data set. If the new generation identifier and the initial generation identifier are different, member device120may recognize that a reboot of group server110has occurred and re-register with group server110. Otherwise, member device110may examine the SKVID (e.g., the version identifier portion). Under normal circumstances, the generation identifier received in the key push message and the heartbeat push message (protected by a KEK) will not be different from the values stored in member device120. This is because the key push message and heartbeat push message are protected by a KEK. If group server120reboots, a new KEK may be generated in additon to the new generation identifier. When the new KEK is used, member devices120would not be able to decode the key push message and/or heartbeat push message received from the rebooted group server110until member120re-registers with group server110.

If the updated version identifier is newer than the initial version identifier (block740—NEWER), it may be determined if the newer version identifier is higher by a single increment (block745). If the newer version identifier is not higher by a single increment (block745—NO), process700may return to block705to register with the server. If the newer version identifier is higher by a single increment (block745—YES), process700may include acting on the updated secure keying set (block750). If the updated version identifier is not newer than the initial version identifier (block740—EQUAL/OLDER), process700may include discarding the updated secure keying set (block755).

For example, if the new SKVID is one increment higher than the SKVID that key distribution client400already has, key distribution client400may cause member device120to act on the new secure keying data set. If the new SKVID is more than one increment higher, key distribution client400, recognizing that a previous secure keying data set update has been missed, may re-register with group server110. If the new SKVID is equal to or older than the one member device120already has, member device120may discard the new secure keying data set, as it may be a retransmission from group server110or obsolete data struck in the network (e.g., network130).

In the systems and/or methods described herein, a server device may generate an initial secure keying data set for a group VPN, where the secure keying data set includes a first version identifier, and may send, to member devices of the group VPN and via multiple point-to-point messages, the secure keying data set with the first version identifier. The server device may later send, to the member devices, one or more heartbeat multicast push messages that include the first version identifier. The server device may later generate an updated secure keying data set with a second version identifier and may send, to the member devices, a key multicast push message that includes the updated secure keying data set with the second version identifier. The server device may then send, to the member devices, one or more heartbeat multicast push messages that include the second version identifier.

The systems and/or methods described herein may provide an easily scalable secure key synchronization mechanism. In a large network with multicast support, updated keying data and heartbeats with version identifiers may be efficiently multicast to all group VPN members, potentially a configurable number of times, without the need for acknowledgements from each member device. Thus, the systems and/or methods may significantly reduce the load on the group server to handle all individual replies from member devices and schedule retransmissions.

The systems and/or methods may enhance availability of the group VPN support by providing resilience against missing new secure keying data when there is network disruption between server and members. A member may detect that it missed newly changed keying data from the server, and trigger re-registration to the server to get the latest keys/data. Also, members may detect that the server may have rebooted, and, thus, the members would need to re-register to the server to get the newly generated keys/data from the recovered server. Furthermore, instead of sending a complete keying data set with each update, the server may preserve network resources by pushing only the difference (or delta) between past secure keying data and updated secure key data.

For example, while implementations are described herein primarily in the context of multicast push messages, in other implementations, the system and/or methods described herein may be applied with unicast push messages to allow member devices, for example, to promptly detect a server reboot.

In another example, implementation may not include a generation identifier. If, for example, a member device may be configured to compare an SKVID number only when it receives pushed data or heartbeats from the group server, and/or ignore the SKVID number when it re-registers to the group server and compare its complete secure keying data received. Under such conditions, use of a generation number may be optional, as pushed server data and heartbeats from a newly rebooted server would not be decrypted by members which have not re-registered to the server (since server's reboot) and employed an old KEK key.

As a further example, while series of blocks have been described with respect toFIGS. 6 and 7, the order of the blocks may be varied in other implementations. Moreover, non-dependent blocks may be implemented in parallel.

It will be apparent that embodiments, as described herein, may be implemented in many different forms of software, firmware, and hardware in the implementations illustrated in the figures. The actual software code or specialized control hardware used to implement embodiments described herein is not limiting of the invention. Thus, the operation and behavior of the embodiments were described without reference to the specific software code—it being understood that software and control hardware may be designed to implement the embodiments based on the description herein.

Further, certain implementations described herein may be implemented as a “component” that performs one or more functions. This component may include hardware, such as a processor, microprocessor, an application specific integrated circuit, or a field programmable gate array; or a combination of hardware and software.

Even though particular combinations of features are recited in the claims and/or disclosed in the specification, these combinations are not intended to limit the disclosure of the invention. In fact, many of these features may be combined in ways not specifically recited in the claims and/or disclosed in the specification.