WO2014139646A1

WO2014139646A1 - Communication in a dynamic multipoint virtual private network

Info

Publication number: WO2014139646A1
Application number: PCT/EP2014/000568
Authority: WO
Inventors: Parag Narayanrao Pote
Original assignee: Alcatel Lucent
Priority date: 2013-03-13
Filing date: 2014-03-05
Publication date: 2014-09-18
Also published as: IN2013DE00727A

Abstract

Systems and methods to establish connection among spoke device communication systems in a dynamic multipoint virtual private network (DMVPN) are described. According to the present subject matter, the system(s) implement the described method(s) for establishing connection among the spoke communication systems. The method includes receiving a NHRP request from a primary spoke device communication system (PSDCS) for providing routing information of a secondary spoke device communication system (SSDCS). The method also includes determining the routing information corresponding to the SSDCS based on a NHRP table. The method further includes providing a primary NHRP reply to the PSDCS including the routing information corresponding to the SSDCS, and providing a secondary NHRP reply to the SSDCS including the routing information corresponding to the PSDCS, where the routing information corresponding to the PSDCS comprises at least a public IP address of the PSDCS.

Description

COMMUNICATION IN A DYNAMIC MULTIPOINT VIRTUAL PRIVATE

NETWORK

TECHNICAL FIELD

[0001] The present subject matter relates to communication networks and, particularly, but not exclusively, to Dynamic Multipoint Virtual Private Networks (DMVPN).

BACKGROUND

[0002] Communication networks have made communication possible between different computers by providing an interconnection between the computers through a plurality of connectivity devices, such as switches and routers. The connectivity devices make use of available routing information to perform routing decisions to facilitate data transfer between different computers.

[0003] A virtual private network (VPN) is a communication network that makes use of the public communication infrastructure, such as Internet, to provide a secure communication channel between two private network entities. VPNs are widely used for communication by countless number of telecommuters, extranet users and mobile workers to access corporate network resources.

[0004] The VPN has now evolved into different flavors one of which is

Dynamic Multipoint Virtual Private Network (DMVPN). The DMVPN is a dynamic tunneling form of a VPN based on standard protocols, such as multipoint Generic Routing Encapsulation (mGRE), Next-Hop Resolution Protocol (NHRP) and Internet Protocol Security (IPSec). The DMVPN is generally configured to build a hub-and-spoke network by statically configuring the hubs on the spokes. Using the hub-and-spoke network, tunnels between spokes can be dynamically built on demand (dynamic-mesh) without additional configuration on the hubs or existing spokes. The DMVPN uses hub-and-spoke for control and management of data traffic, and mesh for control and management of user data traffic. SUMMARY

[0005] This summary is provided to introduce concepts related to establishing connection among spoke device communication systems in a dynamic multipoint virtual private network (DMVPN). 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.

[0006] In one implementation, a method for establishing connection among spoke device communication systems in a DMVPN is described. The method comprises receiving a Next Hop Resolution Protocol (NHRP) request for providing routing information of a secondary spoke device communication system (SSDCS), from a primary spoke device communication system (PSDCS). The NHRP request comprises at least a tunnel Internet Protocol (IP) address associated with the SSDCS. The method further comprises determining the routing information corresponding to the SSDCS based on a NHRP table, where the NHRP table is indicative of a mapping among tunnel IP address and public IP address of spoke device communication systems. The method further comprises providing a primary NHRP reply to the PSDCS including the routing information corresponding to the SSDCS. The method further comprises providing a secondary NHRP reply to the SSDCS including the routing information corresponding to the PSDCS, where the routing information corresponding to the PSDCS comprises at least a public IP address of the PSDCS.

[0007] In one implementation, a method for establishing connection among spoke device communication systems in a DMVPN is described. The method may comprise requesting a hub communication system (HCS) for routing information of a SSDCS, through a NHRP request. The routing information comprises at least a public IP address of the SSDCS. The method further comprises receiving routing information from the HCS through a primary NHRP reply. The method further comprises configuring a port based on the received routing information to selectively exchange data with the SSDCS. [0008] In one implementation, a spoke device communication system

(SDCS) for establishing connection with other spoke device communication system(s) in a DMVPN is described. The SDCS comprises a processor, and a NHRP module coupled to the processor. The NHRP module is adapted to generate a NHRP request to request routing information for a SSDCS. The routing information for the SSDCS is requested from a HCS, through a NHRP request. The NHRP module is further adapted to receive the routing information from the HCS through a primary NHRP reply, where the routing information comprises at least a public IP address of the SSDCS. The NHRP module is further adapted to configure a port based on the received routing information to selectively exchange data with the SSDCS.

[0009] In one implementation, a spoke device communication system

(SDCS) for establishing connection with other spoke device communication system(s) in a DMVPN is described. The SDCS comprises a processor, and a NHRP module coupled to the processor. The NHRP module is adapted to receive routing information corresponding to a PSDCS through a secondary NHRP reply from a HCS, where the routing information corresponding to the PSDCS comprises at least a public IP address of the PSDCS. The NHRP module is further adapted to configure a port based on the received routing information to selectively exchange data with the PSDCS.

[0010] In one implementation, a HCS for establishing connection among spoke device communication systems in a DMVPN is described. The HCS comprises a processor and a request receiving module coupled to the processor. The request receiving module is adapted to receive a NHRP request from a PSDCS for providing routing information of a SSDCS, where the NHRP request comprises at least a tunnel IP address associated with the SSDCS. The HCS further comprises a NHRP response module coupled to the processor. The NHRP response module is adapted to determine the routing information corresponding to the SSDCS based on a NHRP table, where the NHRP table is indicative of a mapping among tunnel IP address and public IP address of spoke device communication systems. The NHRP response module is further adapted to provide a primary NHRP reply to the PSDCS including the routing information corresponding to the SSDCS and provide a secondary NHRP reply to the SSDCS including the routing information corresponding to the PSDCS, where the routing information corresponding to the PSDCS comprises at least a public IP address of the PSDCS corresponding to the tunnel IP address.

