Subject: [Capwap] Expert Review - from Bernard Aboba.

From: "Mani, Mahalingam (Mahalingam)" <[email-masked]>
Date: Wed, 19 May 2004 16:35:28 -0600

Attached is the review comment from Bernard's comments. Feel free to
review them in the context of the -02 draft of architecture taxonomy.

Regards,

-mani

Mahalingam Mani

Subject: Review of draft-ietf-capwap-arch-02.txt
From: "Bernard Aboba" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>, "Mani, Mahalingam (Mahalingam)" <[email-masked]>
Date: Tue, 11 May 2004 18:01:43 -0600

Review of draft-ietf-capwap-arch-02.txt
May 11, 2004
Bernard Aboba <[email-masked]>

Overall comments:

Overall, I found this document useful in summarizing current industry practice.
On reading it however, I found myself questioning whether it was really an
architecture taxonomy, or whether it was just a "Review of CAPWAP Implementations."
See RFC 2194 for an example of an implementation review document.

The distinction is important, I think.  For example, while one might expect
a Taxonomy document to include a detailed examination of architectural
issues an implementation review might not be expected to delve as deeply.

An example of this quandry comes in the security area, where the document provides
examples of security functionality implemented by APs, but does not
(yet) deliver a detailed analysis.  I would prefer not to set the
expectations too high in this regard, because I see this document as
focussing on what current implementations do, not what they could or
should be doing.

Since documents like this age quickly, there is a temptation to endlessly
update it.  My advice would be to resist this temptation and instead to
make rapid progress on resolving outstanding issues so that it can be published
quickly.  I believe this can be most readily accomplished by making the
objectives of the document clear and seting expectations:  the
document focus is on reviewing current implementations.

In terms of technical issues there are only a few that stand out, such as
the distinction between 802.11 AP behavior and 802.1D bridges, and behavior
with respect to static and dynamic VLANs.  My suggestion would be to obtain
review from experts in this area, such as Mick Seaman, Paul Congdon or Tony Jeffree.

In terms of NITs, the document could benefit from a grammar edit and spell check.

Page 6:

"while tunnel all"  -> "while tunneling all"

Page 7:

Change:

"We recognize that some terminology have been used by vendors
historically, but we recommend stop using to avoid further confusion,
mostly around the term of "AP". We provide a list of such terms here
with the recommended new terminology:"

To:

"While some terminology has been used by vendors historically to
describe "Access Points", we recommend that it not continue to
be used in order to avoid further confusion. A list of such
terms and the recommended new terminology are provided below:"

Section 2.1

"   The IEEE 802.11 specifications are wireless standards that specify an
   "over-the-air" interface between a wireless client (STA) and an
   Access Point (AP), as well as among wireless clients. 802.11 also
   describes how mobile devices can associate together into a basic
   service set (BSS), the rough equivalent of a single broadcast domain
   or a segment of a bridged Ethernet LAN."

Actually, the IEEE 802.11 specifications also cover the IBSS case. So
I think it would be more accurate to say that they cover the interface
between STAs (since an AP is also a STA).   A BSS is not really the rough
equivalent of a bridged Ethernet LAN because an Access Point is not a
bridge.  It is also not accurate to say that a BSS is a single broadcast
domain, because an AP may implement multiple VLANs.

"A BSS is identified by a common service set identifier (SSID) or name."

Since many BSSes (potentially in different broadcast domains) can be
identified by a single SSID, the SSID is little more than a non-unique
network name.

"An ESS is also similar to a single broadcast
domain, where a mobile device associated with one AP can successfully
ARP for the address of a mobile device associated with any other AP
in the ESS. Within an ESS, a mobile station can roam from one AP to
another through only layer 2 transitions coordinated by the 802.11
MAC management protocol. Higher layer protocols, including IP are
unaware that the network attachment point of the mobile device has
moved."

This paragraph is not accurate because the STAs in an ESS may not
be members of the same VLAN, even though they are associated with
the same SSID.  So a mobile device associated with one
AP cannot necessarily successfully ARP for the MAC address of
any AP associated with another AP, even though they are both
advertising the same SSID.

It is also not necessarily true that higher layer protocols such
as IP are or should be unaware that the network attachment point
has moved. On connecting to a new AP, the host cannot take for
granted that it remains in the same broadcast domain even though
it remains associated with the same SSID.

Because "same SSID" does not imply "same broadcast domain", it
is possible that the host's address is no longer valid.  As a result,
DNAv4 suggests that the IP layer confirm that the
STA remains attached to a network on which it has a valid routable
IP address before continuing to use that address.

"   o  Authentication: The service used to establish the identity of one
      station as a member of the set of stations authorized to associate
      with another station."

Actually, authentication in IEEE 802.11 does not necessarily operate this
way, because authentication can take place *after* association, in which
case authorization is not determined until later.

"mobility of the STA from one BSS to the other (802.11f),
Radio Resource Management (802.11f) etc."

IEEE 802.11k is Radio Resource Management (RRM), not .11F.

Section 2.3

Change:

"  This document brings into light the different WLAN network
   architectures that have been followed so far by different vendors,"

To:

"This document provides a taxonomy of the WLAN network architectures
developed by the vendor community,"

Change:

"Such AP architecture is called Autonomous WLAN Architecture,"

To:

"Such an AP architecture as called an Autonomous WLAN Architecture,"

Change:

"The centralized controller is commonly referred to as Access
Controller (AC),"

To:

"The centralized controller is commonly referred to as an Access
Controller (AC),"

Change:

"Access Controller could be a L3 or L2 device, and it
could also be co-located with a L2 bridge (switch) or a L3 router,
and hence may be referred to as Access Bridge, or Access Router in
those particular cases. But Access Controller is the generic
terminology we use through this document."

to:

"The Access Controller can be a L3 or L2 device, and it
could also be co-located with a L2 bridge (switch) or a L3 router,
and hence may be referred to as an Access Bridge or Access Router in
those particular cases. Access Controller is the generic
terminology we use in this document."

Change:

"Because the WTP devices
only implement a portion of the functions that standalone APs
implement, and such WTP devices in such architecture are sometimes
referred to as light weight or thin APs."

to:

"Since the WTP devices
only implement a portion of the functions that standalone APs
implement, WTP devices in this architecture are sometimes
referred to as light weight or thin APs."

Section 3.1

"A single physical WTP can optionally be provisioned as multiple
virtual WTPs by supporting multiple SSIDs to which 802.11 clients may
associate. Usually this will also involve putting a corresponding
802.1Q tag on each packet forwarded to the Ethernet infrastructure."

Removal of tags is also required, since tagged frames are not sent
over the WM.

Section 3.2

"   Since both the 802.11 and CAPWAP functionality is tightly integrated
   into a single physical device, the security issues with this
   architecture are confined to the WTP."

I think what you mean to say is that no additional security issues arise
since the AP is autonomous.

Section 4

"Centralied WLAN Architecture" => Centralized WLAN Architecture

Section 4.4

Change:

"Last but not least,  moving functions
like encryption and decryption to the AC instead of WTPs help avoid
any risk from a compromised WTP by not having user encryption keys on
the WTP at all."

To:

""Last but not least,  moving functions
like encryption and decryption to the AC instead of WTPs reduce
vulnerabilities from a compromised WTP since user encryption keys no longer
reside on the WTP."

"It can also protect from LAN-side eavesdropping."

This is most commonly an issue if the DS is implemented as shared media.

"   o  Integration Services: bridging between 802.11 and 802.3"

Careful.  IEEE 802.11 APs do not function as IEEE 802.1D bridges.
For example, they do not necessarily implement spanning tree, and
also do forward frames the same way.  For example, if a frame
is received on the DS destined to an unknown address, an AP will
not forward the frame onto the WM unless there is a STA associated
with that MAC address, whereas a switch would forward the frame.

Change:

"It is clear that even within the Split MAC
Architecture, vendors choose to map many of the functions
differently. All vendors choose to implement Distribution,
Integration Service at the AC, along with 802.1x/EAP authentication
and keys management. All vendors also choose to implement beacon
generation at WTPs. But there exists wide spread difference among the
vendors for most other functions. So this clearly indicates that
Split MAC Architecture represents a category of architectures that
split the MAC somehow, but it does not represent a single way of
splitting at all."

To:

"It is clear that even within the Split MAC
Architecture, vendors choose to map many of the functions
differently. All vendors choose to implement Distribution and
Integration Service at the AC, along with 802.1x/EAP authentication
and key management. All vendors also choose to implement beacon
generation at WTPs. But there are widespread differences among the
vendors for most other functions. Therefore Split MAC Architectures
are not consistent in the manner in which the MAC is split."

" All vendors choose to implement Distribution,
Integration Service at the AC, along with 802.1x/EAP authentication
and keys management."

The major advantage of this approach is that it enables sharing
of the PMK key cache between APs attached to a switch, which
generates a higher cache hit rate.

Section 4.5

Change:

"   One of the main motivation for Remote MAC Architecture is to keep the
   WTPs as light weight as possible by having only the radio interface
   on the WTPs and offloading the entire set of 802.11 MAC functions
   (including delay-sensitive functions)  to the Access Controller. It
   thus keeps all the complexities of the MAC and other CAPWAP control
   functions to the centralized controller and makes the WTP manageable.
   The WTP acts only as a communication means between the Wireless LAN
   clients (STA) and the AC, though they may have an additional feature
   to convert the frames from one format (802.11) to the other
   (Ethernet, TR, Fiber etc.). The centralized controller has a protocol
   for network monitoring, management and control, entire set of the
   802.11 AP services, the WLAN PHY concepts, security features,
   resource management, channel adoption features, guarantying Quality
   of Service to the users etc. Because MAC is separated from the PHY,
   we call this "Remote MAC Architecture". Typically such architecture
   is deployed with special attention to the topology between WTP and AC
   so that the delay is minimized. The RoF (Radio over Fiber) from
   Architecture 5 Appendix F is such an example of Remote MAC
   Architecture."

To:

