Subject: [Capwap] CAPWAP Architecture Taxonomy v04 is ready for WG review

From: "Yang, Lily L" <[email-masked]>
Date: Thu, 29 Jul 2004 11:21:07 -0700

Hi, all -

V04 of the CAPWAP Architecture Taxonomy is ready for WG review and we
also like to request WG last call on it.

Please check it out here at:

http://www.cs.ucla.edu/~pzerfos/draft-ietf-capwap-arch-04.txt, before it
is available through IETF repository.

This revision is mostly motivated by the comments posted by Pat and the
discussions afterward on the mailing list. We also took this opportunity
to remove all the appendix data and hence greatly shortened the length
of the document to only 40 pages long now. 

V04 is a minor revision over 03, with mostly clarification changes, and
a few corrections. To help you review the document, I provide a detailed
change log from v03 to v04  below. 

The Design Team feel the taxonomy document has been matured a lot since
last IETF meeting, and has been thoroughly reviewed by both IEEE 802.11
and IETF members since May, and we feel that it is ready for WG last
call. 

Thanks,

Lily (Editor)

--------------------- Detailed change log from v03 to v04 ------------

In the rough order of significance: 

1) Section 1.3 "Terminology Used in this Document"

For "Split MAC Architecture": 

[old]"...implement the delay sensitive MAC services (like the control
frame processing) for IEEE 802.11, while tunneling all the management
and data frames to AC for centralized processing."

[new]"...implement the delay sensitive MAC services (including all
control frames and some management frames) for IEEE 802.11, while
tunneling all the remaining management and data frames to AC for
centralized processing."

2) Section 3.2 "Security" (note: for autonomous architecture)

[old]"As per problem #4 (in problem statement), the only security issue
in this architecture is mutual authentication between the WTP and the
Ethernet infrastructure to ensure that WTPs cannot be easily stolen and
deployed in unprotected networks. This can be ensured by existing
mechanisms such as, for instance, 802.1x between the WTP and the
Ethernet switch it plugs into."

[new]One of the security issues in this architecture is the need for
mutual authentication between the WTP and the Ethernet infrastructure.
This can be ensured by existing mechanisms such as, 802.1x between the
WTP and the Ethernet switch it plugs into. Another security issue with
this architecture is the very fact that the WTP is most likely not under
lock and key, but does contain secret information in order to
communicate with the backend systems, such as AAA, SNMP, etc. Due to the
common management method used by IT personel of pushing a "template" to
all similar devices, theft of such a device would potentially compromise
the wired network. 

3) Section 4 "Centralized WLAN Architecture": 

At the end of first paragraph, delete "A Network Management Station can
be considered part of the Access Controller, but typically the latter
contains additional functionality beyond that of the former. "

Instead, add the following to the end of last paragraph "The AC(s) may
also choose to implement some of the control functions locally while
providing interfaces to access other global network management functions
which are typically implemented on separate boxes, such as a SNMP
Network Management Station and an AAA backend server (e.g., Radius
Authentication Server)."

4) Section 4.5 "Remote MAC" First paragraph, delete ", and improves WTP
manageability" at the end.

5) Section 4.6 "Comparisons of Local MAC, Split MAC and Remote MAC"

Added the following paragraph at the end of this section:

"Each of the three architectural variants may be advantageous in certain
aspects for certain deployment scenarious. While Local MAC retains most
of the STAs state information at the local WTPs, Remote MAC centralizes
most of the state into the backend AC. Split MAC sits somewhat in the
middle of that spectrum, keeping some state information locally at the
WTPs, and the rest centrally at the AC. Many factors should be taken
into account to determine the exact balance desired between centralized
v.s. decentralized state. The impact of such balance on network
manageability is currently a matter of dispute within the technical
community. "

6) Section 5 "Distributed Mesh Architecture" 3rd paragraph:

[old]Any global configuration or policy

   change can be better served in a coordinated fashion if an AC exists.

   For example, a centralized management entity can be used to update

   every mesh node's default configuration; it may also be more

   desirable to leave certain functions (such as user authentication) to

   a centralized AC (Access Controller), with an alternative being to

   distribute them across the mesh nodes.

[new] Some global configuration or policy

   change may be better served in a coordinated fashion if some form of

   Access Controller (AC) exists in the mesh network, even if not the

   full blown version of the AC as defined in the Centralized WLAN

   Architecture.  For example, a centralized management entity can be

   used to update every mesh node's default configuration; it may also

   be more desirable to leave certain functions such as user

   authentication to a single centralized end point (such as a RADIUS

   server), but mesh networks allows the possibility of each mesh AP to

   directly talk to the RADIUS server.  This reduces single point of

   failure and takes advantage of the client distribution in the

   network.

7) Section 4.1 old title "Interconnection Topology between WTPs and ACs"
is changed to "Interconnection between WTPs and ACs".

Throughout the document, "topology" (when referred to L2 or L3
connection) is replaced with either "connection" or "interconnectivity".

8) 4.2 old title "Overview of Three Centralized WLAN Architectures" is
changed to "Overview of Three Centralized WLAN Architecture Variants"

9) 5.1 "Security" (note: for mesh)

Added "Each node that is part of the mesh must be fully trusted for the
mesh to be secure. " in the first paragraph.

10) removed all appendix sections & references to the individual
architecture submissions

11) Editorial changes (to fix typos, grammar, better sentence/paragraph
flows) throughout the document.

---

From: <[email-masked]>
Date: Fri, 30 Jul 2004 16:33:28 -0700

Hi Lily-
 