[0011] In one implementation, a non-transitory computer readable medium having a set of computer readable instructions that, when executed, cause a computing system to perform a process is described. The process comprises requesting a HCS for routing information of a secondary spoke device communication system (SSDCS), through a NHRP request. The routing information comprises at least a public IP address of the SSDCS. The process further comprises receiving routing information from the HCS (102) through a primary NHRP reply and configuring a port based on the received routing information to selectively exchange data with the SSDCS.

[0012] In one implementation, a non-transitory computer readable medium having a set of computer readable instructions that, when executed, cause a computing system to perform a process is described. The process comprises receiving a NHRP request for providing routing information of a SSDCS, from a PSDCS. The NHRP request comprises at least a tunnel IP address associated with the SSDCS. The process further comprises determining the routing information corresponding to the SSDCS based on a NHRP table, where the NHRP table is indicative of a mapping among tunnel IP address and public IP address of spoke device communication systems. The process further comprises providing a primary NHRP reply to the PSDCS including the routing information corresponding to the SSDCS. The process further comprises providing a secondary NHRP reply to the SSDCS including the routing information corresponding to the PSDCS, where the routing information corresponding to the PSDCS comprises at least a public IP address of the PSDCS. BRIEF DESCRIPTION OF THE FIGURES

[0013] 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 figures to reference like features and components. Some embodiments of system and/or methods in accordance with embodiments of the present subject matter are now described, by way of example only, and with reference to the accompanying figures, in which:

[0014] Fig. 1 illustrates a communication network environment implementing a DMVPN, according to an embodiment of the present subject matter;

[0015] Fig. 2 schematically illustrates a hub communication system and a spoke device communication system, according to an embodiment of the present subject matter;

[0016] Fig. 3(a) illustrates a method for establishing communication between spoke device communication systems, according to an embodiment of the present subject matter;

[0017] Fig. 3(b) illustrates a method for communication by a hub communication system of DMVPN , according to an embodiment of the present subject matter; and

[0018] Fig. 3(c) illustrates another method for establishing communication between spoke device communication systems, according to an embodiment of the present subject matter.

[0019] It should be appreciated by those skilled in the art that any block diagram herein, represent conceptual views of illustrative systems embodying the principles of the present subject matter. Similarly, it will be appreciated that any flow charts, flow diagrams, and the like represent various processes which may be substantially represented in computer readable medium and so executed by a computer or processor, whether or not such computer or processor is explicitly shown.

DESCRIPTION OF EMBODIMENTS

[0020] Systems and methods to establish connection among spoke device communication systems in a dynamic multipoint virtual private network (DMVPN), is described herein. The methods can be implemented in various communication devices communicating through various DMVPNs used by telecommuters, extranet users and mobile workers to access network resources. Although the description herein is with reference to a DMVPN, the methods and the systems may be implemented in other networks providing dynamic addition of devices or a subnet of devices to the network, albeit with a few variations, as will be understood by a person skilled in the art.

[0021] Generally, primary enterprise resources are located in a large central site, with a number of smaller sites or branch offices at various geographical locations connected directly to the central site over a virtual private network (VPN). Typically communication in the VPNs is performed by implementing Internet Protocol Security (IPSec) protocol suite to provide secure and private communication channel over the public communication infrastructure. The IPSec protocol suite uses various protocols, such as Internet Key Exchange (IKE), (IKEv2) and Encapsulating Security Payload (ESP) or Authentication Headers (AH) to establish shared security attributes between two network entities to support secure communication.

[0022] Typically in a DMVPN topology, the primary enterprise resources located at the central site acts as a hub and the smaller sites or branch offices acts as spokes. Whenever a spoke is online it is allocated a dynamic internet protocol (IP) address and this information is communicated to the hub by formation of an Internet Protocol Security (IPSec) tunnel along with a Generic Routing Encapsulation (GRE). Such an environment is essentially a DMVPN built with hub- and-spoke topology. [0023] In a DMVPN built, when a spoke device, say a system connected to a primary spoke device wishes to communicate with a system connected to another spoke device, say a secondary spoke device; the primary spoke device establishes a communication tunnel with the secondary spoke device. The primary spoke device may establish the communication tunnel with the secondary spoke device, using the public IP address of the secondary spoke device. Since the public IP addresses of the spoke devices are dynamically allocated in the DMVPN, this information is available only at the hub. Hence, the primary spoke device may send a Next-Hop Resolution Protocol (NHRP) request to hub requesting for the public IP information of the secondary spoke device. NHRP is a protocol which allows a primary spoke device, wishing to communicate with a secondary spoke device, to determine the route toward the secondary spoke device. Thereafter, based on the Public IP address received from the hub in response to the NHRP request, the primary spoke device may establish the communication channel with the secondary spoke device, with an IKE session. IKE session is based on IKE protocol to set up a security association (SA) in the IPSec protocol suite.

[0024] Typically, in anticipation of an IKE session with the primary spoke device, the secondary spoke device would keep the IKE port open at all times. In such a scenario, the open IKE port make invite for security threats, such as IKE attacks and flooding attacks that may make the spoke devices vulnerable.

[0025] In order to protect a system from such security threats, firewalls are often used. A firewall may filter out the IKE data originating from unknown IP addresses to protect the system. Although, this provides the required security in case of static IP networks, but in dynamic IP networks, such as DMVPNs where the IP addresses of the spokes and connection requesting entities are unavailable a priori; the firewall may reject a valid request from an unknown source with unknown dynamic public address, causing dropping of genuine and authentic connection requests. Although, if an administrator is aware about all spoke IP addresses in advance, he may add an Access Control List (ACL) to allow IKE data only from those IP addresses and drop everything else. But in a DMVPN scenario, this is not possible since the DMVPN allows dynamic IP address allocation at spokes.

[0026] According to an implementation of the present subject matter, systems and methods to establish connection among spoke device communication systems in a dynamic multipoint virtual private network (DMVPN) are described. In said implementation, the systems and the methods may allow selective establishment of IKE channels in the DMVPN.

