RFC 5418: Control And Provisioning of Wireless Access Points (CAPWAP) Threat Analysis for IEEE 802.11 Deployments
In plain English — editorial summary, not part of the RFC
Early Wireless Local Area Network (WLAN) deployments feature a "fat" Access Point (AP), which serves as a \%stand-alone interface between the wired and wireless network segments. However, this model raises scaling, mobility, and manageability issues, and the Control and Provisioning of Wireless Access Points (CAPWAP) protocol is meant to address these issues. 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 IEEE 802.11-based CAPWAP implementations and deployments. This memo provides information for the Internet community.
Document record
- Document ID
- RFC5418
- Published
- March 2009
- Authors
- S. Kelly; T. Clancy
- Status
- INFORMATIONAL
- Stream
- IETF
- Area
- ops
- Pages
- 34
- Also known as
- —
Topics
Related documents
Ranked automatically by shared keywords, IETF area and stream — not by editorial selection.
- RFC 4890Recommendations for Filtering ICMPv6 Messages in FirewallsCurrent
May 2007
- RFC 4564Objectives for Control and Provisioning of Wireless Access Points (CAPWAP)Current
July 2006
- RFC 6382Unique Origin Autonomous System Numbers (ASNs) per Node for Globally Anycasted ServicesCurrent
October 2011
- RFC 7404Using Only Link-Local Addressing inside an IPv6 NetworkCurrent
November 2014
- RFC 3227Guidelines for Evidence Collection and ArchivingCurrent
February 2002
- RFC 3084COPS Usage for Policy Provisioning (COPS-PR)Current
March 2001
- RFC 2870Root Name Server Operational RequirementsObsoleted
June 2000
- RFC 2754RPS IANA IssuesObsoleted
January 2000
Also filed under
About this page
The document record above — title, authors, date, status, stream, area, relationships, DOI and errata — is imported verbatim from the public RFC Editor index. The “in plain English” section is editorial: written by The metasystema editorial team, not part of the RFC. Where the two differ, the RFC text governs.
Last checked against the RFC Editor index on . RFCs are never revised after publication; changes are issued as new documents.
Data sources · Editorial policy · Report a correction · What is an RFC?