From diameter-admin@frascone.com Sat May 1 05:23:03 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA05321 for ; Sat, 1 May 2004 05:23:03 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 65F73207E9 for ; Sat, 1 May 2004 05:10:50 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 600422094F for ; Sat, 1 May 2004 05:06:41 -0400 (EDT) Date: Sat, 01 May 2004 05:06:41 -0400 Message-ID: <20040501090641.18015.7341.Mailman@xavier> Subject: frascone.com mailing list memberships reminder From: mailman-owner@wolverine.cnri.reston.va.us To: capwap-archive@ietf.org X-No-Archive: yes X-Ack: no Sender: diameter-admin@frascone.com Errors-To: diameter-admin@frascone.com X-BeenThere: diameter@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) This is a reminder, sent out once a month, about your frascone.com mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, capwap-request@frascone.com) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. If you have questions, problems, comments, etc, send them to mailman-owner@wolverine. Thanks! Passwords for capwap-archive@lists.ietf.org: List Password // URL ---- -------- capwap@frascone.com xakour http://mail.frascone.com/mailman/options/capwap/capwap-archive%40lists.ietf.org From capwap-admin@frascone.com Tue May 11 14:24:35 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13890 for ; Tue, 11 May 2004 14:24:34 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 0BF031FF67; Tue, 11 May 2004 14:12:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D103D20589; Tue, 11 May 2004 14:12:02 -0400 (EDT) Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id F25B520589 for ; Tue, 11 May 2004 14:11:11 -0400 (EDT) Received: from hubble.802wirelessworld.com (216-237-54-34.orange.nextweb.net [216.237.54.34]) by mail.frascone.com (Postfix) with ESMTP id 433CE1FF67 for ; Tue, 11 May 2004 14:11:10 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by 80211wirelessworld.com (Postfix) with ESMTP id 77D4313B92A for ; Tue, 11 May 2004 14:23:26 -0400 (EDT) Received: from hubble.802wirelessworld.com ([127.0.0.1]) by localhost (hubble [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08476-02 for ; Tue, 11 May 2004 14:23:26 -0400 (EDT) Received: from tsjouthinkpad (dhcp8-005.802wirelessworld.com [10.0.8.5]) by hubble.802wirelessworld.com (Postfix) with ESMTP id 3770013B91D for ; Tue, 11 May 2004 14:23:26 -0400 (EDT) From: "Tyan-Shu Jou" To: Message-ID: <000001c43785$101a8cd0$0508000a@tsjouthinkpad> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2727.1300 Importance: Normal In-Reply-To: <000201c41deb$76ef4990$1400a8c0@tsjouthinkpad> X-Virus-Scanned: by amavisd-new-20030616-p7 (Debian) at idealcorp.com X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [Capwap] WLAN arch survey answer from Janusys Networks Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Tue, 11 May 2004 11:23:31 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Hi all, It seems like the CAPWAP taxonomy document can use more survey results on mesh topology, even though the deadline has passed. Upon the editor's request, I am putting our answer of the arch survey (template v2) onto the mailing list. Hope it can somewhat contribute to the CAPWAP work. Thanks. Tyan-Shu Jou Janusys Networks, Inc. ------------------------------ template starts here ---------------- contribution template for WLAN architecture survey (1) Design considerations & requirements: please briefly describe your design principles for this architecture. Ans: The architecture is to offer a WLAN mesh infrastructure-based ESS with a self-configurable network and adaptive topology. The access service can be easily set up and flexibly adjusted to reflect the need. It can also be used to extend wireless service at places that Ethernet wiring is difficult due to either cost or physical limitation. (2) WLAN functions supported: Please list the functions supported in this WLAN briefly, but please do not send us the entire data sheet. Examples of WLAN functions includes the STA services, Distributed System Services (as defined by 802.11), radio resource management and control, AP load balancing, mobility support, WLAN network wide security functions (including authentication, encryption for privacy and integrity, etc.) and any others not listed here but deemed important in your design. Ans: The STA access service to a WLAN mesh node is fully compliant with IEEE 802.11. Its transit services will be compliant with those specified in the emerging IEEE 802.11 Task Group S. (3) The functional architecture to implement the functions described above: whether it is by autonomous AP architecture, or "split" architecture. For split architecture, please provide the functional mapping of WLAN functions onto the AP and AC -- with just enough details that help us understand the kinds of functional interface necessary between the two. For distributed architectures, describe how the functionality is distributed across the nodes in the network. Ans: A mesh node within an ESS mesh network can be an autonomous device that acts as an AP to its local stations and as a traffic relay to neighboring mesh nodes. In this distributed architecture, each mesh node is expected to fully aware of the network topology of the ESS mesh network through topology information exchanged with its neighboring nodes. Alternatively, the split architecture can be applied to a WLAN mesh network. The mesh nodes can leave certain functions (such as user authentication) to a centralized AC in the wired network. Or, set of passive nodes (APs) can satellite around an active/intelligent node (AC). Network topology information is exchanged only among the active nodes. User access management can be decided either at the associated (autonomous or active) mesh node or at a centralized entity. (4) The protocol used in between AP and AC, for split architecture; or the protocol used between mesh nodes, for distributed architecture. Ans: A proprietary protocol between AP and AC. Another proprietary protocol between Mesh APs. (5) The topological assumptions between the network entities (is it directly connected, L2 switched, or L3 routed?) -- this also helps us to understand the deployment scenarios. Ans: The ESS mesh is a L2 access network. The management communication can be either L2 or L3 based. (6) Security threat analysis: what kinds of threat introduced by the architecture, and how that are addressed. Ans: Mesh nodes must authenticate each other and to secure the data transmission among neighboring nodes. Other than this consideration, the wireless mesh network has the similar security concern as other wireless access network. (7) Pros and Cons of this architecture, esp. in relation to the four problems described in the CAPWAP problem statement. Please keep the analysis at technical instead of marketing level. Ans: Management requirement: Mesh APs are self-configurable. They can form neighboring links and the forwarding Topology dynamically and automatically. The optional centralized control can be used to monitor the network at real time. Consistent configuration: Each Mesh AP node can learn the configuration from two sourcs: either from the network (via neighboring nodes) or from the centralized control. Dynamic media: A mesh network is designed to reflect the dynamic nature of a wireless access network. Its topology can be dynamically formed to reflect the radio situation. A centralized coordination is also possible in the described architecture. Securing Access: See the answer for (6). ------------------------------ template ends here ---------------- _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Wed May 19 18:53:48 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26670 for ; Wed, 19 May 2004 18:53:47 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 4768020A89; Wed, 19 May 2004 18:41:05 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 4353020A8C; Wed, 19 May 2004 18:41:02 -0400 (EDT) Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D312E20A8C for ; Wed, 19 May 2004 18:40:37 -0400 (EDT) Received: from tiere.net.avaya.com (tiere.net.avaya.com [198.152.12.100]) by mail.frascone.com (Postfix) with ESMTP id 0EBCE20A89 for ; Wed, 19 May 2004 18:40:36 -0400 (EDT) Received: from tiere.net.avaya.com (localhost [127.0.0.1]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id i4JMq1am004210 for ; Wed, 19 May 2004 18:52:01 -0400 (EDT) Received: from cof110avexu1.global.avaya.com (h135-9-6-16.avaya.com [135.9.6.16]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id i4JMq0am004183 for ; Wed, 19 May 2004 18:52:00 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C43DF4.117659E0" Message-ID: Thread-Topic: IEEE AdHoc Committee review comments. Thread-Index: AcQ99A2SA6t56CibR+CF7lWiDu19Eg== X-Priority: 1 Priority: Urgent Importance: high From: "Mani, Mahalingam (Mahalingam)" To: X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [Capwap] IEEE AdHoc Committee review comments. Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Wed, 19 May 2004 16:53:14 -0600 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) This is a multi-part message in MIME format. ------_=_NextPart_001_01C43DF4.117659E0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable All: =20 The IEEE 802.11 and related wireless WG's met for interim sessions last week (9-14 May 2004) at Orange County, CA. =20 The IEEE 802.11 WG Chair's AdHoc Committee, headed by Dorothy Stanley, had started the review on draft-ietf-capwap-arch-02 soon after its announcements (in fact they had met to start reviewing even earlier drafts) and have gone through a thorough and systematic review of the draft. =20 The review comments and letter describing the review conclusions are included in the document which is now posted in the CAPWAP Central website. The document link (http://www.capwap.org/11-04-0473-03-0000-input-to-ietf-capwap-wg-may-20 04.doc) is available on the main page and in the "CAPWAP Taxonomy Work" page. =20 Some CAPWAP WG participants (who are also active in IEEE) may have already noted this in the IEEE website (http://www.802wirelessworld.com). =20 We thank IEEE 802.11 WG chair for facilitating the AdHoc committee review and Dorothy Stanley and her AdHoc committee for the diligent critical review and thorough comments. =20 [Should there be difficulty reading the word document do let me know]. =20 Regards, -mani Mahalingam Mani 408.321.4840 (work) =20 ------_=_NextPart_001_01C43DF4.117659E0 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