[0027] A primary spoke device may communicate with the hub through a NHRP request to determine the public IP address of a secondary spoke device, to establish a connection with the secondary spoke device. In one implementation of the present subject matter, based on the NHRP request, the hub may send two NHRP replies, a primary NHRP reply to the primary spoke device and a secondary NHRP reply to the secondary spoke device. Although the hub sends two replies based on a single NHRP request, the information included in each reply may be different. The primary NHRP reply may include, amongst other information, public IP information of the secondary spoke device. The secondary NHRP reply may include public IP information of the primary spoke device. Upon receiving of the primary NHRP reply, the primary spoke device may open an IKE port for the secondary spoke device for a pre-determined time period and similarly, upon receiving of the secondary NHRP reply the secondary spoke device may open an IKE port for the primary spoke device for the pre-determined time period.

[0028] According to another implementation of the present subject matter, the spoke devices may also implement firewalls for the purpose of security and content filtering. In such a scenario, according to the said implementation, the firewalls may be configured to receive a NHRP reply from the hub based on which, the firewall may determine the public IP address of another device with which connection is to be established. Upon determining the public IP address of another device, the firewall may open the IKE port for a pre-determined time period for another device. For example, upon receiving of the primary NHRP reply a firewall of the primary spoke device, say a primary firewall, may open an IKE port for the secondary spoke device for a pre-determined time period. And similarly, upon receiving the secondary NHRP reply, a firewall of the secondary spoke device, say a secondary firewall, may open an IKE port for the primary spoke device for the pre-determined time period.

[0029] The systems and the methods as described herein provide establishment of secure tunnel for communication between spoke devices in the DM VPN. Further, the IKE ports can be selectively opened at the spoke devices for a pre-determined time period. It further allows selective opening of pin holes at the firewalls of the spoke devices to facilitate the IKE session upon valid request.

[0030] It should be noted that the description merely illustrates the principles of the present subject matter. It will thus be appreciated that those skilled in the art will be able to devise various arrangements that, although not explicitly described herein, embody the principles of the present subject matter and are included within its spirit and scope. Furthermore, all examples recited herein are principally intended expressly to be only for pedagogical purposes to aid the reader in understanding the principles of the invention and the concepts contributed by the inventor(s) to furthering the art, and are to be construed as being without limitation to such specifically recited examples and conditions. Moreover, all statements herein reciting principles, aspects, and embodiments of the invention, as well as specific examples thereof, are intended to encompass equivalents thereof.

[0031] The manner in which the systems and the methods of present subject matter shall be implemented has been explained in details with respect to the Figures 1 -3. While aspects of described systems and methods for providing connectivity between spoke devices can be implemented in any number of different computing systems, transmission environments, and/or configurations, the embodiments are described in the context of the following exemplary system(s).

[0032] As described further below, according to various example implementations of the disclosed subject matter described herein, there is provided systems and methods for setting up Internet Key Exchange (IKE) channel between communication network nodes in the DMVPN to improve point to point communication.

[0033] Fig. 1 illustrates a communication network environment 100, according to an implementation of the present subject matter. As shown, the communication network environment 100 includes at least one hub communication system (HCS) 102, logically connected to one or more spoke device communication systems (SDCSs) 104-1 , 104-2, 104-3, .... 104-N, through a communication network 106. The spoke device communication systems 104-1 , 104-2,104-3, 104-N are collectively referred to as SDCSs 104, and individually referred to as SDCS 104, hereinafter. The logical connections of the HCS 102 and the SDCS 104 through the communication network 106 may be facilitated by various routers 110-1 , 1 10-2, 1 10-3, ..... 10-N, collectively referred to as routers 110 and individually referred to as router 1 10 hereinafter.

[0034] The HCS 102 may be implemented in a router 108. The HCS 102 may further be implemented in a variety of servers and communication devices or, may be logically coupled to the servers, such as server 112. The servers that can implement the HCS 102 include, but are not limited to, hub server, VPN server, DMVPN server, mail server, central directory servers, database server, file server, print server, web server, application server, and the like. Although the description herein is with reference to hub servers, the methods and the systems may be implemented in other servers supporting DMVPN services, albeit with a few variations, as will be understood by a person skilled in the art. The HCS 102 may also be implemented in a computing device, such as a laptop computer, a desktop computer, a notebook, a workstation, a mainframe computer, a server, a firewall, a device implementing firewall, and the like. The HCS 102 described herein, can also be implemented in any network environment comprising a variety of network devices, including routers, bridges, servers, computing devices, storage devices, etc.

[0035] In another implementation, the SDCSs 104 may be implemented in the routers 1 10. Further, the communication between the HCS 102 and the SDCSs 104 may be facilitated through one or more firewalls, such as firewall 1 3. In such situations, the SDCSs 104 may be implemented in the firewall 1 13, such as the SDCS 104-3. In said implementation, the routers 110 may further be connected to various user devices 1 14-1 , 1 14-2, 1 14-3, 114-N, collectively referred to as user devices 1 4 and individually referred to as user device 114, hereinafter.

[0036] Further, the HCS 102 may include a NHRP response module 116 configured to send responses to SDCS 104. In one implementation, a NHRP module 1 18 configured to generate NHRP request and process NHRP replies is implemented in the SDCSs 104 to communicate with the HCS 102. For the purpose of explanation, the NHRP module 1 18 is shown in the SDCS 104-1 , it would be understood that the other SDCSs 104 would implement the same. Although the SDCS 104 may be implemented in physical equipments used by users, such as telecommuters, extranet users and mobile workers, to communicate with each other. The SDCSs 104 also be implemented in, but not limited to, desktop computers, hand-held devices, subnet supporting devices, laptops or other portable computers, network computers, mobile phones, landline phones, routers, firewalls, and the like. Further, the SDCSs 104 while implemented in firewalls, gateways, routers, bridges may allow connection between communication devices, and the HCS 102.

[0037] In another implementation, the SDCSs 104 may include, but not limited to, desktop computers, hand-held devices, subnet supporting devices, laptops or other portable computers, network computers, mobile phones, landline phones, routers, firewalls, and the like. Each of the SDCS 104 may allow communication based on a communication protocol as defined by the communication network 106 to which the SDCSs 104 are connected.

