CAPWAP Issues

1
CAPWAP Issues
2
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 OHara)
• Defining where specific AP functions reside in an
  hierarchical model is fine

3
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

4
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

5
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.

6
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

7
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

8
What about proprietary 802.11 extensions?

• How does CAPWAP deal with vendor proprietary
  extensions?
• While CAPWAP cannot go out of its way to break
  the basic 802.11 protocol, interoperability with
  undocumented features cannot be guaranteed

9
Isnt it all about interoperability?

• Comment about whether CAPWAP will provide AP-AR
  interoperability, or if its just a protocol
• If interoperability cannot be achieved, then the
  WG has failed
• New (proposed) charter specifically includes
  interoperability for users
• Anyones AP can plug into any AR

10
Why is it an AR?

• AR was convenient (defined in IETF documents),
  but agree that its not a 100 match
• AR has specific connotations
• Lets call it an access controller (AC), or
  something other than AR

11
Is the management part not a MIB issue?

• Highest potential area of duplication
• Do we need another management protocol?
• Justification needs to be made
• Lets finish the architecture document, and let
  the requirements fall out from that
• We can then decide whether SNMP is sufficient for
  this problem

12
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.

13
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.

14
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.

15
Backup
16
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. draft-calhoun-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.

17
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

18
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

19
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 2004Re-charter