CAPWAP Threat Analysis for 802.11 Deployments
draft-kelly-capwap-threat-analysis-00
| Document | Type |
Replaced Internet-Draft
(individual)
Expired & archived
|
|
|---|---|---|---|
| Authors | Scott G. Kelly , Charles Clancy | ||
| Last updated | 2008-04-16 (Latest revision 2006-10-17) | ||
| Replaced by | draft-ietf-capwap-threat-analysis | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | Replaced by draft-ietf-capwap-threat-analysis | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
This Internet-Draft is no longer active. A copy of the expired Internet-Draft is available in these formats:
Abstract
Early Wireless LAN (WLAN) deployments feature a "fat" Access Point (AP) which serves as a standalone interface between the wired and wireless network segments. However, this model raises scaling, mobility, and manageability issues, and the CAPWAP protocol [CAPWAP] is being developed in reponse. CAPWAP effectively splits the fat AP functionality into two network elements, and the communication channel between these components may traverse potentially hostile hops. This document analyzes the security exposure resulting from the introduction of CAPWAP, and summarizes the associated security considerations for CAPWAP implementations and deployments.
Authors
(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)