Claims:
1. A method for sequence number synchronization in a system (100) having at least one access point (102) and at least two access controllers (104, 106) viz., an active access controller (104) and a standby access controller (106), comprising:
negotiating/ synchronizing (1004) a sequence number between said standby access controller and said access point using a Datagram Transport Layer Security (DTLS) protocol transmitted as a Datagram Transport Layer Security (DTLS) sequence number synchronization message based on prior negotiation of DTLS sequence number synchronization extension to resume current communication session without a new DTLS handshake.

2. A method for sequence number synchronization using a message exchange in a system (100) having at least one access point (102) and at least two access controllers (104, 106) viz., an active access controller(104) and a standby access controller (106), comprising:
synchronizing (1102) periodically a connection state and associated session key parameters between said active access controller and said standby access controller;
after said active access controller fail / in an event of failover:
negotiating/ synchronizing (1104) a sequence number between said standby access controller and said access point using a Datagram Transport Layer Security (DTLS) protocol transmitted as a Datagram Transport Layer Security (DTLS) sequence number synchronization message based on prior negotiation of DTLS sequence number synchronization extension to resume current communication session without a new DTLS handshake.

3. The method as claimed in claims1 or2, wherein, before negotiating/ synchronizing said sequence number, said active access controller and said access point are configured to intimate the capability of supporting said DTLS sequence number synchronization message by:
negotiating/ synchronizing said sequence number between said active access controller and said access point during initial DTLS handshake by including a “dtls_seq_num_sync” extension in a client hello message by said access point to intimate said capability to said active access controller, and if
said active access controller is capable of supporting said sequence number synchronization, said active access controller is configured to include the same “dtls_seq_num_sync” extension in response to said hello message.

4. The method as claimed in claims 1 or 2, wherein said Datagram Transport Layer Security (DTLS) protocol comprises at least three sequence number synchronization messages selected from a DTLS Synchronous Sequence Request, a DTLS Synchronous Sequence Response, and a DTLS Synchronous Sequence Acknowledgement.

5. The method as claimed in claim 3, comprises, transmitting said three sequence number synchronization messages in an encrypted form, wherein said three messages comprises:
a message type field of 1 byte, to represent the DTLS Synchronous Sequence Request, the DTLS Synchronous Sequence Response, or the DTLS Synchronous Sequence Acknowledgement;
a server sequence number field of 6 bytes;
a client sequence number field of 6 bytes;
a random number of 32 byte; and
a padding length field as per encryption algorithm.

6. The method as claimed in claims1, 2 or3, wherein, after said active access controller fails/ in an event of failover, said method comprises:
selecting at least two sequence number by said standby access controller, ;
transmitting, by said standby access controller, said two sequence number to said access point, using at least one DTLS Synchronous Sequence Request message;
receiving, by said access point, said DTLS Synchronous Sequence Request message with said two sequence number, wherein said DTLS Synchronous Sequence Request message indicates said active access controller fail/ an event of failover; thereby
processing, by said access point, said DTLS Synchronous Sequence Request message to confirm if said sequence number received in said DTLS Synchronous Sequence Request message is acceptable;
transmitting, by said access point, said sequence number received, if acceptable, to said standby access controller, using at least one DTLS Synchronous Sequence Response; and
receiving, by said standby access controller, said DTLS Synchronous Sequence Response, if not, terminating said current communication session, or transmitting at least one DTLS Synchronous Sequence Acknowledgement message to said access point.

7. The method as claimed in claims 1 or 2, comprises, maintaining, by said access point and by said standby access controller, a time using a retransmission timer configured to retransmit at least one sequence number synchronization message selected from said three sequence number synchronization messages.

8. The method as claimed in claims 1, 2 or 3, wherein, after said active access controller fails, said method comprises:
transmitting, by said standby access controller, a sequence number starting with value as one to said access point using at least one DTLS Synchronous Sequence Request message.

9. The method as claimed in claims 1, 2 or 4, wherein, said standby access controller is configured to cache said DTLS Synchronous Sequence Acknowledgement message and re-transmit said DTLS Synchronous Sequence Acknowledgement message if said (same) DTLS Synchronous Sequence Response are received from said access point.

10. The method as claimed in claims 1 or 2, wherein said Datagram Transport Layer Security (DTLS) sequence number synchronization extension is a “hello” message having a syntax “dtls_seq_num_sync”.

11. The method as claimed in claims 1 or 2, wherein, said negotiating/synchronizing sequence number between said standby access controller and said access point is achieved if said standby access controller and said access point supports said Datagram Transport Layer Security (DTLS) sequence number synchronization i.e., “dtls_seq_num_sync”.

12. The method as claimed in claims 1 or 2, comprises, checking, if said standby access controller and said access point supports sequence number synchronization, by negotiating/sharing a Datagram Transport Layer Security (DTLS) sequence number synchronization extension in a “hello” message having a syntax “dtls_seq_num_sync”.

13. A computing device, having the connection state information and the session key parameters associated with the connection, the computing device comprising:
a memory; and
a processor configured by instructions retrieved from the memory, while operating in a standby mode, to:
receive at least one indication indicating a switchover;
initiate a handshake mechanism, with at least one peer device for sequence number negotiation, using at least one synchronization protocol by:
generating at least two sequence numbers;
transmitting the two sequence numbers to the peer devices using at least one synchronization request message;
receiving at least one synchronization response message with at least a sequence number as a response from the peer device;
analyzing the response received from the peer device;
transmitting, based on analysis, at least one synchronization acknowledgement message, to the peer device as an indication of a secure session establishment;
communicate data to the peer device through the secure session established.

14. The computing device as claimed in claim 13, wherein the computing device is configured to be synchronized with at least one server to obtain the connection state information and the session key parameters associated with the connection, before receiving the switchover indication.

15. The computing device as claimed in claim 13, wherein the synchronization protocol is preferably a Datagram Transport Layer Security (DTLS) communications protocol.

16. The computing device as claimed in claim 15, wherein the Datagram Transport Layer Security (DTLS) protocol communication comprises at least three sequence number synchronization messages selected from a DTLS Synchronous Sequence Request, a DTLS Synchronous Sequence Response, and a DTLS Synchronous Sequence Acknowledgement.

17. The computing device as claimed in claim 16, wherein the sequence number synchronization messages configured to be transmitted in encrypted format, wherein the sequence number synchronization messages comprises:
a message type field of 1 byte, to represent the DTLS Synchronous Sequence Request, the DTLS Synchronous Sequence Response, or the DTLS Synchronous Sequence Acknowledgement;
a server sequence number field of 6 bytes;
a client sequence number field of 6 bytes;
a random number of 32 byte; and
a padding length field as per encryption algorithm.

18. The computing device as claimed in claim 13, wherein the sequence number received from the peer device comprises:
the two sequence numbers transmitted by the computing device using the synchronization request message, indicating an acceptance of the peer device for communication; or
at least a new sequence number generated by the peer device for the computing device to analyze.

19. The computing device as claimed in claim 13, upon receipt of the response from the peer device, the computing device analyzes the sequence number received in response are same as transmitted in the synchronization request message, wherein:
if the sequence number received are same, the computing device is configured to transmit the synchronization acknowledgement message, and thereby communicate data to the peer device through the secure session established; or
if the sequence number received are different, the computing device is configured to check if the sequence number received can be used for establishing the secure session, based on which the computing device transmit the synchronization acknowledgement message or terminates the connection with the peer device.

20. The computing device as claimed in claim 13, wherein the synchronization response message from the peer device comprises at least a fatal alert indication, indicating termination of the connection with the computing device.

21. The computing device as claimed in claim 13 or 16, comprises at least one retransmission timer to handle packet loss, the retransmission timer is configured to retransmit the sequence number synchronization messages if the peer device fails to respond.

22. The computing device as claimed in claim 13, comprises at least one cache configured to store the data transmitted after the secure session established, wherein the computing device is configured to send the data if the same synchronization acknowledgement message is received from the peer device.

23. A method for sequence number negotiation between at least one computing device and at least one peer device, wherein the computing device is configured to operate in a standby mode, the method comprising:
receiving, by a processor of the computing device, at least one indication indicating a switchover;
initiating, by the processor of the computing device, a handshake mechanism with the peer device for sequence number negotiation, using at least one synchronization protocol by:
generating at least two sequence numbers;
transmitting the two sequence numbers to the peer devices using at least one synchronization request message;
receiving at least one synchronization response message with at least a sequence number as a response from the peer device;
analyzing the response received from the peer device;
transmitting, based on analysis, at least one synchronization acknowledgement message, to the peer device as an indication of a secure session establishment;
communicating, by the processor of the computing device, the data to the peer device through the secure session established.

24. The method as claimed in claim 23, comprises receiving, by the computing device, the connection state information and the session key parameters associated with the connection from at least one at least one server.

25. The method as claimed in claim 23, wherein the synchronization protocol is preferably a Datagram Transport Layer Security (DTLS) communications protocol.

26. The method as claimed in claim 25, wherein the Datagram Transport Layer Security (DTLS) protocol communication comprises at least three sequence number synchronization messages selected from a DTLS Synchronous Sequence Request, a DTLS Synchronous Sequence Response, and a DTLS Synchronous Sequence Acknowledgement.

27. The method as claimed in claim 26, wherein the sequence number synchronization messages configured to be transmitted in encrypted format, wherein the sequence number synchronization messages comprises:
a message type field of 1 byte, to represent the DTLS Synchronous Sequence Request, the DTLS Synchronous Sequence Response, or the DTLS Synchronous Sequence Acknowledgement;
a server sequence number field of 6 bytes;
a client sequence number field of 6 bytes;
a random number of 32 byte; and
a padding length field as per encryption algorithm.