[0038] The communication network 106 may be a wireless or a wired network, or a combination thereof. The communication network 106 can be a collection of individual networks, interconnected with each other and functioning as a single large network (e.g., the internet or an intranet). Examples of such individual networks include, but are not limited to, Wide Area Networks (WAN), Metropolitan Area Networks (MAN), Local Area Networks (LAN), Campus Area Networks (CAN), Virtual Private Networks (VPN), Global System for Mobile Communication (GSM) network, Universal Mobile Telecommunications System (UMTS) network, Personal Communications Service (PCS) network, Time Division Multiple Access (TDMA) network, Code Division Multiple Access (CDMA) network, Next Generation Network (NGN), Public Switched Telephone Network (PSTN), and Integrated Services Digital Network (ISDN). Depending on the technology, the communication network 106 includes various network entities, such as switches, gateways, conventional network backbones, long-haul telephone lines, Internet service providers, various levels of network routers, and other conventional means for routing data between computers; however, such details have been omitted for the sake of brevity.

[0039] In accordance with various implementations described herein, each

SDCS 104 may initially register itself with the HCS 102. When the SDCS 104 registers with the HCS 102, the SDCS 104 may provide its routing information, such as public IP address, GRE tunnel IP address, as part of a set of spoke device registration information. For example, when the SDCS 104-3 becomes online and is allocated with a dynamic IP address, it may register its routing information with the HCS 102. During this process, the SDCS 104-3 may provide its public IP address, along with other details, to the HCS 102. The HCS 102 may store the spoke device registration information in a HCS registration table, such as a NHRP table. The HCS 102 thereby may update the NHRP table with the SDCS's 104-3 registration information. In this manner, the HCS 102 maintains routing information for all the registered SDCSs 104.

[0040] For the purposes of explanation of the present subject matter, a

SDCS 104 initiating a communication with another SDCS 104 is referred to as a primary spoke device communication system (PSDCS). Similarly, another SDCS 104 with which the PSDCS may wish to establish a connection with, is referred to as a secondary spoke device communication system (SSDCS) hereinafter. It will be understood that the described methods for the PSDCSs and the SSDCSs may be implemented to other spoke device communication systems as well.

[0041] It would be appreciated by those skilled in the art that the communication initiated by the PSDCS may either be triggered by an entity, such as the user device 114 or may be initiated suo-moto. For example, when the SDCS 104 is implemented in the router 1 0-1 , the initiation of communication may be based on a trigger from the user device 1 14-1 connected to a router 1 10-1. Similarly, the communication may be initiated by the SDCS 104 independently without any trigger from the user device 1 14-1.

[0042] In order to exchange data, the PSDCS may establish a communication tunnel with the SSDCS. However, to establish the said communication tunnel with the SSDCS, the PSDCS may obtain the routing information, such as public IP address of the SSDCS from tunnel endpoint IP address. The PSDCS obtains the routing information of the SSDCS from the HCS 102 where the HCS 102 stored the routing information in a NHRP table.

[0043] In one implementation of the present subject matter, to obtain the routing information of the SSDCS, the PSDCS may send a NHRP request to the HCS 102, requesting for routing information of the SSDCS. The NHRP request may include information, such as tunnel IP address of the SSDCS, which can be used by the HCS 102 to identify the details associated with the SSDCS. The NHRP request is sent over the IPSec tunnel between the PSDCS and the HCS 102. The HCS 102 may extract the information specific to SSDCS, and identify the corresponding public IP address of the SSDCS from the NHRP table.

[0044] In one implementation of the present subject matter, the HCS 102 may include the NHRP response module 1 16 to provide NHRP responses to the SDCSs 104. In said implementation, in response to the NHRP request received by the PSDCS, the NHRP response module 1 16 may send the identified public IP address of the SSDCS to the PSDCS, through a primary NHRP reply. Further, according to the said implementation, the NHRP response module 116 may also send the public IP address of the PSDCS to the SSDCS, through a secondary NHRP reply. Although it has been described that the exchange of NHRP request and NHRP replies may occur over IPSec tunnels between the HCS 102 and the SDCS 104. Based on the responses received, a communication is established between the PSDCS and the SSDCS. The communication may be established by establishment of the IKE tunnel between the PSDCS and the SSDCS, by selective configuring of the ports of the PSDCS and the SSDCS.

[0045] Fig. 2 schematically illustrates different components of the HCS 102 and the SCDS 104-2, according to an implementation of the present subject matter. In said implementation, the components of the SDCS 104-2 implemented in the router 1 10-2 have been described for the sake of explanation, from amongst multiple SDCSs 104. It would be understood by those skilled in the art that the HCS 102 and the SDCS 104-2, or equivalents thereof, may be implemented in a different manner, without digressing from the scope and spirit if the present subject matter.

[0046] The HCS 102 and the SDCS 104-2 include processors 202-1 , 202-2, collectively referred to as processor 202 hereinafter. The processor 202 can be a single processing unit or a number of units, all of which could include multiple computing units. The processor(s) 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 processor(s) are configured to fetch and execute computer-readable instructions stored in the memory. The memory may include any computer-readable medium known in the art including, for example, volatile memory, such as SRAMs and DRAMs and/or non-volatile memory such as EPROMs and flash memories.

[0047] The functions of the various elements shown in the figure, including any functional blocks labeled as "processor(s)", may be provided through the use of dedicated hardware as well as hardware capable of executing software in association with appropriate software. When provided by a processor, the functions may be provided by a single dedicated processor, by a single shared processor, or by a plurality of individual processors, some of which may be shared. Moreover, explicit use of the term "processor" should not be construed to refer exclusively to hardware capable of executing software, and may implicitly include, without limitation, digital signal processor (DSP) hardware, network processor, application specific integrated circuit (ASIC), field programmable gate array (FPGA), read only memory (ROM) for storing software, random access memory (RAM), non-volatile storage. Other hardware, conventional and/or custom, may also be included.

[0048] Also, the HCS 102 and the SDCS 104-2 include interface(s) 204-1 , 204-2, collectively referred to as interfaces 204 hereinafter. The interfaces 204 may include a variety of software and hardware interfaces that allow the HCS 02 and the SDCSs 04 to interact with the communication network 106, or with each other. Further, the interfaces 204 may enable the hub 102 and the SDCS 104-2 to communicate with other communication and computing devices, such as web servers and external repositories. The interfaces 204 may facilitate multiple communications within a wide variety of networks and protocol types, including wire networks, for example, LAN, cable, etc., and wireless networks, for example, WLAN, cellular, satellite-based network, etc.

