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.
3
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.
4
[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
5
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.
6
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
7
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 huband-
spoke topology.
8
[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,
9
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
10
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
DMVPN. 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
11
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, 110-2, 110-3, ...., 110-N, collectively referred to as routers
110 and individually referred to as router 110 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 110. Further, the communication between the HCS 102 and the SDCSs
12
104 may be facilitated through one or more firewalls, such as firewall 113. In such
situations, the SDCSs 104 may be implemented in the firewall 113, such as the
SDCS 104-3. In said implementation, the routers 110 may further be connected to
various user devices 114-1, 114-2, 114-3, ...., 114-N, collectively referred to as
user devices 114 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 118 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 118 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),
13
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
14
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 110-1, the initiation of communication may be
based on a trigger from the user device 114-1 connected to a router 110-1.
Similarly, the communication may be initiated by the SDCS 104 independently
without any trigger from the user device 114-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 116 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 116 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
15
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 110-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
16
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 102 and
the SDCSs 104 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 computerreadable
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
17
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 116, 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
18
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 102 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 118 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.
19
[0058] Further, in an implementation, the NHRP module 118 of PSDCS is
also configured to process the primary NHRP reply. The NHRP module 118 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 118 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 113. In such an
implementation NHRP module 118 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
20
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
113 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 104
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 116 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 116 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.
21
[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 118 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 118 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 118 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 113 and the IKE/IP port can
be for a pre-determined time period. The opening in the firewall 113 and the IKE/IP
22
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 118 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 116 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 116 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 116 may
generate and transmit two NHRP replies. One may be a primary NHRP reply for
23
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 118 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.
24
[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 -1.
25
[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 implementation 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
26
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
27
(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.

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;
29
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 (118) coupled to the processor (202-2), the NHRP
module (118) adapted to:
generate a NHRP request to request routing information for a
SSDCS, from a HCS (102), through the NHRP request;
30
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.
11. 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.
31
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 (116) 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;
32
receive routing information from the HCS (102) through a primary NHRP
reply; and
configure a port based on the received routing information to selectively
exchange data with the SSDCS.
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;
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.