28. The method as claimed in claim 23, wherein the sequence number received from the peer device comprises:
the two sequence numbers transmitted by the computing device using the synchronization request message, indicating an acceptance of the peer device for communication; or
at least a new sequence number generated by the peer device for the computing device to analyze.

29. The method as claimed in claim 23, comprises analyzing, by the computing device, upon receipt of the response from the peer device, the sequence number received in response are same as transmitted in the synchronization request message, wherein:
if the sequence number received are same, the computing device is configured to transmit the synchronization acknowledgement message, and thereby communicate data to the peer device through the secure session established; or
if the sequence number received are different, the computing device is configured to check if the sequence number received can be used for establishing the secure session, based on which the computing device transmit the synchronization acknowledgement message or terminates the connection with the peer device.

30. The method as claimed in claim 23, wherein the synchronization response message from the peer device comprises at least a fatal alert indication, indicating termination of the connection with the computing device.

31. The method as claimed in claim 23 or 26, comprises at least one retransmission timer to handle packet loss, the retransmission timer is configured to retransmit the sequence number synchronization messages if the peer device fails to respond.

32. The method as claimed in claim 23, comprises at least one cache configured to store the data transmitted after the secure session established, wherein the computing device is configured to send the data if the same synchronization acknowledgement message is received from the peer device.

33. A system comprising:
at least one active device in communication with at least one peer device;
at least one computing device in communication with the active device by sharing the connection state information and the session key parameters associated with the connection, the computing device comprises:
a memory; and
a processor configured by instructions retrieved from the memory, while operating in a standby mode, to:
receive at least one indication indicating a switchover;
initiate a handshake mechanism with at least one peer device for sequence number negotiation using at least one synchronization protocol by:
generating at least two sequence numbers;
transmitting the two sequence numbers to the peer device using at least one synchronization request message;
receiving at least one synchronization response message with at least a sequence number as a response from the peer device;
analyzing the response received from the peer device;
transmitting, based on analysis, at least one synchronization acknowledgement message, to the peer device as an indication of a secure session establishment; and
communicate data to the peer device through the secure session established.

, Description:
TECHNICAL FIELD

The present subject matter described herein, in general, relates to transmitting a datagram with a Datagram Transport Layer Security (DTLS) protocol in a reliable and secured manner, and more particularly, to a system and method providing support for high availability services in applications using DTLS through secure exchange of record information by means of new messages in Datagram Transport Layer Security (DTLS) protocol.

BACKGROUND

High Availability refers to the ability of a system to provide services to the users without loss of service. As well known, in information technology, high availability refers to a system or component that is continuously operational for a desirably long length of time. Availability can be measured relative to "100% operational" or "never failing." A widely-held but difficult-to-achieve standard of availability for a system or product is known as "five 9s" (99.999 percent) availability. A high availability system minimizes the downtime of an overall system. To support high availability, a number of technologies and best practices are available, the most important mechanism being redundancy. High Availability can be achieved using redundant systems and components.

High Availability can be achieved using redundant datagram transport layer security (DTLS) server using DTLS protocol for communication, in which one acts as active member and another acts as stand-by member.

A Datagram Transport Layer Security (DTLS) (RFC 4347 and 6347) Protocol is used for implementing application layer security in many scenarios where UDP is used as the underlying transport mechanism. DTLS communication / connection has three stages, those are Handshake, Application Data and Connection closure.
• Handshake is to negotiate ciphers, generate required session keys for secure data transfer and authenticate peer (optional).
• Application data transfer happens securely with the generated keys in handshake.
• Connection closure is terminating the DTLS handshake by exchanging close notify alerts.

Renegotiation is an optional encrypted handshake which can be initiated by any entity (client or server) after first handshake. Both the entity can perform any number of renegotiations. Reason for initiating renegotiation is if an entity felt like session keys are compromised or if an entity wants to use different cipher suite for further communication. Application data transferred after renegotiation uses newly generated session keys.

The existing DTLS protocol is designed to provide communications privacy for data transferred over datagram protocols (unreliable transport). It is derived from Transport Layer Security (TLS) Protocol. The DTLS consists of multiple protocols like Handshake Protocol, Change Cipher Spec, Alert, Application Data and Record Protocol (as shown in figure 3(a)).
DTLS Handshake Protocol: Handshake Protocol is responsible for cipher suite and version negotiation, authenticating peer, key exchange and to resume a previous session.
DTLS Record Layer Protocol: Record Layer receives uninterrupted data from higher layers in non-empty blocks of arbitrary size. The Record Layer consists of the following fields,
• ContentType – Indicates the type of payload being transmitted in the Record Layer (Ex: Handshake Data, Application Data etc.)
• ProtocolVersion – Indicates the version of the protocol being used (Ex: DTLS 1.0, DTLS 1.2 etc.)
• Epoch – A counter value which is incremented each time keys are freshly negotiated
• Sequence Number – Sequence Number for each record. It is incremented for each record and set to 0 each time keys are freshly negotiated.
• Length – Length of the Payload
• Fragment – Actual Payload

DTLS Anti-Replay Detection Feature: DTLS record header contains a sequence number to provide replay protection. Sequence number verification is performed using the sliding window procedure. A window of size 32 or 64 may be implemented. The “right” edge of the window represents the highest validated sequence number value received on the current session. Records that contain sequence numbers lower than the “left” edge of the window are rejected. Packets falling within this window are checked against a list of received packets within the window. If the received record falls within the window or it is new, or if the packet is to the right of the window, then the receiver proceeds to MAC verification. The receive window is updated only when MAC verification succeeds.

In order to achieve high availability using redundant DTLS server in which one acts as active member and another acts as stand-by member, a DTLS Session is first established between the Peer and the Active Member. Then active member sends the “Connection state” to stand-by member. This synchronization is done each time after new keys are generated, i.e., immediately after the first handshake and then subsequently after each renegotiation. After sync is done, active member starts its secure data transfer with peer.

In the Wireless LAN scenario, multiple access points (approximately more than 4K in a normal scenario) will be connected to an access controller. High availability support will be needed as if the access controller goes down, then connection to all access points will be affected. In case of a Hot Standby based solution, when an active controller fails and the standby takes over, all access points should be able to switch to the standby without having to do a reconnection again, as reconnection will involve complete DTLS Handshake and will lead to lot of delays.

However, in case of the hot standby implementation, the DTLS session is first established between the peer (multiple access points) and the active member (access controller). The active member continuously syncs the “Connection State” with the standby member. This sync is done after each time new keys are generated, i.e. immediately after the first handshake and then subsequently after each renegotiation. But, each record of DTLS includes an explicit sequence number which is incremented for each record and included in MAC generation of DTLS record. This sequence number should be within a “Window” range to thwart “Replay Attacks”. DTLS sequence number and replay detection feature in the current protocol standard poses a problem in the implementation of the high availability feature. When a stand-by takes over from active, it may have old sequence numbers and hence all the packets sent by it, will be based on older sequence numbers which will cause the client to reject all the packets due to anti-replay protection check. In case of packets from client, there is a risk of replay attack from malicious intermediaries who may try to replay older packets of client and server will just end up accepting and processing all those packets which can lead to a lot of processing resource wastage in server along with the problem of providing duplicate data to the server.

During switchover / failover (automatic / manual switch from one system to a redundant or a standby computer server, system, or network upon the failure or abnormal termination of the previously active server, system, or network, or to perform system maintenance, such as installing patches, and upgrading software or hardware), stand-by will not be able to continue the existing DTLS connection even though it has “Connection state” information. This problem is because sequence number of the DTLS application data record transferred between active member and peers, was not synced with stand-by member.

Also, performing sequence number synchronization between the active and standby members for each and every DTLS record is very costly in terms of time and node/network overhead. So, during a failover event, when the standby takes over, though it is aware of the connection state, it is not aware of the current sequence number being used by the Active Member. Since the peer is also unaware of the failover event, it continues to send records with the current sequence number. This creates a situation which leads to a sequence number mismatch and eventual failure of the DTLS connection. Disconnecting DTLS and re-initiating DTLS connections for all the clients of the Server is also quiet expensive and will lead to delays.

SUMMARY

This summary is provided to introduce concepts related to a system and method providing support for high availability services in applications through secure negotiation of new sequence numbers by means of a datagram transport layer security (DTLS) protocol are further described below in the detailed description. This summary is not intended to identify essential features of the claimed subject matter nor is it intended for use in determining or limiting the scope of the claimed subject matter.

One aspect of the present invention is to provide a sequence number synchronization procedure to achieve high availability on DTLS.

Another aspect of the present invention is to provide a sequence number synchronization procedure wherein new active member (after switch over) and the client(peer) negotiate a pair of new values as sequence numbers using minimalistic message exchange to resume the current session.

Another aspect of the present invention is to provide a sequence number synchronization procedure for a newly active cluster member (standby access controller for example) and the peer to negotiate a pair of new values for sequence numbers for the current session itself using minimalistic message exchange, so that future DTLS messages will not be dropped.

Accordingly, in one implementation, the present invention provides a method for sequence number synchronization using a message exchange in a system having at least one access point and at least two access controller’s viz., an active access controller and a standby access controller. The method comprises synchronizing periodically a connection state and associated session key parameters between said active access controllers and said standby access controller. After said active access controller fails / in an event of failover, the method includes negotiating/ synchronizing a sequence number between said standby access controller and said access point using a Datagram Transport Layer Security (DTLS) protocol transmitted as a Datagram Transport Layer Security (DTLS) sequence number synchronization message based on prior negotiation of DTLS sequence number synchronization extension to resume current communication session without a new DTLS handshake.

In one implementation, the present invention provides a system comprising at least one access point and at least two access controllers. The system comprises a synchronization unit configured to synchronize periodically a connection state and associated session key parameters between said active access controller and said standby access controller, and a negotiation unit configured to negotiate/synchronize, after said active access controller fails/ in an event of failover, a sequence number between said standby access controller and said access point using a Datagram Transport Layer Security (DTLS) protocol transmitted as a Datagram Transport Layer Security (DTLS) sequence number synchronization message based on prior negotiation of DTLS sequence number synchronization extension to resume current communication session.

In one implementation of the present invention, as compared to the prior-art or the conventional techniques, the peer and the active member will negotiate their ability to support DTLS Sequence Number synchronization. This is done by exchanging a new “dtls_seq_num_sync” extension in the Hello Messages. The support for this extension is indicated by the peer (the client or the access points) and then a similar support should be asserted by the active member (the server or the active access controller). If either of the parties do not indicate their support, then this feature (synchronization procedure) cannot be used.

In one implementation of the present invention, after the fail-over event, the newly active member uses the DTLS Sequence Number Synchronization capability and initiates sequence number synchronization messages. The peer (client) responds to any synchronization message it receives from the newly active member. Once, both the newly active member and peer finish their exchanges and new sequence numbers have been negotiated, they can continue to exchange normal application data.

BRIEF DESCRIPTION OF THE ACCOMPANYING DRAWINGS

The detailed description is described with reference to the accompanying figures. In the figures, the left-most digit(s) of a reference number identifies the figure in which the reference number first appears. The same numbers are used throughout the drawings to refer like features and components.

Figure 1 illustrates a Wireless LAN scenario, in accordance with an embodiment of the present subject matter.

Figure 2 illustratesa failover or switchover in wireless LAN scenario, in accordance with an embodiment of the present subject matter.

Figure 3(a) and Figure 3(b) illustrates a conventional DTLS Protocol and a new DTLS sequence number sync record / protocol structure, in accordance with an embodiment of the present subject matter.

Figure 4 illustrates a client server communication using a DTLS sequence number sync record / protocol structure, in accordance with an embodiment of the present subject matter.

Figure 5 illustrates a DTLS initial connection and high availability handover sequence, in accordance with an embodiment of the present subject matter.

Figure 6 illustrates a handling synchronization sequence request message lost, in accordance with an embodiment of the present subject matter.

Figure 7 illustrates a handling synchronization sequence response message lost, in accordance with an embodiment of the present subject matter.

Figure 8 illustrates a handling synchronization sequence acknowledgement message lost, in accordance with an embodiment of the present subject matter.

Figure9illustrates a system for sequence number synchronization using a message exchange, in accordance with an embodiment of the present subject matter.

Figure 10 illustrates a method for sequence number negotiation between at least one computing device and at least one peer device, in accordance with an embodiment of the present subject matter.

Figure 11 illustrates a method for sequence number synchronization using a message exchange, in accordance with an embodiment of the present subject matter.

It is to be understood that the attached drawings are for purposes of illustrating the concepts of the invention and may not be to scale.

DETAILED DESCRIPTION OF THE PRESENT INVENTION

The following clearly describes the technical solutions in the embodiments of the present invention with reference to the accompanying drawings in the embodiments of the present invention. Apparently, the described embodiments are merely a part rather than all of the embodiments of the present invention. All other embodiments obtained by a person of ordinary skill in the art based on the embodiments of the present invention without creative efforts shall fall within the protection scope of the present invention.

The invention can be implemented in numerous ways, including as a process, an apparatus, a system, a composition of matter, a computer readable medium such as a computer readable storage medium or a computer network wherein program instructions are sent over optical or electronic communication links. In this specification, these implementations, or any other form that the invention may take, may be referred to as techniques. In general, the order of the steps of disclosed processes may be altered within the scope of the invention.

A detailed description of one or more embodiments of the invention is provided below along with accompanying figures that illustrate the principles of the invention. The invention is described in connection with such embodiments, but the invention is not limited to any embodiment. The scope of the invention is limited only by the claims and the invention encompasses numerous alternatives, modifications and equivalents. Numerous specific details are set forth in the following description in order to provide a thorough understanding of the invention. These details are provided for the purpose of example and the invention may be practiced according to the claims without some or all of these specific details. For the purpose of clarity, technical material that is known in the technical fields related to the invention has not been described in detail so that the invention is not unnecessarily obscured.

System and method providing support for high availability services in DTLS applications through secure negotiation of sequence number by means of exchanging sequence number synchronization messages are disclosed.

While aspects are described for providing high availability services in DTLS applications through secure negotiation of sequence number by means of exchanging sequence number synchronization messages, the present invention may be implemented in any number of different computing systems, environments, and/or configurations, the embodiments are described in the context of the following exemplary systems, apparatus, and methods.

In one implementation, the present invention provides protocol level support in DTLS for high availability.

In one implementation, the peer and the active member will negotiate their ability to support DTLS Sequence Number synchronization. This is done by exchanging a new “dtls_seq_num_sync” extension in the Hello Messages. The support for this extension is indicated by the peer (the client or the access points) and then a similar support should be asserted by the active member (the server or the active access controller). If either of the parties does not indicate their support, then this feature (synchronization procedure) cannot be used.

In one implementation of the present invention, after the fail-over event, the newly active member uses the DTLS Sequence Number Synchronization capability and initiates sequence number synchronization messages. The peer responds to any synchronization message it receives from the newly active member. Once, both the newly active member and peer finish their exchanges and new sequence numbers have been negotiated, they can continue to exchange normal application data.

In one implementation, for DTLS Sequence Number values, both the Standby (newly active member) and the peer will negotiate the new sequence numbers to be used. However, in order to initiate the negotiation, a new DTLS Sequence Number Synchronization Extension should have been shared/negotiated between the Active Member and the peer during Initial Handshake itself.

In one implementation, a new extension for indicating the support for sequence number synchronization i.e., “dtls_seq_num_sync” extension is used.

In one implementation, an entity may indicate if it supports sequence number synchronization by just including the extension type in the Hello Messages with no extension data.

In one implementation, during handshake, both the DTLS server (active access controller) and client (access points) indicate their willingness to support sequence number synchronization during the middle of the session. This is done by exchanging “dtls_seq_num_sync” extension during Initial Handshake.

In one implementation, the client may indicate the willingness to support sequence number synchronization by sending this extension in the “Client Hello” message.

In one implementation, the server depending upon its capability to support this feature, it may send the “dtls_seq_num_sync” extension in the server Hello Message.

In one implementation, after the completion of successful handshake, the connection parameters (including the security parameters, encryption and MAC keys and the like) should be synced up between the active and standby members.

In one implementation, there is a periodic synchronization of sequence numbers between the active and the standby access controllers. A person skilled in the art may understand that the periodicity for the same can be decided during the implementation.

In one implementation, for the high availability solution to work, in the present invention, the active and standby members ensures that, they have synchronized the connection state (CS) and related session key parameters that are needed for record layer confidentiality and integrity protection. It is understood that the only information missing for the standby to communicate with the peer are the send and receive sequence numbers, which is achieved using the sequence number synchronization procedure.

In one implementation, to make new active member and client to negotiate a sequence number, below mentioned two additional features are required in DTLS: a DTLS synchronization protocol, and a DTLS sequence number synchronization extension.

In one implementation, the support for DTLS sequence number synchronization protocol is indicated with Hello Extensions for example, “Server Hello dtls_seq_num_sync”. A peer can indicate if it supports Sequence Number Synchronization for example, “Client Hello dtls_seq_num_sync”. This is done by just including the extension type in the Hello Messages with no extension data. First the client needs to indicate this by adding this extension in client hello, then if server also supports this feature then it needs to add this same extension in its server hello message.

In one implementation, the DTLS synchronization protocol is the new record type in DTLS, which needs to be introduced to perform sequence number negotiation between new active member and peer. Under this record type, below mentioned new three messages needs to be used.
DTLS Synchronization Sequence Request (dtlssyncseq_req)
DTLS Synchronization Sequence Response (dtlssyncseq_resp)
DTLS Synchronization Sequence Acknowledgement (dtlssyncseq_ack)

In one implementation, once new active member comes up (in case of switchover/failover), it already holds connection state (session keys and all session information) about all clients. Then immediately it may start a small secure message exchange with all active clients, which involves the above mentioned three new synchronization messages.

In one exemplary embodiment, the active member needs to first decide two sequence number (for server and client) based on the assessment about the number of messages exchanged so far between the previously active member and peer. Then it needs to send those two sequence number in DTLS Synchronization Sequence request message to client. Once client receives the DTLS synchronization sequence message, it realizes that switchover happened in server and starts processing this message. Then it may decide whether the newly generated sequence number is acceptable by client. If yes it may reply back the same sequence number to server as DTLS synchronization sequence response message. If client wants to use some other number, it can send different number in its response message. If client is not going to agree sequence number synchronization it can send a fatal alert and close the connection, and then it can go for new fresh handshake. Once the newly active member receives the DTLS synchronization sequence response message, it should process and reply back DTLS synchronization sequence acknowledgement message to client. If the sequence numbers in response message is different, then server needs to decide whether the new sequence number can be used. If yes it needs to send back DTLS synchronization sequence acknowledgement message. If no it has to close the connection with fatal alert and wait for client to start fresh handshake.

In one implementation, to handle packet loss, both client and server may maintain their own retransmission timer to retransmit the message if there is no response from peer. Newly Active member initiates the synchronization procedure by using 1 as sequence number in the record header, if there is no response message from peer it should retransmit request message. Client does not drop the DTLS record with synchronization record type when it comes with sequence number as 1, as part of replay attack prevention. Moreover client may also participate in this synchronization procedure from the sequence number 1. All these messages may be transmitted in encrypted manner. These three message may contain the below fields:
• Message type – 1 byte, to represent request, response or acknowledgement
• Server sequence number – 6 byte, Sequence number requires for server to send packets
• Client sequence number – 6 byte, Sequence number requires for client to send packets
• Random number – 32 byte,
• Padding length – padding length as per encryption algorithm

In one implementation, server may start sending application data after sending the DTLS synchronization ACK (acknowledgement) message with the newly negotiated sequence numbers. But, the server also cache the DTLS synchronization ACK message and may send the same if it receives a retransmitted DTLS synchronization response message from client. Similarly server can also start processing application data received from the clients with newly negotiated sequence numbers after sending the DTLS Sync ACK message.

In one implementation, client may start sending application data only after the DTLS Sync ACK message is received. Similarly, client may start processing application data from server only after receiving the DTLS Sync ACK message. But, in case if it receives an application data with the newly negotiated sequence number as per the dtlssyncseq_resp message before receiving DTLS Sync ACK message, it may choose to store the record or discard it.

In one implementation, if an entity starts receiving application data after finishing the sequence synchronization procedure (request-response-acknowledgement), it indicates the completion of sequence number synchronization for that epoch and any further DTLS synchronization request, DTLS synchronization response or DTLS synchronization ACK messages received should be silently discarded.

Figure 1illustrates a Wireless LAN (WLAN) scenario 100 in accordance with an embodiment of the present subject matter. In WLAN, Access controller (AC) 104 manages multiple number of Access Points (AP) 102. Here CAPWAP protocol is used on top of DTLS. Here already redundant Access controllers are deployed to reduce the downtime, but during switchover currently it is doing fresh DTLS handshake with each AP. This is taking a quite long time as minimum 4000 APs are deployed. However, by the implementation of the present invention, the conventional scenario of the WLAN will help to reduce the downtime of ACs in WLAN. Further, the access controllers 104, 106 are coupled to the access points 102-1, 102-2……, 102-n(hereinafter, 102), by means of a switch device 1000.

For example, as shown in figure 1, a standby access controller 106 and the active access controller 104 are continuously in synchronization mode for back up of the configuration data and connection state (session keys and other information) of each client. Hence, at the time of switchover, when the active access controller 104 fails the current connection services to the access points 102 are provided by the standby access controller 106., thereby reducing the downtime of ACs in WLAN.

Figure 2 illustrates a failover or switchover in wireless LAN scenario, in accordance with an embodiment of the present subject matter. As shown in the figure 2, the active AC backs-up/synchronizes DTLS session keys (connection state) of each client with the standby AC. This synchronization is done after successful handshake (or renegotiation) of active AC (server) with each AP (client). After this active AC and AP start sending application data on secure DTLS connection. During switchover or failure, standby AC becomes active and starts sending DTLS sequence synchronization request message to all clients which are configured by pervious active AC during synchronization. After successful completion of sequence number synchronization, all APs and new active AC continue to use the DTLS connections created by previous active AC.

EXAMPLE: When a failover event happens and the standby takes over as the active member, it may use the sequence number synchronization feature, provided the capability has been negotiated during the Initial Handshake. The DTLS synchronization sequence protocol running on top of record layer for synchronizing sequence numbers maybe used. The DTLS synchronization sequence protocol comprises of 3 new messages types, dtlssyncseq_req, dtlssyncseq_resp and dtlssyncseq_ack. For the messages of this protocol type, the sequence number in record header must start with 1 and must not be linked with existing sequence number series of other records which were exchanged prior to this message. The record layer should use existing keys for MAC calculation and encryption of the messages of this type.

Server Behavior (After Switch over): During switch over, when standby becomes active, it needs to send the DTLSSyncSeqMsg of type dtlssyncseq_req. In the message, server proposes values for server_seq_num and client_seq_num based on its assessment or server may also keep the values for these parameters as 0 if it is not in a position to make the assessment. Server also includes a 32 bit random nonce in the message. After sending the dtlssyncseq_req message, server starts a retransmission timer and retransmit dtlssyncseq_req message till it receives a dtlssyncseq_resp message from the client.

Client Behavior: Once the client receives a DTLSSyncSeqMsg of type dtlssyncseq_req, it prepares a response DTLSSyncSeqMsg of type dtlssyncseq_resp. Client checks if the values proposed by server for server_seq_num and client_seq_num are suitable, if yes, it sends the same values in the response message else, it can propose different values depending upon its assessment. Values sent by client will be considered final by the server. After sending the response message, client starts a retransmission timer and should retransmit dtlssyncseq_resp message till it receives a dtlssyncseq_ack message from the Server.

After receiving response from Client server checks if the random nonce present in the client message is same as what was sent by it. It updates the sequence number values from the client message and sends a dtlssyncseq_ack message which contains the sequence number values as received from client. Random nonce for this message should be same as previous server message.

Server starts sending application data after sending the dtlssyncseq_ack message with the newly negotiated sequence numbers. But, is also ready to retransmit the dtlssyncseq_ack message if it receives a retransmitted dtlssyncseq_resp from client. Similarly, client starts sending application data after it receives a dtlssyncseq_ack message from server.

Figure 4 illustrates a client server communication using a DTLS sequence number sync record / protocol structure, in accordance with an embodiment of the present subject matter. As shown in figure 4, the “Client Hello” will now contain an additional extension “dtls_seq_num_sync” to indicate support for sequence number synchronization. The “Server Hello” will also contain an additional extension “dtls_seq_num_sync” to indicate support for sequence number synchronization. The additional messages (i.e., for request-response-acknowledgement) with new record type “DTLSSyncSeq” will be exchanged to sync sequence numbers between Server and Client. This can be done in-between Application Data Exchanges.