[0049] The HCS 102 and the SDCS 104-2 may also include memory 206-1 , and 206-2, respectively, collectively referred to as memory 206 hereinafter. The memory 206-1 and 206-2 may be coupled to the processor 202-1 , and the processor 202-2, respectively. The memory 206 may include any computer- readable medium known in the art including, for example, volatile memory (e.g., RAM), and/or non-volatile memory (e.g., EPROM, flash memory, etc.). [0050] The HCS 102 and the SDCS 104-2 includes modules 208-1 , 208-2 and data 210-1 , 210-2, respectively, collectively referred to as modules 208 and data 210, respectively. The modules 208 may be coupled to the processors 202. The modules 208 include routines, programs, objects, components, data structures, and the like, which perform particular tasks or implement particular abstract data types. The modules 208 further include modules that supplement applications on the HCS 102 and the SDCS 104-2, for example, modules of an operating system. The data 210 serves, amongst other things, as a repository for storing data that may be fetched, processed, received, or generated by one or more of the modules 208. Although the data 210 is shown internal to the HCS 102, and the SDCS 104-2, it may be understood that the data 210 can reside in an external repository (not shown in figure).

[0051] In an implementation of the present subject matter, the modules 208-

1 of the HCS 102 include a request receiving module 212, an authentication module 214-1 , a routing module 216, the NHRP response module 1 16, and other module(s) 218-1. In said implementation, the data 210-1 of the HCS 102 includes authentication data 220-1 , routing data 222, and other data 224-1. The other module(s) 218-1 may include programs or coded instructions that supplement applications and functions, for example, routing encapsulation support modules, programs in the operating system of the HCS 102, etc., and the other data 224-1 comprise data corresponding to one or more other module(s) 218-1.

[0052] Similarly, in an implementation, the modules 208-2 of the SDCS 104-

2 include the NHRP module 118, an authentication module 214-2, a communication module 228, and other module(s) 218-2. In said implementation, the data 210-2 of the SDCS 104-2 includes authentication data 220-2, communication data 234, and other data 224-2. The other module(s) 218-2 may include programs or coded instructions that supplement applications and functions, for example, routing encapsulation support modules, programs in the operating system of the SDCS 104-2, etc., and the other data 224-2 comprise data corresponding to one or more other module(s) 218-2.

[0053] For the sake of explanation and clarity, the SDCS 104-2 is considered as the primary SDCS (PSDCS), and the SDCS 104-1 is considered as the secondary SDCS (SSDCS). In an implementation of the present subject matter, the PSDCS may establish a communication tunnel with the SSDCS. The PSDCS may send a NHRP request to the HCS 102, requesting the routing information of the SSDCS.

[0054] In an implementation of the present subject matter, the NHRP module

118 of the PSDCS is configured to generate the NHRP request. The NHRP request may include information, such as tunnel IP address of the SSDCS, which can be used by the HCS 102, to identify the routing information associated with the SSDCS. The PSDCS and the HCS 102 may have agreed upon a set of security associations and may have established an IPSec tunnel based on the agreed upon security associations. The agreed upon security associations may be saved in the authentication data 220-1 and 220-2 of the HCS 102 and the SDCS 104-1. Hence, the HCS 02 and the SDCS 104-1 may establish the IPSec tunnel based on the security associations.

[0055] In an implementation, the NHRP request generated by the NHRP module 118 may be encapsulated and encrypted by the authentication module 214-2, using the agreed upon security associations saved in authentication data 220-2. The encrypted and encapsulated NHRP request may be sent to the HCS 102 through the IPSec tunnel.

[0056] In an implementation, the communication module of PSDCS is configured to determine the next gateway or hop along the path to the HCS 102 using the communication data 234. The next hop determined may be used and the encrypted and encapsulated NHRP request can be transmitted to the HCS 102 over the IPSec tunnel using the interface(s) 204-2 of the PSDCS.

[0057] Further, in an implementation, the PSDCS may receive a primary

NHRP reply from the HCS 102 in response to the NHRP request. The primary NHRP reply may be received over the IPSec tunnel between the PSDCS and the HCS 102. The primary NHRP reply may be received through the interface(s) 204-2 of the PSDCS. The NHRP module 1 18 of the PSDCS receives the primary NHRP reply. The authentication module 214-2 of PSDCS is configured to use the authentication data 234 and decapsulate and decrypt the primary NHRP reply. [0058] Further, in an implementation, the NHRP module 1 18 of PSDCS is also configured to process the primary NHRP reply. The NHRP module 1 18 of PSDCS may extract the SSDCS's routing information from the decrypted primary NHRP reply. The extracted routing information of SSDCS may include, from amongst other information, the public IP address of the SSDCS. The NHRP module 1 18 may further open at least one of an IKE port, an IP specific port, and a user datagram protocol/Internet protocol (UDP) port in PSDCS for the SSDCS, based on the extracted IP address of the SSDCS. In one implementation, the opening of the IKE/IP port may be for a predetermined time period. Further the IKE/IP port can be used to exchange keys between the PSDCS and the SSDCS. The keys can be used to establish an IPSec tunnel between the PSDCS and the SSDCS. The communication module 228 may establish the IPSec tunnel between the PSDCS and the SSDCS.

[0059] The pre-determined time period may depend on various factors, such as the data and resources at the HCS 102, delay in communication network, quality and latency of the network. This pre-determined period may be less than about 10 milliseconds in one implementation. In another implementation, the predetermined time period may be less than 20 milliseconds. The opened IKE port can be used to set up a communication session to exchange cryptographic keys for the purpose of mutual authentication and establishing and maintaining the security associations. Alternatively, public key techniques and pre shared keys may also be used to mutually authenticate the communicating entities. It will be apparent to those skilled in the art that other equivalent cryptographic methodologies may also be employed without deviating from the sprit and scope of the present subject matter.

