security boundary is in the AC. In other cases, an end-to-end
mutually authenticated secure VPN tunnel is assumed between the
client and AC, other security gateway, or end host entity.
5.8.2. Security of Control Channel between the WTP and AC
In order for the CAPWAP functions to be implemented in the
Centralized WLAN Architecture, a control channel is necessary between
the WTP and AC.
To address potential security threats against the control channel,
existing implementations feature one or more of the following
security mechanisms:
1. Secure discovery of WTP and AC.
2. Authentication of the WTPs to the ACs (and possibly mutual
authentication).
3. Confidentiality, integrity, and replay protection of control
channel frames.
4. Secure management of WTPs and ACs, including mechanisms for
securely setting and resetting secrets and state.
Discovery and authentication of WTPs are addressed in the submissions
by implementing authentication mechanisms that range from X.509
certificates, AAA authentication to pre-shared credential
authentication. In all cases, confidentiality, integrity, and
protection against man-in-the-middle attacks of the control frames
are addressed by a secure encrypted tunnel between the WTP and AC(s),
utilizing keys derived from the authentication methods mentioned
previously. Finally, one of the motivations for the Centralized WLAN
Architecture is to minimize the storage of cryptographic and security
sensitive information, in addition to operational configuration
parameters within the WTPs. It is for that reason that the majority
of the submissions under the Centralized Architecture category have
employed a post WTP authenticated discovery phase of configuration
provisioning, which in turn protects against the theft of WTPs.
5.8.3. Physical Security of WTPs and ACs
To provide comprehensive radio coverage, WTPs are often installed in
locations that are difficult to secure physically; it is relatively
easier to secure the AC physically. If high-value secrets, such as a
RADIUS shared secret, are stored in the AC instead of WTPs, then the
physical loss of an WTP does not compromise these secrets. Hence,
the Centralized Architecture may reduce the security consequences of
a stolen WTP. On the other hand, concentrating all the high-value
secrets in one place makes the AC an attractive target that requires
strict physical, procedural, and technical controls to protect the
secrets.
6. Distributed Mesh Architecture
Out of the sixteen architecture survey submissions, three belong to
the Distributed Mesh Architecture family. An example of the
Distributed Mesh Architecture is shown in Figure 13, and reflects
some of the common characteristics found in these three submissions.
+-----------------+ +-----------------+
| 802.11 BSS 1 | | 802.11 BSS 2 |
| ... | | ... |
| +---------+ | | +---------+ |
+----|mesh node|--+ +----|mesh node|--+
+-+---+---+ +-+-+-----+
| | | |
| | | | +----------+
| +-----------------------+ | Ethernet | Ethernet |
| 802.11 wireless links | +--------+ Switch |
| +-----------------------+ | | | |
| | | | | +----------+
+-+---+---+ +-+--+----+
+----|mesh node|--+ +----|mesh node|--+
| +---------+ | | +---------+ |
| ... | | ... |
| 802.11 BSS 4 | | 802.11 BSS 3 |
+-----------------+ +-----------------+
Figure 13: Example of Distributed Mesh Architecture
6.1. Common Characteristics
To provide wider wireless coverage, mesh nodes in the network may act
as APs to client stations in their respective BSS, as well as traffic
relays to neighboring mesh nodes via 802.11 wireless links. It is
also possible that some mesh nodes in the network may serve only as
wireless traffic relays for other mesh nodes, but not as APs for any
client stations. Instead of pulling Ethernet cable connections to
every AP, wireless mesh networks provide an attractive alternative to
relaying backhaul traffic.
Mesh nodes can also keep track of the state of their neighboring
nodes, or even nodes beyond their immediate neighborhood by
exchanging information periodically amongst them; this way, mesh
nodes can be fully aware of the dynamic network topology and RF
conditions around them. Such peer-to-peer communication model allows
mesh nodes to actively coordinate among themselves to achieve self-
configuration and self-healing. This is the major distinction
between this Distributed Architecture family and the Centralized
Architecture -- much of the CAPWAP functions can be implemented
across the mesh nodes in a distributed fashion, without a centralized
entity making all the control decisions.
It is worthwhile to point out that mesh networks do not necessarily
preclude the use of centralized control. It is possible that a
combination of centralized and distributed control co-exists in mesh
networks. Some global configuration or policy change may be better
served in a coordinated fashion if some form of Access Controller
(AC) exists in the mesh network (even if not the full blown version
of the AC, as defined in the Centralized WLAN Architecture). For
example, a centralized management entity can be used to update every
mesh node’s default configuration. It may also be more desirable to
leave certain functions, such as user authentication to a single
centralized end point (such as a RADIUS server), but mesh networks
allow each mesh AP to directly talk to the RADIUS server. This
eliminates the single point of failure and takes advantage of the
client distribution in the network.
The backhaul transport network of the mesh network can be either an
L2 or L3 networking technology. Currently, vendors are using
proprietary mesh technologies on top of standard 802.11 wireless
links to enable peer-to-peer communication between the mesh nodes.
Hence, there is no interoperability among mesh nodes from different
vendors. The IEEE 802.11 WG has recently started a new Task Group
(TGs) to define the mesh standard for 802.11.
6.2. Security
Similar security concerns for client data security, as described in
Section 5.8.1, also apply to the Distributed Mesh Architecture.
Additionally, one important security consideration for the mesh
networks is that the mesh nodes must authenticate each other within
the same administrative domain. To protect user and management data
that may not be secured at layer 3, data transmission among
neighboring nodes should be secured by a layer 2 mechanism of
confidentiality, integrity, and replay protection.
7. Summary and Conclusions
We requested existing WLAN vendors and other interested parties to
submit a short description of existing or desired WLAN access network
architectures to define a taxonomy of possible WLAN access network
architectures. The information from the 16 submissions was condensed
and summarized in this document.
New terminology has been defined wherever existing terminology was
found to be either insufficient or ambiguous in describing the WLAN
architectures and supporting functions listed in the document. For
example, the broad set of Access Point functions has been divided
into two categories: 802.11 functions, which include those that are
required by the IEEE 802.11 standards, and CAPWAP functions, which
include those that are not required by the IEEE 802.11, but are
deemed essential for control, configuration, and management of 802.11
WLAN access networks. Another term that has caused considerable
ambiguity is "Access Point", which usually reflected a physical box
that has the antennas, but did not have a uniform set of externally
consistent behavior across submissions. To remove this ambiguity, we
have redefined the AP as the set of 802.11 and CAPWAP functions,
while the physical box that terminates the 802.11 PHY is called the
Wireless Termination Point.
Based on the submissions during the architecture survey phase, we
have classified the existing WLAN architectures into three broad
classes:
1. Autonomous WLAN Architecture: Indicates a family of architectures
in which all the 802.11 functions and, where applicable, CAPWAP
functions are implemented in the WTPs.
2. Centralized WLAN Architecture: Indicates a family of architectures
in which the AP functions are split between the WTPs and the AC,
with the AC acting as a centralized control point for multiple
WTPs.
3. Distributed WLAN Architecture: Indicates a family of architectures
in which part of the control functions is implemented across a
distributed network of peer entities.
Within the Centralized WLAN Architecture, there are a few visible
sub-categories that depend on how one maps the MAC functions (at a
high-level), between the WTP and the AC. Three prominent sub-
categories emerged from the information in the submissions:
1. Split MAC Architecture: The 802.11 MAC functions are split between
the WTP and the AC. This subgroup includes all architectures that
split the 802.11 MAC functions even though individual submissions
differed on the specifics of the split.
2. Local MAC Architecture: The entire set of 802.11 MAC functions is
implemented on the WTP.
3. Remote MAC Architecture: The entire set of 802.11 MAC functions is
implemented on the AC.
The following tree diagram summarizes the architectures documented in
this taxonomy.
+----------------+
|Autonomous |
+---------->|Architecture |
| |Family |
| +----------------+
| +--------------+
| |Local |
| +---->|MAC |
| | |Architecture |
| | +--------------+
| |
| +----------------+ | +--------------+
| |Centralized | | |Split |
+---------->|Architecture |--+---->|MAC |
| |Family | | |Architecture |
| +----------------+ | +--------------+
| |
| | +--------------+
| | |Remote |
| +---->|MAC |
| |Architecture |
| +--------------+
| +----------------+
| |Distributed Mesh|
+---------->|Architecture |
|Family |
+----------------+
A majority of the submitted WLAN access network architectures (twelve
out of sixteen) followed the Centralized WLAN Architecture. All but
one of the Centralized WLAN Architecture submissions were grouped
into either a Split MAC Architecture or a Local MAC Architecture.
One submission followed the Autonomous WLAN Architecture, and three
followed the Distributed WLAN Architecture.
The WLAN access network architectures in the submissions indicated
that the connectivity assumptions were:
o Direct connection between the WTP and the AC.
o L2 switched connection between the WTP and the AC.
o L3 routed connection between the WTP and the AC.
o Wireless connection between the mesh nodes in the distributed mesh
architecture.
Interoperability between equipment from different vendors is one of
the fundamental problems in the WLAN market today. To achieve
interoperability via open standard development, the following steps
are suggested for IETF and IEEE 802.11.
Using this taxonomy, a functional model of an Access Point should be
defined by the new study group recently formed within the IEEE
802.11. The functional model will consist of defining functional
elements of an 802.11 Access Point that are considered atomic, i.e.,
not subject to further splitting across multiple network elements.
Such a functional model should serve as a common foundation to
support the existing WLAN architectures as outlined in this taxonomy,
and any further architecture development within or outside the IEEE
802.11 group. It is possible, and even recommended, that work on the
functional model definition may also include impact analysis of
implementing each functional element on either the WTP or the AC.
As part of the functional model definition, interfaces must be
defined as primitives between these functional elements. If a pair
of functional elements that have an interface defined between them is
being implemented on two different network entities, then a protocol
specification definition between such a pair of network elements is
required, and should be developed by the IETF.
8. Security Considerations
This document does not intend to provide a comprehensive threat
analysis of all of the security issues with the different WLAN
architectures. Nevertheless, in addition to documenting the
architectures employed in the existing IEEE 802.11 products in the
market, this taxonomy document also catalogues the security issues
that arise and the manner in which vendors address these security
threats. The WLAN architectures are broadly categorized into three
families: Autonomous Architecture, Centralized Architecture, and
Distributed Architecture. While Sections 4, 5, and 6 are devoted to
each of these three architecture families, respectively, each section
also contains a subsection to address the security issues within each
architecture family.
In summary, the main security concern in the Autonomous Architecture
is the mutual authentication between the WTP and the wired (Ethernet)
infrastructure equipment. Physical security of the WTPs is also a
network security concern because the WTPs contain secret information
and theft of these devices could potentially compromise even the
wired network.
In the Centralized Architecture there are a few new security concerns
due to the new network binding between the WTP and AC. The following
security concerns are raised for this architecture family: keying
material for mobile client traffic may need to be securely
transported from the AC to WTP; secure discovery of the WTP and AC is
required, as well as mutual authentication between the WTPs and AC;
man-in-the-middle attacks to the control channel between WTP and AC,
confidentiality, integrity and replay protection of control channel
frames, and theft of WTPs for extraction of embedded secrets within.
Each of the survey results for this broad architecture category has
presented mechanisms to address these security issues.
The new security issue in the Distributed Mesh Architecture is the
need for mesh nodes to authenticate each other before forming a
secure mesh network. Encrypted communication between mesh nodes is
recommended to protect both control and user data.
9. Acknowledgements
This taxonomy is truly a collaborative effort with contributions from
a large group of people. First, we want to thank all the CAPWAP
Architecture Design Team members who have spent many hours in the
teleconference calls, over e-mails, and in writing and reviewing the
document. The full Design Team is listed here:
o Peyush Agarwal
STMicroelectronics
Plot# 18, Sector 16A
Noida, U.P 201301
India
Phone: +91-120-2512021
EMail: peyush.agarwal@st.com
o Dave Hetherington
Roving Planet
4750 Walnut St., Suite 106
Boulder, CO 80027
United States
Phone: +1-303-996-7560
EMail: Dave.Hetherington@RovingPlanet.com
o Matt Holdrege
Strix Systems
26610 Agoura Road
Calabasas, CA 91302
Phone: +1 818-251-1058
EMail: matt@strixsystems.com
o Victor Lin
Extreme Networks
3585 Monroe Street
Santa Clara, CA 95051
Phone: +1 408-579-3383
EMail: vlin@extremenetworks.com
o James M. Murphy
Trapeze Networks
5753 W. Las Positas Blvd.
Pleasanton, CA 94588
Phone: +1 925-474-2233
EMail: jmurphy@trapezenetworks.com
o Partha Narasimhan
Aruba Wireless Networks
180 Great Oaks Blvd
San Jose, CA 95119
Phone: +1 408-754-3018
EMail: partha@arubanetworks.com
o Bob O’Hara
Airespace
110 Nortech Parkway
San Jose, CA 95134
Phone: +1 408-635-2025
EMail: bob@airespace.com
o Emek Sadot (see Authors’ Addresses)
o Ajit Sanzgiri
Cisco Systems
170 W Tasman Drive
San Jose, CA 95134
Phone: +1 408-527-4252
EMail: sanzgiri@cisco.com
o Singh
Chantry Networks
1900 Minnesota Court
Mississauga, Ontario L5N 3C9
Canada
Phone: +1 905-567-6900
EMail: isingh@chantrynetworks.com
o L. Lily Yang (Editor, see Authors’ Addresses)
o Petros Zerfos (see Authors’ Addresses)
In addition, we would also like to acknowledge contributions from the
following individuals who participated in the architecture survey and
provided detailed input data in preparation of the taxonomy: Parviz
Yegani, Cheng Hong, Saravanan Govindan, Bob Beach, Dennis Volpano,
Shankar Narayanaswamy, Simon Barber, Srinivasa Rao Addepalli,
Subhashini A. Venkataramanan, Kue Wong, Kevin Dick, Ted Kuo, and
Tyan-shu Jou. It is simply impossible to write this taxonomy without
the large set of representative data points that they provided to us.
We would also like to thank our CAPWAP WG co-chairs, Mahalingam Mani
and Dorothy Gellert, and our Area Director, Bert Wijnen, for their
unfailing support.
10. Normative References
[1] "IEEE WLAN MAC and PHY Layer Specifications", August 1999, <IEEE
802.11-99>.
[2] O’Hara, B., Calhoun, P., and J. Kempf, "Configuration and
Provisioning for Wireless Access Points (CAPWAP) Problem
Statement", RFC 3990, February 2005.
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[4] "IEEE Std 802.11i: Medium Access Control (MAC) Security
Enhancements", April 2004.
[5] "IEEE Std 802.11h: Spectrum and Transmit Power Management
Extensions in the 5 GHz Band in Europe", October 2003.
[6] "IEEE Std 802.1X: Port-based Network Access Control", June 2001.
Authors’ Addresses
L. Lily Yang
Intel Corp.
MS JF3 206, 2111 NE 25th Avenue
Hillsboro, OR 97124
Phone: +1 503-264-8813
EMail: lily.l.yang@intel.com
Petros Zerfos
UCLA - Computer Science Department
4403 Boelter Hall
Los Angeles, CA 90095
Phone: +1 310-206-3091
EMail: pzerfos@cs.ucla.edu
Emek Sadot
Avaya
Atidim Technology Park, Building #3
Tel-Aviv 61131
Israel
Phone: +972-3-645-7591
EMail: esadot@avaya.com
Full Copyright Statement
Copyright (C) The Internet Society (2005).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.