Sequence Number Synchronization Support Extension Definition:
A new DTLS Hello Extension, “dtls_seq_num_sync” (with temporary extension type 0xff02 is provided for indicating the support of Sequence Number Synchronization Capability. This extension does not have any payload and hence the length field of this extension will be zero. If the extension is present in client hello, it indicates that the client is ready to accept sequence number synchronization messages. Similarly, from the server, if the extension is present in server hello, it indicates to the client that sequence number synchronization is supported by server.

DTLS Sequence Number Sync Protocol:
DTLSSyncSeq Protocol is a new protocol running on top of the record protocol. The protocol itself consists of 3 messages types: DTLSSeqNumSyncReq, DTLSSeqNumSyncResp and DTLSSeqNumSyncAck.
enum
{
dtlssyncseq_req(1),
dtlssyncseq_resp(2),
dtlssyncseq_ack(3)
(255)
}DTLSSeqNumSyncMessageType;

A DTLSSyncSeq message may occur anytime during the lifetime of the connection. But, it should not come during Handshake Messages. Also, this message must be processed only once (ignoring the timeout re-transmissions) during one epoch.

A New DTLS Sequence Number Sync Content type (with temporary value of approximately 25) is provided for sending a new type of record in DTLS.

The DTLS Sequence Number Sync Messages consist of type, send sequence number, and receive sequence number and a random nonce, and an exemplary structure for DTLS Sequence Number Sync Messages is as given below:
struct {
DTLSSyncSeqMsgType type;
uint48 send_seq_num;
uint48 recv_seq_num;
opaque random[32];
uint8 padding[GenericBlockCipher.padding_length];
uint8 padding_length;
}DTLSSeqNumSyncMessage;

The total length of a DTLSSeqNumSyncMessage should not exceed max_fragment_length. Figure 3(a) and Figure 3(b) illustrates a conventional DTLS Protocol and a new DTLS sequence number sync record / protocol structure, in accordance with an embodiment of the present subject matter.

As shown in figure 3(b), in contrast to the existing DTLS protocol structure, the new structure of the DTLSSyncSeq protocol comprises of:
• type: The message type, either dtlssyncseq_req, dtlssyncseq_resp or dtlssyncseq_ack
• send_seq_num: This is the expected send sequence number. It should be larger than the last seen send sequence number
• recv_seq_num: This is the expected recv sequence number. It should be larger than the last seen receivesequencenumber
• Random: A random nonce which is generated and sent in the request and response just keeps the same value as in the request. The random nonce should be 32 bytes in length.
• padding: padding needed for block ciphers (Same as followed for normal DTLS records)
• padding_length: Padding Length (Same as followed for DTLS records)

In one implementation, the new ID’s disclosed in this patent are as provided in the table below:

ID Values (Suggested Values) Use
dtls_seq_num_sync 0xff02 New Hello Extension used for indicating support for Sequence Number Synchronization Capability
DTLSSeqSync 25 A new content(record) type for sending dtls sequence number synchronization messages
dtlssyncseq_req 1 Indicates the DTLSSeqSync message type as request message
dtlssyncseq_resp 2 Indicates the DTLSSeqSync message type as response message
dtlssyncseq_ack 3 Indicates the DTLSSeqSync message type as acknowledgement message
Table 1: New ID’s for the implementation of the present invention

Figure 5illustrates a DTLS initial connection and high availability handover sequence, in accordance with an embodiment of the present subject matter. The access point will send a “Client Hello” message which will now contain an additional extension “dtls_seq_num_sync” to indicate support for sequence number synchronization to the active AC. The active AC will respond with “Server Hello” message which will also contain an additional extension “dtls_seq_num_sync” to indicate support for sequence number synchronization. The additional messages (i.e., for request-response-acknowledgement) with new record type “DTLSSyncSeq” will be exchanged to sync sequence numbers between Server and Client. This can be done in-between Application Data Exchanges. Simultaneously, the active AC is in synchronization with standby AC for backing up of keys established during DTLS handshake. At the time of switchover / failover, the active AC goes down (fails), the standby AC becomes active and sends DTLS sequence number synchronization request. APs sends response for sequence number synchronization and the Old DTLS connection is recovered between APs and new active AC (standby).

In one implementation, both DTLS server and client needs to use the default DTLS retransmission mechanism to retransmit these DTLS sequence synchronization messages. Mechanism of retransmission of these three packets during packet loss is explained in figure 6, 7, and 8, respectively.

Figure 6 illustrates a handling synchronization sequence request message lost, in accordance with an embodiment of the present subject matter. After switchover or failure, new active AC (server) starts DTLS sequence number synchronization by sending DTLSSyncSeqRequestMsg to AP (client) with the record sequence number as 1. If there is no response message from client then server should assumes that either DTLSSyncSeqRequestMsg sent is lost or the client’s response message is lost. So in this case server starts retransmission of DTLSSyncSeqRequestMsg to AP (client) with the record sequence number as 2 (i.e. increment the sequence number in record header by 1 for each retransmission). Then if server receives DTLSSyncSeqResponseMsg then it should send DTLSSyncSeqAckMsg to finishes the synchronization. Then both the entity can start sending application data with the newly negotiated sequence number. If there is no response from client after sending DTLSSyncSeqRequestMsg for 10 times, server should close the connection and wait for client to start fresh handshake.

Figure 7 illustrates a handling synchronization sequence response message lost, in accordance with an embodiment of the present subject matter. During this DTLS sequence number synchronization if DTLSSyncSeqResponseMsg is lost, retransmission timer in server will get expired and it should retransmit the DTLSSyncSeqRequestMsg as similar to the previous case. Then both the entity should finish synchronization and start sending application data with the newly negotiated sequence number.

Figure 8 illustrates a handling synchronization sequence acknowledgement message lost, in accordance with an embodiment of the present subject matter. During this DTLS sequence number synchronization if DTLSSyncSeqAckMsg is lost, retransmission timer in client will get expired and it should retransmit DTLSSyncSeqResponseMsg. Once new active AC receives DTLSSyncSeqResponseMsg it should assume that DTLSSyncSeqAckMsg is lost and it should retransmit it. Then once synchronization finishes both entities can start sending application data with the newly negotiated sequence number.

Referring now to figure 9, it illustrates a computing device106, having the connection state information and the session key parameters associated with the connection. The computing device comprises a processor 902 and a memory 906. The processor902 configured by instructions retrieved from the memory906.

Although the present subject matter is explained considering that the present invention is implemented as computing device106, it may be understood that the computing device106may also be implemented in a variety of computing systems, such as a laptop computer, a desktop computer, a notebook, a workstation, a mainframe computer, a server, a network server, and the like. It will be understood that the computing device106may be accessed by multiple users, or applications residing on computing device106. Examples of the computing device106may include, but are not limited to, a portable computer, a personal digital assistant, a handheld device, sensors, routers, gateways and a workstation. The computing device106are communicatively coupled to other devices or a nodes or apparatuses to form a network (not shown).

In one implementation, the network (not shown) may be a wireless network, a wired network or a combination thereof. The network can be implemented as one of the different types of networks, such as GSM, CDMA, LTE, UMTS, intranet, local area network (LAN), wide area network (WAN), the internet, and the like. The network may either be a dedicated network or a shared network. The shared network represents an association of the different types of networks that use a variety of protocols, for example, Hypertext Transfer Protocol (HTTP), Transmission Control Protocol/Internet Protocol (TCP/IP), Wireless Application Protocol (WAP), and the like, to communicate with one another. Further the network may include a variety of network devices, including routers, bridges, servers, computing devices, storage devices, and the like.

The computing device106as illustrated in accordance with an embodiment of the present subject matter, may include at least one processor 902, an interface 904, and a memory 906. The at least one processor 902 may be implemented as one or more microprocessors, microcomputers, microcontrollers, digital signal processors, central processing units, state machines, logic circuitries, and/or any devices that manipulate signals based on operational instructions. Among other capabilities, the at least one processor 902 is configured to fetch and execute computer-readable instructions or modules stored in the memory 906.

The interface 904 (I/O interface) may include a variety of software and hardware interfaces, for example, a web interface, a graphical user interface, and the like. The I/O interface 904 may allow the computing device 106 to interact with a user directly. Further, the I/O interface 904 may enable the computing device 106 to communicate with other devices or a nodes, computing devices, such as web servers and external data servers (not shown). The I/O interface 904 can facilitate multiple communications within a wide variety of networks and protocol types, including wired networks, for example, GSM, CDMA, LAN, cable, etc., and wireless networks, such as WLAN, cellular, or satellite. The I/O interface 904 may include one or more ports for connecting a number of devices to one another or to another server. The I/O interface 904 may provide interaction between the user and the computing device106via, a screen provided for the interface 904.

The memory 906 may include any computer-readable medium known in the art including, for example, volatile memory, such as static random access memory (SRAM) and dynamic random access memory (DRAM), and/or non-volatile memory, such as read only memory (ROM), erasable programmable ROM, flash memories, hard disks, optical disks, and magnetic tapes. The memory 906 may include plurality of instructions or modules or applications to perform various functionalities. The memory 906 include routines, programs, objects, components, data structures, etc., which perform particular tasks or implement particular abstract data types.

In one implementation, a computing device106, having the connection state information and the session key parameters associated with the connection, is disclosed. The computing device106comprises a memory906; and a processor902 configured by instructions retrieved from the memory906, while operating in a standby mode, to receive908 at least one indication indicating a switchover;initiate910 a handshake mechanism, with at least one peer device102 for sequence number negotiation, using at least one synchronization protocol by:generating912 at least two sequence numbers; transmitting914 the two sequence numbers to the peer device102 using at least one synchronization request message;receiving916 at least one synchronization response message with at least a sequence number as a response from the peer device; analyze918 the response received from the peer device;transmit920, based on analysis, at least one synchronization acknowledgement message, to the peer device102 as an indication of a secure session establishment; and communicate922 data to the peer device102 through the secure session established.

In one implementation, a system comprising at least one active device 104 in communication with at least one peer device 102;at least one computing device 106 in communication with the active device 104 by sharing the connection state information and the session key parameters associated with the connection, the computing device102 comprises: a memory 906; and a processor 902 configured by instructions retrieved from the memory 906, while operating in a standby mode, to: receive 908 at least one indication indicating a switchover; initiate 910 a handshake mechanism with at least one peer device for sequence number negotiation using at least one synchronization protocol by generating 912 at least two sequence numbers; transmitting 914 the two sequence numbers to the peer device using at least one synchronization request message; receiving 916 at least one synchronization response message with at least a sequence number as a response from the peer device; analyze 918 the response received from the peer device; transmit 920, based on analysis, at least one synchronization acknowledgement message, to the peer device as an indication of a secure session establishment; communicate 922 data to the peer device through the secure session established.

In one implementation, the computing device is configured to be synchronized with at least one server to obtain the connection state information and the session key parameters associated with the connection, before receiving the switchover indication.

In one implementation, the synchronization protocol is preferably a Datagram Transport Layer Security (DTLS) communications protocol.

In one implementation, the Datagram Transport Layer Security (DTLS) protocol communication comprises at least three sequence number synchronization messages selected from a DTLS Synchronous Sequence Request, a DTLS Synchronous Sequence Response, and a DTLS Synchronous Sequence Acknowledgement.

In one implementation, the sequence number synchronization messages configured to be transmitted in encrypted format, wherein the sequence number synchronization messages comprises: a message type field of 1 byte, to represent the DTLS Synchronous Sequence Request, the DTLS Synchronous Sequence Response, or the DTLS Synchronous Sequence Acknowledgement; a server sequence number field of 6 bytes; a client sequence number field of 6 bytes; a random number of 32 byte; and a padding length field as per encryption algorithm.

In one implementation, the sequence number received from the peer device comprises the two sequence numbers transmitted by the computing device using the synchronization request message, indicating an acceptance of the peer device for communication; or at least a new sequence number generated by the peer device for the computing device to analyze.

In one implementation, upon receipt of the response from the peer device, the computing device analyzes the sequence number received in response are same as transmitted in the synchronization request message, wherein if the sequence number received are same, the computing device is configured to transmit the synchronization acknowledgement message, and thereby communicate data to the peer device through the secure session established; or if the sequence number received are different, the computing device is configured to check if the sequence number received can be used for establishing the secure session, based on which the computing device transmit the synchronization acknowledgement message or terminates the connection with the peer device.

In one implementation, the synchronization response message from the peer device comprises at least a fatal alert indication, indicating termination of the connection with the computing device.

In one implementation, the computing device comprises at least one retransmission timer to handle packet loss, the retransmission timer is configured to retransmit the sequence number synchronization messages if the peer device fails to respond.

In one implementation, the computing device comprises at least one cache configured to store the data transmitted after the secure session established, wherein the computing device is configured to send the data if the same synchronization acknowledgement message is received from the peer device.

In one implementation, the system negotiate, by said access point and said active access controller, a capability to support said sequence number synchronization, wherein said capability is checked by an exchange, between said access point and said active access controller, a Datagram Transport Layer Security (DTLS) sequence number synchronization extension in a “hello” message having a syntax “ dtls_seq_num_sync”, establish, if negotiation successful, a connection between said access point and said active access controller; and thereby share application data between said access point and said active access controller.

In one implementation, before negotiating/ synchronizing said sequence number, said active access controller and said access point are configured to intimate the capability of supporting said DTLS sequence number synchronization message by: negotiating/ synchronizing said sequence number between said active access controller and said access point during initial DTLS handshake by including a “dtls_seq_num_sync” extension in a client hello message by said access point to intimate said capability to said active access controller, and if said active access controller is capable of supporting said sequence number synchronization, said active access controller is configured to include the same “dtls_seq_num_sync” extension in response to said hello message

In one implementation, the system Datagram Transport Layer Security (DTLS) protocol comprises at least three sequence number synchronization messages selected from a DTLS Synchronous Sequence Request, a DTLS Synchronous Sequence Response, and a DTLS Synchronous Sequence Acknowledgement.

In one implementation, said three sequence number synchronization messages are transmitted in an encrypted form, and comprises: a message type field of 1 byte, to represent the DTLS Synchronous Sequence Request, the DTLS Synchronous Sequence Response, or the DTLS Synchronous Sequence Acknowledgement; a server sequence number field of 6 bytes; a client sequence number field of 6 bytes; a random number of 32 byte,; and a padding length field as per encryption algorithm.

In one implementation, the system, after said active access controller fails/ in an event of failover, enables said standby access controller configured to: select at least two sequence numbers; transmit said two sequence number selected to said access point, using at least one DTLS Synchronous Sequence Request message; and said access point configured to: receive said DTLS Synchronous Sequence Request message with said two sequence number, wherein said DTLS Synchronous Sequence Request message indicates said active access controller failure/ an event of failover; process said DTLS Synchronous Sequence Request message to confirm if said sequence number selected is received in said DTLS Synchronous Sequence Request message is acceptable; transmit said sequence number received, if acceptable, to said standby access controller, using at least one DTLS Synchronous Sequence Response; (optionally) transmit a new sequence number to said standby access controller, using at least one DTLS Synchronous Sequence Response if sequence numbers in said DTLS Synchronous Sequence Response message are not acceptable by said access point based on a knowledge of its previous data transfer with first active access controller; (optionally) transmit a fatal error message, if not acceptable and not in a willingness to suggest a new sequence numbers (or not in a willingness to continue this DTLS connection), to said standby access controller and thereby terminating said current communication session; and receive, by said standby access controller, said DTLS Synchronous Sequence Response, transmit at least one DTLS Synchronous Sequence Acknowledgement message to said access point.

In one implementation, the system wherein said access point and said standby access controller comprises a retransmission timer configured to maintain a time and retransmit at least one of said three sequence number synchronization messages.

In one implementation, said standby access controller is configured to transmit a sequence number starting with value as one in the record header (not to be confused with the sequence numbers in the body of the synchronization messages) to said access point using at least one DTLS Synchronous Sequence Request message.

In one implementation, said standby access controller and said access point are configured to cache said DTLS Synchronous Sequence Request, Response and Acknowledgement message and to re-transmit it, if any entity felt expected message from peer is lost in unreliable UDP layer transmission.

In one implementation, said negotiation unit is configured to negotiate/synchronize sequence number between said standby access controller and said access point if said standby access controller and said access point supports said Datagram Transport Layer Security (DTLS) sequence number synchronization i.e., “dtls_seq_num_sync”.

In one implementation, when active access controller fails, is configured to: transmit at least one random value assigned to a random nonce field of said DTLS Synchronous Sequence Request message by said standby access controller, to said access point; start a retransmission timer and retransmitting a DTLS Synchronous Sequence Request to said access point until a receipt of a DTLS Synchronous Sequence Response from said access point; and when said standby access controller receives said DTLS Synchronous Sequence Response having said random nonce and said sequence number, compare said random nonce in response with said random nonce in request, and if same, upgrade, by said standby access controller, said sequence number from response, and thereby transmit a DTLS Synchronous Sequence Acknowledgement message to said access point; and thereby resume current communication session. In one example, a person skilled in the art will understand that the random value is a cryptographically generated random value used for checking if a valid recipient is responding.

In one implementation, when said access point receives said DTLS Synchronous Sequence Request message including said two sequence number value by said standby access controller and said random nonce, the standby access controller configured to: check if said two sequence number values assigned are suitable based on its prior knowledge of data transfer with previous active access controller; transmit, if said two sequence number values assigned are suitable, said DTLS Synchronous Sequence Response having a random nonce and same sequence number to said standby access controller; start a retransmission timer and retransmitting a DTLS Synchronous Sequence Response to said standby access controller until a receipt of said DTLS Synchronous Sequence Acknowledgement from said standby access controller; and resume current communication session after said DTLS Synchronous Sequence Acknowledgement is received by said access point.

In one implementation, said Datagram Transport Layer Security (DTLS) sequence number synchronization message comprises a type field / the message type field storing at least one of the a DTLS Synchronous Sequence Request, the DTLS Synchronous Sequence Response, and the DTLS Synchronous Sequence Acknowledgement; a send sequence number field storing send sequence number which is larger than the last seen send sequence number; a receive sequence number field storing expected receive sequence number which is larger than the last seen receive sequence number; a random field storing a random nonce generated and sent in the request and response keeping the same value as in the request, the random nonce is preferably 32 bytes in length; a padding field for block ciphers; and a padding length field.

Figure 10 illustratesa method for sequence number negotiation between at least one computing device and at least one peer device, wherein the computing device is configured to operate in a standby mode, in accordance with an embodiment of the present subject matter. The method may be described in the general context of computer executable instructions. Generally, computer executable instructions can include routines, programs, objects, components, data structures, procedures, modules, functions, etc., that perform particular functions or implement particular abstract data types. The method may also be practiced in a distributed computing environment where functions are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, computer executable instructions may be located in both local and remote computer storage media, including memory storage devices.

The order in which the method described is not intended to be construed as a limitation, and any number of the described method blocks can be combined in any order to implement the method or alternate methods. Additionally, individual blocks may be deleted from the method without departing from the protection scope of the subject matter described herein. Furthermore, the method can be implemented in any suitable hardware, software, firmware, or combination thereof. However, for ease of explanation, in the embodiments described below, the method may be considered to be implemented in the above described computing device106.

At block 1002, at least one indication indicating a switchover is received by a processor 902of the computing device106.

At block 1004, a handshake mechanism is initiated with the peer device for sequence number negotiation, using at least one synchronization protocol. The handshake mechanism may be initiated by the processor of the computing device after detecting the switchover.

At block 1006, at least two sequence numbers are generated. The sequence numbers may be generated by the processor of the computing devices.

At block 1008,the two sequence numbers are transmitted to the peer devices using at least one synchronization request message.

At block 1010, at least one synchronization response message with at least a sequence number as a response from the peer device is received by the processor of the computing device.

At block 1012, the response received from the peer device is analyzed.

At block 1014, at least one synchronization acknowledgement message based on the analysis is transmitted to the peer device as an indication of a secure session establishment.

At block 1016, the data to the peer device through the secure session established is communicated with the peer device.

Referring now to figure 11, a method for sequence number synchronization using a message exchange in a system 100 having at least one access point 102 and at least two access controllers104, 106 viz., an active access controller104 and a standby access controller106 is disclosed. The method comprises synchronizing 1102periodically a connection state and associated session key parameters between said active access controller and said standby access controller; and after said active access controller fail / in an event of failover: negotiating/ synchronizing1104 a sequence number between said standby access controller and said access point using a Datagram Transport Layer Security (DTLS) protocol transmitted as a Datagram Transport Layer Security (DTLS) sequence number synchronization messages based on prior negotiation of DTLS sequence number synchronization extension to resume current communication session without a new DTLS handshake.

In one implementation, a method for sequence number synchronization in a system having at least one access point and at least two access controllers viz., an active access controller and a standby access controller is disclosed. The method comprises negotiating/ synchronizing a sequence number between said standby access controller and said access point using a Datagram Transport Layer Security (DTLS) protocol transmitted as a Datagram Transport Layer Security (DTLS) sequence number synchronization message based on prior negotiation of DTLS sequence number synchronization extension to resume current communication session without a new DTLS handshake.

In one implementation, before negotiating/ synchronizing 1104 said sequence number, said active access controller and said access point are configured to intimate the capability of supporting said DTLS sequence number synchronization message by negotiating/ synchronizing said sequence number between said active access controller and said access point during initial DTLS handshake by including a “dtls_seq_num_sync” extension in a client hello message by said access point to intimate said capability to said active access controller, and if said active access controller is capable of supporting said sequence number synchronization, said active access controller is configured to include the same “dtls_seq_num_sync” extension in response to said hello message.

In one implementation, said Datagram Transport Layer Security (DTLS) protocol comprises at least three sequence number synchronization messages selected from a DTLS Synchronous Sequence Request, a DTLS Synchronous Sequence Response, and a DTLS Synchronous Sequence Acknowledgement.

In one implementation, the method comprises transmitting said three sequence number synchronization messages in an encrypted form, wherein said three sequence number synchronization messages comprises a message type field of 1 byte, to represent the DTLS Synchronous Sequence Request, the DTLS Synchronous Sequence Response, or the DTLS Synchronous Sequence Acknowledgement; a server sequence number field of 6 bytes; a client sequence number field of 6 bytes; a random number of 32 byte, and a padding length field as per encryption algorithm.

In one implementation, after said active access controller fails/ in an event of failover, said method comprises:
• selecting, using said standby access controller, at least two sequence numbers;
• transmitting, by said standby access controller, said two sequence number to said access point, using at least one DTLS Synchronous Sequence Request message;
• receiving, by said access point, said DTLS Synchronous Sequence Request message with said two sequence number, wherein said DTLS Synchronous Sequence Request message indicates said active access controller fail/ an event of failover; thereby
• processing, by said access point, said DTLS Synchronous Sequence Request message to confirm if said sequence number selected received in said DTLS Synchronous Sequence Request message is acceptable;
• transmitting, by said access point, said sequence number received, if acceptable, to said standby access controller, using at least one DTLS Synchronous Sequence Response; In one example, as access point already knows the last server and client sequence number used with first active access controller. Based on this if the received sequence numbers in said DTLS Synchronous Sequence Request message are greater than that, then said access point should accept it, or else it should decide a new server and client sequence number, which are greater than its known sequence numbers.
• (optionally) transmitting, by said access point, a new sequence number to said standby access controller, using at least one DTLS Synchronous Sequence Response if sequence numbers in said DTLS Synchronous Sequence Response message are not acceptable by said access point based on a knowledge of its previous data transfer with first active access controller;
• (optionally) transmitting, by said access point, a fatal error message, if not acceptable and not in a willingness to suggest a new sequence numbers (or not in a willingness to continue this DTLS connection), to said standby access controller and thereby terminating said current communication session; and
• receiving, by said standby access controller, said DTLS Synchronous Sequence Response, if not, terminating said current communication session, or transmitting at least one DTLS Synchronous Sequence Acknowledgement message to said access point.

In one implementation, the method comprises maintaining, by said access point and by said standby access controller, a time using a retransmission timer configured to retransmit at least one synchronization message selected from said three sequence number synchronization messages.

In one implementation, after said active access controller fails, said method comprises transmitting, by said standby access controller, a sequence number starting with value as one to said access point using at least one DTLS Synchronous Sequence Request message.

In one implementation, the method comprises said negotiating/synchronizing sequence number between said standby access controller and said access point is achieved if said standby access controller and said access point supports said Datagram Transport Layer Security (DTLS) sequence number synchronization i.e., “dtls_seq_num_sync”.

In one implementation, the method comprises checking, if said standby access controller and said access point supports sequence number synchronization, by negotiating/sharing a Datagram Transport Layer Security (DTLS) sequence number synchronization extension in a “hello” message having a syntax “dtls_seq_num_sync”.

In one implementation, when said active access controller fails, said method comprises:
• transmitting, by said standby access controller, at least one random value assigned to a random nonce field of said DTLS Synchronous Sequence Request message by said standby access controller, to said access point; In one example, the random value is a cryptographically generated random used for checking if a valid recipient is replying;
• starting, by said standby access controller, a retransmission timer and retransmitting a DTLS Synchronous Sequence Request to said access point until a receipt of a DTLS Synchronous Sequence Response from said access point;
• when said standby controller receives said DTLS Synchronous Sequence Response having a random nonce and a sequence number: comparing said random nonce in response with said random nonce in request, and if same, upgrading, by said standby access controller, said sequence number from response, and transmitting a DTLS Synchronous Sequence Acknowledgement message to said access point; and thereby
• resuming current communication session.

In one implementation, when said access point receives said DTLS Synchronous Sequence Request message including said two sequence number value by said standby access controller and said random nonce, the method comprises:
• checking, by said access point, if said two sequence number values assigned are suitable based on its prior knowledge of data transfer with previous active access controller;
• transmitting, by said access point, if said two sequence numbers assigned are suitable said DTLS Synchronous Sequence Response having the same random nonce as n the request message and same sequence numbers to said standby access controller;
• starting, by said access point, a retransmission timer and retransmitting a DTLS Synchronous Sequence Response to said active access controller until a receipt of said DTLS Synchronous Sequence Acknowledgement from said standby access controller; and
• resuming current communication session after said DTLS Synchronous Sequence Acknowledgement is received by said access point.

In one implementation, the present invention may be used in DTLS sever, where it may be deployed as redundant servers (active and standby). During switchover new active DTLS server will be able to use the DTLS sessions opened by previous active servers. As this DTLS sequence synchronization mechanism is exchanging only 3messages which consume very less time when compared to performing a fresh DTLS handshake. Because fresh DTLS handshake requires to do negotiation of ciphers, authentication and key generation, which involves minimum 11 messages. Few real time application of this mechanism in DTLS redundant server is mentioned below.
1- IoT Border Router: IoT Border router will use CoAP protocol on top of DTLS to communicate with all sensor nodes. Here to reduce the downtime redundant Border routers will be deployed. So using this mechanism on that will provide very minimal downtime even at switchover. Otherwise, there will be a notable downtime, if standby Border router needs to do fresh DTLS handshake with all sensor nodes (clients).
2- WLAN Access Controller: In WLAN, Access controller (AC) manages multiple number of Access Points (AP). Here CAPWAP protocol is used on top of DTLS. Here already redundant Access controllers are deployed to reduce the downtime, but during switchover currently it is doing fresh DTLS handshake with each AP. This is taking a quite long time as minimum 4000 APs are deployed. This mechanism will help to reduce the downtime of ACs in WLAN.
3- The present invention can be used in any other protocol also where sequence number or similar parameter needs to be negotiated by standby server and peer to reuse existing session, which improves the overall downtime during switchover.
4- Products like Access Controller and Access Points (part of WLAN) can use this invention to provide support for High Availability.

Figure 11illustrates a method for sequence number synchronization using a message exchange, in accordance with an embodiment of the present subject matter. The method may be described in the general context of computer executable instructions. Generally, computer executable instructions can include routines, programs, objects, components, data structures, procedures, modules, functions, etc., that perform particular functions or implement particular abstract data types. The method may also be practiced in a distributed computing environment where functions are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, computer executable instructions may be located in both local and remote computer storage media, including memory storage devices.

The order in which the method described is not intended to be construed as a limitation, and any number of the described method blocks can be combined in any order to implement the method or alternate methods. Additionally, individual blocks may be deleted from the method without departing from the protection scope of the subject matter described herein. Furthermore, the method can be implemented in any suitable hardware, software, firmware, or combination thereof. However, for ease of explanation, in the embodiments described below, the method may be considered to be implemented in the above described system 100.

In one implementation, a method for sequence number synchronization using a message exchange in a system (100) having at least one access point (102) and at least two access controllers (104, 106) viz., an active access controller (104) and a standby access controller (106) is disclosed. The method comprises:
synchronizing (1102) periodically a connection state and associated session key parameters between said active access controller and said standby access controller;
after said active access controller fail / in an event of failover:
negotiating/ synchronizing (1104) a sequence number between said standby access controller and said access point using a Datagram Transport Layer Security (DTLS) protocol transmitted as a Datagram Transport Layer Security (DTLS) sequence number synchronization messages based on prior negotiation of DTLS sequence number synchronization extension to resume current communication session without a new DTLS handshake.

In one implementation, before negotiating/ synchronizing (1104) said sequence number, said active access controller and said access point are configured to intimate the capability of supporting said DTLS sequence number synchronization message by negotiating/ synchronizing said sequence number between said active access controller and said access point during initial DTLS handshake by including a “dtls_seq_num_sync” extension in a client hello message by said access point to intimate said capability to said active access controller, and if said active access controller is capable of supporting said sequence number synchronization, said active access controller is configured to include the same “dtls_seq_num_sync” extension in response to said hello message.

In one implementation, the method comprises transmitting said three sequence number synchronization messages in an encrypted form, wherein said three sequence number synchronization messages comprises a message type field of 1 byte, to represent the DTLS Synchronous Sequence Request, the DTLS Synchronous Sequence Response, or the DTLS Synchronous Sequence Acknowledgement; a server sequence number field of 6 bytes; a client sequence number field of 6 bytes; a random number of 32 byte, and a padding length field as per encryption algorithm.

In one implementation, after said active access controller fails/ in an event of failover, said method comprises:
• selecting, using said standby access controller, at least two sequence numbers;
• transmitting, by said standby access controller, said two sequence number to said access point, using at least one DTLS Synchronous Sequence Request message;
• receiving, by said access point, said DTLS Synchronous Sequence Request message with said two sequence number, wherein said DTLS Synchronous Sequence Request message indicates said active access controller fail/ an event of failover; thereby
• processing, by said access point, said DTLS Synchronous Sequence Request message to confirm if said sequence number selected received in said DTLS Synchronous Sequence Request message is acceptable;
• transmitting, by said access point, said sequence number received, if acceptable, to said standby access controller, using at least one DTLS Synchronous Sequence Response; In one example, as access point already knows the last server and client sequence number used with first active access controller. Based on this if the received sequence numbers in said DTLS Synchronous Sequence Request message are greater than that, then said access point should accept it, or else it should decide a new server and client sequence number, which are greater than its known sequence numbers.
• (optionally) transmitting, by said access point, a new sequence number to said standby access controller, using at least one DTLS Synchronous Sequence Response if sequence numbers in said DTLS Synchronous Sequence Response message are not acceptable by said access point based on a knowledge of its previous data transfer with first active access controller;
• (optionally) transmitting, by said access point, a fatal error message, if not acceptable and not in a willingness to suggest a new sequence numbers (or not in a willingness to continue this DTLS connection), to said standby access controller and thereby terminating said current communication session; and
• receiving, by said standby access controller, said DTLS Synchronous Sequence Response, if not, terminating said current communication session, or transmitting at least one DTLS Synchronous Sequence Acknowledgement message to said access point.

In one implementation, the method comprises maintaining, by said access point and by said standby access controller, a time using a retransmission timer configured to retransmit at least one synchronization message selected from said three sequence number synchronization messages.

In one implementation, after said active access controller fails, said method comprises transmitting, by said standby access controller, a sequence number starting with value as one to said access point using at least one DTLS Synchronous Sequence Request message.

In one implementation, the method comprises said negotiating/synchronizing sequence number between said standby access controller and said access point is achieved if said standby access controller and said access point supports said Datagram Transport Layer Security (DTLS) sequence number synchronization i.e., “dtls_seq_num_sync”.

In one implementation, the method comprises checking, if said standby access controller and said access point supports sequence number synchronization, by negotiating/sharing a Datagram Transport Layer Security (DTLS) sequence number synchronization extension in a “hello” message having a syntax “dtls_seq_num_sync”.

In one implementation, when said active access controller fails, said method comprises:
• transmitting, by said standby access controller, at least one random value assigned to a random nonce field of said DTLS Synchronous Sequence Request message by said standby access controller, to said access point; In one example, the random value is a cryptographically generated random used for checking if a valid recipient is replying to us
• starting, by said standby access controller, a retransmission timer and retransmitting a DTLS Synchronous Sequence Request to said access point until a receipt of a DTLS Synchronous Sequence Response from said access point;
• when said standby controller receives said DTLS Synchronous Sequence Response having a random nonce and a sequence number:
• comparing said random nonce in response with said random nonce in request, and if same, upgrading, by said standby access controller, said sequence number from response, and transmitting a DTLS Synchronous Sequence Acknowledgement message to said access point; and thereby
• resuming current communication session.

In one implementation, when said access point receives said DTLS Synchronous Sequence Request message including said two sequence number value by said standby access controller and said random nonce,, the method comprises:
• checking, by said access point, if said two sequence number values assigned are suitable based on its prior knowledge of data transfer with previous active access controller;
• transmitting, by said access point, if said two sequence numbers assigned are suitable said DTLS Synchronous Sequence Response having the same random nonce as n the request message and same sequence numbers to said standby access controller;
• starting, by said access point, a retransmission timer and retransmitting a DTLS Synchronous Sequence Response to said active access controller until a receipt of said DTLS Synchronous Sequence Acknowledgement from said standby access controller; and
• resuming current communication session after said DTLS Synchronous Sequence Acknowledgement is received by said access point.

In one implementation, the present invention may be used in DTLS sever, where it may be deployed as redundant servers (active and standby). During switchover new active DTLS server will be able to use the DTLS sessions opened by previous active servers. As this DTLS sequence synchronization mechanism is exchanging only 3 messages which consume very less time when compared to performing a fresh DTLS handshake. Because fresh DTLS handshake requires to do negotiation of ciphers, authentication and key generation, which involves minimum 11 messages. Few real time application of this mechanism in DTLS redundant server is mentioned below.
5- IoT Border Router: IoT Border router will use CoAP protocol on top of DTLS to communicate with all sensor nodes. Here to reduce the downtime redundant Border routers will be deployed. So using this mechanism on that will provide very minimal downtime even at switchover. Otherwise, there will be a notable downtime, if standby Border router needs to do fresh DTLS handshake with all sensor nodes (clients).
6- WLAN Access Controller: In WLAN, Access controller (AC) manages multiple number of Access Points (AP). Here CAPWAP protocol is used on top of DTLS. Here already redundant Access controllers are deployed to reduce the downtime, but during switchover currently it is doing fresh DTLS handshake with each AP. This is taking a quite long time as minimum 4000 APs are deployed. This mechanism will help to reduce the downtime of ACs in WLAN.

7- The present invention can be used in any other protocol also where sequence number or similar parameter needs to be negotiated by standby server and peer to reuse existing session, which improves the overall downtime during switchover.
8- Products like Access Controller and Access Points (part of WLAN) can use this invention to provide support for High Availability.

Apart from the certain advantages discussed above the aspects of the disclosure provides the advantages as discussed below:
The present invention enables reusing the existing DTLS session by standby server during switchover time thereby providing high availability on DTLS.
High Availability Support
? This present invention extends the DTLS protocol support for High Availability Scenario.
? Any product using DTLS for application layer security can implement high availability with minimal message exchange between Server and Client.
? DTLS is the security protocol used in CAPWAP which is used between Access Point and Access Controllers. This helps in improving fault tolerance of CAPWAP networks by providing support for High Availability.
? WLAN, Access Router and Border Router of IoT are some of the Products which are using DTLS. This will be quite beneficial for them.
Latency Reduction
? If present invention is not supported by the system, then on switchover from active to standby, all the DTLS connections with clients should be re-established which will be resource intensive and also consume a lot of time, which will give a notable down time to end users even with redundant servers.

Usefulness in new domains like IoT
? DTLS is becoming the de-facto protocol in IoT domain due to its usage over UDP and CoAP (most famous application protocol for IoT) mandating the use of DTLS for its security.
? This present invention helps in IoT domain for High availability scenarios where multiple border routers are placed for redundancy. Generally the application layer security between Border Routers and Nodes is implemented using DTLS, so this invention will help in avoiding resource intensive activity of re-doing the DTLS handshake in case of switch-over between Border Routers.
The present invention enables reusing the existing DTLS session by standby server during switchover time thereby providing high availability on DTLS.
High Availability Support
? This present invention extends the DTLS protocol support for High Availability Scenario.
? Any product using DTLS for application layer security can implement high availability with minimal message exchange between Server and Client.
? DTLS is the security protocol used in CAPWAP which is used between Access Point and Access Controllers. This helps in improving fault tolerance of CAPWAP networks by providing support for High Availability.
? WLAN, Access Router and Border Router of IoT are some of the Products which are using DTLS. This will be quite beneficial for them.
Latency Reduction
? If present invention is not supported by the system, then on switchover from active to standby, all the DTLS connections with clients should be re-established which will be resource intensive and also consume a lot of time, which will give a notable down time to end users even with redundant servers.

Usefulness in new domains like IoT
? DTLS is becoming the de-facto protocol in IoT domain due to its usage over UDP and CoAP (most famous application protocol for IoT) mandating the use of DTLS for its security.
? This present invention helps in IoT domain for High availability scenarios where multiple border routers are placed for redundancy. Generally the application layer security between Border Routers and Nodes is implemented using DTLS, so this invention will help in avoiding resource intensive activity of re-doing the DTLS handshake incase of switch-over between Border Routers.

A person of ordinary skill in the art may be aware that in combination with the examples described in the embodiments disclosed in this specification, units and algorithm steps may be implemented by electronic hardware, or a combination of computer software and electronic hardware. Whether the functions are performed by hardware or software depends on the particular applications and design constraint conditions of the technical solution. A person skilled in the art may use different methods to implement the described functions for each particular application, but it should not be considered that the implementation goes beyond the scope of the present invention.

It may be clearly understood by a person skilled in the art that for the purpose of convenient and brief description, for a detailed working process of the foregoing system, apparatus, and unit, reference may be made to a corresponding process in the foregoing method embodiments, and details are not described herein again.

In the several embodiments provided in the present application, it should be understood that the disclosed system, apparatus, and method may be implemented in other manners. For example, the described apparatus embodiment is merely exemplary. For example, the unit division is merely logical function division and may be other division in actual implementation. For example, a plurality of units or components may be combined or integrated into another system, or some features may be ignored or not performed. In addition, the displayed or discussed mutual couplings or direct couplings or communication connections may be implemented through some interfaces. The indirect couplings or communication connections between the apparatuses or units may be implemented in electronic, mechanical, or other forms.

The units described as separate parts may or may not be physically separate, and the parts displayed as units may or may not be physical units, may be located in one position, or may be distributed on a plurality of network units. Some or all of the units may be selected to achieve the objective of the solution of the embodiment according to actual needs.

In addition, functional units in the embodiments of the present invention may be integrated into one processing unit, or each of the units may exist alone physically, or two or more units may be integrated into one unit.

When the functions are implemented in a form of a software functional unit and sold or used as an independent product, the functions may be stored in a computer-readable storage medium. Based on such an understanding, the technical solutions of the present invention essentially, or the part contributing to the prior art, or a part of the technical solutions may be implemented in a form of a software product. The computer software product is stored in a storage medium, and includes several instructions for instructing a computer device (which may be a personal computer, a server, or a network device) to perform all or a part of the steps of the methods described in the embodiment of the present invention. The foregoing storage medium includes: any medium that can store program code, such as a USB flash drive, a removable hard disk, a read-only memory (Read-Only Memory, ROM), a random access memory (Random Access Memory, RAM), a magnetic disk, or an optical disc.

Although implementations for a system and method providing support for high availability services in applications through secure exchange of sequence number using new DTLS sequence synchronization protocol have been described in language specific to structural features and/or methods, it is to be understood that the appended claims are not necessarily limited to the specific features or methods described. Rather, the specific features and methods are disclosed as examples of implementations of the system and method for providing high availability services in applications through secure exchange of record information by means of a Datagram Transport Layer Security (DTLS) protocol.