[0060] In an implementation of the present subject matter, the PSDCS may be implemented with, or in, one or more firewalls, such as firewall 1 13. In such an implementation NHRP module 1 18 may be configured to create an opening in the firewalls for the SSDCS and further open at least one of an IKE port, an IP specific port, and an UDP port, for the SSDCS based on the extracted routing information of the SSDCS. The opening in the firewall and the IKE/IP port can be for a predetermined time period. Further, the IKE/IP port and the opening in the firewall 1 13 can be used to exchange keys between the PSDCS and the SSDCS. The keys can be used to establish an IPSec tunnel between the PSDCS and the SSDCS.

[0061] In an implementation, as described earlier, the SDCSs 104 when online shall share their routing information, such as public IP address and tunnel IP address, with the HSC 102. In said implementation, the routing module 216 of the HSC 102 is adapted to receive and save the routing information of the SDCSs 04 in the routing data 222 in the form of a NHRP table.

[0062] In one implementation, the HCS 102 may receive a NHRP request from a SDSC 104, such as the PSDCS, requesting for routing information of a SSDCS. The NHRP request may be received by the HCS 102 over the IPSec tunnel. In said implementation, the request receiving module 212 of the HCS 102 is configured to receive the NHRP request from the SDCS 104-2, or the PSDCS. The NHRP request may be received through the Interface(s) 204-1. Further, the authentication module 214-1 is adapted to use the authentication data 220-1 and decapsulate and decrypt the received NHRP request.

[0063] In another implementation of the present subject matter, the NHRP response module 1 16 is configured to extract the NHRP request details and identify the SSDCS for which the routing information is requested. The NHRP response module 116 may further be adapted to determine the routing information associated with the SSDCS from the routing data 222. Further, the NHRP response module 1 16 is configured to generate and transmit two NHRP replies, a primary NHRP reply to the PSDCS and a secondary NHRP reply to the SSDCS.

[0064] The primary NHRP reply sent to the PSDCS may include the routing information, such as public IP address of the SSDCS and the secondary NHRP reply sent to the SSDCS may include the routing information, such as public IP address of the PSDCS. [0065] In an implementation of the present subject matter, SSDCS, such as the SDCS 104-1 may receive the secondary NHRP reply from the HSC 102. The secondary NHRP reply may be received over the IPSec tunnel between the SSDCS and the HCS 102. The NHRP module 118 receives the secondary NHRP reply. The authentication module 214-2 of SSDCS is configured to use the authentication data 220-2 and decapsulate and decrypt the secondary NHRP reply.

[0066] Further, the NHRP module 1 18 of SSDCS is adapted to extract the

PSDCS's routing information from the decrypted secondary NHRP reply. The extracted routing information of PSDCS may include the public IP address of the PSDCS. The NHRP module 1 18 may be configured to further open at least one of an IKE port, an IP specific port, and an UDP port, in SSDCS for the based on the extracted routing information of the PSDCS. The opening of the IKE/IP port can be for a predetermined time period.

[0067] As described earlier, the pre-determined time period may depend on various factors, such as the data and resources at the HCS 102, delay in communication network, quality and latency of the network. This pre-determined period may be less than about 10 milliseconds in one implementation. In another implementation, the pre-determined time period may be less than 20 milliseconds. The opened IKE/IP port can be used to set up a communication session to exchange cryptographic keys for the purpose of mutual authentication and establishing and maintaining the security associations. Alternatively, public key techniques and pre shared keys may also be used to mutually authenticate the communicating entities.

[0068] In an implementation of the present subject matter, the SSDCS may be implemented with, or in, one or more firewalls. In such an implementation the NHRP module 1 18 may be configured to create an opening in the firewall 113 for the SSDCS and open an IKE/IP port for the PSDCS based on the extracted routing information of the PSDCS. The opening in the firewall 1 13 and the IKE/IP port can be for a pre-determined time period. The opening in the firewall 113 and the IKE/IP port can be used to set up a shared session to exchange cryptographic keys for the purpose of mutual authentication and establishing and maintaining Security Associations, along with exchange of data.

[0069] In an example of an implementation of the present subject matter, a PSDCS with tunnel IP address 192.168.20.10 and public IP address 172.16.20.2 may wish to communicate with the SSDCS. The SSDCS may have a tunnel IP address 192.168.30.10 and public IP address 172.16.30.2. It would be appreciated by those skilled in the art that the SDCSs 104 are aware of the tunnel IP of different SDCS 104 connected to the HCS 102 through routing updates. However, the public IP address of individual SDCS 104 is unknown to the SDCSs 104. As would be understood by those skilled in the art, the PSDCS is aware that the SSDCS is reachable though the SSDCS tunnel IP address, however, to initiate a communication with the SSDCS, the PSDCS would also have to have the public IP address of the SSDCS. In said example, for the PSDCS to communicate with the SSDCS, the communication module 228 of the PSDCS may require the public IP address of the SSDCS.

[0070] Since the public IP address of the SSDCS is not available at the

PSDCS, the NHRP module 1 18 of PSDCS sends a NHRP request to HCS 102 requesting for the public IP address for the SSDCS. The NHRP request includes the tunnel IP address of the SSDCS, i.e., 192.168.30.10. In such situation, The NHRP response module 1 6 of the HCS 102 may extract the NHRP request details and identify the SSDCS for which the routing information is requested based on the tunnel IP address 192.168.30.10. The NHRP response module 1 16 may determine the routing information, such as the public IP address, associated with the SSDCS from the routing data 222 by querying on a NHRP table to find the public IP address corresponding to the tunnel IP address 192.168.30.10.

[0071] Once the public IP address, i.e., 172.16.30.2 corresponding to the tunnel IP address 192.168.30.10 is obtained, the NHRP response module 1 16 may generate and transmit two NHRP replies. One may be a primary NHRP reply for the PSDCS in response to the NHRP request, and a secondary NHRP reply to the SSDCS. In said example, the public IP address of the SSDCS is included in the primary NHRP reply while the public IP address of the PSDCS is included in the secondary NHRP reply.