"  One of the main motivations for the Remote MAC Architecture is to keep the
   WTPs as light weight as possible, by having only the radio interface
   on the WTPs and offloading the entire 802.11 MAC (including delay-sensitive
   functions)  to the Access Controller. This leaves the complexities
   of the MAC and control functions to the centralized controller and
   improves WTP manageability.

   The WTP acts only as a pass-through between the Wireless LAN
   clients (STA) and the AC, though they may have an additional feature
   to convert frames from one format (802.11) to another (Ethernet,
   Token Ring, FDDI, etc.). The centralized controller provides
   for network monitoring, management and control, the entire set of
   802.11 AP services, the WLAN PHY concepts, security features,
   resource management, channel adoption features, guarantying Quality
   of Service to the users etc.  Because the MAC is separated from the PHY,
   we call this the "Remote MAC Architecture".  Typically such an architecture
   is deployed with special attention to the topology between the WTP and AC,
   so that the delay is minimized.  The RoF (Radio over Fiber) design described
   in Architecture 5 Appendix F is an example of the Remote MAC
   Architecture."

Section 4.6

Change: "so that 802.11 timing constraint is still satisfied." To:

"so that the 802.11 timing contraints are satisfied."

"   ACs can be employed for 802.11 frames bridging (data plane)."

Same comment that 802.11 APs != bridging.

Section 4.7

"   1.  Discovery : WTP(s) discover the AC with which they will
       associate, and be controlled by."

I would recommend that the term "associate" not be used in this context. How
about "which they will be bound to and controlled by."

"The opposite is not always supported, since
some vendors strive for zero-configuration on the WTP side."

I think you mean to say that mutual authentication is not always supported.
You might say a few words about the drawbacks -- attacks by rogue ACs.

"   4.  Firmware Download: after successful association, the WTP may
       pull, or the AC may push the WTPs firmware , which is digitally
       signed."

I would say "which may be protected in some manner, such as via digital
signatures."

"   5.  Control Channel Establishment: the WTP establishes either an
       IP-tunnel (ex. Architecture 2 (Appendix C), Architecture 1
       (Appendix B)) or performs Ethernet encapsulation (ex.
       Architecture 4 (Appendix E)) with the AC, in order to transfer
       data traffic and management frames."

I have also in one case seen MAC Address Translation (MAT) state
established in the WTP for the purpose of offload 802.1X to the
AC.  This has some drawbacks, such as when EAP method utilized
for 802.11 authentication implement Channel Binding.

Section 4.8.2

Overall this section is trying to describe the security measures that are
put in place by current designs.  This goal is distinct from attempting to
provide a threat analysis and I think you need to keep this distinction clear.

Change:

"  In order for the CAPWAP functions to be implemented in the
   Centralized WLAN Architecture there is a requirement for a control
   channel between WTP and AC.  This is the link where security threats
   may arise.

   Threats to the Centralized WLAN Architecture as presented in the
   submissions are:
   1.  Secure discovery of WTP and AC
   2.  Authentication of the WTPs to the ACs and vice versa
   3.  Man-in-the-middle attacks to the control channel between WTP and
       AC.
   4.  Confidentiality and integrity of control channel frames
   5.  Theft of WTPs and extraction of embedded secrets within."

To:

"  In order for CAPWAP functions to be implemented in the Centralized
   WLAN Architecture it is necessary for a control channel to
   exist between the WTP and AC.

   In order to address potential security threats against the control
   channel, existing implementations feature one or more of the following
   security mechanisms:

   1.  Secure discovery of the WTP by the AC (or is it of the AP by the WTC?)
   2.  Authentication of the WTPs to the ACs (and possibly mutual authentication)
   3.  Confidentiality and integrity of control channel frames
   4.  Secure management of WTPs and ACs, including mechanisms for securely
       setting and resetting secrets."

Section 5 & 5.1

I realize that your taxonomy will not be complete without describing the Mesh
networking family.  However, mesh networking is a large area in and of itself,
so I hope that the authors will not have to expend inordinate effort on this,
particularly since only 1 of the 14 submitted surveys utilized this
architecture.

My advice is to only make a modest effort in this direction for completeness,
so that rapid progress can be made on completing the document.

Section 6

devided -> divided

"which includes those that are" -> "which include those that are"

Section 6.2

I'd suggest that this section be moved to the end of the documents as an Appendix,
since it's likely to be deleted prior to publication.

Section 7

"   While this taxonomy documents the architectures employed in the
   existing IEEE 802.11 products in the market, it also documents the
   security issues that arise with the varied ways in which vendors have
   chosen to employ these architectures."

I am not sure that Section 4.8.2 really accomplishes this, and more
importantly I'm not sure that a comprehensive threat analysis is a goal
of this document.

"While
Section 3, Section 4 and Section 5 are devoted to each of these three
architecture families, respectively, each section also contains a
subsection to address the security issues within each architecture
family. Please refer to Section 3Section 3 and Section 3  for
detailed security considerations in each of these architecture
families."

I think you don't really want to sign up to do a comprehensive
security review of each architecture family within this document,
so I would delete this paragraph and summarize in Section 7 as you
have been doing, adding a disclaimer that a complete security review
is not a goal.  Otherwise you could be stepping in quicksand...