U.S. patent application number 12/477774 was filed with the patent office on 2010-12-09 for provisioning remote access points.
This patent application is currently assigned to ARUBA NETWORKS, INC.. Invention is credited to Shekhar Kshirsagar, Manish Mehta.
Application Number | 20100313262 12/477774 |
Document ID | / |
Family ID | 43301725 |
Filed Date | 2010-12-09 |
United States Patent
Application |
20100313262 |
Kind Code |
A1 |
Mehta; Manish ; et
al. |
December 9, 2010 |
PROVISIONING REMOTE ACCESS POINTS
Abstract
Provisioning remote access points for use in a telecommunication
network. A remote access point contains identity information
established during manufacturing; this identity information may be
in the nature of a digital certificate. The identity information is
stored in the remote access point, and may be stored in a Trusted
Platform Module if present. When the remote access node is powered
up in unprovisioned state, outside the manufacturing environment,
it attempts to establish an internet connection via a first wired
interface, and queries a user for information representing the
TCP/IP address of its controller via a second wired interface. Once
an internet connection is present, and a TCP/IP address has been
provided, the remote access point attempts to connect to the
controller at that address. The controller may filter connection
requests through a whitelist of approved remote access points. Once
a connection is established, controller and access point exchange
and verify each other's identities. This may be done through the
exchange and verification of digital certificates. Provisioning
information is downloaded from controller to remote access point
and installed. This may be done via a tunnel such as an encrypted
tunnel. Software updates may be applied. The provisioned remote
access point is placed in operation.
Inventors: |
Mehta; Manish; (Santa Clara,
CA) ; Kshirsagar; Shekhar; (San Jose, CA) |
Correspondence
Address: |
BLAKELY SOKOLOFF TAYLOR & ZAFMAN LLP
1279 OAKMEAD PARKWAY
SUNNYVALE
CA
94085-4040
US
|
Assignee: |
ARUBA NETWORKS, INC.
Sunnyvale
CA
|
Family ID: |
43301725 |
Appl. No.: |
12/477774 |
Filed: |
June 3, 2009 |
Current U.S.
Class: |
726/12 ; 370/338;
380/255; 713/100; 713/176; 717/171 |
Current CPC
Class: |
G06F 8/61 20130101; H04L
63/101 20130101; G06F 16/951 20190101; H04L 63/0876 20130101; H04L
61/1511 20130101; H04L 61/2007 20130101; H04W 84/045 20130101; H04L
63/0823 20130101; G06F 8/65 20130101; H04W 88/085 20130101; H04W
84/042 20130101; H04L 67/02 20130101; H04W 24/02 20130101 |
Class at
Publication: |
726/12 ; 370/338;
380/255; 713/100; 717/171; 713/176 |
International
Class: |
G06F 21/20 20060101
G06F021/20; H04W 84/02 20090101 H04W084/02 |
Claims
1. A method of provisioning a remote access point having identity
information stored in the remote access point memory, a first wired
interface for connecting to the internet, and a second wired
interface for connecting to a user computer, the method comprising:
establishing an internet connection on the first wired interface,
accepting user input through the second wired interface, the user
input representing a TCP/IP address, attempting to connect to a
controller at the TCP/IP address via the internet connection on the
first wired interface, exchanging and verifying identity
information with the controller, downloading and installing
configuration information from the controller, and placing the
remote access node in operation.
2. The method of claim 1 where the identity information contains
the MAC address of at least the first wired interface.
3. The method of claim 1 where the identity information is a
digital certificate.
4. The method of claim 1 where the controller maintains a whitelist
of remote access points which are allowed to connect, and refusing
connections from remote access points not on the whitelist.
5. The method of claim 1 where the step of downloading and
installing configuration information includes downloading and
installing any software updates for the remote access point.
6. The method of claim 1 where the step of downloading and
installing configuration information is performed using a
tunnel.
7. The method of claim 6 where the tunnel is encrypted.
8. The method of claim 6 where the tunnel is an IPsec tunnel.
9. The method of claim 1 where the user input representing a TCI/IP
address is a TCP/IP address.
10. The method of claim 1 where the user input representing a
TCI/IP address is a Fully Qualified Domain Name (FQDN),
11. The method of claim 1 where the user input representing a
TCI/IP address is a code representing a TCP/IP address.
Description
BACKGROUND OF THE INVENTION
[0001] The present invention relates to telecommunication networks,
and in particular, to the problem of setting up (provisioning)
remote access points for use in telecommunication networks.
[0002] Remote networking allows the extension of a networking
environment, such as a corporate networking environment, to remote
locations. In operation, a remote access point at a remote location
establishes a connection with its home (corporate) controller over
the switched internet. In most cases this connection is an
encrypted tunnel. The remote access point, connected to the home
controller, extends the services available in the corporate
environment through wireless and/or wired connections with the
remote access point. This allows corporate users full access to
systems and services in remote locations, such as remote offices or
homes. It also allows corporate information technology groups to
provide such access in a controlled and secure manner.
[0003] An issue with remote access points, and in particular to
deploying remote access points to a large number of users and/or
locations is the time and labor required. Each remote access point
must be properly set up, or provisioned. Typically this requires an
information technology specialist in the organization to take a
remote access point out of its packaging, install required
configuration information such as the IP address of the corporate
controller the remote access point is to contact, device
credentials, and any updates necessary. Then the remote access
point is repackaged and sent to the particular user or location for
installation and use. Of course the remote access point must be
tracked through all these steps.
[0004] While such provisioning may be acceptable for a small number
of units, such a process does not scale, becoming burdensome when
more than a few units are involved.
[0005] What is needed is a better way to provision remote access
points.
BRIEF DESCRIPTION OF THE DRAWINGS
[0006] The invention may be best understood by referring to the
following description and accompanying drawings that are used to
illustrate embodiments of the invention in which:
[0007] FIG. 1 shows a network, and
[0008] FIG. 2 shows device provisioning.
DETAILED DESCRIPTION
[0009] Embodiments of the invention relate to methods of
provisioning remote access points.
[0010] An access point has identification information stored in it
as part of the manufacturing process. This identification
information may include digital certificates which are
cryptographically signed, and keys corresponding to these
certificates may be stored in a Trusted Platform Module (TPM) if
available in the remote access point. The identification
information contains information about the particular remote access
point, and may include information such as Media Access Control
(MAC) addresses for wired and/or wireless ports. The remote access
point also contains a program to be run at power up if the access
point is in an unprovisioned state.
[0011] When an unprovisioned remote access point is powered up by a
user it establishes an internet connection using a first wired
port. On a second wired port, the remote access point requests user
input relating to the TCP/IP address or fully qualified domain name
of the controller which is to support the remote access point. The
remote access point uses this user input to establish a connection
to the controller via the internet connection using the first wired
port. This connection between the remote access point and the
controller may be via a tunnel, which may be encrypted or secured.
Optionally, the controller may have a list of remote access points
it is to support, and accept connections from and send
configuration information to only those remote access points. Once
connected, the remote access point and the controller exchange
identification information to verify identities. Once verified, the
controller sends configuration data and any updates to the remote
access point. The remote access point installs this configuration
information to provision the remote access point, and places it
into operation. This may require rebooting the remote access
point.
[0012] FIG. 1 shows a network. Router 100 connects 180 to a
switched network 200 such as the Internet. At a remote location,
interface 300 also connects 320 to network 200 providing
connectivity 350. Interface 300 may be a device known to the art
such as a DSL or Cable modem, or a wireless interface such as a 3G,
WiMAX, WiFi, or other radio connection. Interface 300 provides
services such as Internet access via wired connection 350, which
may be in the form of an IEEE802.3 Ethernet interface, or another
wired interface such as USB or IEEE1394 Firewire. Remote access
point 400 connects 350 to the Internet via first wired interface
430.
[0013] Controller 100 is a purpose-built digital device having a
CPU 110, memory hierarchy 120, and a plurality of network
interfaces 130. CPU 110 may be a MIPS-class processor from
companies such as Raza Microelectronics or Cavium Networks,
although CPUs from companies such as Intel, AMD, IBM, Freescale, or
the like may also be used. Memory hierarchy 120 includes read-only
memory for device startup and initialization, high-speed read-write
memory such as DRAM for containing programs and data during
operation, and bulk memory such as hard disk or compact flash for
permanent file storage of programs and data. Network interfaces 130
are typically IEEE 802.3 Ethernet interfaces to copper, although
high-speed optical fiber interfaces may also be used. Controller
100 typically operates under the control of purpose-built embedded
software, typically running under a Linux operating system, or an
operating system for embedded devices such as VXWorks. Controller
100 may have dedicated hardware for encryption, and/or for routing
packets between network interfaces 130. Controller 100 may also be
equipped with Trusted Platform Module (TPM) 160, an
industry-standard device for providing secure storage.
[0014] Remote access point 400 is also a purpose-built digital
device having a CPU 410, memory hierarchy 420, a first wired
interface 430, an optional wireless interface 440, second wired
interface 450 which may represent a plurality of additional wired
interfaces, and may contain TPM 460 for secure storage. As with
controller 100, the CPU commonly used for such access nodes is a
MIPS-class CPU such as one from Raza Microelectronics or Cavium
Networks, although processors from other vendors such as Intel,
AMD, Freescale, and IBM may be used. Memory hierarchy 420 comprises
read-only storage such as ROM or EEPROM for device startup and
initialization, fast read-write storage such as DRAM for holding
operating programs and data, and permanent bulk file storage such
as compact flash memory. Remote access point 400 typically operates
under control of purpose-built programs running on an embedded
operating system such as Linux or VXWorks. Optional wireless
interface 340 is typically an interface operating to the family of
IEEE 802.11 standards including but not limited to 802.11a, b, g,
and/or n. First wired interface 430 may be an IEEE803.2 Ethernet
interface, or other wired interface such as USB or IEEE1394
Firewire. Similarly, second wired interface 450 may be one or more
IEEE802.3 Ethernet interfaces, USB interfaces, IEEE1493 Firewire
interfaces, or a combination. As an example, a small remote access
point 400 may have an IEEE803.2 Ethernet wired interface for first
wired interface 430, an IEEE802.11a/b/g/n wireless interface 440,
and an additional IEEE802.3 Ethernet port and a USB port as second
wired interface 450. A larger remote access point 400 may have
multiple second Ethernet ports.
[0015] According to an aspect of the invention, during
manufacturing, identification information is generated and stored
in remote access point 400. This information may be stored in
memory hierarchy 420, as an example in EEPROM or flash storage,
and/or in TPM 460 if a TPM is present. This identification
information contains device unique information, which may be for
example a serial number, or the MAC address of the first wired
interface 430.
[0016] In one embodiment of the invention, this information is
stored as a digital certificate containing a Distinguished Name
which contains the MAC address of the first wired interface 430 of
the device. If remote access point 400 contains a TPM 460, the key
for this certificate is stored in the TPM, otherwise the key for
the certificate is stored in EEPROM or Flash memory.
[0017] Remote access point 400 also contains an initialization
program stored in memory hierarchy 420 which is to be run whenever
the remote access point 400 is powered up in unprovisioned
state.
[0018] According to the invention, the user of remote access point
400 prepares it for setup by establishing a wired connection 350
between internet interface 300 and first wired interface 430. A
second wired connection 480 is established between second wired
interface 450 and a personal computer 500.
[0019] When remote access point 400 is powered up in an
unprovisioned state, the initialization program executes as shown
in FIG. 2. It first attempts to establish an Internet connection
via first wired interface 430. The exact process required for
establishing this connection depends on the nature of the
interface, but is understood in the art. As an example, for
Internet Protocol (IP) interfaces, the DHCP protocol described in
RFC 2131 for IPv4 networks and RFC 3315 for IPv6 networks is used
by the device to obtain the information necessary to establish an
Internet connection.
[0020] The user is queried via second wired interface 450 and
connection 480 to computer 500 for information on controller 100
which is to support remote access point 400.
[0021] In one embodiment of the invention, remote access point 400
starts up a simple web server attached to second wired interface
450. This allows the user to use any web browser on computer 500,
such as Mozilla Firefox, Apple's Safari, Google's Chrome, or even
Internet Explorer, to provide the needed information. This simple
web server running on remote access point 400 provides a page in
response to any URI requested from computer 500, requesting
information on the controller which is to support remote access
point 400. In one example, the information requested may be as
simple as the TCP/IP address of controller 100, for example, an
address such as 192.168.249.240 may be provided by the user. Rather
than providing a TCP/IP address, the user may provide a fully
qualified domain name (FQDN), such as setup.yoyodyne.com, which
will be looked up by the initialization program and translated to a
TCP/IP address. In another example, the user may be provided with a
key code which is resolved to the TCP/IP address of the controller,
such as XP3Y-4GG7-3DEK-6RTM which is resolved by the web server
software running on remote access point 400 to the TCP/IP address
needed.
[0022] In another embodiment of the invention, a simple serial
protocol and interface may be used on second wired interface 450,
such as an RS-232 serial interface, or RS-232 over USB, and a
simple query and response scheme prompting the user for input and
accepting that input, once again, the TCP/IP address of controller
100, a FQDN, or a key code which is resolved to the TCP/IP address
of the controller.
[0023] Once the TCP/IP address of controller 100 has been provided,
and the Internet connection established, remote access point 400
attempts to contact controller 100 at the specified TCP/IP address
using wired interface 430.
[0024] Assume controller 100 is accessible via the Internet at the
specified TCP/IP address. Controller 100 may accept requests from
all remote access points contacting it at this address, or
controller 100 may contain a whitelist stored in memory hierarchy
120 of those individual remote access points which are to be
accepted. This whitelist may also reside outside of the controller
100 with the controller 100 being able to access the information at
any time. This whitelist for example could be based on the unique
MAC address of first wired interface 430 present in each remote
access point 400. If the MAC address, which is present in the
device credentials such as digital certificate, is on the
whitelist, the connection is accepted, otherwise the connection is
rejected.
[0025] If controller 100 accepts the connection from remote access
point 400, controller 100 and remote access point 400 exchange and
verify identity information. In one embodiment of the invention,
this involves verifying certificates and certificate chain kept by
each party.
[0026] Once identities have been verified, controller 100 sends
configuration information to remote access point 400. In one
embodiment of the invention, once the identities of controller 100
and remote access point 400 have been verified, a secure tunnel
such as an IPsec tunnel is established between controller 100 and
remote access point 400, and configuration information is
downloaded through this tunnel. IPsec protocols are known to the
art and are defined for example in RFC 4301, and RFC 4309.
[0027] The configuration information provided by controller 100 is
installed in remote access point 400.
[0028] Optionally, a check for updates to the software present in
remote access point 400 may be made with controller 100, and any
additional or updated software downloaded and installed in remote
access point 400. This may be performed, for example, by a system
where controller 100 queries remote access point 400 for
information on versions of installed software, compares those
versions to current versions maintained on the controller, and
sends updates as needed.
[0029] With the configuration information now present,
initialization is complete, and operation of the remote access
point in its provisioned state many now begin. This may be
accomplished by the initialization program starting the remote
access point software, or by the initialization software restarting
remote access point 400.
[0030] While the invention has been described in terms of various
embodiments, the invention should not be limited to only those
embodiments described, but can be practiced with modification and
alteration within the spirit and scope of the appended claims. The
description is this to be regarded as illustrative rather than
limiting.
* * * * *