[0072] In another example of an implementation of the present subject matter, the HCS 102 and the SDCSs 104, such as the PSDCS and the SSDCS may be implemented in firewall(s) or system implementing firewall(s) implemented for the hub server and spoke devices of a DMPVN, respectively. In said implementation, the PSDCS implemented in the firewall may receive the primary NHRP reply from the HCS 102, in response to a NHRP request. The PSDCS may extract the public IP address 172.16.30.2 of the SSDCS and may open an IKE/IP (UDP 500/4500) port in the firewall for the public IP address 172.16.30.2. The IKE/IP port may be opened for a pre-determined time period, like, but not limited to, 5 milliseconds, 10 milliseconds, 15 milliseconds, 20 milliseconds, etc. Opening of the IKE/IP port in the firewall may create a pinhole at the UDP port 500/4500 for the public IP address 172.16.30.2. Similarly, after the SSDCS receives the secondary NHRP reply from the HCS 102, the SSDCS may extract the public IP address 172.16.20.2 of the PSDCS. The NHRP module 1 18 of SSDCS may open the UDP port 500/4500 in the firewall associated with the SSDCS, for the public IP address 172.16.20.2.

[0073] Fig. 3(a), 3(b), and 3(c) illustrates, methods 300-1 , 300-2, and 300-2 to facilitate communication between spoke device communication systems, according to an implementation of the present subject matter. The number of the described method blocks in which the methods 300-1 , 300-2, and 300-2 are described is not intended to be construed as a limitation, and any number of the described method blocks can be combined in any suitable order to implement the respective method, or any alternative methods. Additionally, individual blocks may be deleted from the method without departing from the spirit and scope of the subject matter described herein. Furthermore, the methods can be implemented in any suitable hardware, software, firmware, or combination thereof. [0074] The method(s) 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.

[0075] A person skilled in the art will readily recognize that steps of the methods can be performed by programmed computers. Herein, some embodiments are also intended to cover program storage devices, for example, digital data storage media, which are machine or computer readable and encode machine-executable or computer-executable programs of instructions, where said instructions perform some or all of the steps of the described method. The program storage devices may be, for example, digital memories, magnetic storage media such as a magnetic disks and magnetic tapes, hard drives, or optically readable digital data storage media. The embodiments are also intended to cover both communication network and communication devices configured to perform said steps of the exemplary methods.

[0076] Fig. 3(a) illustrates an exemplary method of a procedure performed by a spoke device communication device (SDCS), such as the SDCS 104-2. In one implementation, the method may be implemented by a primary SDCS for establishing communication channel with another SDCS 104. [0077] Fig. 3(b) illustrates an exemplary method of a procedure performed by a hub communication system (HCS), such as the HCS 102.

[0078] Fig. 3(c) illustrates another exemplary method of a procedure performed by the SDCS, such as the SDCS 104 - . [0079] Referring to Fig. 3(a), at block 312, routing information for a secondary spoke device communication system (SSDCS) is requested, from a hub through a NHRP request. In one impiementation of the present subject matter, to establish communication with a SSDCS, the NHRP request may be sent to the hub. The NHRP request may be GRE encapsulated and sent over an IPSec tunnel to the hub.

[0080] At block 314, routing information for the SSDCS is received from the hub through a primary NHRP reply. The primary NHRP reply may also be encapsulated and encrypted and received over an IPSec tunnel. In one implementation, the primary NHRP reply may be decrypted and de-capsulated to extract the routing information for the SSDCS.

[0081] At block 316, an IKE/IP port is opened for the SSDCS based on the received routing information to exchange data. In an implementation, the IKE/IP port may be opened in a spoke device implementing the SDCS and wishing to establish communication with the SSDCS. In another implementation, the IKE/IP port may be opened in one or more firewalls associated with the spoke device, where the firewall is implementing the SDCS.

[0082] At block 318, an IPSec tunnel is established with the SSDCS. In one implementation, the IPSec tunnel is configured based on the cryptographic keys agreed upon with the SSDCS. Upon formation of the IPSec tunnel, data may be exchanged with the SSDCS for communication.

[0083] Referring to Fig. 3(b), at block 322, a NHRP request is received from a primary spoke device communication system (PSDCS) requesting routing information for a secondary spoke device communication system (SSDCS). The NHRP request may be GRE encapsulated and sent over an IPSec tunnel.

[0084] At block 324, routing information corresponding to the SSDCS may be determined based on a NHRP table. In one implementation, the routing information corresponding to the SSDCS may include a public IP address of the SSDCS. The public IP address may correspond to a tunnel IP address associated with the SSDCS. In one implementation, the routing information may be determined based on various querying and/or mapping techniques.

[0085] At block 326, a primary NHRP reply is provided to the PSDCS including the routing information corresponding to the SSDCS. The NHRP reply may be in response to the NHRP request received at step 322, from the PSDCS. The primary NHRP reply may include the requested routing information for the SSDCS. Again the NHRP reply might be encapsulated and encrypted and sent over the IPSec tunnel to the PSDCS.

[0086] At block 328, a secondary NHRP reply is provided to the SSDCS including the routing information corresponding to the PSDCS. The secondary NHRP reply may include the routing information associated with the PSDCS and may be provided to the SSDCS.

[0087] Referring to Fig. 3(c), at block 332, routing information is received from a hub through a secondary NHRP reply. In one implementation, the secondary NHRP reply may be received by a SSDCS with which a PSDCS wishes to communicate with. Further, the secondary NHRP reply may be decrypted and de-capsulated, to extracts the routing information associated with the PSDCS.

[0088] At block 334, an IKE/IP port is opened for the PSDCS to exchange data based on the received routing information. In one implementation, the IKE/IP port may be opened for a pre-determined time period like, 5 milliseconds, 10 milliseconds, 15 milliseconds, etc.

[0089] At block 336, an IPSec tunnel may be established with the PSDCS based on the routing information received in the secondary NHRP reply. Upon establishment of the IPSec tunnel, the IPSec tunnel can be used for communication between the PSDCS and the SSDCS.

