1 / 19

CAPWAP Issues

This topic discusses the scope of work for CAPWAP and addresses various protocol-related issues. It includes agreements on architecture review, liaison with IEEE, and the need for a technical advisor. The discussion also covers concerns about a secure download protocol and the use of IP in CAPWAP.

gibsonc
Download Presentation

CAPWAP Issues

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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 O’Hara) • 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 it’s way to break the basic 802.11 protocol, interoperability with undocumented features cannot be guaranteed

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

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

  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 • 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

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

More Related