Thanks to you and the design team for V04 of the architecture taxonomy draft.    The WG process requires documents to be submitted in to the internet-drafts repository 2 weeks prior to an IETF meeting, in order to discuss it at the WG meeting.  SInce the DT has placed the draft in an accessible location (see link below) and petitioned the AD and the Chairs, unless the WG has any objections we will proceed to discuss the latest 04 version of the taxonomy draft at the CAPWAP WG meeting next week in San Diego.
 
Additionally, we cannot officially go into WGLC with a draft that has not been accepted into the internet-drafts repository yet, so the WG LC cannot officially begin until after August 9th.    However, we can still use the WG list to comment on the draft and we encourage the WG to review v04 and submit comments as they arise.
 
Thanks,
Dorothy and Mani

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of ext Yang, Lily L
Sent: Thursday, July 29, 2004 11:21 AM
To: [email-masked]
Subject: [Capwap] CAPWAP Architecture Taxonomy v04 is ready for WG review

Hi, all -

V04 of the CAPWAP Architecture Taxonomy is ready for WG review and we also like to request WG last call on it.

http://www.cs.ucla.edu/~pzerfos/draft-ietf-capwap-arch-04.txt, before it is available through IETF repository.

This revision is mostly motivated by the comments posted by Pat and the discussions afterward on the mailing list. We also took this opportunity to remove all the appendix data and hence greatly shortened the length of the document to only 40 pages long now. 

V04 is a minor revision over 03, with mostly clarification changes, and a few corrections. To help you review the document, I provide a detailed change log from v03 to v04  below. 

The Design Team feel the taxonomy document has been matured a lot since last IETF meeting, and has been thoroughly reviewed by both IEEE 802.11 and IETF members since May, and we feel that it is ready for WG last call. 

Thanks,

Lily (Editor)

--------------------- Detailed change log from v03 to v04 ------------

[old]"...implement the delay sensitive MAC services (like the control frame processing) for IEEE 802.11, while tunneling all the management and data frames to AC for centralized processing."

[new]"...implement the delay sensitive MAC services (including all control frames and some management frames) for IEEE 802.11, while tunneling all the remaining management and data frames to AC for centralized processing."

[old]"As per problem #4 (in problem statement), the only security issue in this architecture is mutual authentication between the WTP and the Ethernet infrastructure to ensure that WTPs cannot be easily stolen and deployed in unprotected networks. This can be ensured by existing mechanisms such as, for instance, 802.1x between the WTP and the Ethernet switch it plugs into."

[new]One of the security issues in this architecture is the need for mutual authentication between the WTP and the Ethernet infrastructure. This can be ensured by existing mechanisms such as, 802.1x between the WTP and the Ethernet switch it plugs into. Another security issue with this architecture is the very fact that the WTP is most likely not under lock and key, but does contain secret information in order to communicate with the backend systems, such as AAA, SNMP, etc. Due to the common management method used by IT personel of pushing a "template" to all similar devices, theft of such a device would potentially compromise the wired network. 

At the end of first paragraph, delete "A Network Management Station can be considered part of the Access Controller, but typically the latter contains additional functionality beyond that of the former. "

Instead, add the following to the end of last paragraph "The AC(s) may also choose to implement some of the control functions locally while providing interfaces to access other global network management functions which are typically implemented on separate boxes, such as a SNMP Network Management Station and an AAA backend server (e.g., Radius Authentication Server)."

4) Section 4.5 "Remote MAC" First paragraph, delete ", and improves WTP manageability" at the end.

"Each of the three architectural variants may be advantageous in certain aspects for certain deployment scenarious. While Local MAC retains most of the STAs state information at the local WTPs, Remote MAC centralizes most of the state into the backend AC. Split MAC sits somewhat in the middle of that spectrum, keeping some state information locally at the WTPs, and the rest centrally at the AC. Many factors should be taken into account to determine the exact balance desired between centralized v.s. decentralized state. The impact of such balance on network manageability is currently a matter of dispute within the technical community. "

   network.

7) Section 4.1 old title "Interconnection Topology between WTPs and ACs" is changed to "Interconnection between WTPs and ACs".

Throughout the document, "topology" (when referred to L2 or L3 connection) is replaced with either "connection" or "interconnectivity". 

8) 4.2 old title "Overview of Three Centralized WLAN Architectures" is changed to "Overview of Three Centralized WLAN Architecture Variants"

Added "Each node that is part of the mesh must be fully trusted for the mesh to be secure. " in the first paragraph.

10) removed all appendix sections & references to the individual architecture submissions

11) Editorial changes (to fix typos, grammar, better sentence/paragraph flows) throughout the document.

---

From: "Pat R. Calhoun" <[email-masked]>
Date: Fri, 30 Jul 2004 16:42:24 -0700

I do not object - let's discuss the draft next week.
 
And thanks to the DT for a great job.
 
PatC

________________________________

From: [email-masked] on behalf of [email-masked]
Sent: Fri 7/30/2004 4:33 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [Capwap] CAPWAP Architecture Taxonomy v04 is ready for WG review

Hi Lily-

 
Thanks,
Dorothy and Mani

	-----Original Message-----
	From: [email-masked] [mailto:[email-masked]]On Behalf Of ext Yang, Lily L
	Sent: Thursday, July 29, 2004 11:21 AM
	To: [email-masked]
	Subject: [Capwap] CAPWAP Architecture Taxonomy v04 is ready for WG review

	Hi, all -

	Thanks,

	Lily (Editor)

	--------------------- Detailed change log from v03 to v04 ------------

	   network.