[0090] Although the present specification describes components and functions implemented in the embodiments with reference to particular standards and protocols, the disclosed subject matter may not be limited to such standards and protocols. Each of the standards for Internet, and other packet switched network transmission (e.g., transmission control protocol/Internet protocol (TCP/IP), Internet Protocol Security (IPSec), Internet Security Association and Key Management Protocol (ISAKMP), Next-Hop Resolution Protocol (NHRP), user datagram protocol/Internet protocol (UDP/IP)) represent examples of the state of the art.

[0091] Although the disclosed subject matter has been described with reference to particular means, materials, and embodiments, the disclosed subject matter is not intended to be limited to the particulars disclosed; rather, the subject matter extends to all functionally equivalent structures, methods, and uses, such as are within the scope of the appended claims.

[0092] Although embodiments for methods and systems for establishing connection between spoke device communication systems in the DMVPN have been described in a language specific to structural features and/or methods, it is to be understood that the invention is not necessarily limited to the specific features or methods described. Rather, the specific features and methods are disclosed as exemplary embodiments for establishing connection between spoke device communication systems.

Claims

I/We claim:

1. A method for establishing connection among spoke device communication systems in a dynamic multipoint virtual private network (DMVPN), the method comprising:

receiving a Next Hop Resolution Protocol (NHRP) request from a primary spoke device communication system (PSDCS) for providing routing information of a secondary spoke device communication system (SSDCS), wherein the NHRP request comprises at least a tunnel Internet Protocol (IP) address associated with the SSDCS;

determining the routing information corresponding to the SSDCS based on a NHRP table, wherein the NHRP table is indicative of a mapping among tunnel IP and public IP of spoke device communication systems;

providing a primary NHRP reply to the PSDCS including the routing information corresponding to the SSDCS; and

providing a secondary NHRP reply to the SSDCS including the routing information corresponding to the PSDCS, wherein the routing information corresponding to the PSDCS comprises at least a public IP address of the PSDCS. 2. The method as claimed in claim 1 , wherein the determining is based on the tunnel IP associated with the SSDCS.

3. The method as claimed in claim 1 , wherein the routing information corresponding to the SSDCS comprises at least a public IP address of the SSDCS.

4. A method for establishing connection among spoke device communication systems in a DMVPN, the method comprising:

requesting routing information for a SSDCS, from a hub communication system (HCS) (102) through a NHRP request, wherein the routing information comprises at least a public IP address of the SSDCS; receiving routing information from the HCS (102) through a primary NHRP reply, in response to the NHRP request; and

configuring a port based on the received routing information to selectively exchange data with the SSDCS.

5. The method as claimed in claim 4, wherein the method further comprising establishing an Internet Protocol Security (IPSec) tunnel with the SSDCS, and wherein the IPSec tunnel allows secure communication with the SSDCS. 6. The method as claimed in claim 4, wherein the NHRP request comprises a tunnel IP address associated with the SSDCS.

7. The method as claimed in claim 4, wherein the configuring is at least one of opening an internet key exchange (IKE) port, opening an IP specific port, and opening an user datagram protocol/Internet protocol (UDP) port.

8. The method as claimed in claim 4, wherein the configuring is for a predetermined time period. 9. A spoke device communication system (SDCS) (104) for establishing connection with other spoke device communication system(s) in a DMVPN, the SDCS (104) comprising:

a processor (202-2); and

a NHRP module ( 18) coupled to the processor (202-2), the NHRP module (1 18) adapted to: generate a NHRP request to request routing information for a SSDCS, from a HCS (102), through the NHRP request; receive the routing information from the HCS (102) through a primary NHRP reply, wherein the routing information comprises at least a IP address of the SSDCS; and

configure a port based on the received routing information to selectively exchange data with the SSDCS.

10. The SDCS (104) as claimed in claim 9 further comprising a communication module (228) adapted to establish an IPSec tunnel with the SSDCS, wherein the IPSec tunnel allows secure communication with the SSDCS. 1. The SDCS (104) as claimed in claim 9, wherein the configuring is at least one of opening an IKE port, opening an IP specific port, and opening an UDP port.

12. A SDCS (104) for establishing connection with other spoke device communication systems in a DMVPN, the SDCS (104) comprising:

a processor (202-2); and

a NHRP module (118) coupled to the processor (202-2), adapted to: receive routing information corresponding to a PSDCS through a secondary NHRP reply from a HCS (102), wherein the routing information corresponding to the PSDCS comprises at least a public

IP address of the PSDCS; and configure a port based on the received routing information to selectively exchange data with the PSDCS.

13. The SDCS (104) as claimed in claim 12, wherein the configuring is at least one of opening an IKE port, opening an IP specific port, and opening an UDP port, for a pre-determined time period.

14. A hub communication system (HCS) (102) for establishing connection among spoke device communication systems in a DMVPN, the HCS (102) comprising:

a processor (202-1); a request receiving module (212) coupled to the processor (202-1 ), adapted to receive a NHRP request from a PSDCS for providing routing information of a SSDCS, wherein the NHRP request comprises at least a tunnel IP address associated with the SSDCS; and

a NHRP response module (1 16) coupled to the processor (202-1 ), adapted to:

determine the routing information corresponding to the SSDCS based on a NHRP table, wherein the NHRP table is indicative of a mapping among tunnel IP address and public IP address of spoke device communication systems;

provide a primary NHRP reply to the PSDCS including the routing information corresponding to the SSDCS; and

provide a secondary NHRP reply to the SSDCS including the routing information corresponding to the PSDCS, wherein the routing information corresponding to the PSDCS comprises at least a public IP address of the PSDCS.

15. The HCS (102) as claimed in claim 14, wherein the determination is based on the tunnel IP address associated with the SSDCS.

16. A non-transitory computer readable medium having a set of computer readable instructions that, when executed, cause a computing system to:

request routing information for a SSDCS, from a HCS (102) through a NHRP request, wherein the routing information comprises at least a public IP address of the SSDCS; receive routing information from the HCS (102) through a primary NHRP reply; and

■

17. A non-transitory computer readable medium having a set of computer readable instructions that, when executed, cause a computing system to:

receive a NHRP request from a PSDCS for providing routing information of a SSDCS, wherein the NHRP request comprises at least a tunnel IP address associated with the SSDCS;