All:

 

The IEEE 802.11 and related wireless WG’s met = for interim sessions last week (9-14 May 2004) at Orange = County, CA.

 

The IEEE 802.11 WG Chair’s AdHoc Committee, = headed by Dorothy Stanley, had started the review on = draft-ietf-capwap-arch-02

soon after its announcements (in fact they had met to = start reviewing even earlier drafts) and have gone through a thorough = and

systematic review of the draft.

 

The review comments and letter describing the review = conclusions are included in the document which is now posted in = the

CAPWAP Central = website. The document link (http://www.capwap.org/11-04-0473-03-0000-input-to-ietf-capw= ap-wg-may-2004.doc)

is available on the main page and in the = “CAPWAP Taxonomy Work” page.

 

Some CAPWAP WG participants (who are also active in = IEEE) may have already noted this in the IEEE website = (http://www.802wirelessworld.com).

 

We thank IEEE 802.11 WG chair for facilitating the = AdHoc committee review and Dorothy Stanley and her AdHoc committee for = the

diligent critical review and thorough = comments.

 

[Should there be difficulty reading the word document = do let me know].

 

Regards,

-mani

Mahalingam Mani

408.321.4840 (work)

 

------_=_NextPart_001_01C43DF4.117659E0-- _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Wed May 19 19:01:51 2004 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27041 for ; Wed, 19 May 2004 19:01:48 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A5F2E20540; Wed, 19 May 2004 18:49:08 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 9DC0E2058D; Wed, 19 May 2004 18:49:04 -0400 (EDT) Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 8960320946 for ; Wed, 19 May 2004 18:22:54 -0400 (EDT) Received: from tiere.net.avaya.com (tiere.net.avaya.com [198.152.12.100]) by mail.frascone.com (Postfix) with ESMTP id 178AB20215 for ; Wed, 19 May 2004 18:22:52 -0400 (EDT) Received: from tiere.net.avaya.com (localhost [127.0.0.1]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id i4JMYHam013558 for ; Wed, 19 May 2004 18:34:17 -0400 (EDT) Received: from cof110avexu1.global.avaya.com (h135-9-6-16.avaya.com [135.9.6.16]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id i4JMYEam013488 for ; Wed, 19 May 2004 18:34:15 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C43DF1.9632A772" Message-ID: X-MS-Has-Attach: yes Thread-Topic: Expert Review - from Bernard Aboba. Thread-Index: AcQ98ZGGEDGeAY+BT4mMpzrGwUSKvA== From: "Mani, Mahalingam (Mahalingam)" To: X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [Capwap] Expert Review - from Bernard Aboba. Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Wed, 19 May 2004 16:35:28 -0600 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) This is a multi-part message in MIME format. ------_=_NextPart_001_01C43DF1.9632A772 Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01C43DF1.9632A772" ------_=_NextPart_002_01C43DF1.9632A772 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Attached is the review comment from Bernard's comments. Feel free to review them in the context of the -02 draft of architecture taxonomy. =20 Regards, -mani Mahalingam Mani =20 =20 ------_=_NextPart_002_01C43DF1.9632A772 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

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

 

 

------_=_NextPart_002_01C43DF1.9632A772-- ------_=_NextPart_001_01C43DF1.9632A772 Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Received: from cof110avexp1.global.avaya.com ([135.9.6.15]) by cof110avexu1.global.avaya.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 11 May 2004 17:58:02 -0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_003_01C437B3.CB6FEC40" Received: from rhw.post.avaya.com ([198.152.7.29]) by cof110avexp1.global.avaya.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 11 May 2004 17:58:01 -0600 Received: from tierw.net.avaya.com by rhw.post.avaya.com (8.9.3+Sun/EMS-1.5a Solaris/Relay/POST) id TAA11446; Tue, 11 May 2004 19:59:18 -0400 (EDT) Received: from tierw.net.avaya.com (localhost [127.0.0.1]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id i4BNqqrw006889 for ; Tue, 11 May 2004 18:52:52 -0500 (EST) Received: from internaut.com (h-66-167-171-107.sttnwaho.covad.net [66.167.171.107]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id i4BNqmrw006834 for ; Tue, 11 May 2004 18:52:49 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i4C01hu05509; Tue, 11 May 2004 17:01:44 -0700 content-class: urn:content-classes:message Subject: Review of draft-ietf-capwap-arch-02.txt Date: Tue, 11 May 2004 18:01:43 -0600 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Review of draft-ietf-capwap-arch-02.txt Thread-Index: AcQ3s8ttdYm2lpt4SA2Avb9YxZmy9w== From: "Bernard Aboba" To: Cc: , "Mani, Mahalingam (Mahalingam)" This is a multi-part message in MIME format. ------_=_NextPart_003_01C437B3.CB6FEC40 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Review of draft-ietf-capwap-arch-02.txt May 11, 2004 Bernard Aboba 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" =3D> 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 !=3D 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... ------_=_NextPart_003_01C437B3.CB6FEC40 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Review of draft-ietf-capwap-arch-02.txt

Review of draft-ietf-capwap-arch-02.txt
May 11, 2004
Bernard Aboba <aboba@internaut.com>

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" =3D> = 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 !=3D 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...

------_=_NextPart_003_01C437B3.CB6FEC40-- ------_=_NextPart_001_01C43DF1.9632A772-- _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap