CAPWAP Issues
1
Capwap issues.PPT / DD-MM-YYYY / Initials
Does the work belong in the IETF?
• This topic has been discussed at length, and the following agreements have
been made:
• CAPWAP cannot require any changes to the MAC or the PHY
• The architecture/work must be closely reviewed by the IEEE
• A liaison with IEEE is required (Dorothy Stanley)
• A technical advisor from IEEE is also required (Bob O’Hara)
• Defining where specific AP functions reside in an hierarchical model is
fine
2
Capwap issues.PPT / DD-MM-YYYY / Initials
Is “Secure Download” in scope?
• There are concerns about this (proposed) WG working on a secure
download protocol
• It is a generic problem
• CAPWAP will not include this work in the proposed charter
• Should be defined in another WG, if it is required
3
Capwap issues.PPT / DD-MM-YYYY / Initials
Why re-invent a discovery protocol?
• The original charter included defining a discovery protocol
• The (proposed) WG will recommend existing discovery mechanisms to be
used
4
Capwap issues.PPT / DD-MM-YYYY / Initials
Is IP used in CAPWAP solely to justify it being
defined in the IETF?
• CAPWAP is all about scaling!
• Enterprise networks follow the recommended distribution/core network
architecture proposed by Cisco.
• This means that networks have a greater number of smaller subnets
• Using a layers 2 protocol between the AP and the AR means:
• A greater number of ARs per network (one per subnet), or
• Extending VLANs to create the perception of a larger subnet
• IT managers have spoken. They want to have fewer ARs, centralized in
their core network. So L3 is necessary.
5
Capwap issues.PPT / DD-MM-YYYY / Initials
Why discuss protocol work in the charter?
• The previous charter included protocol milestones.
• The consensus is to work on a problem statement and architecture
document.
• The (proposed) WG can re-charter afterwards
6
Capwap issues.PPT / DD-MM-YYYY / Initials
Get agreement on functionality split
• Point raised by the IESG is that one of the highest priority items is to get
agreement on the functionality split (“split AP”)
• The architecture document will address this issue
• Once the document is complete, and last call is completed, we can move
forward with a clear understanding of the model used
7
Capwap issues.PPT / DD-MM-YYYY / Initials
What about proprietary 802.11 extensions?
• How does CAPWAP deal with vendor proprietary extensions?
• While CAPWAP cannot go out of it’s way to break the basic 802.11
protocol, interoperability with undocumented features cannot be
guaranteed
8
Capwap issues.PPT / DD-MM-YYYY / Initials
Isn’t it all about interoperability?
• Comment about whether CAPWAP will provide AP-AR interoperability, or if
it’s just a protocol
• If interoperability cannot be achieved, then the WG has failed
• New (proposed) charter specifically includes interoperability for users
• Anyone’s AP can plug into any AR
9
Capwap issues.PPT / DD-MM-YYYY / Initials
Why is it an AR?
• AR was convenient (defined in IETF documents), but agree that it’s not a
100% match
• AR has specific connotations
• Let’s call it an access controller (AC), or something other than AR
10
Capwap issues.PPT / DD-MM-YYYY / Initials
Is the management part not a MIB issue?
• Highest potential area of duplication
• Do we need another management protocol?
• Justification needs to be made
• Let’s finish the architecture document, and let the requirements fall out
from that
• We can then decide whether SNMP is sufficient for this problem
11
Capwap issues.PPT / DD-MM-YYYY / Initials
Terminology: Is CAPWAP AP lightweight?
• Lightweight AP: how light is light? should we drop lightweight references in
favor of emphasis on varied AP-AR split agnostic to heaviness.
12
Capwap issues.PPT / DD-MM-YYYY / Initials
CAPWAP Security: How light should it be?
• Given the range of AP architectures to be supported - how lightweight
should security protocol be?
• Frame Security (bulk encryption)
• It is one thing to consider security of CAPWAP exchanges
• it is another to include data security into the picture.
13
Capwap issues.PPT / DD-MM-YYYY / Initials
Security: Authentication Protocol Attributes
• Authentication: how many methods should be supported?
• Given the allowance for failover in the charter – latency may be a factor.
• Need to work on existing AP platforms will need to make this strong and
lightweight.
• Newer platforms must be able to use stronger methods.
• the above two may be achievable in one stroke.
14
Capwap issues.PPT / DD-MM-YYYY / Initials
Backup
15
Capwap issues.PPT / DD-MM-YYYY / Initials
Charter-v2
•
As the size and complexity of IEEE 802.11 wireless networks has increased, problems in the
deployment, management, and usability of these networks have become evident. draftcalhoun-capwap-problem-statement-00.txt describes some of those problems. In addition,
security considerations have become increasingly important as IEEE 802.11 networks have
been deployed in situations where their use in accessing sensitive data must be restricted for
business or other reasons. While there are many possible approaches to solving these
problems, most of them involve IP-level protocols in some fashion. To the extent changes to
existing IETF protocols are necessary or new IP-level protocols must be standardized to
facilitate interoperability, this work is an appropriate topic for the IETF.
• The charter of the CAPWAP Working Group is to define a "split AP" architecture for
the purpose of simplifying the deployment, management and usability of IEEE
802.11 wireless networks. The split AP architecture centralizes processing of access
point (AP) management functions, such as inter-AP configuration and control, and
non-realtime host functions, such as data transport and host authentication, in a
management entity, typically an Access Controller (AC). The IEEE 802.11 APs
continue to perform real-time host functions. The split AP architecture does not
involve any changes in IEEE 802.11 standards, since the IEEE 802.11 specification
says nothing about the architecture of the IEEE 802.11 access point. This new
architecture has been adopted by many manufacturers, each with some variation.
Creating an interoperable protocol between the AP and the AC will benefit the
network operator community by allowing operators to build networks with equipment
from a collection of vendors. The Working Group will attempt to utilize existing IETF
protocols where possible, but will engage in new design if necessary.
16
Capwap issues.PPT / DD-MM-YYYY / Initials
Charter-v2
• Specific Working Group work items are:
• Clear problem statement of CAPWAP work
• Description of the split AP architecture
• CAPWAP security requirements, defining the needs for security between
the AP and the AC, both for host data transport and for AP-AC signaling
and control
• The split AP architecture document will describe the following
components
• Discovery of ACs by APs
• Auto-organization of APs and ACs into a managed wireless access
network, including AC redundancy
• Secure Encapsulation of host data and AC-AP signaling, as
necessary to address the requirements
• Secure Configuration of the AP by the AC
17
Capwap issues.PPT / DD-MM-YYYY / Initials
Charter-v2
• The intent of the CAPWAP WG is to complete architecture specification as
quickly as possible and thereupon enhance charter to embark on
development of appropriate CAPWAP protocol.
• While not specifically a work item, the Working Group will attempt to make
all designs as independent of the IEEE 802.11 radio protocol as possible,
so that the protocol might, in the future be used with other radio protocols.
However, in any situation where a tradeoff between simplicity/speed of
design completion and extensibility is required, the Working Group will opt
for the former. The Working Group will also co-ordinate closely with the
IEEE 802.11 WG.
• The CAPWAP WG will maintain a close working liaison with relevant
working groups in IEEE 802.11 and IEEE 802.1
18
Capwap issues.PPT / DD-MM-YYYY / Initials
Charter-v2
• Specific non-goals of this work are:
• Support for general, inter-subnet micro-mobility,
• Interoperable APIs for downloaded AP code images,
• Any IP-layer work that would require changes to the IEEE 802.11 MAC layer,
• Dependence on yet to be approved IEEE 802.11 work or drafts,
• Support for an inter-AP communication protocol, like IEEE 802.11f,
• Direct joint development of protocols with the IEEE 802.11 WG.
• Working Group protocol documents and the security requirements will be sent to the
Security Area Advisory Group (SAAG) for review prior to submission to the IESG.
• Goals and Milestones:
• Feb 2004 Last call for problem statement draft
• Mar 2004: Last Call for architecture description document
• Apr 2004: Submit problem statement to IESG for review
• Jun 2004: Submit Architecture description document to IESG for review.
• July 2004 Submit to IESG for publication for review.
• July 2004:Re-charter
19
Capwap issues.PPT / DD-MM-YYYY / Initials