From capwap-admin@frascone.com Sat Oct 01 14:32:31 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ELm9t-0007Ag-7n for capwap-archive@megatron.ietf.org; Sat, 01 Oct 2005 14:32:31 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13136 for ; Sat, 1 Oct 2005 14:32:24 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D6028205F5; Sat, 1 Oct 2005 14:32:25 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 8FFF2205D4; Sat, 1 Oct 2005 14:32:08 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id C54752057A for ; Sat, 1 Oct 2005 14:26:26 -0400 (EDT) Received: from tiere.net.avaya.com (tiere.net.avaya.com [198.152.12.100]) by mail.frascone.com (Postfix) with ESMTP id 9065020593 for ; Sat, 1 Oct 2005 14:26:09 -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 j8THqWGO021574 for ; Thu, 29 Sep 2005 13:52:32 -0400 (EDT) Received: from nj7460avexu2.global.avaya.com (h198-152-6-52.avaya.com [198.152.6.52]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id j8THq7GO021046 for ; Thu, 29 Sep 2005 13:52:12 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Capwap] CAPWAP evaluation draft complete Message-ID: <5844A41F4E146044A2E8356C6328588009AD0214@nj7460avexu2.global.avaya.com> Thread-Topic: [Capwap] CAPWAP evaluation draft complete Thread-Index: AcW/FcI2CZhyH4KQRBqFRs87raP/XgGBW4FQ From: "Sadot, Emek (Emek)" To: , Cc: "Mani, Mahalingam (Mahalingam)" , , X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) 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-Unsubscribe: , List-Id: A list for CAPWAP technical discussions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 29 Sep 2005 13:54:25 -0400 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Thanks, Darren and company, for the thorough evaluation work. I have a few observation I'd like to pass along: 1. section 6.1. talks about setting logical groups, and SSID in particular. I believe the message should be extended to include VLAN (per Saravanan note in a different email chain), that's for the case where DS is implemented at the WTP. s 2. section 6.2. discuss the use of "C-bit" as a mean to distinguish data vs. controller messages. Although the "C-bit" satisfies the requirement, I think that 1 bit is too restrictive and allows no scalability (e.g. segregate control vs. management, or future wireless technology, if needed). It might be advisable to follow the recommendation sprit you made in section 9.1.1 to extend the IE. 3. section 6.14. approves NAT traversal objective, however I would challenge LWAPP in this case as it carries the IP address in the payload. Although NAT devices can be statically configured, I would vote against taking such approach, and a prove would be the need for an ALGs for each protocol that carries IP address in body message. I would think that adding a recommendation to avoid embedded IP address in control messages would be advisable. In addition it would improve the protocol "readiness" for IPv6. Regards, Emek -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Dorothy.Gellert@nokia.com Sent: Wednesday, September 21, 2005 9:34 PM To: capwap@frascone.com Cc: Mani, Mahalingam (Mahalingam); bwijnen@lucent.com; david.kessens@nokia.com; Dorothy.Gellert@nokia.com Subject: [Capwap] CAPWAP evaluation draft complete After much hard work, the evaluation team has completed the CAPWAP evaluation draft. Its is available for review at: http://www.ietf.org/internet-drafts/draft-ietf-capwap-eval-00.txt and also in the internet drafts directory. The evaluation team concluded that LWAPP is the most complete proposal and should be used as the basis for CAPWAP protocol moving forward. In addition, a number of recommendations were made which the evaluation team believed should be addressed by the working group. Over the next 2 weeks the evaluation team will address clarification questions on the WG list. The recommendation provided by the evaluation team will not change, as this was intended to be an independent activity supported by the WG. This is essentially a WGLC on the evaluation draft. Please submit any clarification question to the list by Friday, September 30th. The next step will be to come to an agreement on the WG list to decide to accept the recommended protocol. Once we have established consensus, we can further discuss the additional recommendations presented in the draft. We would like to thank the evaluation team on its thorough work and a job well done. Regards, Dorothy and Mani _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Sat Oct 01 14:40:27 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ELmHb-0002Lj-8M for capwap-archive@megatron.ietf.org; Sat, 01 Oct 2005 14:40:27 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13430 for ; Sat, 1 Oct 2005 14:40:22 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 685FA20649; Sat, 1 Oct 2005 14:40:24 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 9C6E32061D; Sat, 1 Oct 2005 14:40:05 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 89C282062B for ; Sat, 1 Oct 2005 14:37:19 -0400 (EDT) Received: from tiere.net.avaya.com (tiere.net.avaya.com [198.152.12.100]) by mail.frascone.com (Postfix) with ESMTP id E17A4205DD for ; Sat, 1 Oct 2005 14:36:57 -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 j8TKquGO007026 for ; Thu, 29 Sep 2005 16:52:56 -0400 (EDT) Received: from nj7460avexu2.global.avaya.com (h198-152-6-52.avaya.com [198.152.6.52]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id j8TKqgGO006642 for ; Thu, 29 Sep 2005 16:52:46 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5C538.1D2B6330" Subject: RE: [Capwap] Change Request 9.2.2. Removal of Layer 2 Encapsulation for Data Tunneling Message-ID: <5844A41F4E146044A2E8356C6328588009B2CE00@nj7460avexu2.global.avaya.com> Thread-Topic: [Capwap] Change Request 9.2.2. Removal of Layer 2 Encapsulation for Data Tunneling Thread-Index: AcXEd4S35/Mx/NmhSKCaNSz7Be84bQAwF2lQ From: "Sadot, Emek (Emek)" To: X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) 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-Unsubscribe: , List-Id: A list for CAPWAP technical discussions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 29 Sep 2005 16:55:24 -0400 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) This is a multi-part message in MIME format. ------_=_NextPart_001_01C5C538.1D2B6330 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Works for me. Emek _____ =20 From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of James Kempf Sent: Wednesday, September 28, 2005 5:55 PM To: Pat Calhoun (pacalhou); capwap@frascone.com Subject: Re: [Capwap] Change Request 9.2.2. Removal of Layer 2 Encapsulation for Data Tunneling Actually, I've been in favor of this for quite some time. So I agree. =20 jak ----- Original Message -----=20 From: Pat Calhoun (pacalhou) =20 To: capwap@frascone.com=20 Sent: Wednesday, September 28, 2005 2:32 PM Subject: [Capwap] Change Request 9.2.2. Removal of Layer 2 Encapsulation for Data Tunneling I am ok with making the change to only allow LWAPP to operate over IP, but would like to get WG rough consensus on this topic before I make the necessary changes (which is really more of a cut than paste exercise). =20 Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 ------_=_NextPart_001_01C5C538.1D2B6330 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Works=20 for me.
Emek

From: capwap-admin@frascone.com=20 [mailto:capwap-admin@frascone.com] On Behalf Of James=20 Kempf
Sent: Wednesday, September 28, 2005 5:55 = PM
To: Pat=20 Calhoun (pacalhou); capwap@frascone.com
Subject: Re: [Capwap] = Change=20 Request 9.2.2. Removal of Layer 2 Encapsulation for Data=20 Tunneling

Actually, I've been in favor of this for quite some = time. So I=20 agree.
 
        =    =20 jak
----- Original Message -----
From:=20 Pat = Calhoun=20 (pacalhou)
Sent: Wednesday, September 28, = 2005 2:32=20 PM
Subject: [Capwap] Change = Request 9.2.2.=20 Removal of Layer 2 Encapsulation for Data Tunneling

I am = ok with=20 making the change to only allow LWAPP to operate over IP, but would = like to=20 get WG rough consensus on this topic before I make the necessary = changes=20 (which is really more of a cut than paste = exercise).
 

Pat Calhoun
CTO, Wireless Networking = Business=20 Unit
Cisco Systems

 
------_=_NextPart_001_01C5C538.1D2B6330-- _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Sat Oct 01 14:58:42 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ELmZG-0003nh-2b for capwap-archive@megatron.ietf.org; Sat, 01 Oct 2005 14:58:42 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13877 for ; Sat, 1 Oct 2005 14:58:33 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B6C1E206A7; Sat, 1 Oct 2005 14:58:34 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 6DAD42052E; Sat, 1 Oct 2005 14:58:08 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id AFE60206A7 for ; Sat, 1 Oct 2005 14:57:55 -0400 (EDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by mail.frascone.com (Postfix) with ESMTP id 38F9E203FA for ; Sat, 1 Oct 2005 14:57:49 -0400 (EDT) Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-5.cisco.com with ESMTP; 29 Sep 2005 15:00:40 -0700 X-IronPort-AV: i="3.97,158,1125903600"; d="scan'208,217"; a="215901965:sNHT47234472" Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j8TM0YW3009420; Thu, 29 Sep 2005 15:00:41 -0700 (PDT) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 29 Sep 2005 15:00:41 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5C541.3B42939A" Subject: RE: [Capwap] Change Request 9.1.3.1. Support for Local MAC User Data Tunneling Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2B8BC87@xmb-sjc-235.amer.cisco.com> Thread-Topic: [Capwap] Change Request 9.1.3.1. Support for Local MAC User Data Tunneling Thread-Index: AcXEZkqBuwf+LMdnQ8KyHVKiUjMwyAA02ebAAAHWmtA= From: "Pat Calhoun (pacalhou)" To: "Sadot, Emek (Emek)" , X-OriginalArrivalTime: 29 Sep 2005 22:00:41.0061 (UTC) FILETIME=[3B6F1950:01C5C541] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) 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-Unsubscribe: , List-Id: A list for CAPWAP technical discussions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 29 Sep 2005 15:00:39 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) This is a multi-part message in MIME format. ------_=_NextPart_001_01C5C541.3B42939A Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable In terms of option 2, no traffic is sent to the AC, so the model is quite different. =20 Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 ________________________________ From: Sadot, Emek (Emek) [mailto:esadot@avaya.com]=20 Sent: Thursday, September 29, 2005 2:16 PM To: Pat Calhoun (pacalhou); capwap@frascone.com Subject: RE: [Capwap] Change Request 9.1.3.1. Support for Local MAC User Data Tunneling =09 =09 Pat, you certainly raise valid questions w.r.t. option #3, however I am curious as to the differences between the challenges you listed between options #2 and #3. In other words, in what sense option #2 and #3 are differ w.r.t. encryption and 11e at the AC, as well as RSSI/SNR/data-rate/other monitoring support? =20 Regards, Emek =20 ________________________________ From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Pat Calhoun (pacalhou) Sent: Wednesday, September 28, 2005 5:32 PM To: capwap@frascone.com Subject: [Capwap] Change Request 9.1.3.1. Support for Local MAC User Data Tunneling =09 =09 This change request is to allow for 802.3 tunneling of user data in local bridging mode. I believe that the changes should be relatively straightforward, but do introduce an interesting set of complications that need to be evaluated and agreed upon as a group. =20 The LWAPP protocol currently allows for 802.11 tunneling in Split-MAC mode, allowing for such things as centralized encryption of user data frames. However, the current definition of the protocol is that when running in Local-MAC mode, no traffic is tunneled to the controller. =20 If we were to introduce this change, the LWAPP protocol would have three modes of operation: 1. Split-MAC: Tunnel native MAC frames in UDP (e.g., 802.11) 2. Local-MAC w/ Local Bridge: Do not tunnel 802.3 frames 3. Local-MAC w/ Tunnel: Tunnel 802.3 frames in UDP =20 The issue that we need to decide as a group is whether we really want a protocol that has three modes of operation, and if so, which one is mandatory. The evaluation draft states that option 3 is useful for support of non 802.11 technologies, but this introduces a set of restrictions. For instance, today the LWAPP protocol allows for centralized control of various 802.11 functions, including encryption and 802.11e. This function is not possible with option 3, and therefore any new technology that assumes this option would not be able to provide centralization of data frame functions. =20 There is a comment in the recommendation that LWAPP could retain the RSSI/SNR fields, and then perform 802.3 encapsulation, allowing the AC to have more visibility. However, I have had some requests to expand these fields to also include the data rate. Further, there are possible fields in the header (of technologies we know nothing about) that the WTP may want to extract and expose to the AC - and how could this be done with 802.3? Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 ------_=_NextPart_001_01C5C541.3B42939A Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
In terms of option 2, no traffic is sent to the = AC, so the=20 model is quite different.
 

Pat Calhoun
CTO, Wireless Networking = Business=20 Unit
Cisco Systems

 

From: Sadot, Emek (Emek)=20 [mailto:esadot@avaya.com]
Sent: Thursday, September 29, = 2005 2:16=20 PM
To: Pat Calhoun (pacalhou);=20 capwap@frascone.com
Subject: RE: [Capwap] Change Request = 9.1.3.1.=20 Support for Local MAC User Data Tunneling

Pat,=20 you certainly raise valid questions w.r.t. option #3, however I am = curious as=20 to the differences between the challenges you listed = between options=20 #2 and #3. In other words, in what sense option #2 and #3 are = differ=20 w.r.t. encryption and 11e at the AC, as well as = RSSI/SNR/data-rate/other=20 monitoring support?
 
Regards,
Emek
 
From: = capwap-admin@frascone.com=20 [mailto:capwap-admin@frascone.com] On Behalf Of Pat Calhoun=20 (pacalhou)
Sent: Wednesday, September 28, 2005 5:32 = PM
To:=20 capwap@frascone.com
Subject: [Capwap] Change Request = 9.1.3.1.=20 Support for Local MAC User Data Tunneling

This = change=20 request is to allow for 802.3 tunneling of user data in local bridging = mode. I=20 believe that the changes should be relatively straightforward, but do=20 introduce an interesting set of complications that need to be = evaluated and=20 agreed upon as a group.
 
The = LWAPP protocol=20 currently allows for 802.11 tunneling in Split-MAC mode, allowing for = such=20 things as centralized encryption of user data frames. However, the = current=20 definition of the protocol is that when running in Local-MAC mode, no = traffic=20 is tunneled to the controller.
 
If = we were to=20 introduce this change, the LWAPP protocol would have three modes of=20 operation:
1. = Split-MAC:=20 Tunnel native MAC frames in UDP (e.g., = 802.11)
2. = Local-MAC w/=20 Local Bridge: Do not tunnel 802.3 frames
3. = Local-MAC w/=20 Tunnel: Tunnel 802.3 frames in UDP
 
The = issue that we=20 need to decide as a group is whether we really want a protocol that = has three=20 modes of operation, and if so, which one is mandatory. The evaluation = draft=20 states that option 3 is useful for support of non 802.11 technologies, = but=20 this introduces a set of restrictions. For instance, today the LWAPP = protocol=20 allows for centralized control of various 802.11 functions, including=20 encryption and 802.11e. This function is not possible with option = 3, and=20 therefore any new technology that assumes this option would not be = able to=20 provide centralization of data frame functions.
 
There is a comment=20 in the recommendation that LWAPP could retain the RSSI/SNR fields, and = then=20 perform 802.3 encapsulation, allowing the AC to have more visibility. = However,=20 I have had some requests to expand these fields to also include the = data rate.=20 Further, there are possible fields in the header (of technologies we = know=20 nothing about) that the WTP may want to extract and expose to the AC - = and how=20 could this be done with 802.3?

Pat Calhoun
CTO, Wireless Networking = Business=20 Unit
Cisco Systems

 
------_=_NextPart_001_01C5C541.3B42939A-- _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Sat Oct 01 15:20:23 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ELmuF-0005zf-3H for capwap-archive@megatron.ietf.org; Sat, 01 Oct 2005 15:20:23 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15642 for ; Sat, 1 Oct 2005 15:20:15 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 3DFA4206CE; Sat, 1 Oct 2005 15:20:18 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 2E2B4206C2; Sat, 1 Oct 2005 15:20:05 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 5951520644 for ; Sat, 1 Oct 2005 15:19:25 -0400 (EDT) Received: from tiere.net.avaya.com (tiere.net.avaya.com [198.152.12.100]) by mail.frascone.com (Postfix) with ESMTP id A197C205FF for ; Sat, 1 Oct 2005 15:19:23 -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 j8UGtnGO025196 for ; Fri, 30 Sep 2005 12:55:49 -0400 (EDT) Received: from nj7460avexu2.global.avaya.com (h198-152-6-52.avaya.com [198.152.6.52]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id j8UGtmGO025146 for ; Fri, 30 Sep 2005 12:55:48 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Capwap] CAPWAP evaluation draft complete Message-ID: <5844A41F4E146044A2E8356C6328588009B2D26D@nj7460avexu2.global.avaya.com> Thread-Topic: [Capwap] CAPWAP evaluation draft complete Thread-Index: AcW/FcI2CZhyH4KQRBqFRs87raP/XgGBW4FQ From: "Sadot, Emek (Emek)" To: X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) 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-Unsubscribe: , List-Id: A list for CAPWAP technical discussions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 30 Sep 2005 12:58:32 -0400 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Thanks, Darren and company, for the thorough evaluation work. I have a few observation I'd like to pass along: 1. section 6.1. talks about setting logical groups, and SSID in particular. I believe the message should be extended to include VLAN (per Saravanan note in a different email chain), that's for the case where DS is implemented at the WTP. s 2. section 6.2. discuss the use of "C-bit" as a mean to distinguish data vs. controller messages. Although the "C-bit" satisfies the requirement, I think that 1 bit is too restrictive and allows no scalability (e.g. segregate control vs. management, or future wireless technology, if needed). It might be advisable to follow the recommendation sprit you made in section 9.1.1 to extend the IE. 3. section 6.14. approves NAT traversal objective, however I would challenge LWAPP in this case as it carries the IP address in the payload. Although NAT devices can be statically configured, I would vote against taking such approach, and a prove would be the need for an ALGs for each protocol that carries IP address in body message. I would think that adding a recommendation to avoid embedded IP address in control messages would be advisable. In addition it would improve the protocol "readiness" for IPv6. Regards, Emek -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Dorothy.Gellert@nokia.com Sent: Wednesday, September 21, 2005 9:34 PM To: capwap@frascone.com Cc: Mani, Mahalingam (Mahalingam); bwijnen@lucent.com; david.kessens@nokia.com; Dorothy.Gellert@nokia.com Subject: [Capwap] CAPWAP evaluation draft complete After much hard work, the evaluation team has completed the CAPWAP evaluation draft. Its is available for review at: http://www.ietf.org/internet-drafts/draft-ietf-capwap-eval-00.txt and also in the internet drafts directory. The evaluation team concluded that LWAPP is the most complete proposal and should be used as the basis for CAPWAP protocol moving forward. In addition, a number of recommendations were made which the evaluation team believed should be addressed by the working group. Over the next 2 weeks the evaluation team will address clarification questions on the WG list. The recommendation provided by the evaluation team will not change, as this was intended to be an independent activity supported by the WG. This is essentially a WGLC on the evaluation draft. Please submit any clarification question to the list by Friday, September 30th. The next step will be to come to an agreement on the WG list to decide to accept the recommended protocol. Once we have established consensus, we can further discuss the additional recommendations presented in the draft. We would like to thank the evaluation team on its thorough work and a job well done. Regards, Dorothy and Mani _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Sat Oct 01 15:43:30 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ELnGc-00008m-0U for capwap-archive@megatron.ietf.org; Sat, 01 Oct 2005 15:43:30 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16466 for ; Sat, 1 Oct 2005 15:43:23 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id CD46C206E3; Sat, 1 Oct 2005 15:43:20 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id AC60E206D8; Sat, 1 Oct 2005 15:43:05 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 3F4681FCAC for ; Sat, 1 Oct 2005 15:42:14 -0400 (EDT) Received: from tiere.net.avaya.com (tiere.net.avaya.com [198.152.12.100]) by mail.frascone.com (Postfix) with ESMTP id CCA081FC94 for ; Sat, 1 Oct 2005 15:42:11 -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 j8UHDeGO022824 for ; Fri, 30 Sep 2005 13:13:40 -0400 (EDT) Received: from nj7460avexu2.global.avaya.com (h198-152-6-52.avaya.com [198.152.6.52]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id j8UHDTGO022579 for ; Fri, 30 Sep 2005 13:13:31 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5C5E2.A6E27485" Subject: RE: [Capwap] Change Request 9.1.3.1. Support for Local MAC User Data Tunneling Message-ID: <5844A41F4E146044A2E8356C6328588009B2D28E@nj7460avexu2.global.avaya.com> Thread-Topic: [Capwap] Change Request 9.1.3.1. Support for Local MAC User Data Tunneling Thread-Index: AcXEZkqBuwf+LMdnQ8KyHVKiUjMwyAA02ebAAAHWmtAAJ8HLcA== From: "Sadot, Emek (Emek)" To: "Pat Calhoun (pacalhou)" , X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) 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-Unsubscribe: , List-Id: A list for CAPWAP technical discussions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 30 Sep 2005 13:16:10 -0400 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) This is a multi-part message in MIME format. ------_=_NextPart_001_01C5C5E2.A6E27485 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Regarding the points you raised I believe option #2 and #3 share the same qualities. In both options 802.11 encryption and 11e cannot be implemented at the AC. In both options a mechanism shall be design to extract RF and data-traffic statistics either (a) appended in the tunneling (option #3 only) or (b) exposed by the WTP as read-only values for the AC inquiries (both options). =20 Am I missing something? =20 On the other hand one can respect the unique merits that these options offer: - option 2: non-appliance product. meaning a software based AC that can be executed on any server / platform. - option 3: avoid parse 802.11 traffic in silicon at the AC. Leverage existing products (e.g. routers) with "only" add-on 802.11 code running at the Cpu. =20 Emek _____ =20 From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com]=20 Sent: Thursday, September 29, 2005 6:01 PM To: Sadot, Emek (Emek); capwap@frascone.com Subject: RE: [Capwap] Change Request 9.1.3.1. Support for Local MAC User Data Tunneling In terms of option 2, no traffic is sent to the AC, so the model is quite different. =20 Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 _____ =20 From: Sadot, Emek (Emek) [mailto:esadot@avaya.com]=20 Sent: Thursday, September 29, 2005 2:16 PM To: Pat Calhoun (pacalhou); capwap@frascone.com Subject: RE: [Capwap] Change Request 9.1.3.1. Support for Local MAC User Data Tunneling =09 =09 Pat, you certainly raise valid questions w.r.t. option #3, however I am curious as to the differences between the challenges you listed between options #2 and #3. In other words, in what sense option #2 and #3 are differ w.r.t. encryption and 11e at the AC, as well as RSSI/SNR/data-rate/other monitoring support? =20 Regards, Emek =20 _____ =20 From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Pat Calhoun (pacalhou) Sent: Wednesday, September 28, 2005 5:32 PM To: capwap@frascone.com Subject: [Capwap] Change Request 9.1.3.1. Support for Local MAC User Data Tunneling =09 =09 This change request is to allow for 802.3 tunneling of user data in local bridging mode. I believe that the changes should be relatively straightforward, but do introduce an interesting set of complications that need to be evaluated and agreed upon as a group. =20 The LWAPP protocol currently allows for 802.11 tunneling in Split-MAC mode, allowing for such things as centralized encryption of user data frames. However, the current definition of the protocol is that when running in Local-MAC mode, no traffic is tunneled to the controller. =20 If we were to introduce this change, the LWAPP protocol would have three modes of operation: 1. Split-MAC: Tunnel native MAC frames in UDP (e.g., 802.11) 2. Local-MAC w/ Local Bridge: Do not tunnel 802.3 frames 3. Local-MAC w/ Tunnel: Tunnel 802.3 frames in UDP =20 The issue that we need to decide as a group is whether we really want a protocol that has three modes of operation, and if so, which one is mandatory. The evaluation draft states that option 3 is useful for support of non 802.11 technologies, but this introduces a set of restrictions. For instance, today the LWAPP protocol allows for centralized control of various 802.11 functions, including encryption and 802.11e. This function is not possible with option 3, and therefore any new technology that assumes this option would not be able to provide centralization of data frame functions. =20 There is a comment in the recommendation that LWAPP could retain the RSSI/SNR fields, and then perform 802.3 encapsulation, allowing the AC to have more visibility. However, I have had some requests to expand these fields to also include the data rate. Further, there are possible fields in the header (of technologies we know nothing about) that the WTP may want to extract and expose to the AC - and how could this be done with 802.3? Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 ------_=_NextPart_001_01C5C5E2.A6E27485 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Regarding the points you raised I believe option #2 and #3 = share the same=20 qualities.
In=20 both options 802.11 encryption and 11e cannot be implemented at the = AC.
In=20 both options a mechanism shall be design to extract RF and = data-traffic=20 statistics either (a) appended in the tunneling (option #3 only) or = (b) exposed by the WTP as read-only values for the AC = inquiries=20 (both options).
 
Am I=20 missing something?
 
On the=20 other hand one can respect the unique merits that these=20 options offer:
-=20 option 2: non-appliance product. meaning a software based AC that can be = executed on any server / platform.
-=20 option 3: avoid parse 802.11 traffic in silicon at the AC. Leverage = existing=20 products (e.g. routers) with "only" add-on 802.11 code running at the=20 Cpu.
 
Emek

From: Pat Calhoun (pacalhou)=20 [mailto:pcalhoun@cisco.com]
Sent: Thursday, September 29, = 2005 6:01=20 PM
To: Sadot, Emek (Emek); = capwap@frascone.com
Subject: RE:=20 [Capwap] Change Request 9.1.3.1. Support for Local MAC User Data=20 Tunneling

In terms of option 2, no traffic is sent to the = AC, so the=20 model is quite different.
 

Pat Calhoun
CTO, Wireless Networking = Business=20 Unit
Cisco Systems

 

From: Sadot, Emek (Emek)=20 [mailto:esadot@avaya.com]
Sent: Thursday, September 29, = 2005 2:16=20 PM
To: Pat Calhoun (pacalhou);=20 capwap@frascone.com
Subject: RE: [Capwap] Change Request = 9.1.3.1.=20 Support for Local MAC User Data Tunneling

Pat,=20 you certainly raise valid questions w.r.t. option #3, however I am = curious as=20 to the differences between the challenges you listed = between options=20 #2 and #3. In other words, in what sense option #2 and #3 are = differ=20 w.r.t. encryption and 11e at the AC, as well as = RSSI/SNR/data-rate/other=20 monitoring support?
 
Regards,
Emek
 
From: = capwap-admin@frascone.com=20 [mailto:capwap-admin@frascone.com] On Behalf Of Pat Calhoun=20 (pacalhou)
Sent: Wednesday, September 28, 2005 5:32 = PM
To:=20 capwap@frascone.com
Subject: [Capwap] Change Request = 9.1.3.1.=20 Support for Local MAC User Data Tunneling

This = change=20 request is to allow for 802.3 tunneling of user data in local bridging = mode. I=20 believe that the changes should be relatively straightforward, but do=20 introduce an interesting set of complications that need to be = evaluated and=20 agreed upon as a group.
 
The = LWAPP protocol=20 currently allows for 802.11 tunneling in Split-MAC mode, allowing for = such=20 things as centralized encryption of user data frames. However, the = current=20 definition of the protocol is that when running in Local-MAC mode, no = traffic=20 is tunneled to the controller.
 
If = we were to=20 introduce this change, the LWAPP protocol would have three modes of=20 operation:
1. = Split-MAC:=20 Tunnel native MAC frames in UDP (e.g., = 802.11)
2. = Local-MAC w/=20 Local Bridge: Do not tunnel 802.3 frames
3. = Local-MAC w/=20 Tunnel: Tunnel 802.3 frames in UDP
 
The = issue that we=20 need to decide as a group is whether we really want a protocol that = has three=20 modes of operation, and if so, which one is mandatory. The evaluation = draft=20 states that option 3 is useful for support of non 802.11 technologies, = but=20 this introduces a set of restrictions. For instance, today the LWAPP = protocol=20 allows for centralized control of various 802.11 functions, including=20 encryption and 802.11e. This function is not possible with option = 3, and=20 therefore any new technology that assumes this option would not be = able to=20 provide centralization of data frame functions.
 
There is a comment=20 in the recommendation that LWAPP could retain the RSSI/SNR fields, and = then=20 perform 802.3 encapsulation, allowing the AC to have more visibility. = However,=20 I have had some requests to expand these fields to also include the = data rate.=20 Further, there are possible fields in the header (of technologies we = know=20 nothing about) that the WTP may want to extract and expose to the AC - = and how=20 could this be done with 802.3?

Pat Calhoun
CTO, Wireless Networking = Business=20 Unit
Cisco Systems

 
------_=_NextPart_001_01C5C5E2.A6E27485-- _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Sat Oct 01 16:26:32 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ELnwG-0003XU-DD for capwap-archive@megatron.ietf.org; Sat, 01 Oct 2005 16:26:32 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17811 for ; Sat, 1 Oct 2005 16:26:25 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id EADEB206F7; Sat, 1 Oct 2005 16:26:16 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 932DD206EE; Sat, 1 Oct 2005 16:26:03 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 4A329206ED for ; Sat, 1 Oct 2005 16:25:45 -0400 (EDT) Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by mail.frascone.com (Postfix) with ESMTP id 840E920404 for ; Sat, 1 Oct 2005 16:25:42 -0400 (EDT) Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-3.cisco.com with ESMTP; 01 Oct 2005 13:25:41 -0700 X-IronPort-AV: i="3.97,164,1125903600"; d="scan'208,217"; a="347430314:sNHT43728540" Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j91KPa4u024016; Sat, 1 Oct 2005 13:25:37 -0700 (PDT) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sat, 1 Oct 2005 13:25:39 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5C6C6.496D68C4" Subject: RE: [Capwap] Change Request 9.1.3.1. Support for Local MAC User Data Tunneling Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2BEED4D@xmb-sjc-235.amer.cisco.com> Thread-Topic: [Capwap] Change Request 9.1.3.1. Support for Local MAC User Data Tunneling Thread-Index: AcXEZkqBuwf+LMdnQ8KyHVKiUjMwyAA02ebAAAHWmtAAJ8HLcAAM1Msw From: "Pat Calhoun (pacalhou)" To: "Sadot, Emek (Emek)" , X-OriginalArrivalTime: 01 Oct 2005 20:25:39.0095 (UTC) FILETIME=[499FA270:01C5C6C6] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) 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-Unsubscribe: , List-Id: A list for CAPWAP technical discussions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sat, 1 Oct 2005 13:25:38 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) This is a multi-part message in MIME format. ------_=_NextPart_001_01C5C6C6.496D68C4 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Emek, =20 In option 3, when a user associates with the WTP, the association is handled locally, but the packet is tunneled to the AC in order for the AC to have access to usage information (and make overriding policy decisions). So 802.11 needs to be supported on the AC regardless, right? =20 Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 ________________________________ From: Sadot, Emek (Emek) [mailto:esadot@avaya.com]=20 Sent: Friday, September 30, 2005 10:16 AM To: Pat Calhoun (pacalhou); capwap@frascone.com Subject: RE: [Capwap] Change Request 9.1.3.1. Support for Local MAC User Data Tunneling =09 =09 Regarding the points you raised I believe option #2 and #3 share the same qualities. In both options 802.11 encryption and 11e cannot be implemented at the AC. In both options a mechanism shall be design to extract RF and data-traffic statistics either (a) appended in the tunneling (option #3 only) or (b) exposed by the WTP as read-only values for the AC inquiries (both options). =20 Am I missing something? =20 On the other hand one can respect the unique merits that these options offer: - option 2: non-appliance product. meaning a software based AC that can be executed on any server / platform. - option 3: avoid parse 802.11 traffic in silicon at the AC. Leverage existing products (e.g. routers) with "only" add-on 802.11 code running at the Cpu. =20 Emek ________________________________ From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com]=20 Sent: Thursday, September 29, 2005 6:01 PM To: Sadot, Emek (Emek); capwap@frascone.com Subject: RE: [Capwap] Change Request 9.1.3.1. Support for Local MAC User Data Tunneling =09 =09 In terms of option 2, no traffic is sent to the AC, so the model is quite different. =20 Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 ________________________________ From: Sadot, Emek (Emek) [mailto:esadot@avaya.com]=20 Sent: Thursday, September 29, 2005 2:16 PM To: Pat Calhoun (pacalhou); capwap@frascone.com Subject: RE: [Capwap] Change Request 9.1.3.1. Support for Local MAC User Data Tunneling =09 =09 Pat, you certainly raise valid questions w.r.t. option #3, however I am curious as to the differences between the challenges you listed between options #2 and #3. In other words, in what sense option #2 and #3 are differ w.r.t. encryption and 11e at the AC, as well as RSSI/SNR/data-rate/other monitoring support? =20 Regards, Emek =20 ________________________________ From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Pat Calhoun (pacalhou) Sent: Wednesday, September 28, 2005 5:32 PM To: capwap@frascone.com Subject: [Capwap] Change Request 9.1.3.1. Support for Local MAC User Data Tunneling =09 =09 This change request is to allow for 802.3 tunneling of user data in local bridging mode. I believe that the changes should be relatively straightforward, but do introduce an interesting set of complications that need to be evaluated and agreed upon as a group. =20 The LWAPP protocol currently allows for 802.11 tunneling in Split-MAC mode, allowing for such things as centralized encryption of user data frames. However, the current definition of the protocol is that when running in Local-MAC mode, no traffic is tunneled to the controller. =20 If we were to introduce this change, the LWAPP protocol would have three modes of operation: 1. Split-MAC: Tunnel native MAC frames in UDP (e.g., 802.11) 2. Local-MAC w/ Local Bridge: Do not tunnel 802.3 frames 3. Local-MAC w/ Tunnel: Tunnel 802.3 frames in UDP =20 The issue that we need to decide as a group is whether we really want a protocol that has three modes of operation, and if so, which one is mandatory. The evaluation draft states that option 3 is useful for support of non 802.11 technologies, but this introduces a set of restrictions. For instance, today the LWAPP protocol allows for centralized control of various 802.11 functions, including encryption and 802.11e. This function is not possible with option 3, and therefore any new technology that assumes this option would not be able to provide centralization of data frame functions. =20 There is a comment in the recommendation that LWAPP could retain the RSSI/SNR fields, and then perform 802.3 encapsulation, allowing the AC to have more visibility. However, I have had some requests to expand these fields to also include the data rate. Further, there are possible fields in the header (of technologies we know nothing about) that the WTP may want to extract and expose to the AC - and how could this be done with 802.3? Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 ------_=_NextPart_001_01C5C6C6.496D68C4 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
Emek,
 
In option 3, when a user associates with the = WTP, the=20 association is handled locally, but the packet is tunneled to the AC in = order=20 for the AC to have access to usage information (and make overriding = policy=20 decisions). So 802.11 needs to be supported on the AC regardless,=20 right?
 

Pat Calhoun
CTO, Wireless Networking = Business=20 Unit
Cisco Systems

 

From: Sadot, Emek (Emek)=20 [mailto:esadot@avaya.com]
Sent: Friday, September 30, 2005 = 10:16=20 AM
To: Pat Calhoun (pacalhou);=20 capwap@frascone.com
Subject: RE: [Capwap] Change Request = 9.1.3.1.=20 Support for Local MAC User Data Tunneling

Regarding the points you raised I believe option #2 and #3 = share the=20 same qualities.
In=20 both options 802.11 encryption and 11e cannot be implemented at = the=20 AC.
In=20 both options a mechanism shall be design to extract RF and = data-traffic=20 statistics either (a) appended in the tunneling (option #3 only) = or=20 (b) exposed by the WTP as read-only values for the AC = inquiries=20 (both options).
 
Am I=20 missing something?
 
On=20 the other hand one can respect the unique merits that these=20 options offer:
-=20 option 2: non-appliance product. meaning a software based AC that can = be=20 executed on any server / platform.
-=20 option 3: avoid parse 802.11 traffic in silicon at the AC. Leverage = existing=20 products (e.g. routers) with "only" add-on 802.11 code running at the=20 Cpu.
 
Emek

From: Pat Calhoun (pacalhou)=20 [mailto:pcalhoun@cisco.com]
Sent: Thursday, September 29, = 2005 6:01=20 PM
To: Sadot, Emek (Emek); = capwap@frascone.com
Subject:=20 RE: [Capwap] Change Request 9.1.3.1. Support for Local MAC User Data=20 Tunneling

In terms of option 2, no traffic is sent to = the AC, so=20 the model is quite different.
 

Pat Calhoun
CTO, Wireless Networking = Business=20 Unit
Cisco Systems

 

From: Sadot, Emek (Emek)=20 [mailto:esadot@avaya.com]
Sent: Thursday, September 29, = 2005 2:16=20 PM
To: Pat Calhoun (pacalhou);=20 capwap@frascone.com
Subject: RE: [Capwap] Change Request = 9.1.3.1.=20 Support for Local MAC User Data Tunneling

Pat, you certainly raise valid questions w.r.t. option #3, = however I=20 am curious as to the differences between the challenges you = listed=20 between options #2 and #3. In other words, in what = sense option #2=20 and #3 are differ w.r.t. encryption and 11e at the AC, as well as=20 RSSI/SNR/data-rate/other monitoring support?
 
Regards,
Emek
 
From: = capwap-admin@frascone.com=20 [mailto:capwap-admin@frascone.com] On Behalf Of Pat Calhoun=20 (pacalhou)
Sent: Wednesday, September 28, 2005 5:32=20 PM
To: capwap@frascone.com
Subject: [Capwap] = Change=20 Request 9.1.3.1. Support for Local MAC User Data=20 Tunneling

This change=20 request is to allow for 802.3 tunneling of user data in local = bridging mode.=20 I believe that the changes should be relatively straightforward, but = do=20 introduce an interesting set of complications that need to be = evaluated and=20 agreed upon as a group.
 
The LWAPP=20 protocol currently allows for 802.11 tunneling in Split-MAC mode, = allowing=20 for such things as centralized encryption of user data frames. = However, the=20 current definition of the protocol is that when running in Local-MAC = mode,=20 no traffic is tunneled to the controller.
 
If = we were to=20 introduce this change, the LWAPP protocol would have three modes of=20 operation:
1. = Split-MAC:=20 Tunnel native MAC frames in UDP (e.g., = 802.11)
2. = Local-MAC w/=20 Local Bridge: Do not tunnel 802.3 frames
3. = Local-MAC w/=20 Tunnel: Tunnel 802.3 frames in UDP
 
The issue that=20 we need to decide as a group is whether we really want a protocol = that has=20 three modes of operation, and if so, which one is mandatory. The = evaluation=20 draft states that option 3 is useful for support of non 802.11 = technologies,=20 but this introduces a set of restrictions. For instance, today the = LWAPP=20 protocol allows for centralized control of various 802.11 functions, = including encryption and 802.11e. This function is not possible = with=20 option 3, and therefore any new technology that assumes this option = would=20 not be able to provide centralization of data frame=20 functions.
 
There is a=20 comment in the recommendation that LWAPP could retain the RSSI/SNR = fields,=20 and then perform 802.3 encapsulation, allowing the AC to have more=20 visibility. However, I have had some requests to expand these fields = to also=20 include the data rate. Further, there are possible fields in the = header (of=20 technologies we know nothing about) that the WTP may want to extract = and=20 expose to the AC - and how could this be done with=20 802.3?

Pat Calhoun
CTO, Wireless = Networking Business=20 Unit
Cisco Systems

 
------_=_NextPart_001_01C5C6C6.496D68C4-- _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Sat Oct 01 16:29:19 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ELnyx-0005Ok-Bv for capwap-archive@megatron.ietf.org; Sat, 01 Oct 2005 16:29:19 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17900 for ; Sat, 1 Oct 2005 16:29:15 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 39182206F8; Sat, 1 Oct 2005 16:29:16 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 528C1206EE; Sat, 1 Oct 2005 16:29:03 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B58E3206ED for ; Sat, 1 Oct 2005 16:28:55 -0400 (EDT) Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by mail.frascone.com (Postfix) with ESMTP id 4BEDD20404 for ; Sat, 1 Oct 2005 16:28:53 -0400 (EDT) Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-3.cisco.com with ESMTP; 01 Oct 2005 13:28:52 -0700 X-IronPort-AV: i="3.97,164,1125903600"; d="scan'208"; a="347430741:sNHT25846196" Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j91KScKI001150 for ; Sat, 1 Oct 2005 13:28:46 -0700 (PDT) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sat, 1 Oct 2005 13:28:49 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2BEED54@xmb-sjc-235.amer.cisco.com> Thread-Topic: Cisco IPR Statement Thread-Index: AcXGxro7rc+J+9V1RGGtvTMwgAmscw== From: "Pat Calhoun (pacalhou)" To: X-OriginalArrivalTime: 01 Oct 2005 20:28:49.0295 (UTC) FILETIME=[BAFDD9F0:01C5C6C6] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [Capwap] Cisco IPR Statement 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-Unsubscribe: , List-Id: A list for CAPWAP technical discussions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sat, 1 Oct 2005 13:28:48 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable This e-mail is in response to the requests made to Cisco regarding IPR in CAPWAP. Cisco has always been a strong supporter of the IETF and open standards process, and I would like to re-iterate that our goal is not to limit, restrict, or slow down WG progress. I believe that the language of the IPR statement, which is that Cisco is donating its technology to the IETF (with only defensive restrictions), clearly demonstrates that Cisco is not interested in IPR battles. While some have expressed concern about the LWAPP IPR statement language, it is important to note that Cisco's IPR is not recent news. Cisco (then Airespace) made the IETF aware of its patent application on July 23rd, 2003. Cisco has followed all of the process and procedures of the IETF as it relates to disclosure of IPR, as defined in section 6.4 of RFC 3979. At this point, it is not fair to ask Cisco to disclose the contents of the patent application because until the Patent Office issues the said application, there are no claims worth discussing - and therefore anything I could say on this list would be pure speculation on my part.=20 The Cisco LWAPP IPR statement says anyone can use Cisco's IPR without any kind of explicit license as long as the implementor doesn't assert its own IPR against Cisco. This implies no paperwork, no money, nothing has to be transfered between Cisco and the implementor. But, if the implementor prefers an explicit license without the suspension provision in our IPR statement, such licenses are available from Cisco on RAND terms. Cisco believe this kind of license is better than the traditional RAND IPR statement often used in other cases in standard organizations as what is reasonable terms is not known at the time of (according to the IETF process) last call of a document, and it is not clear the license terms, if known, will be exactly the same for all time. Because of this, Cisco believes anyone having IPR on a technology they bring to the IETF should let anyone implement the technology without any need for explicit license, payments and other kind of uncertainties. But, as stated earlier, if someone doesn't agree with this, and wants an alternative arrangement you are welcome to contact Cisco proactively for a RAND license (and then you can be free to assert your IPR). It is up to the implementor to choose. So I once more ask that the WG consider the presence of IPR as one of many criteria in its decision process. I point you to the vast number of IPR statements that exists against other IETF technologies, some Cisco and some not, and regardless of the fact that IPR exists against most technologies, there are many companies successful in the networking space today. Further, Cisco has a clear track record, in many areas, of not asserting its patents against IETF technologies, and of not limiting or restricting the progress of the Internet. To conclude, I believe that shutting down the working group would not be in the best interest of the Internet community, and I hope the rest of the WG members share this sentiment.=20 Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Sat Oct 01 16:37:19 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ELo6h-0007hr-3B for capwap-archive@megatron.ietf.org; Sat, 01 Oct 2005 16:37:19 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18352 for ; Sat, 1 Oct 2005 16:37:15 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 08678206FB; Sat, 1 Oct 2005 16:37:17 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 5E558206F1; Sat, 1 Oct 2005 16:37:04 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 6EFE1206F0 for ; Sat, 1 Oct 2005 16:36:14 -0400 (EDT) Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by mail.frascone.com (Postfix) with ESMTP id 07079206ED for ; Sat, 1 Oct 2005 16:36:11 -0400 (EDT) Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-3.cisco.com with ESMTP; 01 Oct 2005 13:36:11 -0700 X-IronPort-AV: i="3.97,164,1125903600"; d="scan'208"; a="347431689:sNHT25373264" Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j91Ka54w026160; Sat, 1 Oct 2005 13:36:08 -0700 (PDT) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sat, 1 Oct 2005 13:36:05 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Capwap] CAPWAP evaluation draft complete Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2BEED59@xmb-sjc-235.amer.cisco.com> Thread-Topic: [Capwap] CAPWAP evaluation draft complete Thread-Index: AcW/FcI2CZhyH4KQRBqFRs87raP/XgGBW4FQAGsYUgA= From: "Pat Calhoun (pacalhou)" To: "Sadot, Emek (Emek)" , , Cc: "Mani, Mahalingam (Mahalingam)" , , X-OriginalArrivalTime: 01 Oct 2005 20:36:05.0496 (UTC) FILETIME=[BEFCD780:01C5C6C7] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) 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-Unsubscribe: , List-Id: A list for CAPWAP technical discussions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sat, 1 Oct 2005 13:36:02 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable > 3. section 6.14. approves NAT traversal objective, however I=20 > would challenge LWAPP in this case as it carries the IP=20 > address in the payload. Although NAT devices can be=20 > statically configured, I would vote against taking such=20 > approach, and a prove would be the need for an ALGs for each=20 > protocol that carries IP address in body message. > I would think that adding a recommendation to avoid embedded=20 > IP address in control messages would be advisable. > In addition it would improve the protocol "readiness" for IPv6. Actually, we NAT perfectly well today. The issues are with certain enhanced features, such as the ability to send the data frames to a separate IP address from the control frames. So in NAT scenarios, we simply do not use those features. Given that I participated in the design of PPTP, and was the person that pushed for GRE, I am quite familiar with the protocol. One issue that came about from the use of GRE was its inability to traverse NATs. However, the saving grace was the fact that the PPTP protocol inserted key values in the GRE protocol that allowed for NATs to be able to support PPTP. However, in order for NATs to support PPTP, they needed to implement enough of the PPTP protocol in order to extract information that would allow it to identify information in the GRE header, which it uses to create to correlation between the control and data frames.=20 Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Sat Oct 01 17:02:25 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ELoUz-0003dn-2H for capwap-archive@megatron.ietf.org; Sat, 01 Oct 2005 17:02:25 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18875 for ; Sat, 1 Oct 2005 17:02:18 -0400 (EDT) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 7E00520713; Sat, 1 Oct 2005 17:02:17 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 88D572070A; Sat, 1 Oct 2005 17:02:04 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 7494E20707 for ; Sat, 1 Oct 2005 17:01:43 -0400 (EDT) Received: from tierw.net.avaya.com (tierw.net.avaya.com [198.152.13.100]) by mail.frascone.com (Postfix) with ESMTP id 96AEB20706 for ; Sat, 1 Oct 2005 17:01:40 -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 j8TL2Xpd003539 for ; Thu, 29 Sep 2005 17:02:34 -0400 (EDT) Received: from nj7460avexu2.global.avaya.com (h198-152-6-52.avaya.com [198.152.6.52]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id j8TL2Upd003428 for ; Thu, 29 Sep 2005 17:02:30 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5C53A.FCFE5129" Subject: RE: [Capwap] Change Request 9.1.3.1. Support for Local MAC User Data Tunneling Message-ID: <5844A41F4E146044A2E8356C6328588009B2CE3D@nj7460avexu2.global.avaya.com> Thread-Topic: [Capwap] Change Request 9.1.3.1. Support for Local MAC User Data Tunneling Thread-Index: AcXEZkqBuwf+LMdnQ8KyHVKiUjMwyAA02ebA From: "Sadot, Emek (Emek)" To: "Pat Calhoun (pacalhou)" , X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) 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-Unsubscribe: , List-Id: A list for CAPWAP technical discussions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 29 Sep 2005 17:15:59 -0400 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) This is a multi-part message in MIME format. ------_=_NextPart_001_01C5C53A.FCFE5129 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Pat, you certainly raise valid questions w.r.t. option #3, however I am curious as to the differences between the challenges you listed between options #2 and #3. In other words, in what sense option #2 and #3 are differ w.r.t. encryption and 11e at the AC, as well as RSSI/SNR/data-rate/other monitoring support? =20 Regards, Emek =20 _____ =20 From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Pat Calhoun (pacalhou) Sent: Wednesday, September 28, 2005 5:32 PM To: capwap@frascone.com Subject: [Capwap] Change Request 9.1.3.1. Support for Local MAC User Data Tunneling This change request is to allow for 802.3 tunneling of user data in local bridging mode. I believe that the changes should be relatively straightforward, but do introduce an interesting set of complications that need to be evaluated and agreed upon as a group. =20 The LWAPP protocol currently allows for 802.11 tunneling in Split-MAC mode, allowing for such things as centralized encryption of user data frames. However, the current definition of the protocol is that when running in Local-MAC mode, no traffic is tunneled to the controller. =20 If we were to introduce this change, the LWAPP protocol would have three modes of operation: 1. Split-MAC: Tunnel native MAC frames in UDP (e.g., 802.11) 2. Local-MAC w/ Local Bridge: Do not tunnel 802.3 frames 3. Local-MAC w/ Tunnel: Tunnel 802.3 frames in UDP =20 The issue that we need to decide as a group is whether we really want a protocol that has three modes of operation, and if so, which one is mandatory. The evaluation draft states that option 3 is useful for support of non 802.11 technologies, but this introduces a set of restrictions. For instance, today the LWAPP protocol allows for centralized control of various 802.11 functions, including encryption and 802.11e. This function is not possible with option 3, and therefore any new technology that assumes this option would not be able to provide centralization of data frame functions. =20 There is a comment in the recommendation that LWAPP could retain the RSSI/SNR fields, and then perform 802.3 encapsulation, allowing the AC to have more visibility. However, I have had some requests to expand these fields to also include the data rate. Further, there are possible fields in the header (of technologies we know nothing about) that the WTP may want to extract and expose to the AC - and how could this be done with 802.3? Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 ------_=_NextPart_001_01C5C53A.FCFE5129 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Pat,=20 you certainly raise valid questions w.r.t. option #3, however I am = curious as to=20 the differences between the challenges you listed = between options #2=20 and #3. In other words, in what sense option #2 and #3 are differ = w.r.t.=20 encryption and 11e at the AC, as well as RSSI/SNR/data-rate/other = monitoring=20 support?
 
Regards,
Emek
 
From: capwap-admin@frascone.com = [mailto:capwap-admin@frascone.com] On Behalf Of Pat Calhoun=20 (pacalhou)
Sent: Wednesday, September 28, 2005 5:32 = PM
To:=20 capwap@frascone.com
Subject: [Capwap] Change Request 9.1.3.1. = Support=20 for Local MAC User Data Tunneling

This = change request=20 is to allow for 802.3 tunneling of user data in local bridging mode. I = believe=20 that the changes should be relatively straightforward, but do introduce = an=20 interesting set of complications that need to be evaluated and agreed = upon as a=20 group.
 
The = LWAPP protocol=20 currently allows for 802.11 tunneling in Split-MAC mode, allowing for = such=20 things as centralized encryption of user data frames. However, the = current=20 definition of the protocol is that when running in Local-MAC mode, no = traffic is=20 tunneled to the controller.
 
If we = were to=20 introduce this change, the LWAPP protocol would have three modes of=20 operation:
1. = Split-MAC:=20 Tunnel native MAC frames in UDP (e.g., = 802.11)
2. = Local-MAC w/=20 Local Bridge: Do not tunnel 802.3 frames
3. = Local-MAC w/=20 Tunnel: Tunnel 802.3 frames in UDP
 
The = issue that we=20 need to decide as a group is whether we really want a protocol that has = three=20 modes of operation, and if so, which one is mandatory. The evaluation = draft=20 states that option 3 is useful for support of non 802.11 technologies, = but this=20 introduces a set of restrictions. For instance, today the LWAPP protocol = allows=20 for centralized control of various 802.11 functions, including=20 encryption and 802.11e. This function is not possible with option = 3, and=20 therefore any new technology that assumes this option would not be able = to=20 provide centralization of data frame functions.
 
There = is a comment=20 in the recommendation that LWAPP could retain the RSSI/SNR fields, and = then=20 perform 802.3 encapsulation, allowing the AC to have more visibility. = However, I=20 have had some requests to expand these fields to also include the data = rate.=20 Further, there are possible fields in the header (of technologies we = know=20 nothing about) that the WTP may want to extract and expose to the AC - = and how=20 could this be done with 802.3?

Pat Calhoun
CTO, Wireless Networking = Business=20 Unit
Cisco Systems

 
------_=_NextPart_001_01C5C53A.FCFE5129-- _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Sun Oct 02 15:11:16 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EM9Ey-0003TK-0O for capwap-archive@megatron.ietf.org; Sun, 02 Oct 2005 15:11:16 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28302 for ; Sun, 2 Oct 2005 15:11:13 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id C22251FE8B; Sun, 2 Oct 2005 15:11:03 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from smtp4.centerbeam.com (smtp4.centerbeam.com [63.120.115.248]) by mail.frascone.com (Postfix) with ESMTP id 7F0791FE89 for ; Sun, 2 Oct 2005 15:10:53 -0400 (EDT) Received: from CBA0E2K01.CBA0.centerbeam.com ([64.95.101.24]) by smtp4.centerbeam.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 2 Oct 2005 12:15:36 -0700 Received: from CBA0E2K06.CBA0.centerbeam.com ([64.95.101.40]) by CBA0E2K01.CBA0.centerbeam.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 2 Oct 2005 12:10:46 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Capwap] Change Request 9.1.2 (Control Channel Security) Message-ID: Thread-Topic: [Capwap] Change Request 9.1.2 (Control Channel Security) Thread-Index: AcXFDjTnnPGF/FsVQz2OGJkJEIEZRgCdRwaM From: "Darren Loher" To: X-OriginalArrivalTime: 02 Oct 2005 19:10:46.0180 (UTC) FILETIME=[FE0CF640:01C5C784] 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-Unsubscribe: , List-Id: A list for CAPWAP technical discussions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sun, 2 Oct 2005 12:10:45 -0700 Content-Transfer-Encoding: quoted-printable Speaking as an individual, I also agree that the AC load information = sent in the clear during discovery is not a significant threat above and = beyond doing discovery without this information. I support = post-discovery encryption setup. =20 =20 So would it be correct to say we want security negotiated at the Join = phase (control channel setup)? =20 -Darren ________________________________ From: capwap-admin@frascone.com on behalf of James Kempf Sent: Thu 9/29/2005 9:54 AM To: Pat Calhoun (pacalhou); Dan Harkins Cc: capwap@frascone.com Subject: Re: [Capwap] Change Request 9.1.2 (Control Channel Security)=20 I agree with Dan. I think the risk from doing DTLS post-discovery is minimal. Security protocols have a history of bugs turning up after some years of deployment. An added benefit of using DTLS is that LWAPP benefits from = the attention given to DTLS by users of other protocols, so any bugs will = most likely be found more quickly than if LWAPP designs its own, specialized protocol. Regarding IPsec v.s. DTLS v.s. encryption of the Radius attribute for = PMK distribution, I don't have any real opinion on this. Actually, I think I would prefer to leave this as a deployment option, with appropriate text = in the Security Considerations section about the requirement to use one of these method, and the methods are described. I realize that there is an interoperability concern here, but I can imagine cases where a network operator might prefer one method over another due to their existing deployment. As Dan mentioned, the concerns expressed about using IPsec related to particular implementation issues rather than any fundamental architectural or design issue with the protocol. But I don't have a real strong opinion on this, and I can think of reasons why it might be a = good idea to include a particular "required to implement" method too. jak ----- Original Message ----- From: "Dan Harkins" To: "Pat Calhoun (pacalhou)" Cc: Sent: Wednesday, September 28, 2005 3:16 PM Subject: Re: [Capwap] Change Request 9.1.2 (Control Channel Security) > Pat, > > I agree that the information in the discovery phase is benign. Also, > anything an attacker could do to at that point is the same as what an > attacker could do during the DTLS "hello" exchange-- modify packets > in flight, redirect packets-- and the result would be the same: an > unsuccessful DTLS exchange or unsuccessful discovery. An attacker > could deny service-- prevent a successful DTLS exchange or successful > discovery of AC-- but any middlebox can start dropping packets on a > whim and do the same thing. I don't believe there is a possibility of > a resource exhaustion attack or launch a man-in-the-middle attack > against the AC or WTP. > > I don't think we really need to worry about doing DTLS = post-discovery. > > To address your call for wider WG response to this recommendation: > I strongly believe that (D)TLS should be used for the key exchange and > authentication protocol. > > My understanding on the reason that NIST preferred AES-KeyWrap over > IPsec for the transporting of PMKs had nothing to do with any > preceived weakness in IPsec. It was because there is nothing in the > IPsec standard to allow a user-space app-- like a RADIUS client-- to > know whether the packets it is sending are in the clear or are IPsec- > protected. Therefore a mis-configuration could result in PMKs being > sent over-the-wire in-the-clear. (There are IPsec implementations that > do allow for such queries of the SADB but that isn't part of the IPsec > standard and therefore there isn't a guarantee that such a capability > will be available everywhere). Putting the security for passing the > PMKs directly into the RADIUS app-- i.e. using AES-KeyWrap-- addresses > that concern. Therefore I don't believe NIST would have a problem = sending > PTKs down a (D)TLS-protected link because the app that is sending and > receiving them knows whether that link is protected or not. > > Dan. > > On Wed, 28 Sep 2005 14:32:16 PDT you wrote >> The evaluation team has made a request to modify LWAPP's built-in >> security mechanism with DTLS instead. This specific change is tricky = as >> we first need to identify whether the DTLS session should be created >> prior to, or post, the discovery phase. >> >> Here are my high level thoughts on the issue: >> 1. Pre-Discovery DTLS. >> >> One of the LWAPP features is load balancing of WTPs among ACs. This = load >> balancing can occur within, or across multiple, ACs. How this works = is >> that a WTP would perform the discovery phase by initiating a = Discovery >> Request packet to one or more ACs. The receiving ACs respond with a >> Discovery Response, which also includes the total number of WTPs >> supported (see section 5.2.2), as well as its current WTP load (see >> section 5.2.3). The WTP collects all of the Discovery Responses, and >> then decides which AC it wishes to connect to based on its policy. = The >> policy can be either least loaded AC, or through a list of preferred = ACs >> (see section 7.2.3). Further, the WTP can opt to not establish a = session >> with the AC if it determines that it does not have the basic >> capabilities required by the AC. >> >> Performing DTLS prior to the Discovery Request would mean that the = WTP >> would mean one of two things: >> a. The WTP establishes a DTLS session with every AC it knows about. = The >> side effect here is the LWAPP connect time on the WTP, not to mention >> the CPU load imposed on the AC. >> b. The LWAPP protocol eliminates this feature altogether. This means >> that a WTP would only connect to the AC of its choice, regardless of = the >> AC's current load of configuration. >> >> 2. Post-Discovery DTLS. In this mode, the above limitations are = removed, >> and the Discovery phase is done in the clear. While it is true that = this >> raises some security concerns, the information in the Discovery = Response >> is relatively benign, and therefore any malicious tweaking (or = altering) >> of the response packet has created limited damage (although the WG = needs >> to evaluate this, but it was not found to be problematic during the >> security review). >> >> This change would also require that the the Discovery packets be >> exchanged on a separate UDP port, which is not a big change to the >> protocol. >> >> while I understand the evaluation team's recommendation to adopt = DTLS, I >> would also like to get a larger WG rough consensus on whether we feel >> that this change should be made. While I will make the change based = on >> rough consensus, I want to make sure that we think and agree on this >> decision through as a group. I understand the concerns raised about >> increasing the time of the protocol development phase in having our = own >> security approach, there are strategies that can be done to help us. = For >> instance, initiate another security review with another reviewer >> identified by Russ Housely asap (he did recommend Charles Clancy, = btw). >> >> I think that another important point here is that during a recent >> meeting with NIST, we discussed the transport of 802.11i PMKs within = the >> RADIUS protocol. During this discussion, we proposed two methods. The >> first would explicitely encrypt the PMK using AES-KeyWrap within a >> RADIUS attribute. The second approach was simply to encrypt the whole >> RADIUS transaction with IPSec. It was NIST's opinion at that time = that >> they felt comfortable with option one, while option two would require >> them to evaluate whether IPSec would be appropriate for the transport = of >> PMKs. Given that CAPWAP has a requirement to allow the WTP to perform >> encryption, this means that PTKs (and GTKs) would have to be = transported >> over a DTLS session, and therefore I wonder whether we would have >> similar issues as those mentioned above. If this were an issue, then >> FIPS certification of any CAPWAP based system could become = impossible. >> >> Your comments are appreciated, >> >> Pat Calhoun >> CTO, Wireless Networking Business Unit >> Cisco Systems >> _______________________________________________ >> Capwap mailing list >> Capwap@frascone.com >> http://mail.frascone.com/mailman/listinfo/capwap >> > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap > _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Sun Oct 02 15:18:18 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EM9Lm-0006A8-4w for capwap-archive@megatron.ietf.org; Sun, 02 Oct 2005 15:18:18 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28877 for ; Sun, 2 Oct 2005 15:18:12 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 391B71FE8D; Sun, 2 Oct 2005 15:18:04 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from smtp4.centerbeam.com (smtp4.centerbeam.com [63.120.115.248]) by mail.frascone.com (Postfix) with ESMTP id 250F91FE8A for ; Sun, 2 Oct 2005 15:17:23 -0400 (EDT) Received: from CBA0E2K01.CBA0.centerbeam.com ([64.95.101.24]) by smtp4.centerbeam.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 2 Oct 2005 12:22:08 -0700 Received: from CBA0E2K06.CBA0.centerbeam.com ([64.95.101.40]) by CBA0E2K01.CBA0.centerbeam.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 2 Oct 2005 12:17:18 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Capwap] Change Request 9.1.2 (Control Channel Security) Message-ID: Thread-Topic: [Capwap] Change Request 9.1.2 (Control Channel Security) Thread-Index: AcXFDjTnnPGF/FsVQz2OGJkJEIEZRgCdtv2b From: "Darren Loher" To: "James Kempf" , "Pat Calhoun (pacalhou)" , "Dan Harkins" Cc: X-OriginalArrivalTime: 02 Oct 2005 19:17:18.0530 (UTC) FILETIME=[E7E8D220:01C5C785] 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-Unsubscribe: , List-Id: A list for CAPWAP technical discussions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sun, 2 Oct 2005 12:17:16 -0700 Content-Transfer-Encoding: quoted-printable Regarding secure distribtion of PMK/GMK between AC and WTP, it is = mandatory that these attributes are sent over the secured control = channel. So we should be covered on the AC <-> WTP communication. =20 Isn't the transmission of RADIUS attributes an issue between the AC and = a AAA server and therefore outside the scope of CAPWAP? =20 =20 -Darren ________________________________ From: capwap-admin@frascone.com on behalf of James Kempf Sent: Thu 9/29/2005 9:54 AM To: Pat Calhoun (pacalhou); Dan Harkins Cc: capwap@frascone.com Subject: Re: [Capwap] Change Request 9.1.2 (Control Channel Security)=20 I agree with Dan. I think the risk from doing DTLS post-discovery is minimal. Security protocols have a history of bugs turning up after some years of deployment. An added benefit of using DTLS is that LWAPP benefits from = the attention given to DTLS by users of other protocols, so any bugs will = most likely be found more quickly than if LWAPP designs its own, specialized protocol. Regarding IPsec v.s. DTLS v.s. encryption of the Radius attribute for = PMK distribution, I don't have any real opinion on this. Actually, I think I would prefer to leave this as a deployment option, with appropriate text = in the Security Considerations section about the requirement to use one of these method, and the methods are described. I realize that there is an interoperability concern here, but I can imagine cases where a network operator might prefer one method over another due to their existing deployment. As Dan mentioned, the concerns expressed about using IPsec related to particular implementation issues rather than any fundamental architectural or design issue with the protocol. But I don't have a real strong opinion on this, and I can think of reasons why it might be a = good idea to include a particular "required to implement" method too. jak ----- Original Message ----- From: "Dan Harkins" To: "Pat Calhoun (pacalhou)" Cc: Sent: Wednesday, September 28, 2005 3:16 PM Subject: Re: [Capwap] Change Request 9.1.2 (Control Channel Security) > Pat, > > I agree that the information in the discovery phase is benign. Also, > anything an attacker could do to at that point is the same as what an > attacker could do during the DTLS "hello" exchange-- modify packets > in flight, redirect packets-- and the result would be the same: an > unsuccessful DTLS exchange or unsuccessful discovery. An attacker > could deny service-- prevent a successful DTLS exchange or successful > discovery of AC-- but any middlebox can start dropping packets on a > whim and do the same thing. I don't believe there is a possibility of > a resource exhaustion attack or launch a man-in-the-middle attack > against the AC or WTP. > > I don't think we really need to worry about doing DTLS = post-discovery. > > To address your call for wider WG response to this recommendation: > I strongly believe that (D)TLS should be used for the key exchange and > authentication protocol. > > My understanding on the reason that NIST preferred AES-KeyWrap over > IPsec for the transporting of PMKs had nothing to do with any > preceived weakness in IPsec. It was because there is nothing in the > IPsec standard to allow a user-space app-- like a RADIUS client-- to > know whether the packets it is sending are in the clear or are IPsec- > protected. Therefore a mis-configuration could result in PMKs being > sent over-the-wire in-the-clear. (There are IPsec implementations that > do allow for such queries of the SADB but that isn't part of the IPsec > standard and therefore there isn't a guarantee that such a capability > will be available everywhere). Putting the security for passing the > PMKs directly into the RADIUS app-- i.e. using AES-KeyWrap-- addresses > that concern. Therefore I don't believe NIST would have a problem = sending > PTKs down a (D)TLS-protected link because the app that is sending and > receiving them knows whether that link is protected or not. > > Dan. > > On Wed, 28 Sep 2005 14:32:16 PDT you wrote >> The evaluation team has made a request to modify LWAPP's built-in >> security mechanism with DTLS instead. This specific change is tricky = as >> we first need to identify whether the DTLS session should be created >> prior to, or post, the discovery phase. >> >> Here are my high level thoughts on the issue: >> 1. Pre-Discovery DTLS. >> >> One of the LWAPP features is load balancing of WTPs among ACs. This = load >> balancing can occur within, or across multiple, ACs. How this works = is >> that a WTP would perform the discovery phase by initiating a = Discovery >> Request packet to one or more ACs. The receiving ACs respond with a >> Discovery Response, which also includes the total number of WTPs >> supported (see section 5.2.2), as well as its current WTP load (see >> section 5.2.3). The WTP collects all of the Discovery Responses, and >> then decides which AC it wishes to connect to based on its policy. = The >> policy can be either least loaded AC, or through a list of preferred = ACs >> (see section 7.2.3). Further, the WTP can opt to not establish a = session >> with the AC if it determines that it does not have the basic >> capabilities required by the AC. >> >> Performing DTLS prior to the Discovery Request would mean that the = WTP >> would mean one of two things: >> a. The WTP establishes a DTLS session with every AC it knows about. = The >> side effect here is the LWAPP connect time on the WTP, not to mention >> the CPU load imposed on the AC. >> b. The LWAPP protocol eliminates this feature altogether. This means >> that a WTP would only connect to the AC of its choice, regardless of = the >> AC's current load of configuration. >> >> 2. Post-Discovery DTLS. In this mode, the above limitations are = removed, >> and the Discovery phase is done in the clear. While it is true that = this >> raises some security concerns, the information in the Discovery = Response >> is relatively benign, and therefore any malicious tweaking (or = altering) >> of the response packet has created limited damage (although the WG = needs >> to evaluate this, but it was not found to be problematic during the >> security review). >> >> This change would also require that the the Discovery packets be >> exchanged on a separate UDP port, which is not a big change to the >> protocol. >> >> while I understand the evaluation team's recommendation to adopt = DTLS, I >> would also like to get a larger WG rough consensus on whether we feel >> that this change should be made. While I will make the change based = on >> rough consensus, I want to make sure that we think and agree on this >> decision through as a group. I understand the concerns raised about >> increasing the time of the protocol development phase in having our = own >> security approach, there are strategies that can be done to help us. = For >> instance, initiate another security review with another reviewer >> identified by Russ Housely asap (he did recommend Charles Clancy, = btw). >> >> I think that another important point here is that during a recent >> meeting with NIST, we discussed the transport of 802.11i PMKs within = the >> RADIUS protocol. During this discussion, we proposed two methods. The >> first would explicitely encrypt the PMK using AES-KeyWrap within a >> RADIUS attribute. The second approach was simply to encrypt the whole >> RADIUS transaction with IPSec. It was NIST's opinion at that time = that >> they felt comfortable with option one, while option two would require >> them to evaluate whether IPSec would be appropriate for the transport = of >> PMKs. Given that CAPWAP has a requirement to allow the WTP to perform >> encryption, this means that PTKs (and GTKs) would have to be = transported >> over a DTLS session, and therefore I wonder whether we would have >> similar issues as those mentioned above. If this were an issue, then >> FIPS certification of any CAPWAP based system could become = impossible. >> >> Your comments are appreciated, >> >> Pat Calhoun >> CTO, Wireless Networking Business Unit >> Cisco Systems >> _______________________________________________ >> Capwap mailing list >> Capwap@frascone.com >> http://mail.frascone.com/mailman/listinfo/capwap >> > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap > _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Sun Oct 02 16:10:12 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMAA0-0002H0-A0 for capwap-archive@megatron.ietf.org; Sun, 02 Oct 2005 16:10:12 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01115 for ; Sun, 2 Oct 2005 16:10:09 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 7D11B1FE8B; Sun, 2 Oct 2005 16:10:03 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from smtp4.centerbeam.com (smtp4.centerbeam.com [63.120.115.248]) by mail.frascone.com (Postfix) with ESMTP id 63F8E1FE89 for ; Sun, 2 Oct 2005 16:09:23 -0400 (EDT) Received: from cba0e2k00.CBA0.centerbeam.com ([64.95.101.25]) by smtp4.centerbeam.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 2 Oct 2005 13:14:07 -0700 Received: from CBA0E2K06.CBA0.centerbeam.com ([64.95.101.40]) by cba0e2k00.CBA0.centerbeam.com with Microsoft SMTPSVC(6.0.3790.0); Sun, 2 Oct 2005 13:09:17 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Capwap] CAPWAP evaluation draft complete Message-ID: Thread-Topic: [Capwap] CAPWAP evaluation draft complete Thread-Index: AcW/FcI2CZhyH4KQRBqFRs87raP/XgGBW4FQAJreRm0= From: "Darren Loher" To: "Sadot, Emek (Emek)" , , Cc: "Mani, Mahalingam (Mahalingam)" , , X-OriginalArrivalTime: 02 Oct 2005 20:09:17.0437 (UTC) FILETIME=[2AEC42D0:01C5C78D] 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-Unsubscribe: , List-Id: A list for CAPWAP technical discussions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sun, 2 Oct 2005 13:09:16 -0700 Content-Transfer-Encoding: quoted-printable LWAPP can accomodate VLAN assignment on a per STA basis through it's = "Add Mobile" function [LWAPP 1.7.1.1]. While it's not a hard, BSSID - = VLAN mapping, I think this is actually a bit more flexible. I have seen = scenarios where administrators would like to have multiple VLAN's on one = SSID. This allows creation of policies on a per VLAN basis, somewhere = upstream of the WTP and possible AC too, that are independant of the = SSID. Often users don't know which SSID they are supposed to attach to. =20 Regarding the "c-bit", I agree, this would become a non-issue if control = and data are encapsulated with different protocols. If you have a = strong case for an additional type of data (control vs. user) that might = be used, that might be useful to know. =20 Regarding NAT traversal support via LWAPP, we the evaluation team does = note that carrying the IP address is a potential weakness. However, = this is only in the control path for the purposes of configuring the = location of the AC and Data termination points. =20 =20 Looking at all the proposals, it seems they all can only support NAT = where the WTP is in the hidden address space without some kind of = explicit compensation in the discovery process or configuration in a NAT = device. I'm not sure there's really a good way around this without a = much more complicated discovery or middle-box proxy mechanism that can = detect and/or work around NAT. =20 =20 -Darren ________________________________ From: capwap-admin@frascone.com on behalf of Sadot, Emek (Emek) Sent: Thu 9/29/2005 11:54 AM To: Dorothy.Gellert@nokia.com; capwap@frascone.com Cc: Mani, Mahalingam (Mahalingam); bwijnen@lucent.com; = david.kessens@nokia.com Subject: RE: [Capwap] CAPWAP evaluation draft complete Thanks, Darren and company, for the thorough evaluation work. I have a few observation I'd like to pass along: 1. section 6.1. talks about setting logical groups, and SSID in particular. I believe the message should be extended to include VLAN (per Saravanan note in a different email chain), that's for the case where DS is implemented at the WTP. 2. section 6.2. discuss the use of "C-bit" as a mean to distinguish data vs. controller messages. Although the "C-bit" satisfies the requirement, I think that 1 bit is too restrictive and allows no scalability (e.g. segregate control vs. management, or future wireless technology, if needed). It might be advisable to follow the recommendation sprit you made in section 9.1.1 to extend the IE. 3. section 6.14. approves NAT traversal objective, however I would challenge LWAPP in this case as it carries the IP address in the payload. Although NAT devices can be statically configured, I would vote against taking such approach, and a prove would be the need for an ALGs for each protocol that carries IP address in body message. I would think that adding a recommendation to avoid embedded IP address in control messages would be advisable. In addition it would improve the protocol "readiness" for IPv6. Regards, Emek -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Dorothy.Gellert@nokia.com Sent: Wednesday, September 21, 2005 9:34 PM To: capwap@frascone.com Cc: Mani, Mahalingam (Mahalingam); bwijnen@lucent.com; david.kessens@nokia.com; Dorothy.Gellert@nokia.com Subject: [Capwap] CAPWAP evaluation draft complete After much hard work, the evaluation team has completed the CAPWAP evaluation draft. Its is available for review at: http://www.ietf.org/internet-drafts/draft-ietf-capwap-eval-00.txt and also in the internet drafts directory. The evaluation team concluded that LWAPP is the most complete proposal and should be used as the basis for CAPWAP protocol moving forward. In addition, a number of recommendations were made which the evaluation team believed should be addressed by the working group. Over the next 2 weeks the evaluation team will address clarification questions on the WG list. The recommendation provided by the evaluation team will not change, as this was intended to be an independent activity supported by the WG. This is essentially a WGLC on the evaluation draft. Please submit any clarification question to the list by Friday, September 30th. The next step will be to come to an agreement on the WG list to decide to accept the recommended protocol. Once we have established consensus, we can further discuss the additional recommendations presented in the draft. We would like to thank the evaluation team on its thorough work and a job well done. Regards, Dorothy and Mani _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Sun Oct 02 20:16:18 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EME0A-0004wq-9i for capwap-archive@megatron.ietf.org; Sun, 02 Oct 2005 20:16:18 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10253 for ; Sun, 2 Oct 2005 20:16:14 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 516481FE8F; Sun, 2 Oct 2005 20:16:03 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from homebrew.trpz.com (66-7-225-40.cust.telepacific.net [66.7.225.40]) by mail.frascone.com (Postfix) with ESMTP id D55861FE89 for ; Sun, 2 Oct 2005 20:15:25 -0400 (EDT) Received: from trpz.com (localhost.trpz.com [127.0.0.1]) by homebrew.trpz.com (8.13.1/8.13.1) with ESMTP id j9307JQC069289; Sun, 2 Oct 2005 17:07:19 -0700 (PDT) (envelope-from dharkins@trpz.com) Message-Id: <200510030007.j9307JQC069289@homebrew.trpz.com> To: "Darren Loher" Cc: "James Kempf" , "Pat Calhoun (pacalhou)" , capwap@frascone.com Subject: Re: [Capwap] Change Request 9.1.2 (Control Channel Security) In-Reply-To: Your message of "Sun, 02 Oct 2005 12:17:16 PDT." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <69287.1128298039.1@trpz.com> From: Dan Harkins 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-Unsubscribe: , List-Id: A list for CAPWAP technical discussions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sun, 02 Oct 2005 17:07:19 -0700 Darren, It is the PTK and GTK that are being sent between the AC and WTP not the PMK and GMK, and yes they are secured by the since the control channel through which they are sent is secured. You never want to send a PMK from the AC to the WTP. The PMK is bound to the authenticator and if the authenticator resides on the AC the PMK stays on the AC, if the authent- icator resides on the WTP the PMK stays on the WTP. Yes, RADIUS attributes sent from an AS to an authenticator are outside the scope of CAPWAP but the reason for bringing it up was to point out that NIST has a problem with an IPsec-protected channel (from the AS to the authenticator) and might it also with a DTLS-protected channel (from the AC to the WTP). For the reasons I mentioned below I think the answer is no. Dan. On Sun, 02 Oct 2005 12:17:16 PDT you wrote > Regarding secure distribtion of PMK/GMK between AC and WTP, it is mandatory t >hat these attributes are sent over the secured control channel. So we should >be covered on the AC <-> WTP communication. > > Isn't the transmission of RADIUS attributes an issue between the AC and a AAA > server and therefore outside the scope of CAPWAP? > > -Darren > > ________________________________ > > From: capwap-admin@frascone.com on behalf of James Kempf > Sent: Thu 9/29/2005 9:54 AM > To: Pat Calhoun (pacalhou); Dan Harkins > Cc: capwap@frascone.com > Subject: Re: [Capwap] Change Request 9.1.2 (Control Channel Security) > > > > I agree with Dan. I think the risk from doing DTLS post-discovery is > minimal. > > Security protocols have a history of bugs turning up after some years of > deployment. An added benefit of using DTLS is that LWAPP benefits from the > attention given to DTLS by users of other protocols, so any bugs will most > likely be found more quickly than if LWAPP designs its own, specialized > protocol. > > Regarding IPsec v.s. DTLS v.s. encryption of the Radius attribute for PMK > distribution, I don't have any real opinion on this. Actually, I think I > would prefer to leave this as a deployment option, with appropriate text in > the Security Considerations section about the requirement to use one of > these method, and the methods are described. I realize that there is an > interoperability concern here, but I can imagine cases where a network > operator might prefer one method over another due to their existing > deployment. As Dan mentioned, the concerns expressed about using IPsec > related to particular implementation issues rather than any fundamental > architectural or design issue with the protocol. But I don't have a real > strong opinion on this, and I can think of reasons why it might be a good > idea to include a particular "required to implement" method too. > > > jak > > > > ----- Original Message ----- > From: "Dan Harkins" > To: "Pat Calhoun (pacalhou)" > Cc: > Sent: Wednesday, September 28, 2005 3:16 PM > Subject: Re: [Capwap] Change Request 9.1.2 (Control Channel Security) > > > > Pat, > > > > I agree that the information in the discovery phase is benign. Also, > > anything an attacker could do to at that point is the same as what an > > attacker could do during the DTLS "hello" exchange-- modify packets > > in flight, redirect packets-- and the result would be the same: an > > unsuccessful DTLS exchange or unsuccessful discovery. An attacker > > could deny service-- prevent a successful DTLS exchange or successful > > discovery of AC-- but any middlebox can start dropping packets on a > > whim and do the same thing. I don't believe there is a possibility of > > a resource exhaustion attack or launch a man-in-the-middle attack > > against the AC or WTP. > > > > I don't think we really need to worry about doing DTLS post-discovery. > > > > To address your call for wider WG response to this recommendation: > > I strongly believe that (D)TLS should be used for the key exchange and > > authentication protocol. > > > > My understanding on the reason that NIST preferred AES-KeyWrap over > > IPsec for the transporting of PMKs had nothing to do with any > > preceived weakness in IPsec. It was because there is nothing in the > > IPsec standard to allow a user-space app-- like a RADIUS client-- to > > know whether the packets it is sending are in the clear or are IPsec- > > protected. Therefore a mis-configuration could result in PMKs being > > sent over-the-wire in-the-clear. (There are IPsec implementations that > > do allow for such queries of the SADB but that isn't part of the IPsec > > standard and therefore there isn't a guarantee that such a capability > > will be available everywhere). Putting the security for passing the > > PMKs directly into the RADIUS app-- i.e. using AES-KeyWrap-- addresses > > that concern. Therefore I don't believe NIST would have a problem sending > > PTKs down a (D)TLS-protected link because the app that is sending and > > receiving them knows whether that link is protected or not. > > > > Dan. > > > > On Wed, 28 Sep 2005 14:32:16 PDT you wrote > >> The evaluation team has made a request to modify LWAPP's built-in > >> security mechanism with DTLS instead. This specific change is tricky as > >> we first need to identify whether the DTLS session should be created > >> prior to, or post, the discovery phase. > >> > >> Here are my high level thoughts on the issue: > >> 1. Pre-Discovery DTLS. > >> > >> One of the LWAPP features is load balancing of WTPs among ACs. This load > >> balancing can occur within, or across multiple, ACs. How this works is > >> that a WTP would perform the discovery phase by initiating a Discovery > >> Request packet to one or more ACs. The receiving ACs respond with a > >> Discovery Response, which also includes the total number of WTPs > >> supported (see section 5.2.2), as well as its current WTP load (see > >> section 5.2.3). The WTP collects all of the Discovery Responses, and > >> then decides which AC it wishes to connect to based on its policy. The > >> policy can be either least loaded AC, or through a list of preferred ACs > >> (see section 7.2.3). Further, the WTP can opt to not establish a session > >> with the AC if it determines that it does not have the basic > >> capabilities required by the AC. > >> > >> Performing DTLS prior to the Discovery Request would mean that the WTP > >> would mean one of two things: > >> a. The WTP establishes a DTLS session with every AC it knows about. The > >> side effect here is the LWAPP connect time on the WTP, not to mention > >> the CPU load imposed on the AC. > >> b. The LWAPP protocol eliminates this feature altogether. This means > >> that a WTP would only connect to the AC of its choice, regardless of the > >> AC's current load of configuration. > >> > >> 2. Post-Discovery DTLS. In this mode, the above limitations are removed, > >> and the Discovery phase is done in the clear. While it is true that this > >> raises some security concerns, the information in the Discovery Response > >> is relatively benign, and therefore any malicious tweaking (or altering) > >> of the response packet has created limited damage (although the WG needs > >> to evaluate this, but it was not found to be problematic during the > >> security review). > >> > >> This change would also require that the the Discovery packets be > >> exchanged on a separate UDP port, which is not a big change to the > >> protocol. > >> > >> while I understand the evaluation team's recommendation to adopt DTLS, I > >> would also like to get a larger WG rough consensus on whether we feel > >> that this change should be made. While I will make the change based on > >> rough consensus, I want to make sure that we think and agree on this > >> decision through as a group. I understand the concerns raised about > >> increasing the time of the protocol development phase in having our own > >> security approach, there are strategies that can be done to help us. For > >> instance, initiate another security review with another reviewer > >> identified by Russ Housely asap (he did recommend Charles Clancy, btw). > >> > >> I think that another important point here is that during a recent > >> meeting with NIST, we discussed the transport of 802.11i PMKs within the > >> RADIUS protocol. During this discussion, we proposed two methods. The > >> first would explicitely encrypt the PMK using AES-KeyWrap within a > >> RADIUS attribute. The second approach was simply to encrypt the whole > >> RADIUS transaction with IPSec. It was NIST's opinion at that time that > >> they felt comfortable with option one, while option two would require > >> them to evaluate whether IPSec would be appropriate for the transport of > >> PMKs. Given that CAPWAP has a requirement to allow the WTP to perform > >> encryption, this means that PTKs (and GTKs) would have to be transported > >> over a DTLS session, and therefore I wonder whether we would have > >> similar issues as those mentioned above. If this were an issue, then > >> FIPS certification of any CAPWAP based system could become impossible. > >> > >> Your comments are appreciated, > >> > >> Pat Calhoun > >> CTO, Wireless Networking Business Unit > >> Cisco Systems > >> _______________________________________________ > >> Capwap mailing list > >> Capwap@frascone.com > >> http://mail.frascone.com/mailman/listinfo/capwap > >> > > _______________________________________________ > > Capwap mailing list > > Capwap@frascone.com > > http://mail.frascone.com/mailman/listinfo/capwap > > > > > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap > > > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap > _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Mon Oct 03 01:00:13 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMIQv-0004Zp-KV for capwap-archive@megatron.ietf.org; Mon, 03 Oct 2005 01:00:13 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18682 for ; Mon, 3 Oct 2005 01:00:11 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E71B31FE95; Mon, 3 Oct 2005 01:00:03 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from huawei-3com.com (smtp.huawei-3com.com [219.133.0.19]) by mail.frascone.com (Postfix) with ESMTP id AD34B1FD0B for ; Mon, 3 Oct 2005 00:59:31 -0400 (EDT) Received: from smtp.huawei-3com.com (localhost [127.0.0.1]) by smtp.huawei-3com.com (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTP id <0INR002O0PPQW1@smtp.huawei-3com.com> for capwap@frascone.com; Mon, 03 Oct 2005 12:56:14 +0800 (CST) Received: from huawei-3com.com (ldapb.huawei-3com.com [172.19.1.228]) by smtp.huawei-3com.com (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTP id <0INR00IHHPPPVO@smtp.huawei-3com.com> for capwap@frascone.com; Mon, 03 Oct 2005 12:56:14 +0800 (CST) Received: from [10.18.1.7] by mail.huawei-3com.com (mshttpd); Mon, 03 Oct 2005 09:57:35 +0500 From: zhaoyujin 00919 Subject: RE: [Capwap] Change Request 9.1.3.1. Support for Local MAC User Data Tunneling To: "Pat Calhoun (pacalhou)" Cc: capwap@frascone.com Message-id: MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 1.16 (built May 14 2003) Content-type: text/plain; charset=us-ascii Content-language: zh-CN Content-transfer-encoding: 7BIT Content-disposition: inline X-Accept-Language: zh-CN Priority: normal 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-Unsubscribe: , List-Id: A list for CAPWAP technical discussions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 03 Oct 2005 09:57:35 +0500 Content-Transfer-Encoding: 7BIT Hi: Can we use the "add mobile frame" to notify AC create the usage information? Like above, CAPWAP can defined "local-local mac". All 802.11 frame is terminated on WTP. If there need communication between AC and AP, the LWAPP cotrol message can be used. Best regards Michael > Emek, > > In option 3, when a user associates with the WTP, the association is > handled locally, but the packet is tunneled to the AC in order for the > AC to have access to usage information (and make overriding policy > decisions). So 802.11 needs to be supported on the AC regardless, > right? > > Pat Calhoun > CTO, Wireless Networking Business Unit > Cisco Systems > > > > > ________________________________ > > From: Sadot, Emek (Emek) [esadot@avaya.com] > Sent: Friday, September 30, 2005 10:16 AM > To: Pat Calhoun (pacalhou); capwap@frascone.com > Subject: RE: [Capwap] Change Request 9.1.3.1. Support for Local > MAC User Data Tunneling > > > Regarding the points you raised I believe option #2 and #3 share > the same qualities. > In both options 802.11 encryption and 11e cannot be implemented > at the AC. > In both options a mechanism shall be design to extract RF and > data-traffic statistics either (a) appended in the tunneling > (option #3 > only) or (b) exposed by the WTP as read-only values for the AC > inquiries(both options). > > Am I missing something? > > On the other hand one can respect the unique merits that these > options offer: > - option 2: non-appliance product. meaning a software based AC > that can be executed on any server / platform. > - option 3: avoid parse 802.11 traffic in silicon at the AC. > Leverage existing products (e.g. routers) with "only" add-on > 802.11 code > running at the Cpu. > > Emek > > ________________________________ > > From: Pat Calhoun (pacalhou) [pcalhoun@cisco.com] > Sent: Thursday, September 29, 2005 6:01 PM > To: Sadot, Emek (Emek); capwap@frascone.com > Subject: RE: [Capwap] Change Request 9.1.3.1. Support for Local > MAC User Data Tunneling > > > In terms of option 2, no traffic is sent to the AC, so the model > is quite different. > > > Pat Calhoun > CTO, Wireless Networking Business Unit > Cisco Systems > > > > > ________________________________ > > From: Sadot, Emek (Emek) [esadot@avaya.com] > Sent: Thursday, September 29, 2005 2:16 PM > To: Pat Calhoun (pacalhou); capwap@frascone.com > Subject: RE: [Capwap] Change Request 9.1.3.1. Support > for Local MAC User Data Tunneling > > > Pat, you certainly raise valid questions w.r.t. option > #3, however I am curious as to the differences between the challenges > you listed between options #2 and #3. In other words, in what sense > option #2 and #3 are differ w.r.t. encryption and 11e at the AC, > as well > as RSSI/SNR/data-rate/other monitoring support? > > Regards, > Emek > > ________________________________ > > From: capwap-admin@frascone.com > [capwap-admin@frascone.com] On Behalf Of Pat Calhoun (pacalhou) > Sent: Wednesday, September 28, 2005 5:32 PM > To: capwap@frascone.com > Subject: [Capwap] Change Request 9.1.3.1. Support for > Local MAC User Data Tunneling > > > This change request is to allow for 802.3 tunneling of > user data in local bridging mode. I believe that the changes > should be > relatively straightforward, but do introduce an interesting set of > complications that need to be evaluated and agreed upon as a group. > > The LWAPP protocol currently allows for 802.11 tunneling > in Split-MAC mode, allowing for such things as centralized > encryption of > user data frames. However, the current definition of the protocol is > that when running in Local-MAC mode, no traffic is tunneled to the > controller. > > If we were to introduce this change, the LWAPP protocol > would have three modes of operation: > 1. Split-MAC: Tunnel native MAC frames in UDP (e.g., > 802.11) > 2. Local-MAC w/ Local Bridge: Do not tunnel 802.3 frames > 3. Local-MAC w/ Tunnel: Tunnel 802.3 frames in UDP > > The issue that we need to decide as a group is whether > we really want a protocol that has three modes of operation, and > if so, > which one is mandatory. The evaluation draft states that option 3 is > useful for support of non 802.11 technologies, but this introduces > a set > of restrictions. For instance, today the LWAPP protocol allows for > centralized control of various 802.11 functions, including encryption > and 802.11e. This function is not possible with option 3, and > thereforeany new technology that assumes this option would not be > able to provide > centralization of data frame functions. > > There is a comment in the recommendation that LWAPP > could retain the RSSI/SNR fields, and then perform 802.3 > encapsulation,allowing the AC to have more visibility. However, I > have had some > requests to expand these fields to also include the data rate. > Further,there are possible fields in the header (of technologies > we know nothing > about) that the WTP may want to extract and expose to the AC - and how > could this be done with 802.3? > > Pat Calhoun > CTO, Wireless Networking Business Unit > Cisco Systems > > > > _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Mon Oct 03 04:05:19 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMLK2-0006CG-Rz for capwap-archive@megatron.ietf.org; Mon, 03 Oct 2005 04:05:19 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09643 for ; Mon, 3 Oct 2005 04:05:16 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A8A751FE96; Mon, 3 Oct 2005 04:05:03 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from huawei-3com.com (smtp.huawei-3com.com [219.133.0.19]) by mail.frascone.com (Postfix) with ESMTP id BD88A1FE94 for ; Mon, 3 Oct 2005 04:04:38 -0400 (EDT) Received: from smtp.huawei-3com.com (localhost [127.0.0.1]) by smtp.huawei-3com.com (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTP id <0INR0027NVHGW1@smtp.huawei-3com.com> for capwap@frascone.com; Mon, 03 Oct 2005 15:00:52 +0800 (CST) Received: from huawei-3com.com (ldapb.huawei-3com.com [172.19.1.228]) by smtp.huawei-3com.com (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTP id <0INR00I4PVHGVO@smtp.huawei-3com.com> for capwap@frascone.com; Mon, 03 Oct 2005 15:00:52 +0800 (CST) Received: from [10.18.1.7] by mail.huawei-3com.com (mshttpd); Mon, 03 Oct 2005 12:02:13 +0500 From: zhaoyujin 00919 To: capwap@frascone.com Message-id: <9e19ea2f21.a2f219e19e@huawei-3com.com> MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 1.16 (built May 14 2003) Content-type: text/plain; charset=us-ascii Content-language: zh-CN Content-transfer-encoding: 7BIT Content-disposition: inline X-Accept-Language: zh-CN Priority: normal Subject: [Capwap] Conflict about Local MAC 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-Unsubscribe: , List-Id: A list for CAPWAP technical discussions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 03 Oct 2005 12:02:13 +0500 Content-Transfer-Encoding: 7BIT Hi all: In rfc4118.txt, Section 5.3 "Local MAC" gives examples (Figure 7) which all 802.11 mgmt are termianted by WTP. And in Figure 9, 80 percent vendors realize the association process on AC. Figure 5 in "draft-ohara-capwap-lwapp-03" section 11.1.2 "Local MAC" depicts the "Assoc / Disassoc / Reassoc" processes on WTP. Otherwise the description in "Figure 6: Local MAC Message Flow" is conflict with the above description. Next is the description: "The WTP forwards the 802.11 Authentication and Association frames to the AC, which is responsible for responding to the client." And the Figure 6: Client WTP AC 802.11 Association <---------------------------( - )-------------------------> But the LWAPP protocol does not defined the message for association between AP and AC. I think there may need some change. Best Regards. Michael _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Mon Oct 03 08:27:13 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMPPU-0006Zr-Eo for capwap-archive@megatron.ietf.org; Mon, 03 Oct 2005 08:27:13 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24918 for ; Mon, 3 Oct 2005 08:27:10 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id F244620352; Mon, 3 Oct 2005 08:27:03 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from homebrew.trpz.com (66-7-225-40.cust.telepacific.net [66.7.225.40]) by mail.frascone.com (Postfix) with ESMTP id 772CE20328 for ; Mon, 3 Oct 2005 08:26:38 -0400 (EDT) Received: from trpz.com (localhost.trpz.com [127.0.0.1]) by homebrew.trpz.com (8.13.1/8.13.1) with ESMTP id j93CKCab071213; Mon, 3 Oct 2005 05:20:12 -0700 (PDT) (envelope-from dharkins@trpz.com) Message-Id: <200510031220.j93CKCab071213@homebrew.trpz.com> To: "Pat Calhoun (pacalhou)" Cc: capwap@frascone.com Subject: Re: [Capwap] Cisco IPR Statement In-Reply-To: Your message of "Sat, 01 Oct 2005 13:28:48 PDT." <4FF84B0BC277FF45AA27FE969DD956A2BEED54@xmb-sjc-235.amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <71211.1128342012.1@trpz.com> From: Dan Harkins 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-Unsubscribe: , List-Id: A list for CAPWAP technical discussions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 03 Oct 2005 05:20:12 -0700 Pat, If Cisco believes that the terms of its LWAPP IPR statement are better than traditional RAND IPR statements then why is Cisco offering RAND terms for CTP, WiCOP, and SLAPP? You said, "Cisco believes anyone having IPR on a technology they bring to the IETF should let anyone implement the technology without any need for exlicit license, payments and other kind of uncertainties." How can you make such a statement without punctuating it with emoticons or the popular acronyms for laughing out loud? "Cisco believes..." and "Cisco believes..." yet Cisco is acting in ways contrary to what you're saying it believes in. Actions speak louder than words. You state that "Cisco's IPR is not recent news". Really? A mere 3 weeks ago Cisco claimed that it had IPR over CTP, WiCOP and SLAPP. Furthermore you say it wouldn't be "fair" to ask Cisco to disclose what, exactly, is being claimed because "there are no claims worth discussing" until the PTO rules on pending application. On the contrary, the claims worth discussing are _exactly_ what is being claimed in the pending application. Since the evaluation team is recommending changes to LWAPP that come from protocols which have RAND terms on them I think it is imperative that you disclose what is in those pending applications so the working group can decide how and whether to move forward. Once again I would like to point out that while the LWAPP IPR statement is certainly better than RAND terms it still has an unlimited field of use that applies to when the grant of rights terminate. That is A Bad Thing and, in my opinion, has to change. Dan. On Sat, 01 Oct 2005 13:28:48 PDT you wrote > This e-mail is in response to the requests made to Cisco regarding IPR > in CAPWAP. Cisco has always been a strong supporter of the IETF and open > standards process, and I would like to re-iterate that our goal is not > to limit, restrict, or slow down WG progress. I believe that the > language of the IPR statement, which is that Cisco is donating its > technology to the IETF (with only defensive restrictions), clearly > demonstrates that Cisco is not interested in IPR battles. > > While some have expressed concern about the LWAPP IPR statement > language, it is important to note that Cisco's IPR is not recent news. > Cisco (then Airespace) made the IETF aware of its patent application on > July 23rd, 2003. Cisco has followed all of the process and procedures of > the IETF as it relates to disclosure of IPR, as defined in section 6.4 > of RFC 3979. At this point, it is not fair to ask Cisco to disclose the > contents of the patent application because until the Patent Office > issues the said application, there are no claims worth discussing - and > therefore anything I could say on this list would be pure speculation on > my part. > > The Cisco LWAPP IPR statement says anyone can use Cisco's IPR without > any kind of explicit license as long as the implementor doesn't assert > its own IPR against Cisco. This implies no paperwork, no money, nothing > has to be transfered between Cisco and the implementor. But, if the > implementor prefers an explicit license without the suspension provision > in our IPR statement, such licenses are available from Cisco on RAND > terms. > > Cisco believe this kind of license is better than the traditional RAND > IPR statement often used in other cases in standard organizations as > what is reasonable terms is not known at the time of (according to the > IETF process) last call of a document, and it is not clear the license > terms, if known, will be exactly the same for all time. > > Because of this, Cisco believes anyone having IPR on a technology they > bring to the IETF should let anyone implement the technology without any > need for explicit license, payments and other kind of uncertainties. > But, as stated earlier, if someone doesn't agree with this, and wants an > alternative arrangement you are welcome to contact Cisco proactively for > a RAND license (and then you can be free to assert your IPR). It is up > to the implementor to choose. > > So I once more ask that the WG consider the presence of IPR as one of > many criteria in its decision process. I point you to the vast number of > IPR statements that exists against other IETF technologies, some Cisco > and some not, and regardless of the fact that IPR exists against most > technologies, there are many companies successful in the networking > space today. Further, Cisco has a clear track record, in many areas, of > not asserting its patents against IETF technologies, and of not limiting > or restricting the progress of the Internet. > > To conclude, I believe that shutting down the working group would not be > in the best interest of the Internet community, and I hope the rest of > the WG members share this sentiment. > > Pat Calhoun > CTO, Wireless Networking Business Unit > Cisco Systems > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap > _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Mon Oct 03 10:13:13 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMR44-0000EQ-Oo for capwap-archive@megatron.ietf.org; Mon, 03 Oct 2005 10:13:13 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01693 for ; Mon, 3 Oct 2005 10:13:10 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 2E18E20364; Mon, 3 Oct 2005 10:13:04 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from flyer.cs.umd.edu (flyer.cs.umd.edu [128.8.128.178]) by mail.frascone.com (Postfix) with ESMTP id D06EB20352 for ; Mon, 3 Oct 2005 10:12:19 -0400 (EDT) Received: from ismene (ismene.cs.umd.edu [128.8.126.62]) by flyer.cs.umd.edu (8.12.11/8.12.5) with ESMTP id j93DqOiI026708; Mon, 3 Oct 2005 09:52:24 -0400 From: "T. Charles Clancy" X-X-Sender: clancy@ismene To: "Pat Calhoun (pacalhou)" Cc: capwap@frascone.com Subject: Re: [Capwap] Change Request 9.1.2 (Control Channel Security) In-Reply-To: <4FF84B0BC277FF45AA27FE969DD956A2B8B782@xmb-sjc-235.amer.cisco.com> Message-ID: References: <4FF84B0BC277FF45AA27FE969DD956A2B8B782@xmb-sjc-235.amer.cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed 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-Unsubscribe: , List-Id: A list for CAPWAP technical discussions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 3 Oct 2005 09:52:04 -0400 (EDT) I see no problems with post-discovery DTLS. Pre-discovery really doesn't make much sense. I suppose there is a chance for a DoS if someone sends bogus discovery response messages, but the mutual authentication requirements prevents any compromise of data. I also see no problem with transporting plaintext keys within the DTLS session. As a side note, IMHO the existing LWAPP security features are adequate. However, in the spirit of modular standards, I think reusing a security protocol would be a good idea. [ t. charles clancy ]--[ tcc@umd.edu ]--[ www.cs.umd.edu/~clancy ] [ computer science ]-----[ university of maryland | college park ] On Wed, 28 Sep 2005, Pat Calhoun (pacalhou) wrote: > The evaluation team has made a request to modify LWAPP's built-in > security mechanism with DTLS instead. This specific change is tricky as > we first need to identify whether the DTLS session should be created > prior to, or post, the discovery phase. > > Here are my high level thoughts on the issue: > 1. Pre-Discovery DTLS. > > One of the LWAPP features is load balancing of WTPs among ACs. This load > balancing can occur within, or across multiple, ACs. How this works is > that a WTP would perform the discovery phase by initiating a Discovery > Request packet to one or more ACs. The receiving ACs respond with a > Discovery Response, which also includes the total number of WTPs > supported (see section 5.2.2), as well as its current WTP load (see > section 5.2.3). The WTP collects all of the Discovery Responses, and > then decides which AC it wishes to connect to based on its policy. The > policy can be either least loaded AC, or through a list of preferred ACs > (see section 7.2.3). Further, the WTP can opt to not establish a session > with the AC if it determines that it does not have the basic > capabilities required by the AC. > > Performing DTLS prior to the Discovery Request would mean that the WTP > would mean one of two things: > a. The WTP establishes a DTLS session with every AC it knows about. The > side effect here is the LWAPP connect time on the WTP, not to mention > the CPU load imposed on the AC. > b. The LWAPP protocol eliminates this feature altogether. This means > that a WTP would only connect to the AC of its choice, regardless of the > AC's current load of configuration. > > 2. Post-Discovery DTLS. In this mode, the above limitations are removed, > and the Discovery phase is done in the clear. While it is true that this > raises some security concerns, the information in the Discovery Response > is relatively benign, and therefore any malicious tweaking (or altering) > of the response packet has created limited damage (although the WG needs > to evaluate this, but it was not found to be problematic during the > security review). > > This change would also require that the the Discovery packets be > exchanged on a separate UDP port, which is not a big change to the > protocol. > > while I understand the evaluation team's recommendation to adopt DTLS, I > would also like to get a larger WG rough consensus on whether we feel > that this change should be made. While I will make the change based on > rough consensus, I want to make sure that we think and agree on this > decision through as a group. I understand the concerns raised about > increasing the time of the protocol development phase in having our own > security approach, there are strategies that can be done to help us. For > instance, initiate another security review with another reviewer > identified by Russ Housely asap (he did recommend Charles Clancy, btw). > > I think that another important point here is that during a recent > meeting with NIST, we discussed the transport of 802.11i PMKs within the > RADIUS protocol. During this discussion, we proposed two methods. The > first would explicitely encrypt the PMK using AES-KeyWrap within a > RADIUS attribute. The second approach was simply to encrypt the whole > RADIUS transaction with IPSec. It was NIST's opinion at that time that > they felt comfortable with option one, while option two would require > them to evaluate whether IPSec would be appropriate for the transport of > PMKs. Given that CAPWAP has a requirement to allow the WTP to perform > encryption, this means that PTKs (and GTKs) would have to be transported > over a DTLS session, and therefore I wonder whether we would have > similar issues as those mentioned above. If this were an issue, then > FIPS certification of any CAPWAP based system could become impossible. > > Your comments are appreciated, > > Pat Calhoun > CTO, Wireless Networking Business Unit > Cisco Systems > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap > _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Tue Oct 04 12:59:25 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMq8O-0002n9-1r for capwap-archive@megatron.ietf.org; Tue, 04 Oct 2005 12:59:25 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09975 for ; Tue, 4 Oct 2005 12:59:15 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B825720377; Tue, 4 Oct 2005 12:59:04 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from smtp4.centerbeam.com (smtp4.centerbeam.com [63.120.115.248]) by mail.frascone.com (Postfix) with ESMTP id 229D120365 for ; Tue, 4 Oct 2005 12:58:56 -0400 (EDT) Received: from cba0e2k00.CBA0.centerbeam.com ([64.95.101.25]) by smtp4.centerbeam.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 4 Oct 2005 10:03:44 -0700 Received: from CBA0E2K06.CBA0.centerbeam.com ([64.95.101.40]) by cba0e2k00.CBA0.centerbeam.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 4 Oct 2005 09:58:45 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Capwap] Change Request 9.1.2 (Control Channel Security) Message-ID: Thread-Topic: [Capwap] Change Request 9.1.2 (Control Channel Security) Thread-Index: AcXHr5XE/H81I+yNQ0mbeS3oocFh/wBVKOPA From: "Darren Loher" To: "Dan Harkins" Cc: "James Kempf" , "Pat Calhoun (pacalhou)" , X-OriginalArrivalTime: 04 Oct 2005 16:58:45.0251 (UTC) FILETIME=[E1A29D30:01C5C904] 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-Unsubscribe: , List-Id: A list for CAPWAP technical discussions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 4 Oct 2005 09:58:49 -0700 Content-Transfer-Encoding: quoted-printable You are right, it was my mistake to refer to PMK/GMK, we are talking about the PTK and GTK between the AC and WTP. =20 So we agree that it's highly unlikely that there is any issue with transmission of the PTK/GTK over the secure CAPWAP control channel between the AC and WTP. -Darren > -----Original Message----- > From: Dan Harkins [mailto:dharkins@trpz.com] > Sent: Sunday, October 02, 2005 6:07 PM > To: Darren Loher > Cc: James Kempf; Pat Calhoun (pacalhou); capwap@frascone.com > Subject: Re: [Capwap] Change Request 9.1.2 (Control Channel Security) >=20 > Darren, >=20 > It is the PTK and GTK that are being sent between the AC and WTP not > the PMK and GMK, and yes they are secured by the since the control channel > through which they are sent is secured. You never want to send a PMK from > the AC to the WTP. The PMK is bound to the authenticator and if the > authenticator resides on the AC the PMK stays on the AC, if the authent- > icator resides on the WTP the PMK stays on the WTP. >=20 > Yes, RADIUS attributes sent from an AS to an authenticator are outside > the scope of CAPWAP but the reason for bringing it up was to point out > that NIST has a problem with an IPsec-protected channel (from the AS to > the authenticator) and might it also with a DTLS-protected channel (from > the AC to the WTP). For the reasons I mentioned below I think the > answer is no. >=20 > Dan. >=20 > On Sun, 02 Oct 2005 12:17:16 PDT you wrote > > Regarding secure distribtion of PMK/GMK between AC and WTP, it is > mandatory t > >hat these attributes are sent over the secured control channel. So we > should > >be covered on the AC <-> WTP communication. > > > > Isn't the transmission of RADIUS attributes an issue between the AC and > a AAA > > server and therefore outside the scope of CAPWAP? > > > > -Darren > > > > ________________________________ > > > > From: capwap-admin@frascone.com on behalf of James Kempf > > Sent: Thu 9/29/2005 9:54 AM > > To: Pat Calhoun (pacalhou); Dan Harkins > > Cc: capwap@frascone.com > > Subject: Re: [Capwap] Change Request 9.1.2 (Control Channel Security) > > > > > > > > I agree with Dan. I think the risk from doing DTLS post-discovery is > > minimal. > > > > Security protocols have a history of bugs turning up after some years of > > deployment. An added benefit of using DTLS is that LWAPP benefits from > the > > attention given to DTLS by users of other protocols, so any bugs will > most > > likely be found more quickly than if LWAPP designs its own, specialized > > protocol. > > > > Regarding IPsec v.s. DTLS v.s. encryption of the Radius attribute for > PMK > > distribution, I don't have any real opinion on this. Actually, I think I > > would prefer to leave this as a deployment option, with appropriate text > in > > the Security Considerations section about the requirement to use one of > > these method, and the methods are described. I realize that there is an > > interoperability concern here, but I can imagine cases where a network > > operator might prefer one method over another due to their existing > > deployment. As Dan mentioned, the concerns expressed about using IPsec > > related to particular implementation issues rather than any fundamental > > architectural or design issue with the protocol. But I don't have a real > > strong opinion on this, and I can think of reasons why it might be a > good > > idea to include a particular "required to implement" method too. > > > > > > jak > > > > > > > > ----- Original Message ----- > > From: "Dan Harkins" > > To: "Pat Calhoun (pacalhou)" > > Cc: > > Sent: Wednesday, September 28, 2005 3:16 PM > > Subject: Re: [Capwap] Change Request 9.1.2 (Control Channel Security) > > > > > > > Pat, > > > > > > I agree that the information in the discovery phase is benign. Also, > > > anything an attacker could do to at that point is the same as what an > > > attacker could do during the DTLS "hello" exchange-- modify packets > > > in flight, redirect packets-- and the result would be the same: an > > > unsuccessful DTLS exchange or unsuccessful discovery. An attacker > > > could deny service-- prevent a successful DTLS exchange or successful > > > discovery of AC-- but any middlebox can start dropping packets on a > > > whim and do the same thing. I don't believe there is a possibility of > > > a resource exhaustion attack or launch a man-in-the-middle attack > > > against the AC or WTP. > > > > > > I don't think we really need to worry about doing DTLS post- > discovery. > > > > > > To address your call for wider WG response to this recommendation: > > > I strongly believe that (D)TLS should be used for the key exchange and > > > authentication protocol. > > > > > > My understanding on the reason that NIST preferred AES-KeyWrap over > > > IPsec for the transporting of PMKs had nothing to do with any > > > preceived weakness in IPsec. It was because there is nothing in the > > > IPsec standard to allow a user-space app-- like a RADIUS client-- to > > > know whether the packets it is sending are in the clear or are IPsec- > > > protected. Therefore a mis-configuration could result in PMKs being > > > sent over-the-wire in-the-clear. (There are IPsec implementations that > > > do allow for such queries of the SADB but that isn't part of the IPsec > > > standard and therefore there isn't a guarantee that such a capability > > > will be available everywhere). Putting the security for passing the > > > PMKs directly into the RADIUS app-- i.e. using AES-KeyWrap-- addresses > > > that concern. Therefore I don't believe NIST would have a problem > sending > > > PTKs down a (D)TLS-protected link because the app that is sending and > > > receiving them knows whether that link is protected or not. > > > > > > Dan. > > > > > > On Wed, 28 Sep 2005 14:32:16 PDT you wrote > > >> The evaluation team has made a request to modify LWAPP's built-in > > >> security mechanism with DTLS instead. This specific change is tricky > as > > >> we first need to identify whether the DTLS session should be created > > >> prior to, or post, the discovery phase. > > >> > > >> Here are my high level thoughts on the issue: > > >> 1. Pre-Discovery DTLS. > > >> > > >> One of the LWAPP features is load balancing of WTPs among ACs. This > load > > >> balancing can occur within, or across multiple, ACs. How this works > is > > >> that a WTP would perform the discovery phase by initiating a > Discovery > > >> Request packet to one or more ACs. The receiving ACs respond with a > > >> Discovery Response, which also includes the total number of WTPs > > >> supported (see section 5.2.2), as well as its current WTP load (see > > >> section 5.2.3). The WTP collects all of the Discovery Responses, and > > >> then decides which AC it wishes to connect to based on its policy. > The > > >> policy can be either least loaded AC, or through a list of preferred > ACs > > >> (see section 7.2.3). Further, the WTP can opt to not establish a > session > > >> with the AC if it determines that it does not have the basic > > >> capabilities required by the AC. > > >> > > >> Performing DTLS prior to the Discovery Request would mean that the > WTP > > >> would mean one of two things: > > >> a. The WTP establishes a DTLS session with every AC it knows about. > The > > >> side effect here is the LWAPP connect time on the WTP, not to mention > > >> the CPU load imposed on the AC. > > >> b. The LWAPP protocol eliminates this feature altogether. This means > > >> that a WTP would only connect to the AC of its choice, regardless of > the > > >> AC's current load of configuration. > > >> > > >> 2. Post-Discovery DTLS. In this mode, the above limitations are > removed, > > >> and the Discovery phase is done in the clear. While it is true that > this > > >> raises some security concerns, the information in the Discovery > Response > > >> is relatively benign, and therefore any malicious tweaking (or > altering) > > >> of the response packet has created limited damage (although the WG > needs > > >> to evaluate this, but it was not found to be problematic during the > > >> security review). > > >> > > >> This change would also require that the the Discovery packets be > > >> exchanged on a separate UDP port, which is not a big change to the > > >> protocol. > > >> > > >> while I understand the evaluation team's recommendation to adopt > DTLS, I > > >> would also like to get a larger WG rough consensus on whether we feel > > >> that this change should be made. While I will make the change based > on > > >> rough consensus, I want to make sure that we think and agree on this > > >> decision through as a group. I understand the concerns raised about > > >> increasing the time of the protocol development phase in having our > own > > >> security approach, there are strategies that can be done to help us. > For > > >> instance, initiate another security review with another reviewer > > >> identified by Russ Housely asap (he did recommend Charles Clancy, > btw). > > >> > > >> I think that another important point here is that during a recent > > >> meeting with NIST, we discussed the transport of 802.11i PMKs within > the > > >> RADIUS protocol. During this discussion, we proposed two methods. The > > >> first would explicitely encrypt the PMK using AES-KeyWrap within a > > >> RADIUS attribute. The second approach was simply to encrypt the whole > > >> RADIUS transaction with IPSec. It was NIST's opinion at that time > that > > >> they felt comfortable with option one, while option two would require > > >> them to evaluate whether IPSec would be appropriate for the transport > of > > >> PMKs. Given that CAPWAP has a requirement to allow the WTP to perform > > >> encryption, this means that PTKs (and GTKs) would have to be > transported > > >> over a DTLS session, and therefore I wonder whether we would have > > >> similar issues as those mentioned above. If this were an issue, then > > >> FIPS certification of any CAPWAP based system could become > impossible. > > >> > > >> Your comments are appreciated, > > >> > > >> Pat Calhoun > > >> CTO, Wireless Networking Business Unit > > >> Cisco Systems > > >> _______________________________________________ > > >> Capwap mailing list > > >> Capwap@frascone.com > > >> http://mail.frascone.com/mailman/listinfo/capwap > > >> > > > _______________________________________________ > > > Capwap mailing list > > > Capwap@frascone.com > > > http://mail.frascone.com/mailman/listinfo/capwap > > > > > > > > > _______________________________________________ > > Capwap mailing list > > Capwap@frascone.com > > http://mail.frascone.com/mailman/listinfo/capwap > > > > > > _______________________________________________ > > Capwap mailing list > > Capwap@frascone.com > > http://mail.frascone.com/mailman/listinfo/capwap > > _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Tue Oct 04 21:58:11 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMyXr-0005K7-FV for capwap-archive@megatron.ietf.org; Tue, 04 Oct 2005 21:58:11 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21216 for ; Tue, 4 Oct 2005 21:58:08 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 7D832203E6; Tue, 4 Oct 2005 21:58:03 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from homebrew.trpz.com (66-7-225-40.cust.telepacific.net [66.7.225.40]) by mail.frascone.com (Postfix) with ESMTP id 5D8942039E for ; Tue, 4 Oct 2005 21:57:55 -0400 (EDT) Received: from trpz.com (localhost.trpz.com [127.0.0.1]) by homebrew.trpz.com (8.13.1/8.13.1) with ESMTP id j951pYE0077556; Tue, 4 Oct 2005 18:51:34 -0700 (PDT) (envelope-from dharkins@trpz.com) Message-Id: <200510050151.j951pYE0077556@homebrew.trpz.com> To: "Pat Calhoun (pacalhou)" Cc: capwap@frascone.com Subject: Re: [Capwap] Cisco IPR Statement In-Reply-To: Your message of "Sat, 01 Oct 2005 13:28:48 PDT." <4FF84B0BC277FF45AA27FE969DD956A2BEED54@xmb-sjc-235.amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <77554.1128477094.1@trpz.com> From: Dan Harkins 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-Unsubscribe: , List-Id: A list for CAPWAP technical discussions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 04 Oct 2005 18:51:34 -0700 Pat, I have been asked to clarify my previous response to your email. Please indulge me here.... You said: Cisco believe [the LWAPP IPR statement's license] is better than the traditional RAND IPR statement often used in other cases in standard organizations as what is reasonable terms is not known at the time of (according to the IETF process) last call of a document, and it is not clear the license terms, if known, will be exactly the same for all time. Yet Cisco is granting RAND terms on the IPR is claims to have that is necessary to implement CTP, WiCOP, and SLAPP, not the kind of terms it believes are better. You also said: Cisco believes anyone having IPR on a technology they bring to the IETF should let anyone implement the technology without any need for explicit license, payments and other kind of uncertainties. Yet Cisco is demanding an explicit license, payments and other kinds of uncertainties for the right to use the IPR it claims to have that is necessary to implement CTP, WiCOP, and SLAPP. Can you please explain why the actions Cisco is taking with respect to its IPR on CTP, WiCOP and SLAPP does not match its stated beliefs on IPR in the IETF? Can you also explain why the terms for Cisco's IPR on LWAPP are more favorable than the terms for Cisco's IPR on CTP, WiCOP and SLAPP? It would also be extremely helpful to the working group to know exactly what is being claimed because the changes recommended to LWAPP are in the protocols on which Cisco has given RAND terms. If the working group knows what is being claimed then we can ensure that any changes made to LWAPP will not include the technology being claimed. If you are unable to tell the working group then there is a possibility that the resulting CAPWAP protocol will have RAND terms on it because it may include the technology from SLAPP that was covered by your IPR statement of 7 September 2005. Dan. On Sat, 01 Oct 2005 13:28:48 PDT you wrote > This e-mail is in response to the requests made to Cisco regarding IPR > in CAPWAP. Cisco has always been a strong supporter of the IETF and open > standards process, and I would like to re-iterate that our goal is not > to limit, restrict, or slow down WG progress. I believe that the > language of the IPR statement, which is that Cisco is donating its > technology to the IETF (with only defensive restrictions), clearly > demonstrates that Cisco is not interested in IPR battles. > > While some have expressed concern about the LWAPP IPR statement > language, it is important to note that Cisco's IPR is not recent news. > Cisco (then Airespace) made the IETF aware of its patent application on > July 23rd, 2003. Cisco has followed all of the process and procedures of > the IETF as it relates to disclosure of IPR, as defined in section 6.4 > of RFC 3979. At this point, it is not fair to ask Cisco to disclose the > contents of the patent application because until the Patent Office > issues the said application, there are no claims worth discussing - and > therefore anything I could say on this list would be pure speculation on > my part. > > The Cisco LWAPP IPR statement says anyone can use Cisco's IPR without > any kind of explicit license as long as the implementor doesn't assert > its own IPR against Cisco. This implies no paperwork, no money, nothing > has to be transfered between Cisco and the implementor. But, if the > implementor prefers an explicit license without the suspension provision > in our IPR statement, such licenses are available from Cisco on RAND > terms. > > Cisco believe this kind of license is better than the traditional RAND > IPR statement often used in other cases in standard organizations as > what is reasonable terms is not known at the time of (according to the > IETF process) last call of a document, and it is not clear the license > terms, if known, will be exactly the same for all time. > > Because of this, Cisco believes anyone having IPR on a technology they > bring to the IETF should let anyone implement the technology without any > need for explicit license, payments and other kind of uncertainties. > But, as stated earlier, if someone doesn't agree with this, and wants an > alternative arrangement you are welcome to contact Cisco proactively for > a RAND license (and then you can be free to assert your IPR). It is up > to the implementor to choose. > > So I once more ask that the WG consider the presence of IPR as one of > many criteria in its decision process. I point you to the vast number of > IPR statements that exists against other IETF technologies, some Cisco > and some not, and regardless of the fact that IPR exists against most > technologies, there are many companies successful in the networking > space today. Further, Cisco has a clear track record, in many areas, of > not asserting its patents against IETF technologies, and of not limiting > or restricting the progress of the Internet. > > To conclude, I believe that shutting down the working group would not be > in the best interest of the Internet community, and I hope the rest of > the WG members share this sentiment. > > Pat Calhoun > CTO, Wireless Networking Business Unit > Cisco Systems > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap > _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Wed Oct 05 10:08:17 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EN9wO-0000eP-TT for capwap-archive@megatron.ietf.org; Wed, 05 Oct 2005 10:08:17 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25178 for ; Wed, 5 Oct 2005 10:08:13 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 65E11203F9; Wed, 5 Oct 2005 10:08:03 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by mail.frascone.com (Postfix) with ESMTP id 34358203F0 for ; Wed, 5 Oct 2005 10:07:50 -0400 (EDT) Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-4.cisco.com with ESMTP; 05 Oct 2005 07:07:49 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j95E7EWJ002974; Wed, 5 Oct 2005 07:07:42 -0700 (PDT) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 5 Oct 2005 07:07:44 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Capwap] CAPWAP evaluation draft complete Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2BEF77B@xmb-sjc-235.amer.cisco.com> Thread-Topic: [Capwap] CAPWAP evaluation draft complete Thread-Index: AcW/FcI2CZhyH4KQRBqFRs87raP/XgGBW4FQAQ7d+3A= From: "Pat Calhoun (pacalhou)" To: "Sadot, Emek (Emek)" , , Cc: "Mani, Mahalingam (Mahalingam)" , , X-OriginalArrivalTime: 05 Oct 2005 14:07:44.0384 (UTC) FILETIME=[28185000:01C5C9B6] 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-Unsubscribe: , List-Id: A list for CAPWAP technical discussions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 5 Oct 2005 07:07:44 -0700 Content-Transfer-Encoding: quoted-printable > 2. section 6.2. discuss the use of "C-bit" as a mean to=20 > distinguish data vs. controller messages. Although the=20 > "C-bit" satisfies the requirement, I think that 1 bit is too=20 > restrictive and allows no scalability (e.g. > segregate control vs. management, or future wireless=20 > technology, if needed). It might be advisable to follow the=20 > recommendation sprit you made in section 9.1.1 to extend the IE. >=20 I do not believe that the objectives listed here are sufficient. I believe that in order to fully support the objective, a protocol must be capable of not only identifying a control frame from a data frame, but it must also allow for either to be sent to a separate IP Address (isn't that really the reason for separation of both control/data frames?). This would address the scaling issues discussed in this objective, allowing a system to comprise of multiple separate network nodes. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Wed Oct 05 10:08:24 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EN9wW-0000ev-6P for capwap-archive@megatron.ietf.org; Wed, 05 Oct 2005 10:08:24 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25192 for ; Wed, 5 Oct 2005 10:08:20 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id F3385203FE; Wed, 5 Oct 2005 10:08:05 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by mail.frascone.com (Postfix) with ESMTP id 4943E203F7 for ; Wed, 5 Oct 2005 10:07:50 -0400 (EDT) Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-5.cisco.com with ESMTP; 05 Oct 2005 07:07:49 -0700 X-IronPort-AV: i="3.97,177,1125903600"; d="scan'208"; a="217216893:sNHT27933600" Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j95E7DvG029450; Wed, 5 Oct 2005 07:07:49 -0700 (PDT) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 5 Oct 2005 07:07:44 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Capwap] CAPWAP evaluation draft complete Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2BEF77C@xmb-sjc-235.amer.cisco.com> Thread-Topic: [Capwap] CAPWAP evaluation draft complete Thread-Index: AcW/FcI2CZhyH4KQRBqFRs87raP/XgGBW4FQAJreRm0AdBFkcA== From: "Pat Calhoun (pacalhou)" To: "Darren Loher" , "Sadot, Emek (Emek)" , , Cc: "Mani, Mahalingam (Mahalingam)" , , X-OriginalArrivalTime: 05 Oct 2005 14:07:44.0603 (UTC) FILETIME=[2839BAB0:01C5C9B6] 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-Unsubscribe: , List-Id: A list for CAPWAP technical discussions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 5 Oct 2005 07:07:44 -0700 Content-Transfer-Encoding: quoted-printable > Looking at all the proposals, it seems they all can only=20 > support NAT where the WTP is in the hidden address space=20 > without some kind of explicit compensation in the discovery=20 > process or configuration in a NAT device. I'm not sure=20 > there's really a good way around this without a much more=20 > complicated discovery or middle-box proxy mechanism that can=20 > detect and/or work around NAT. =20 Please see my other e-mail regarding NAT traversal. I would argue that any GRE based protocol is not NAT'able today without significant changes to a NAT system. PPTP uses GRE, and NAT boxes had to implement the necessary ALG to handle it. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 > -----Original Message----- > From: capwap-admin@frascone.com=20 > [mailto:capwap-admin@frascone.com] On Behalf Of Darren Loher > Sent: Sunday, October 02, 2005 1:09 PM > To: Sadot, Emek (Emek); Dorothy.Gellert@nokia.com; capwap@frascone.com > Cc: Mani, Mahalingam (Mahalingam); bwijnen@lucent.com;=20 > david.kessens@nokia.com > Subject: RE: [Capwap] CAPWAP evaluation draft complete >=20 > LWAPP can accomodate VLAN assignment on a per STA basis=20 > through it's "Add Mobile" function [LWAPP 1.7.1.1]. While=20 > it's not a hard, BSSID - VLAN mapping, I think this is=20 > actually a bit more flexible. I have seen scenarios where=20 > administrators would like to have multiple VLAN's on one=20 > SSID. This allows creation of policies on a per VLAN basis,=20 > somewhere upstream of the WTP and possible AC too, that are=20 > independant of the SSID. Often users don't know which SSID=20 > they are supposed to attach to. > =20 > Regarding the "c-bit", I agree, this would become a non-issue=20 > if control and data are encapsulated with different=20 > protocols. If you have a strong case for an additional type=20 > of data (control vs. user) that might be used, that might be=20 > useful to know. > =20 > Regarding NAT traversal support via LWAPP, we the evaluation=20 > team does note that carrying the IP address is a potential=20 > weakness. However, this is only in the control path for the=20 > purposes of configuring the location of the AC and Data=20 > termination points. =20 > =20 > =20 > -Darren >=20 > ________________________________ >=20 > From: capwap-admin@frascone.com on behalf of Sadot, Emek (Emek) > Sent: Thu 9/29/2005 11:54 AM > To: Dorothy.Gellert@nokia.com; capwap@frascone.com > Cc: Mani, Mahalingam (Mahalingam); bwijnen@lucent.com;=20 > david.kessens@nokia.com > Subject: RE: [Capwap] CAPWAP evaluation draft complete >=20 >=20 >=20 > Thanks, Darren and company, for the thorough evaluation work. > I have a few observation I'd like to pass along: >=20 > 1. section 6.1. talks about setting logical groups, and SSID=20 > in particular. I believe the message should be extended to=20 > include VLAN (per Saravanan note in a different email chain),=20 > that's for the case where DS is implemented at the WTP. >=20 > 2. section 6.2. discuss the use of "C-bit" as a mean to=20 > distinguish data vs. controller messages. Although the=20 > "C-bit" satisfies the requirement, I think that 1 bit is too=20 > restrictive and allows no scalability (e.g. > segregate control vs. management, or future wireless=20 > technology, if needed). It might be advisable to follow the=20 > recommendation sprit you made in section 9.1.1 to extend the IE. >=20 > 3. section 6.14. approves NAT traversal objective, however I=20 > would challenge LWAPP in this case as it carries the IP=20 > address in the payload. Although NAT devices can be=20 > statically configured, I would vote against taking such=20 > approach, and a prove would be the need for an ALGs for each=20 > protocol that carries IP address in body message. > I would think that adding a recommendation to avoid embedded=20 > IP address in control messages would be advisable. > In addition it would improve the protocol "readiness" for IPv6. >=20 > Regards, > Emek >=20 > -----Original Message----- > From: capwap-admin@frascone.com=20 > [mailto:capwap-admin@frascone.com] On Behalf Of=20 > Dorothy.Gellert@nokia.com > Sent: Wednesday, September 21, 2005 9:34 PM > To: capwap@frascone.com > Cc: Mani, Mahalingam (Mahalingam); bwijnen@lucent.com;=20 > david.kessens@nokia.com; Dorothy.Gellert@nokia.com > Subject: [Capwap] CAPWAP evaluation draft complete >=20 >=20 > After much hard work, the evaluation team has completed the=20 > CAPWAP evaluation draft. Its is available for review at: > http://www.ietf.org/internet-drafts/draft-ietf-capwap-eval-00. > txt and also in the internet drafts directory. >=20 > The evaluation team concluded that LWAPP is the most complete=20 > proposal and should be used as the basis for CAPWAP protocol=20 > moving forward. In addition, a number of recommendations=20 > were made which the evaluation team believed should be=20 > addressed by the working group. >=20 > Over the next 2 weeks the evaluation team will address clarification > questions on the WG list. The recommendation provided by the > evaluation team will not change, as this was intended to be an > independent activity supported by the WG. This is essentially a WGLC > on the evaluation draft. Please submit any clarification=20 > question to the list by Friday, September 30th. >=20 > The next step will be to come to an agreement on the WG list=20 > to decide to accept the recommended protocol. Once we have=20 > established consensus, we can further discuss the additional=20 > recommendations presented in the draft. >=20 > We would like to thank the evaluation team on its thorough=20 > work and a job well done. >=20 > Regards, > Dorothy and Mani >=20 >=20 > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap >=20 > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap >=20 >=20 > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap >=20 _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Wed Oct 05 10:08:41 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EN9wj-0000nP-HM for capwap-archive@megatron.ietf.org; Wed, 05 Oct 2005 10:08:41 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25211 for ; Wed, 5 Oct 2005 10:08:34 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 0EB7220402; Wed, 5 Oct 2005 10:08:09 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by mail.frascone.com (Postfix) with ESMTP id 025CB203F9 for ; Wed, 5 Oct 2005 10:07:51 -0400 (EDT) Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-4.cisco.com with ESMTP; 05 Oct 2005 07:07:50 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j95E7JvE029469; Wed, 5 Oct 2005 07:07:49 -0700 (PDT) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 5 Oct 2005 07:07:44 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Capwap] Change Request 9.1.3.1. Support for Local MAC User Data Tunneling Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2BEF77D@xmb-sjc-235.amer.cisco.com> Thread-Topic: [Capwap] Change Request 9.1.3.1. Support for Local MAC User Data Tunneling Thread-Index: AcXH10jTw1pbjM2mQ0+ZjpEEpGIawABgAXaA From: "Pat Calhoun (pacalhou)" To: "zhaoyujin 00919" Cc: X-OriginalArrivalTime: 05 Oct 2005 14:07:44.0822 (UTC) FILETIME=[285B2560:01C5C9B6] 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-Unsubscribe: , List-Id: A list for CAPWAP technical discussions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 5 Oct 2005 07:07:44 -0700 Content-Transfer-Encoding: quoted-printable > Like above, CAPWAP can defined "local-local mac". All=20 > 802.11 frame is terminated on WTP. If there need=20 > communication between AC and AP, the LWAPP cotrol message can be used. Sure, that would be one approach, but it really seems unnecessary complex as we already have a mechanism to exchange this information. What you are proposing is for the WTP to translate the association request to some new control protocol - seems like a lot of work with no specific gain. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 > -----Original Message----- > From: zhaoyujin 00919 [mailto:zhaoyujin@huawei-3com.com]=20 > Sent: Sunday, October 02, 2005 9:58 PM > To: Pat Calhoun (pacalhou) > Cc: capwap@frascone.com > Subject: RE: [Capwap] Change Request 9.1.3.1. Support for=20 > Local MAC User Data Tunneling >=20 > Hi: >=20 > Can we use the "add mobile frame" to notify AC create the=20 > usage information? >=20 >=20 > Best regards > Michael >=20 >=20 > > Emek, > >=20 > > In option 3, when a user associates with the WTP, the=20 > association is=20 > > handled locally, but the packet is tunneled to the AC in=20 > order for the=20 > > AC to have access to usage information (and make overriding policy=20 > > decisions). So 802.11 needs to be supported on the AC regardless,=20 > > right? > >=20 > > Pat Calhoun > > CTO, Wireless Networking Business Unit Cisco Systems > >=20 > >=20 > >=20 > >=20 > > ________________________________ > >=20 > > From: Sadot, Emek (Emek) [esadot@avaya.com]=20 > > Sent: Friday, September 30, 2005 10:16 AM > > To: Pat Calhoun (pacalhou); capwap@frascone.com > > Subject: RE: [Capwap] Change Request 9.1.3.1. Support=20 > for Local MAC=20 > > User Data Tunneling > > =09 > > =09 > > Regarding the points you raised I believe option #2 and=20 > #3 share the=20 > > same qualities. > > In both options 802.11 encryption and 11e cannot be=20 > implemented at=20 > > the AC. > > In both options a mechanism shall be design to extract RF and=20 > > data-traffic statistics either (a) appended in the=20 > tunneling (option=20 > > #3 > > only) or (b) exposed by the WTP as read-only values for the AC=20 > > inquiries(both options). > > =20 > > Am I missing something? > > =20 > > On the other hand one can respect the unique merits that these=20 > > options offer: > > - option 2: non-appliance product. meaning a software=20 > based AC that=20 > > can be executed on any server / platform. > > - option 3: avoid parse 802.11 traffic in silicon at the AC. > > Leverage existing products (e.g. routers) with "only" add-on > > 802.11 code > > running at the Cpu. > > =20 > > Emek > >=20 > > ________________________________ > >=20 > > From: Pat Calhoun (pacalhou) [pcalhoun@cisco.com]=20 > > Sent: Thursday, September 29, 2005 6:01 PM > > To: Sadot, Emek (Emek); capwap@frascone.com > > Subject: RE: [Capwap] Change Request 9.1.3.1. Support=20 > for Local MAC=20 > > User Data Tunneling > > =09 > > =09 > > In terms of option 2, no traffic is sent to the AC, so=20 > the model is=20 > > quite different. > > =20 > >=20 > > Pat Calhoun > > CTO, Wireless Networking Business Unit > > Cisco Systems > >=20 > > =20 > >=20 > >=20 > > ________________________________ > >=20 > > From: Sadot, Emek (Emek) [esadot@avaya.com]=20 > > Sent: Thursday, September 29, 2005 2:16 PM > > To: Pat Calhoun (pacalhou); capwap@frascone.com > > Subject: RE: [Capwap] Change Request 9.1.3.1.=20 > Support for=20 > > Local MAC User Data Tunneling > > =09 > > =09 > > Pat, you certainly raise valid questions w.r.t.=20 > option #3,=20 > > however I am curious as to the differences between the=20 > challenges you=20 > > listed between options #2 and #3. In other words, in what=20 > sense option=20 > > #2 and #3 are differ w.r.t. encryption and 11e at the AC,=20 > as well as=20 > > RSSI/SNR/data-rate/other monitoring support? > > =20 > > Regards, > > Emek > > =20 > > ________________________________ > >=20 > > From: capwap-admin@frascone.com=20 > [capwap-admin@frascone.com] On=20 > > Behalf Of Pat Calhoun (pacalhou) > > Sent: Wednesday, September 28, 2005 5:32 PM > > To: capwap@frascone.com > > Subject: [Capwap] Change Request 9.1.3.1.=20 > Support for Local=20 > > MAC User Data Tunneling > > =09 > > =09 > > This change request is to allow for 802.3=20 > tunneling of user=20 > > data in local bridging mode. I believe that the changes should be=20 > > relatively straightforward, but do introduce an interesting set of=20 > > complications that need to be evaluated and agreed upon as a group. > > =20 > > The LWAPP protocol currently allows for 802.11=20 > tunneling in=20 > > Split-MAC mode, allowing for such things as centralized=20 > encryption of=20 > > user data frames. However, the current definition of the=20 > protocol is=20 > > that when running in Local-MAC mode, no traffic is tunneled to the=20 > > controller. > > =20 > > If we were to introduce this change, the LWAPP=20 > protocol would=20 > > have three modes of operation: > > 1. Split-MAC: Tunnel native MAC frames in UDP (e.g., > > 802.11) > > 2. Local-MAC w/ Local Bridge: Do not tunnel 802.3 frames > > 3. Local-MAC w/ Tunnel: Tunnel 802.3 frames in UDP > > =20 > > The issue that we need to decide as a group is=20 > whether we=20 > > really want a protocol that has three modes of operation,=20 > and if so,=20 > > which one is mandatory. The evaluation draft states that=20 > option 3 is=20 > > useful for support of non 802.11 technologies, but this=20 > introduces a=20 > > set of restrictions. For instance, today the LWAPP protocol=20 > allows for=20 > > centralized control of various 802.11 functions, including=20 > encryption=20 > > and 802.11e. This function is not possible with option 3, and=20 > > thereforeany new technology that assumes this option would=20 > not be able=20 > > to provide centralization of data frame functions. > > =20 > > There is a comment in the recommendation that=20 > LWAPP could=20 > > retain the RSSI/SNR fields, and then perform 802.3=20 > > encapsulation,allowing the AC to have more visibility.=20 > However, I have=20 > > had some requests to expand these fields to also include the data=20 > > rate. > > Further,there are possible fields in the header (of technologies we=20 > > know nothing > > about) that the WTP may want to extract and expose to the=20 > AC - and how=20 > > could this be done with 802.3? > >=20 > > Pat Calhoun > > CTO, Wireless Networking Business Unit > > Cisco Systems > >=20 > > =20 > >=20 > >=20 >=20 _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Wed Oct 05 10:08:46 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EN9ws-0000pq-6f for capwap-archive@megatron.ietf.org; Wed, 05 Oct 2005 10:08:46 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25224 for ; Wed, 5 Oct 2005 10:08:43 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id CC4A62041F; Wed, 5 Oct 2005 10:08:11 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by mail.frascone.com (Postfix) with ESMTP id DBB3E203F0 for ; Wed, 5 Oct 2005 10:07:52 -0400 (EDT) Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-4.cisco.com with ESMTP; 05 Oct 2005 07:07:52 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j95E7EWL002974; Wed, 5 Oct 2005 07:07:44 -0700 (PDT) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 5 Oct 2005 07:07:45 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Capwap] Conflict about Local MAC Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2BEF77F@xmb-sjc-235.amer.cisco.com> Thread-Topic: [Capwap] Conflict about Local MAC Thread-Index: AcXH8Ts+RWNh6OHnTzqeV6AWKXFZ0wBZsDmg From: "Pat Calhoun (pacalhou)" To: "zhaoyujin 00919" , X-OriginalArrivalTime: 05 Oct 2005 14:07:45.0259 (UTC) FILETIME=[289DD3B0:01C5C9B6] 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-Unsubscribe: , List-Id: A list for CAPWAP technical discussions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 5 Oct 2005 07:07:44 -0700 Content-Transfer-Encoding: quoted-printable Unless I am misunderstanding your question Michael, the association between the AP and the AC is simply the 802.11 MAC management (re)association frame, encapsulated in LWAPP. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 > -----Original Message----- > From: capwap-admin@frascone.com=20 > [mailto:capwap-admin@frascone.com] On Behalf Of zhaoyujin 00919 > Sent: Monday, October 03, 2005 12:02 AM > To: capwap@frascone.com > Subject: [Capwap] Conflict about Local MAC >=20 > Hi all: >=20 > In rfc4118.txt, Section 5.3 "Local MAC" gives examples=20 > (Figure 7) which all 802.11 mgmt are termianted by WTP. And=20 > in Figure 9, 80 percent vendors realize the association process on AC. >=20 > Figure 5 in "draft-ohara-capwap-lwapp-03" section=20 > 11.1.2 "Local MAC" depicts the "Assoc / Disassoc / Reassoc"=20 > processes on WTP. >=20 > Otherwise the description in "Figure 6: Local MAC=20 > Message Flow" is conflict with the above description. >=20 > Next is the description: > "The WTP forwards the 802.11 Authentication and Association=20 > frames to the AC, which is responsible for responding to the client." > And the Figure 6: > Client WTP =20 > AC > 802.11 Association > <---------------------------( -=20 > )-------------------------> >=20 > But the LWAPP protocol does not defined the message for=20 > association between AP and AC. >=20 > I think there may need some change. >=20 >=20 > Best Regards. > Michael >=20 >=20 >=20 > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap >=20 _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Wed Oct 05 10:09:11 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EN9xC-000162-4z for capwap-archive@megatron.ietf.org; Wed, 05 Oct 2005 10:09:11 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25250 for ; Wed, 5 Oct 2005 10:09:00 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 87F1C20432; Wed, 5 Oct 2005 10:08:14 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by mail.frascone.com (Postfix) with ESMTP id 09A59203FB for ; Wed, 5 Oct 2005 10:07:51 -0400 (EDT) Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-4.cisco.com with ESMTP; 05 Oct 2005 07:07:51 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j95E7LWH002993; Wed, 5 Oct 2005 07:07:43 -0700 (PDT) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 5 Oct 2005 07:07:45 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Capwap] Change Request 9.1.2 (Control Channel Security) Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2BEF77E@xmb-sjc-235.amer.cisco.com> Thread-Topic: [Capwap] Change Request 9.1.2 (Control Channel Security) Thread-Index: AcXFDjTnnPGF/FsVQz2OGJkJEIEZRgCdtv2bAHSbgEA= From: "Pat Calhoun (pacalhou)" To: "Darren Loher" , "James Kempf" , "Dan Harkins" Cc: X-OriginalArrivalTime: 05 Oct 2005 14:07:45.0040 (UTC) FILETIME=[287C6900:01C5C9B6] 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-Unsubscribe: , List-Id: A list for CAPWAP technical discussions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 5 Oct 2005 07:07:44 -0700 Content-Transfer-Encoding: quoted-printable I think you meant PTK/GTK, but I was just making an observation that the use of IPSec to carry keys was considered suspicious by NIST. I see a parallel here in our proposed direction. I will follow what the WG feels is right, I was just making sure folks had additional info I thought was useful. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 > -----Original Message----- > From: Darren Loher [mailto:DLoher@rovingplanet.com]=20 > Sent: Sunday, October 02, 2005 12:17 PM > To: James Kempf; Pat Calhoun (pacalhou); Dan Harkins > Cc: capwap@frascone.com > Subject: RE: [Capwap] Change Request 9.1.2 (Control Channel Security)=20 >=20 > Regarding secure distribtion of PMK/GMK between AC and WTP,=20 > it is mandatory that these attributes are sent over the=20 > secured control channel. So we should be covered on the AC=20 > <-> WTP communication. > =20 > Isn't the transmission of RADIUS attributes an issue between=20 > the AC and a AAA server and therefore outside the scope of CAPWAP? =20 > =20 > -Darren >=20 > ________________________________ >=20 > From: capwap-admin@frascone.com on behalf of James Kempf > Sent: Thu 9/29/2005 9:54 AM > To: Pat Calhoun (pacalhou); Dan Harkins > Cc: capwap@frascone.com > Subject: Re: [Capwap] Change Request 9.1.2 (Control Channel Security)=20 >=20 >=20 >=20 > I agree with Dan. I think the risk from doing DTLS=20 > post-discovery is minimal. >=20 > Security protocols have a history of bugs turning up after=20 > some years of deployment. An added benefit of using DTLS is=20 > that LWAPP benefits from the attention given to DTLS by users=20 > of other protocols, so any bugs will most likely be found=20 > more quickly than if LWAPP designs its own, specialized protocol. >=20 > Regarding IPsec v.s. DTLS v.s. encryption of the Radius=20 > attribute for PMK distribution, I don't have any real opinion=20 > on this. Actually, I think I would prefer to leave this as a=20 > deployment option, with appropriate text in the Security=20 > Considerations section about the requirement to use one of=20 > these method, and the methods are described. I realize that=20 > there is an interoperability concern here, but I can imagine=20 > cases where a network operator might prefer one method over=20 > another due to their existing deployment. As Dan mentioned,=20 > the concerns expressed about using IPsec related to=20 > particular implementation issues rather than any fundamental=20 > architectural or design issue with the protocol. But I don't=20 > have a real strong opinion on this, and I can think of=20 > reasons why it might be a good idea to include a particular=20 > "required to implement" method too. >=20 >=20 > jak >=20 >=20 >=20 > ----- Original Message ----- > From: "Dan Harkins" > To: "Pat Calhoun (pacalhou)" > Cc: > Sent: Wednesday, September 28, 2005 3:16 PM > Subject: Re: [Capwap] Change Request 9.1.2 (Control Channel Security) >=20 >=20 > > Pat, > > > > I agree that the information in the discovery phase is=20 > benign. Also,=20 > > anything an attacker could do to at that point is the same=20 > as what an=20 > > attacker could do during the DTLS "hello" exchange-- modify=20 > packets in=20 > > flight, redirect packets-- and the result would be the same: an=20 > > unsuccessful DTLS exchange or unsuccessful discovery. An attacker=20 > > could deny service-- prevent a successful DTLS exchange or=20 > successful=20 > > discovery of AC-- but any middlebox can start dropping packets on a=20 > > whim and do the same thing. I don't believe there is a=20 > possibility of=20 > > a resource exhaustion attack or launch a man-in-the-middle attack=20 > > against the AC or WTP. > > > > I don't think we really need to worry about doing DTLS=20 > post-discovery. > > > > To address your call for wider WG response to this recommendation: > > I strongly believe that (D)TLS should be used for the key=20 > exchange and=20 > > authentication protocol. > > > > My understanding on the reason that NIST preferred=20 > AES-KeyWrap over=20 > > IPsec for the transporting of PMKs had nothing to do with any=20 > > preceived weakness in IPsec. It was because there is nothing in the=20 > > IPsec standard to allow a user-space app-- like a RADIUS=20 > client-- to=20 > > know whether the packets it is sending are in the clear or=20 > are IPsec-=20 > > protected. Therefore a mis-configuration could result in PMKs being=20 > > sent over-the-wire in-the-clear. (There are IPsec=20 > implementations that=20 > > do allow for such queries of the SADB but that isn't part=20 > of the IPsec=20 > > standard and therefore there isn't a guarantee that such a=20 > capability=20 > > will be available everywhere). Putting the security for passing the=20 > > PMKs directly into the RADIUS app-- i.e. using=20 > AES-KeyWrap-- addresses=20 > > that concern. Therefore I don't believe NIST would have a problem=20 > > sending PTKs down a (D)TLS-protected link because the app that is=20 > > sending and receiving them knows whether that link is=20 > protected or not. > > > > Dan. > > > > On Wed, 28 Sep 2005 14:32:16 PDT you wrote > >> The evaluation team has made a request to modify LWAPP's built-in=20 > >> security mechanism with DTLS instead. This specific change=20 > is tricky=20 > >> as we first need to identify whether the DTLS session should be=20 > >> created prior to, or post, the discovery phase. > >> > >> Here are my high level thoughts on the issue: > >> 1. Pre-Discovery DTLS. > >> > >> One of the LWAPP features is load balancing of WTPs among=20 > ACs. This=20 > >> load balancing can occur within, or across multiple, ACs. How this=20 > >> works is that a WTP would perform the discovery phase by=20 > initiating a=20 > >> Discovery Request packet to one or more ACs. The receiving ACs=20 > >> respond with a Discovery Response, which also includes the total=20 > >> number of WTPs supported (see section 5.2.2), as well as=20 > its current=20 > >> WTP load (see section 5.2.3). The WTP collects all of the=20 > Discovery=20 > >> Responses, and then decides which AC it wishes to connect=20 > to based on=20 > >> its policy. The policy can be either least loaded AC, or through a=20 > >> list of preferred ACs (see section 7.2.3). Further, the=20 > WTP can opt=20 > >> to not establish a session with the AC if it determines=20 > that it does=20 > >> not have the basic capabilities required by the AC. > >> > >> Performing DTLS prior to the Discovery Request would mean that the=20 > >> WTP would mean one of two things: > >> a. The WTP establishes a DTLS session with every AC it=20 > knows about.=20 > >> The side effect here is the LWAPP connect time on the WTP, not to=20 > >> mention the CPU load imposed on the AC. > >> b. The LWAPP protocol eliminates this feature altogether.=20 > This means=20 > >> that a WTP would only connect to the AC of its choice,=20 > regardless of=20 > >> the AC's current load of configuration. > >> > >> 2. Post-Discovery DTLS. In this mode, the above limitations are=20 > >> removed, and the Discovery phase is done in the clear. While it is=20 > >> true that this raises some security concerns, the=20 > information in the=20 > >> Discovery Response is relatively benign, and therefore any=20 > malicious=20 > >> tweaking (or altering) of the response packet has created limited=20 > >> damage (although the WG needs to evaluate this, but it was=20 > not found=20 > >> to be problematic during the security review). > >> > >> This change would also require that the the Discovery packets be=20 > >> exchanged on a separate UDP port, which is not a big change to the=20 > >> protocol. > >> > >> while I understand the evaluation team's recommendation to adopt=20 > >> DTLS, I would also like to get a larger WG rough consensus=20 > on whether=20 > >> we feel that this change should be made. While I will make=20 > the change=20 > >> based on rough consensus, I want to make sure that we=20 > think and agree=20 > >> on this decision through as a group. I understand the=20 > concerns raised=20 > >> about increasing the time of the protocol development=20 > phase in having=20 > >> our own security approach, there are strategies that can=20 > be done to=20 > >> help us. For instance, initiate another security review=20 > with another=20 > >> reviewer identified by Russ Housely asap (he did recommend=20 > Charles Clancy, btw). > >> > >> I think that another important point here is that during a recent=20 > >> meeting with NIST, we discussed the transport of 802.11i=20 > PMKs within=20 > >> the RADIUS protocol. During this discussion, we proposed=20 > two methods.=20 > >> The first would explicitely encrypt the PMK using=20 > AES-KeyWrap within=20 > >> a RADIUS attribute. The second approach was simply to encrypt the=20 > >> whole RADIUS transaction with IPSec. It was NIST's opinion at that=20 > >> time that they felt comfortable with option one, while option two=20 > >> would require them to evaluate whether IPSec would be=20 > appropriate for=20 > >> the transport of PMKs. Given that CAPWAP has a requirement=20 > to allow=20 > >> the WTP to perform encryption, this means that PTKs (and=20 > GTKs) would=20 > >> have to be transported over a DTLS session, and therefore I wonder=20 > >> whether we would have similar issues as those mentioned above. If=20 > >> this were an issue, then FIPS certification of any CAPWAP=20 > based system could become impossible. > >> > >> Your comments are appreciated, > >> > >> Pat Calhoun > >> CTO, Wireless Networking Business Unit Cisco Systems=20 > >> _______________________________________________ > >> Capwap mailing list > >> Capwap@frascone.com > >> http://mail.frascone.com/mailman/listinfo/capwap > >> > > _______________________________________________ > > Capwap mailing list > > Capwap@frascone.com > > http://mail.frascone.com/mailman/listinfo/capwap > > >=20 >=20 > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap >=20 _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Wed Oct 05 10:37:23 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENAOY-0002ZA-QK for capwap-archive@megatron.ietf.org; Wed, 05 Oct 2005 10:37:23 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27813 for ; Wed, 5 Oct 2005 10:37:13 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 2614620403; Wed, 5 Oct 2005 10:37:04 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from smtp4.centerbeam.com (smtp4.centerbeam.com [63.120.115.248]) by mail.frascone.com (Postfix) with ESMTP id BB2E5203FB for ; Wed, 5 Oct 2005 10:36:34 -0400 (EDT) Received: from cba0e2k00.CBA0.centerbeam.com ([64.95.101.25]) by smtp4.centerbeam.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 5 Oct 2005 07:41:20 -0700 Received: from CBA0E2K06.CBA0.centerbeam.com ([64.95.101.40]) by cba0e2k00.CBA0.centerbeam.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 5 Oct 2005 07:36:27 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Capwap] Change Request 9.1.2 (Control Channel Security) Message-ID: Thread-Topic: [Capwap] Change Request 9.1.2 (Control Channel Security) Thread-Index: AcXFDjTnnPGF/FsVQz2OGJkJEIEZRgCdtv2bAHSbgEAAGHYUEA== From: "Darren Loher" To: "Pat Calhoun (pacalhou)" , "James Kempf" , "Dan Harkins" Cc: X-OriginalArrivalTime: 05 Oct 2005 14:36:27.0685 (UTC) FILETIME=[2B432D50:01C5C9BA] 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-Unsubscribe: , List-Id: A list for CAPWAP technical discussions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 5 Oct 2005 07:36:23 -0700 Content-Transfer-Encoding: quoted-printable I think the main difference between NIST's concern and our scenario is the following: As Pat relayed to us in the RADIUS with IPSec case, there is no way for RADIUS to really know it's using IPSec and therefore does not know if it's transport is secure or not. =20 In the CAPWAP/LWAPP case the control channel is guaranteed to be secure, so it's okay to carry to PTK/GTK within the control channel. So within the context of CAPWAP, there is implicit knowledge that transient keys are using secure transport. -Darren > -----Original Message----- > From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com] > Sent: Wednesday, October 05, 2005 8:08 AM > To: Darren Loher; James Kempf; Dan Harkins > Cc: capwap@frascone.com > Subject: RE: [Capwap] Change Request 9.1.2 (Control Channel Security) >=20 > I think you meant PTK/GTK, but I was just making an observation that the > use of IPSec to carry keys was considered suspicious by NIST. I see a > parallel here in our proposed direction. >=20 > I will follow what the WG feels is right, I was just making sure folks > had additional info I thought was useful. >=20 > Pat Calhoun > CTO, Wireless Networking Business Unit > Cisco Systems >=20 >=20 >=20 > > -----Original Message----- > > From: Darren Loher [mailto:DLoher@rovingplanet.com] > > Sent: Sunday, October 02, 2005 12:17 PM > > To: James Kempf; Pat Calhoun (pacalhou); Dan Harkins > > Cc: capwap@frascone.com > > Subject: RE: [Capwap] Change Request 9.1.2 (Control Channel Security) > > > > Regarding secure distribtion of PMK/GMK between AC and WTP, > > it is mandatory that these attributes are sent over the > > secured control channel. So we should be covered on the AC > > <-> WTP communication. > > > > Isn't the transmission of RADIUS attributes an issue between > > the AC and a AAA server and therefore outside the scope of CAPWAP? > > > > -Darren > > > > ________________________________ > > > > From: capwap-admin@frascone.com on behalf of James Kempf > > Sent: Thu 9/29/2005 9:54 AM > > To: Pat Calhoun (pacalhou); Dan Harkins > > Cc: capwap@frascone.com > > Subject: Re: [Capwap] Change Request 9.1.2 (Control Channel Security) > > > > > > > > I agree with Dan. I think the risk from doing DTLS > > post-discovery is minimal. > > > > Security protocols have a history of bugs turning up after > > some years of deployment. An added benefit of using DTLS is > > that LWAPP benefits from the attention given to DTLS by users > > of other protocols, so any bugs will most likely be found > > more quickly than if LWAPP designs its own, specialized protocol. > > > > Regarding IPsec v.s. DTLS v.s. encryption of the Radius > > attribute for PMK distribution, I don't have any real opinion > > on this. Actually, I think I would prefer to leave this as a > > deployment option, with appropriate text in the Security > > Considerations section about the requirement to use one of > > these method, and the methods are described. I realize that > > there is an interoperability concern here, but I can imagine > > cases where a network operator might prefer one method over > > another due to their existing deployment. As Dan mentioned, > > the concerns expressed about using IPsec related to > > particular implementation issues rather than any fundamental > > architectural or design issue with the protocol. But I don't > > have a real strong opinion on this, and I can think of > > reasons why it might be a good idea to include a particular > > "required to implement" method too. > > > > > > jak > > > > > > > > ----- Original Message ----- > > From: "Dan Harkins" > > To: "Pat Calhoun (pacalhou)" > > Cc: > > Sent: Wednesday, September 28, 2005 3:16 PM > > Subject: Re: [Capwap] Change Request 9.1.2 (Control Channel Security) > > > > > > > Pat, > > > > > > I agree that the information in the discovery phase is > > benign. Also, > > > anything an attacker could do to at that point is the same > > as what an > > > attacker could do during the DTLS "hello" exchange-- modify > > packets in > > > flight, redirect packets-- and the result would be the same: an > > > unsuccessful DTLS exchange or unsuccessful discovery. An attacker > > > could deny service-- prevent a successful DTLS exchange or > > successful > > > discovery of AC-- but any middlebox can start dropping packets on a > > > whim and do the same thing. I don't believe there is a > > possibility of > > > a resource exhaustion attack or launch a man-in-the-middle attack > > > against the AC or WTP. > > > > > > I don't think we really need to worry about doing DTLS > > post-discovery. > > > > > > To address your call for wider WG response to this recommendation: > > > I strongly believe that (D)TLS should be used for the key > > exchange and > > > authentication protocol. > > > > > > My understanding on the reason that NIST preferred > > AES-KeyWrap over > > > IPsec for the transporting of PMKs had nothing to do with any > > > preceived weakness in IPsec. It was because there is nothing in the > > > IPsec standard to allow a user-space app-- like a RADIUS > > client-- to > > > know whether the packets it is sending are in the clear or > > are IPsec- > > > protected. Therefore a mis-configuration could result in PMKs being > > > sent over-the-wire in-the-clear. (There are IPsec > > implementations that > > > do allow for such queries of the SADB but that isn't part > > of the IPsec > > > standard and therefore there isn't a guarantee that such a > > capability > > > will be available everywhere). Putting the security for passing the > > > PMKs directly into the RADIUS app-- i.e. using > > AES-KeyWrap-- addresses > > > that concern. Therefore I don't believe NIST would have a problem > > > sending PTKs down a (D)TLS-protected link because the app that is > > > sending and receiving them knows whether that link is > > protected or not. > > > > > > Dan. > > > > > > On Wed, 28 Sep 2005 14:32:16 PDT you wrote > > >> The evaluation team has made a request to modify LWAPP's built-in > > >> security mechanism with DTLS instead. This specific change > > is tricky > > >> as we first need to identify whether the DTLS session should be > > >> created prior to, or post, the discovery phase. > > >> > > >> Here are my high level thoughts on the issue: > > >> 1. Pre-Discovery DTLS. > > >> > > >> One of the LWAPP features is load balancing of WTPs among > > ACs. This > > >> load balancing can occur within, or across multiple, ACs. How this > > >> works is that a WTP would perform the discovery phase by > > initiating a > > >> Discovery Request packet to one or more ACs. The receiving ACs > > >> respond with a Discovery Response, which also includes the total > > >> number of WTPs supported (see section 5.2.2), as well as > > its current > > >> WTP load (see section 5.2.3). The WTP collects all of the > > Discovery > > >> Responses, and then decides which AC it wishes to connect > > to based on > > >> its policy. The policy can be either least loaded AC, or through a > > >> list of preferred ACs (see section 7.2.3). Further, the > > WTP can opt > > >> to not establish a session with the AC if it determines > > that it does > > >> not have the basic capabilities required by the AC. > > >> > > >> Performing DTLS prior to the Discovery Request would mean that the > > >> WTP would mean one of two things: > > >> a. The WTP establishes a DTLS session with every AC it > > knows about. > > >> The side effect here is the LWAPP connect time on the WTP, not to > > >> mention the CPU load imposed on the AC. > > >> b. The LWAPP protocol eliminates this feature altogether. > > This means > > >> that a WTP would only connect to the AC of its choice, > > regardless of > > >> the AC's current load of configuration. > > >> > > >> 2. Post-Discovery DTLS. In this mode, the above limitations are > > >> removed, and the Discovery phase is done in the clear. While it is > > >> true that this raises some security concerns, the > > information in the > > >> Discovery Response is relatively benign, and therefore any > > malicious > > >> tweaking (or altering) of the response packet has created limited > > >> damage (although the WG needs to evaluate this, but it was > > not found > > >> to be problematic during the security review). > > >> > > >> This change would also require that the the Discovery packets be > > >> exchanged on a separate UDP port, which is not a big change to the > > >> protocol. > > >> > > >> while I understand the evaluation team's recommendation to adopt > > >> DTLS, I would also like to get a larger WG rough consensus > > on whether > > >> we feel that this change should be made. While I will make > > the change > > >> based on rough consensus, I want to make sure that we > > think and agree > > >> on this decision through as a group. I understand the > > concerns raised > > >> about increasing the time of the protocol development > > phase in having > > >> our own security approach, there are strategies that can > > be done to > > >> help us. For instance, initiate another security review > > with another > > >> reviewer identified by Russ Housely asap (he did recommend > > Charles Clancy, btw). > > >> > > >> I think that another important point here is that during a recent > > >> meeting with NIST, we discussed the transport of 802.11i > > PMKs within > > >> the RADIUS protocol. During this discussion, we proposed > > two methods. > > >> The first would explicitely encrypt the PMK using > > AES-KeyWrap within > > >> a RADIUS attribute. The second approach was simply to encrypt the > > >> whole RADIUS transaction with IPSec. It was NIST's opinion at that > > >> time that they felt comfortable with option one, while option two > > >> would require them to evaluate whether IPSec would be > > appropriate for > > >> the transport of PMKs. Given that CAPWAP has a requirement > > to allow > > >> the WTP to perform encryption, this means that PTKs (and > > GTKs) would > > >> have to be transported over a DTLS session, and therefore I wonder > > >> whether we would have similar issues as those mentioned above. If > > >> this were an issue, then FIPS certification of any CAPWAP > > based system could become impossible. > > >> > > >> Your comments are appreciated, > > >> > > >> Pat Calhoun > > >> CTO, Wireless Networking Business Unit Cisco Systems > > >> _______________________________________________ > > >> Capwap mailing list > > >> Capwap@frascone.com > > >> http://mail.frascone.com/mailman/listinfo/capwap > > >> > > > _______________________________________________ > > > Capwap mailing list > > > Capwap@frascone.com > > > http://mail.frascone.com/mailman/listinfo/capwap > > > > > > > > > _______________________________________________ > > Capwap mailing list > > Capwap@frascone.com > > http://mail.frascone.com/mailman/listinfo/capwap > > _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Wed Oct 05 14:36:25 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENE7r-0003KJ-FV for capwap-archive@megatron.ietf.org; Wed, 05 Oct 2005 14:36:25 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08768 for ; Wed, 5 Oct 2005 14:36:17 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 98A4020440; Wed, 5 Oct 2005 14:36:03 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from sj-iport-1.cisco.com (sj-iport-1-in.cisco.com [171.71.176.70]) by mail.frascone.com (Postfix) with ESMTP id AFFCE203FE for ; Wed, 5 Oct 2005 14:35:44 -0400 (EDT) Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-1.cisco.com with ESMTP; 05 Oct 2005 11:35:43 -0700 X-IronPort-AV: i="3.97,178,1125903600"; d="scan'208"; a="663711432:sNHT43919176" Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j95IZcKE024798; Wed, 5 Oct 2005 11:35:40 -0700 (PDT) Received: from xmb-sjc-222.amer.cisco.com ([128.107.191.106]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 5 Oct 2005 11:35:40 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Capwap] Change Request 9.1.2 (Control Channel Security) Message-ID: <08A9A3213527A6428774900A80DBD8D8BB821E@xmb-sjc-222.amer.cisco.com> Thread-Topic: [Capwap] Change Request 9.1.2 (Control Channel Security) Thread-Index: AcXFDjTnnPGF/FsVQz2OGJkJEIEZRgCdtv2bAHSbgEAAGHYUEAAIDskQ From: "Nancy Winget (ncamwing)" To: "Darren Loher" , "Pat Calhoun (pacalhou)" , "James Kempf" , "Dan Harkins" Cc: X-OriginalArrivalTime: 05 Oct 2005 18:35:40.0335 (UTC) FILETIME=[961BC3F0:01C5C9DB] 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-Unsubscribe: , List-Id: A list for CAPWAP technical discussions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 5 Oct 2005 11:35:39 -0700 Content-Transfer-Encoding: quoted-printable NIST's concern is that care and (re)review is taken when security protocols that were designed for one application are applied to another. In the case of RADIUS, NIST pointed out that both RADIUS and IPSec were complex enough that it was not clearly obvious to them how the use of IPSec would address the key transport security....nor has there been any security analysis to demonstrate what security properties and vulnerabilities IPSec provides when used with RADIUS. As for CAPWAP/LWAPP, it seems that the LWAPP protocol has already undergone security review and has been shown to meet this group's security requirements. So, how does DTLS improve upon the currently proposed security? My concern is that thus far, the adoption of DTLS has been suggested but I've not readily seen how it would be applied. I believe modifications will have to be made to DTLS to ensure it's appropriate use for this group's application. DTLS is fairly open in how it achieves authentication to the point that it does not guarantee (identity) authenticity, so I think that additional specification for how DTLS is applied will be needed. That is, strong recommendations of the options of credential and cipher suites will have to be defined to ensure that this group's security requirements are met. Nancy.=20 -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Darren Loher Sent: Wednesday, October 05, 2005 7:36 AM To: Pat Calhoun (pacalhou); James Kempf; Dan Harkins Cc: capwap@frascone.com Subject: RE: [Capwap] Change Request 9.1.2 (Control Channel Security)=20 I think the main difference between NIST's concern and our scenario is the following: As Pat relayed to us in the RADIUS with IPSec case, there is no way for RADIUS to really know it's using IPSec and therefore does not know if it's transport is secure or not. =20 In the CAPWAP/LWAPP case the control channel is guaranteed to be secure, so it's okay to carry to PTK/GTK within the control channel. So within the context of CAPWAP, there is implicit knowledge that transient keys are using secure transport. -Darren > -----Original Message----- > From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com] > Sent: Wednesday, October 05, 2005 8:08 AM > To: Darren Loher; James Kempf; Dan Harkins > Cc: capwap@frascone.com > Subject: RE: [Capwap] Change Request 9.1.2 (Control Channel Security) >=20 > I think you meant PTK/GTK, but I was just making an observation that the > use of IPSec to carry keys was considered suspicious by NIST. I see a=20 > parallel here in our proposed direction. >=20 > I will follow what the WG feels is right, I was just making sure folks > had additional info I thought was useful. >=20 > Pat Calhoun > CTO, Wireless Networking Business Unit Cisco Systems >=20 >=20 >=20 > > -----Original Message----- > > From: Darren Loher [mailto:DLoher@rovingplanet.com] > > Sent: Sunday, October 02, 2005 12:17 PM > > To: James Kempf; Pat Calhoun (pacalhou); Dan Harkins > > Cc: capwap@frascone.com > > Subject: RE: [Capwap] Change Request 9.1.2 (Control Channel Security) > > > > Regarding secure distribtion of PMK/GMK between AC and WTP, it is=20 > > mandatory that these attributes are sent over the secured control=20 > > channel. So we should be covered on the AC <-> WTP communication. > > > > Isn't the transmission of RADIUS attributes an issue between the AC=20 > > and a AAA server and therefore outside the scope of CAPWAP? > > > > -Darren > > > > ________________________________ > > > > From: capwap-admin@frascone.com on behalf of James Kempf > > Sent: Thu 9/29/2005 9:54 AM > > To: Pat Calhoun (pacalhou); Dan Harkins > > Cc: capwap@frascone.com > > Subject: Re: [Capwap] Change Request 9.1.2 (Control Channel Security) > > > > > > > > I agree with Dan. I think the risk from doing DTLS post-discovery is > > minimal. > > > > Security protocols have a history of bugs turning up after some=20 > > years of deployment. An added benefit of using DTLS is that LWAPP=20 > > benefits from the attention given to DTLS by users of other=20 > > protocols, so any bugs will most likely be found more quickly than=20 > > if LWAPP designs its own, specialized protocol. > > > > Regarding IPsec v.s. DTLS v.s. encryption of the Radius attribute=20 > > for PMK distribution, I don't have any real opinion on this.=20 > > Actually, I think I would prefer to leave this as a deployment=20 > > option, with appropriate text in the Security Considerations section > > about the requirement to use one of these method, and the methods=20 > > are described. I realize that there is an interoperability concern=20 > > here, but I can imagine cases where a network operator might prefer=20 > > one method over another due to their existing deployment. As Dan=20 > > mentioned, the concerns expressed about using IPsec related to=20 > > particular implementation issues rather than any fundamental=20 > > architectural or design issue with the protocol. But I don't have a=20 > > real strong opinion on this, and I can think of reasons why it might > > be a good idea to include a particular "required to implement"=20 > > method too. > > > > > > jak > > > > > > > > ----- Original Message ----- > > From: "Dan Harkins" > > To: "Pat Calhoun (pacalhou)" > > Cc: > > Sent: Wednesday, September 28, 2005 3:16 PM > > Subject: Re: [Capwap] Change Request 9.1.2 (Control Channel Security) > > > > > > > Pat, > > > > > > I agree that the information in the discovery phase is > > benign. Also, > > > anything an attacker could do to at that point is the same > > as what an > > > attacker could do during the DTLS "hello" exchange-- modify > > packets in > > > flight, redirect packets-- and the result would be the same: an=20 > > > unsuccessful DTLS exchange or unsuccessful discovery. An attacker=20 > > > could deny service-- prevent a successful DTLS exchange or > > successful > > > discovery of AC-- but any middlebox can start dropping packets on a > > > whim and do the same thing. I don't believe there is a > > possibility of > > > a resource exhaustion attack or launch a man-in-the-middle attack=20 > > > against the AC or WTP. > > > > > > I don't think we really need to worry about doing DTLS > > post-discovery. > > > > > > To address your call for wider WG response to this recommendation: > > > I strongly believe that (D)TLS should be used for the key > > exchange and > > > authentication protocol. > > > > > > My understanding on the reason that NIST preferred > > AES-KeyWrap over > > > IPsec for the transporting of PMKs had nothing to do with any=20 > > > preceived weakness in IPsec. It was because there is nothing in the > > > IPsec standard to allow a user-space app-- like a RADIUS > > client-- to > > > know whether the packets it is sending are in the clear or > > are IPsec- > > > protected. Therefore a mis-configuration could result in PMKs being > > > sent over-the-wire in-the-clear. (There are IPsec > > implementations that > > > do allow for such queries of the SADB but that isn't part > > of the IPsec > > > standard and therefore there isn't a guarantee that such a > > capability > > > will be available everywhere). Putting the security for passing the > > > PMKs directly into the RADIUS app-- i.e. using > > AES-KeyWrap-- addresses > > > that concern. Therefore I don't believe NIST would have a problem=20 > > > sending PTKs down a (D)TLS-protected link because the app that is=20 > > > sending and receiving them knows whether that link is > > protected or not. > > > > > > Dan. > > > > > > On Wed, 28 Sep 2005 14:32:16 PDT you wrote > > >> The evaluation team has made a request to modify LWAPP's built-in > > >> security mechanism with DTLS instead. This specific change > > is tricky > > >> as we first need to identify whether the DTLS session should be=20 > > >> created prior to, or post, the discovery phase. > > >> > > >> Here are my high level thoughts on the issue: > > >> 1. Pre-Discovery DTLS. > > >> > > >> One of the LWAPP features is load balancing of WTPs among > > ACs. This > > >> load balancing can occur within, or across multiple, ACs. How this > > >> works is that a WTP would perform the discovery phase by > > initiating a > > >> Discovery Request packet to one or more ACs. The receiving ACs=20 > > >> respond with a Discovery Response, which also includes the total=20 > > >> number of WTPs supported (see section 5.2.2), as well as > > its current > > >> WTP load (see section 5.2.3). The WTP collects all of the > > Discovery > > >> Responses, and then decides which AC it wishes to connect > > to based on > > >> its policy. The policy can be either least loaded AC, or through a > > >> list of preferred ACs (see section 7.2.3). Further, the > > WTP can opt > > >> to not establish a session with the AC if it determines > > that it does > > >> not have the basic capabilities required by the AC. > > >> > > >> Performing DTLS prior to the Discovery Request would mean that the > > >> WTP would mean one of two things: > > >> a. The WTP establishes a DTLS session with every AC it > > knows about. > > >> The side effect here is the LWAPP connect time on the WTP, not to > > >> mention the CPU load imposed on the AC. > > >> b. The LWAPP protocol eliminates this feature altogether. > > This means > > >> that a WTP would only connect to the AC of its choice, > > regardless of > > >> the AC's current load of configuration. > > >> > > >> 2. Post-Discovery DTLS. In this mode, the above limitations are=20 > > >> removed, and the Discovery phase is done in the clear. While it is > > >> true that this raises some security concerns, the > > information in the > > >> Discovery Response is relatively benign, and therefore any > > malicious > > >> tweaking (or altering) of the response packet has created limited > > >> damage (although the WG needs to evaluate this, but it was > > not found > > >> to be problematic during the security review). > > >> > > >> This change would also require that the the Discovery packets be=20 > > >> exchanged on a separate UDP port, which is not a big change to the > > >> protocol. > > >> > > >> while I understand the evaluation team's recommendation to adopt=20 > > >> DTLS, I would also like to get a larger WG rough consensus > > on whether > > >> we feel that this change should be made. While I will make > > the change > > >> based on rough consensus, I want to make sure that we > > think and agree > > >> on this decision through as a group. I understand the > > concerns raised > > >> about increasing the time of the protocol development > > phase in having > > >> our own security approach, there are strategies that can > > be done to > > >> help us. For instance, initiate another security review > > with another > > >> reviewer identified by Russ Housely asap (he did recommend > > Charles Clancy, btw). > > >> > > >> I think that another important point here is that during a recent > > >> meeting with NIST, we discussed the transport of 802.11i > > PMKs within > > >> the RADIUS protocol. During this discussion, we proposed > > two methods. > > >> The first would explicitely encrypt the PMK using > > AES-KeyWrap within > > >> a RADIUS attribute. The second approach was simply to encrypt the > > >> whole RADIUS transaction with IPSec. It was NIST's opinion at that > > >> time that they felt comfortable with option one, while option two > > >> would require them to evaluate whether IPSec would be > > appropriate for > > >> the transport of PMKs. Given that CAPWAP has a requirement > > to allow > > >> the WTP to perform encryption, this means that PTKs (and > > GTKs) would > > >> have to be transported over a DTLS session, and therefore I wonder > > >> whether we would have similar issues as those mentioned above. If > > >> this were an issue, then FIPS certification of any CAPWAP > > based system could become impossible. > > >> > > >> Your comments are appreciated, > > >> > > >> Pat Calhoun > > >> CTO, Wireless Networking Business Unit Cisco Systems=20 > > >> _______________________________________________ > > >> Capwap mailing list > > >> Capwap@frascone.com > > >> http://mail.frascone.com/mailman/listinfo/capwap > > >> > > > _______________________________________________ > > > Capwap mailing list > > > Capwap@frascone.com > > > http://mail.frascone.com/mailman/listinfo/capwap > > > > > > > > > _______________________________________________ > > Capwap mailing list > > Capwap@frascone.com > > http://mail.frascone.com/mailman/listinfo/capwap > > _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Wed Oct 05 14:56:22 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENERB-0001oY-Cd for capwap-archive@megatron.ietf.org; Wed, 05 Oct 2005 14:56:22 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10320 for ; Wed, 5 Oct 2005 14:56:15 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B17D52045A; Wed, 5 Oct 2005 14:56:03 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by mail.frascone.com (Postfix) with ESMTP id A68C220440 for ; Wed, 5 Oct 2005 14:55:17 -0400 (EDT) Message-ID: <076301c5c9de$52e9bda0$196115ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Nancy Winget (ncamwing)" , "Darren Loher" , "Pat Calhoun (pacalhou)" , "Dan Harkins" Cc: References: <08A9A3213527A6428774900A80DBD8D8BB821E@xmb-sjc-222.amer.cisco.com> Subject: Re: [Capwap] Change Request 9.1.2 (Control Channel Security) MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit 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-Unsubscribe: , List-Id: A list for CAPWAP technical discussions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 5 Oct 2005 11:55:15 -0700 Content-Transfer-Encoding: 7bit Nancy, I think it is only fair to ask for a written proposal (i.e. a draft) about how DTLS would be applied to LWAPP before the WG makes a decision, if only to ensure that the technical details are in order. jak ----- Original Message ----- From: "Nancy Winget (ncamwing)" To: "Darren Loher" ; "Pat Calhoun (pacalhou)" ; "James Kempf" ; "Dan Harkins" Cc: Sent: Wednesday, October 05, 2005 11:35 AM Subject: RE: [Capwap] Change Request 9.1.2 (Control Channel Security) NIST's concern is that care and (re)review is taken when security protocols that were designed for one application are applied to another. In the case of RADIUS, NIST pointed out that both RADIUS and IPSec were complex enough that it was not clearly obvious to them how the use of IPSec would address the key transport security....nor has there been any security analysis to demonstrate what security properties and vulnerabilities IPSec provides when used with RADIUS. As for CAPWAP/LWAPP, it seems that the LWAPP protocol has already undergone security review and has been shown to meet this group's security requirements. So, how does DTLS improve upon the currently proposed security? My concern is that thus far, the adoption of DTLS has been suggested but I've not readily seen how it would be applied. I believe modifications will have to be made to DTLS to ensure it's appropriate use for this group's application. DTLS is fairly open in how it achieves authentication to the point that it does not guarantee (identity) authenticity, so I think that additional specification for how DTLS is applied will be needed. That is, strong recommendations of the options of credential and cipher suites will have to be defined to ensure that this group's security requirements are met. Nancy. -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Darren Loher Sent: Wednesday, October 05, 2005 7:36 AM To: Pat Calhoun (pacalhou); James Kempf; Dan Harkins Cc: capwap@frascone.com Subject: RE: [Capwap] Change Request 9.1.2 (Control Channel Security) I think the main difference between NIST's concern and our scenario is the following: As Pat relayed to us in the RADIUS with IPSec case, there is no way for RADIUS to really know it's using IPSec and therefore does not know if it's transport is secure or not. In the CAPWAP/LWAPP case the control channel is guaranteed to be secure, so it's okay to carry to PTK/GTK within the control channel. So within the context of CAPWAP, there is implicit knowledge that transient keys are using secure transport. -Darren > -----Original Message----- > From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com] > Sent: Wednesday, October 05, 2005 8:08 AM > To: Darren Loher; James Kempf; Dan Harkins > Cc: capwap@frascone.com > Subject: RE: [Capwap] Change Request 9.1.2 (Control Channel Security) > > I think you meant PTK/GTK, but I was just making an observation that the > use of IPSec to carry keys was considered suspicious by NIST. I see a > parallel here in our proposed direction. > > I will follow what the WG feels is right, I was just making sure folks > had additional info I thought was useful. > > Pat Calhoun > CTO, Wireless Networking Business Unit Cisco Systems > > > > > -----Original Message----- > > From: Darren Loher [mailto:DLoher@rovingplanet.com] > > Sent: Sunday, October 02, 2005 12:17 PM > > To: James Kempf; Pat Calhoun (pacalhou); Dan Harkins > > Cc: capwap@frascone.com > > Subject: RE: [Capwap] Change Request 9.1.2 (Control Channel Security) > > > > Regarding secure distribtion of PMK/GMK between AC and WTP, it is > > mandatory that these attributes are sent over the secured control > > channel. So we should be covered on the AC <-> WTP communication. > > > > Isn't the transmission of RADIUS attributes an issue between the AC > > and a AAA server and therefore outside the scope of CAPWAP? > > > > -Darren > > > > ________________________________ > > > > From: capwap-admin@frascone.com on behalf of James Kempf > > Sent: Thu 9/29/2005 9:54 AM > > To: Pat Calhoun (pacalhou); Dan Harkins > > Cc: capwap@frascone.com > > Subject: Re: [Capwap] Change Request 9.1.2 (Control Channel Security) > > > > > > > > I agree with Dan. I think the risk from doing DTLS post-discovery is > > minimal. > > > > Security protocols have a history of bugs turning up after some > > years of deployment. An added benefit of using DTLS is that LWAPP > > benefits from the attention given to DTLS by users of other > > protocols, so any bugs will most likely be found more quickly than > > if LWAPP designs its own, specialized protocol. > > > > Regarding IPsec v.s. DTLS v.s. encryption of the Radius attribute > > for PMK distribution, I don't have any real opinion on this. > > Actually, I think I would prefer to leave this as a deployment > > option, with appropriate text in the Security Considerations section > > about the requirement to use one of these method, and the methods > > are described. I realize that there is an interoperability concern > > here, but I can imagine cases where a network operator might prefer > > one method over another due to their existing deployment. As Dan > > mentioned, the concerns expressed about using IPsec related to > > particular implementation issues rather than any fundamental > > architectural or design issue with the protocol. But I don't have a > > real strong opinion on this, and I can think of reasons why it might > > be a good idea to include a particular "required to implement" > > method too. > > > > > > jak > > > > > > > > ----- Original Message ----- > > From: "Dan Harkins" > > To: "Pat Calhoun (pacalhou)" > > Cc: > > Sent: Wednesday, September 28, 2005 3:16 PM > > Subject: Re: [Capwap] Change Request 9.1.2 (Control Channel Security) > > > > > > > Pat, > > > > > > I agree that the information in the discovery phase is > > benign. Also, > > > anything an attacker could do to at that point is the same > > as what an > > > attacker could do during the DTLS "hello" exchange-- modify > > packets in > > > flight, redirect packets-- and the result would be the same: an > > > unsuccessful DTLS exchange or unsuccessful discovery. An attacker > > > could deny service-- prevent a successful DTLS exchange or > > successful > > > discovery of AC-- but any middlebox can start dropping packets on a > > > whim and do the same thing. I don't believe there is a > > possibility of > > > a resource exhaustion attack or launch a man-in-the-middle attack > > > against the AC or WTP. > > > > > > I don't think we really need to worry about doing DTLS > > post-discovery. > > > > > > To address your call for wider WG response to this recommendation: > > > I strongly believe that (D)TLS should be used for the key > > exchange and > > > authentication protocol. > > > > > > My understanding on the reason that NIST preferred > > AES-KeyWrap over > > > IPsec for the transporting of PMKs had nothing to do with any > > > preceived weakness in IPsec. It was because there is nothing in the > > > IPsec standard to allow a user-space app-- like a RADIUS > > client-- to > > > know whether the packets it is sending are in the clear or > > are IPsec- > > > protected. Therefore a mis-configuration could result in PMKs being > > > sent over-the-wire in-the-clear. (There are IPsec > > implementations that > > > do allow for such queries of the SADB but that isn't part > > of the IPsec > > > standard and therefore there isn't a guarantee that such a > > capability > > > will be available everywhere). Putting the security for passing the > > > PMKs directly into the RADIUS app-- i.e. using > > AES-KeyWrap-- addresses > > > that concern. Therefore I don't believe NIST would have a problem > > > sending PTKs down a (D)TLS-protected link because the app that is > > > sending and receiving them knows whether that link is > > protected or not. > > > > > > Dan. > > > > > > On Wed, 28 Sep 2005 14:32:16 PDT you wrote > > >> The evaluation team has made a request to modify LWAPP's built-in > > >> security mechanism with DTLS instead. This specific change > > is tricky > > >> as we first need to identify whether the DTLS session should be > > >> created prior to, or post, the discovery phase. > > >> > > >> Here are my high level thoughts on the issue: > > >> 1. Pre-Discovery DTLS. > > >> > > >> One of the LWAPP features is load balancing of WTPs among > > ACs. This > > >> load balancing can occur within, or across multiple, ACs. How this > > >> works is that a WTP would perform the discovery phase by > > initiating a > > >> Discovery Request packet to one or more ACs. The receiving ACs > > >> respond with a Discovery Response, which also includes the total > > >> number of WTPs supported (see section 5.2.2), as well as > > its current > > >> WTP load (see section 5.2.3). The WTP collects all of the > > Discovery > > >> Responses, and then decides which AC it wishes to connect > > to based on > > >> its policy. The policy can be either least loaded AC, or through a > > >> list of preferred ACs (see section 7.2.3). Further, the > > WTP can opt > > >> to not establish a session with the AC if it determines > > that it does > > >> not have the basic capabilities required by the AC. > > >> > > >> Performing DTLS prior to the Discovery Request would mean that the > > >> WTP would mean one of two things: > > >> a. The WTP establishes a DTLS session with every AC it > > knows about. > > >> The side effect here is the LWAPP connect time on the WTP, not to > > >> mention the CPU load imposed on the AC. > > >> b. The LWAPP protocol eliminates this feature altogether. > > This means > > >> that a WTP would only connect to the AC of its choice, > > regardless of > > >> the AC's current load of configuration. > > >> > > >> 2. Post-Discovery DTLS. In this mode, the above limitations are > > >> removed, and the Discovery phase is done in the clear. While it is > > >> true that this raises some security concerns, the > > information in the > > >> Discovery Response is relatively benign, and therefore any > > malicious > > >> tweaking (or altering) of the response packet has created limited > > >> damage (although the WG needs to evaluate this, but it was > > not found > > >> to be problematic during the security review). > > >> > > >> This change would also require that the the Discovery packets be > > >> exchanged on a separate UDP port, which is not a big change to the > > >> protocol. > > >> > > >> while I understand the evaluation team's recommendation to adopt > > >> DTLS, I would also like to get a larger WG rough consensus > > on whether > > >> we feel that this change should be made. While I will make > > the change > > >> based on rough consensus, I want to make sure that we > > think and agree > > >> on this decision through as a group. I understand the > > concerns raised > > >> about increasing the time of the protocol development > > phase in having > > >> our own security approach, there are strategies that can > > be done to > > >> help us. For instance, initiate another security review > > with another > > >> reviewer identified by Russ Housely asap (he did recommend > > Charles Clancy, btw). > > >> > > >> I think that another important point here is that during a recent > > >> meeting with NIST, we discussed the transport of 802.11i > > PMKs within > > >> the RADIUS protocol. During this discussion, we proposed > > two methods. > > >> The first would explicitely encrypt the PMK using > > AES-KeyWrap within > > >> a RADIUS attribute. The second approach was simply to encrypt the > > >> whole RADIUS transaction with IPSec. It was NIST's opinion at that > > >> time that they felt comfortable with option one, while option two > > >> would require them to evaluate whether IPSec would be > > appropriate for > > >> the transport of PMKs. Given that CAPWAP has a requirement > > to allow > > >> the WTP to perform encryption, this means that PTKs (and > > GTKs) would > > >> have to be transported over a DTLS session, and therefore I wonder > > >> whether we would have similar issues as those mentioned above. If > > >> this were an issue, then FIPS certification of any CAPWAP > > based system could become impossible. > > >> > > >> Your comments are appreciated, > > >> > > >> Pat Calhoun > > >> CTO, Wireless Networking Business Unit Cisco Systems > > >> _______________________________________________ > > >> Capwap mailing list > > >> Capwap@frascone.com > > >> http://mail.frascone.com/mailman/listinfo/capwap > > >> > > > _______________________________________________ > > > Capwap mailing list > > > Capwap@frascone.com > > > http://mail.frascone.com/mailman/listinfo/capwap > > > > > > > > > _______________________________________________ > > Capwap mailing list > > Capwap@frascone.com > > http://mail.frascone.com/mailman/listinfo/capwap > > _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Wed Oct 05 14:57:33 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENESL-00030E-JV for capwap-archive@megatron.ietf.org; Wed, 05 Oct 2005 14:57:33 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10380 for ; Wed, 5 Oct 2005 14:57:30 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 4548B2045D; Wed, 5 Oct 2005 14:57:04 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from sj-iport-1.cisco.com (sj-iport-1-in.cisco.com [171.71.176.70]) by mail.frascone.com (Postfix) with ESMTP id 726452045D for ; Wed, 5 Oct 2005 14:56:16 -0400 (EDT) Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-1.cisco.com with ESMTP; 05 Oct 2005 11:56:16 -0700 X-IronPort-AV: i="3.97,178,1125903600"; d="scan'208"; a="663714775:sNHT31715176" Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j95ItPKm006744; Wed, 5 Oct 2005 11:56:13 -0700 (PDT) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 5 Oct 2005 11:56:13 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Capwap] Change Request 9.1.2 (Control Channel Security) Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2BEF97D@xmb-sjc-235.amer.cisco.com> Thread-Topic: [Capwap] Change Request 9.1.2 (Control Channel Security) Thread-Index: AcXJ3l3qh1ZiNEotRQ+YCQpObyDXjwAABDtg From: "Pat Calhoun (pacalhou)" To: "James Kempf" , "Nancy Winget (ncamwing)" , "Darren Loher" , "Dan Harkins" Cc: X-OriginalArrivalTime: 05 Oct 2005 18:56:13.0175 (UTC) FILETIME=[74F03870:01C5C9DE] 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-Unsubscribe: , List-Id: A list for CAPWAP technical discussions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 5 Oct 2005 11:56:12 -0700 Content-Transfer-Encoding: quoted-printable Great idea. Anyone willing to sign up? Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 > -----Original Message----- > From: James Kempf [mailto:Kempf@docomolabs-usa.com]=20 > Sent: Wednesday, October 05, 2005 11:55 AM > To: Nancy Winget (ncamwing); Darren Loher; Pat Calhoun=20 > (pacalhou); Dan Harkins > Cc: capwap@frascone.com > Subject: Re: [Capwap] Change Request 9.1.2 (Control Channel Security)=20 >=20 > Nancy, >=20 > I think it is only fair to ask for a written proposal (i.e. a=20 > draft) about how DTLS would be applied to LWAPP before the WG=20 > makes a decision, if only to ensure that the technical=20 > details are in order. >=20 > jak >=20 >=20 > ----- Original Message ----- > From: "Nancy Winget (ncamwing)" > To: "Darren Loher" ; "Pat Calhoun=20 > (pacalhou)"=20 > ; "James Kempf"=20 > ; "Dan Harkins" > Cc: > Sent: Wednesday, October 05, 2005 11:35 AM > Subject: RE: [Capwap] Change Request 9.1.2 (Control Channel Security) >=20 >=20 >=20 > NIST's concern is that care and (re)review is taken when=20 > security protocols that were designed for one application are=20 > applied to another. > In the case of RADIUS, NIST pointed out that both RADIUS and=20 > IPSec were complex enough that it was not clearly obvious to=20 > them how the use of IPSec would address the key transport=20 > security....nor has there been any security analysis to=20 > demonstrate what security properties and vulnerabilities=20 > IPSec provides when used with RADIUS. >=20 > As for CAPWAP/LWAPP, it seems that the LWAPP protocol has=20 > already undergone security review and has been shown to meet=20 > this group's security requirements. So, how does DTLS=20 > improve upon the currently proposed security? >=20 > My concern is that thus far, the adoption of DTLS has been=20 > suggested but I've not readily seen how it would be applied. =20 > I believe modifications will have to be made to DTLS to=20 > ensure it's appropriate use for this group's application. =20 > DTLS is fairly open in how it achieves authentication to the=20 > point that it does not guarantee (identity) authenticity, so=20 > I think that additional specification for how DTLS is applied=20 > will be needed. That is, strong recommendations of the=20 > options of credential and cipher suites will have to be=20 > defined to ensure that this group's security requirements are met. >=20 > Nancy. >=20 > -----Original Message----- > From: capwap-admin@frascone.com=20 > [mailto:capwap-admin@frascone.com] On Behalf Of Darren Loher > Sent: Wednesday, October 05, 2005 7:36 AM > To: Pat Calhoun (pacalhou); James Kempf; Dan Harkins > Cc: capwap@frascone.com > Subject: RE: [Capwap] Change Request 9.1.2 (Control Channel Security) >=20 > I think the main difference between NIST's concern and our=20 > scenario is the following: >=20 > As Pat relayed to us in the RADIUS with IPSec case, there is=20 > no way for RADIUS to really know it's using IPSec and=20 > therefore does not know if it's transport is secure or not. >=20 > In the CAPWAP/LWAPP case the control channel is guaranteed to=20 > be secure, so it's okay to carry to PTK/GTK within the=20 > control channel. So within the context of CAPWAP, there is=20 > implicit knowledge that transient keys are using secure transport. >=20 > -Darren >=20 > > -----Original Message----- > > From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com] > > Sent: Wednesday, October 05, 2005 8:08 AM > > To: Darren Loher; James Kempf; Dan Harkins > > Cc: capwap@frascone.com > > Subject: RE: [Capwap] Change Request 9.1.2 (Control Channel=20 > Security) > > > > I think you meant PTK/GTK, but I was just making an observation that > the > > use of IPSec to carry keys was considered suspicious by=20 > NIST. I see a=20 > > parallel here in our proposed direction. > > > > I will follow what the WG feels is right, I was just making=20 > sure folks >=20 > > had additional info I thought was useful. > > > > Pat Calhoun > > CTO, Wireless Networking Business Unit Cisco Systems > > > > > > > > > -----Original Message----- > > > From: Darren Loher [mailto:DLoher@rovingplanet.com] > > > Sent: Sunday, October 02, 2005 12:17 PM > > > To: James Kempf; Pat Calhoun (pacalhou); Dan Harkins > > > Cc: capwap@frascone.com > > > Subject: RE: [Capwap] Change Request 9.1.2 (Control Channel > Security) > > > > > > Regarding secure distribtion of PMK/GMK between AC and WTP, it is=20 > > > mandatory that these attributes are sent over the secured control=20 > > > channel. So we should be covered on the AC <-> WTP communication. > > > > > > Isn't the transmission of RADIUS attributes an issue=20 > between the AC=20 > > > and a AAA server and therefore outside the scope of CAPWAP? > > > > > > -Darren > > > > > > ________________________________ > > > > > > From: capwap-admin@frascone.com on behalf of James Kempf > > > Sent: Thu 9/29/2005 9:54 AM > > > To: Pat Calhoun (pacalhou); Dan Harkins > > > Cc: capwap@frascone.com > > > Subject: Re: [Capwap] Change Request 9.1.2 (Control Channel > Security) > > > > > > > > > > > > I agree with Dan. I think the risk from doing DTLS=20 > post-discovery is >=20 > > > minimal. > > > > > > Security protocols have a history of bugs turning up after some=20 > > > years of deployment. An added benefit of using DTLS is that LWAPP=20 > > > benefits from the attention given to DTLS by users of other=20 > > > protocols, so any bugs will most likely be found more=20 > quickly than=20 > > > if LWAPP designs its own, specialized protocol. > > > > > > Regarding IPsec v.s. DTLS v.s. encryption of the Radius attribute=20 > > > for PMK distribution, I don't have any real opinion on this. > > > Actually, I think I would prefer to leave this as a deployment=20 > > > option, with appropriate text in the Security=20 > Considerations section >=20 > > > about the requirement to use one of these method, and the methods=20 > > > are described. I realize that there is an=20 > interoperability concern=20 > > > here, but I can imagine cases where a network operator=20 > might prefer=20 > > > one method over another due to their existing deployment. As Dan=20 > > > mentioned, the concerns expressed about using IPsec related to=20 > > > particular implementation issues rather than any fundamental=20 > > > architectural or design issue with the protocol. But I=20 > don't have a=20 > > > real strong opinion on this, and I can think of reasons=20 > why it might >=20 > > > be a good idea to include a particular "required to implement" > > > method too. > > > > > > > > > jak > > > > > > > > > > > > ----- Original Message ----- > > > From: "Dan Harkins" > > > To: "Pat Calhoun (pacalhou)" > > > Cc: > > > Sent: Wednesday, September 28, 2005 3:16 PM > > > Subject: Re: [Capwap] Change Request 9.1.2 (Control Channel > Security) > > > > > > > > > > Pat, > > > > > > > > I agree that the information in the discovery phase is > > > benign. Also, > > > > anything an attacker could do to at that point is the same > > > as what an > > > > attacker could do during the DTLS "hello" exchange-- modify > > > packets in > > > > flight, redirect packets-- and the result would be the same: an=20 > > > > unsuccessful DTLS exchange or unsuccessful discovery.=20 > An attacker=20 > > > > could deny service-- prevent a successful DTLS exchange or > > > successful > > > > discovery of AC-- but any middlebox can start dropping=20 > packets on > a > > > > whim and do the same thing. I don't believe there is a > > > possibility of > > > > a resource exhaustion attack or launch a=20 > man-in-the-middle attack=20 > > > > against the AC or WTP. > > > > > > > > I don't think we really need to worry about doing DTLS > > > post-discovery. > > > > > > > > To address your call for wider WG response to this > recommendation: > > > > I strongly believe that (D)TLS should be used for the key > > > exchange and > > > > authentication protocol. > > > > > > > > My understanding on the reason that NIST preferred > > > AES-KeyWrap over > > > > IPsec for the transporting of PMKs had nothing to do with any=20 > > > > preceived weakness in IPsec. It was because there is nothing in > the > > > > IPsec standard to allow a user-space app-- like a RADIUS > > > client-- to > > > > know whether the packets it is sending are in the clear or > > > are IPsec- > > > > protected. Therefore a mis-configuration could result in PMKs > being > > > > sent over-the-wire in-the-clear. (There are IPsec > > > implementations that > > > > do allow for such queries of the SADB but that isn't part > > > of the IPsec > > > > standard and therefore there isn't a guarantee that such a > > > capability > > > > will be available everywhere). Putting the security for passing > the > > > > PMKs directly into the RADIUS app-- i.e. using > > > AES-KeyWrap-- addresses > > > > that concern. Therefore I don't believe NIST would have=20 > a problem=20 > > > > sending PTKs down a (D)TLS-protected link because the=20 > app that is=20 > > > > sending and receiving them knows whether that link is > > > protected or not. > > > > > > > > Dan. > > > > > > > > On Wed, 28 Sep 2005 14:32:16 PDT you wrote > > > >> The evaluation team has made a request to modify=20 > LWAPP's built-in >=20 > > > >> security mechanism with DTLS instead. This specific change > > > is tricky > > > >> as we first need to identify whether the DTLS session=20 > should be=20 > > > >> created prior to, or post, the discovery phase. > > > >> > > > >> Here are my high level thoughts on the issue: > > > >> 1. Pre-Discovery DTLS. > > > >> > > > >> One of the LWAPP features is load balancing of WTPs among > > > ACs. This > > > >> load balancing can occur within, or across multiple, ACs. How > this > > > >> works is that a WTP would perform the discovery phase by > > > initiating a > > > >> Discovery Request packet to one or more ACs. The receiving ACs=20 > > > >> respond with a Discovery Response, which also includes=20 > the total=20 > > > >> number of WTPs supported (see section 5.2.2), as well as > > > its current > > > >> WTP load (see section 5.2.3). The WTP collects all of the > > > Discovery > > > >> Responses, and then decides which AC it wishes to connect > > > to based on > > > >> its policy. The policy can be either least loaded AC,=20 > or through > a > > > >> list of preferred ACs (see section 7.2.3). Further, the > > > WTP can opt > > > >> to not establish a session with the AC if it determines > > > that it does > > > >> not have the basic capabilities required by the AC. > > > >> > > > >> Performing DTLS prior to the Discovery Request would mean that > the > > > >> WTP would mean one of two things: > > > >> a. The WTP establishes a DTLS session with every AC it > > > knows about. > > > >> The side effect here is the LWAPP connect time on the=20 > WTP, not to >=20 > > > >> mention the CPU load imposed on the AC. > > > >> b. The LWAPP protocol eliminates this feature altogether. > > > This means > > > >> that a WTP would only connect to the AC of its choice, > > > regardless of > > > >> the AC's current load of configuration. > > > >> > > > >> 2. Post-Discovery DTLS. In this mode, the above=20 > limitations are=20 > > > >> removed, and the Discovery phase is done in the clear. While it > is > > > >> true that this raises some security concerns, the > > > information in the > > > >> Discovery Response is relatively benign, and therefore any > > > malicious > > > >> tweaking (or altering) of the response packet has=20 > created limited >=20 > > > >> damage (although the WG needs to evaluate this, but it was > > > not found > > > >> to be problematic during the security review). > > > >> > > > >> This change would also require that the the Discovery=20 > packets be=20 > > > >> exchanged on a separate UDP port, which is not a big change to > the > > > >> protocol. > > > >> > > > >> while I understand the evaluation team's=20 > recommendation to adopt=20 > > > >> DTLS, I would also like to get a larger WG rough consensus > > > on whether > > > >> we feel that this change should be made. While I will make > > > the change > > > >> based on rough consensus, I want to make sure that we > > > think and agree > > > >> on this decision through as a group. I understand the > > > concerns raised > > > >> about increasing the time of the protocol development > > > phase in having > > > >> our own security approach, there are strategies that can > > > be done to > > > >> help us. For instance, initiate another security review > > > with another > > > >> reviewer identified by Russ Housely asap (he did recommend > > > Charles Clancy, btw). > > > >> > > > >> I think that another important point here is that=20 > during a recent >=20 > > > >> meeting with NIST, we discussed the transport of 802.11i > > > PMKs within > > > >> the RADIUS protocol. During this discussion, we proposed > > > two methods. > > > >> The first would explicitely encrypt the PMK using > > > AES-KeyWrap within > > > >> a RADIUS attribute. The second approach was simply to=20 > encrypt the >=20 > > > >> whole RADIUS transaction with IPSec. It was NIST's opinion at > that > > > >> time that they felt comfortable with option one, while=20 > option two >=20 > > > >> would require them to evaluate whether IPSec would be > > > appropriate for > > > >> the transport of PMKs. Given that CAPWAP has a requirement > > > to allow > > > >> the WTP to perform encryption, this means that PTKs (and > > > GTKs) would > > > >> have to be transported over a DTLS session, and therefore I > wonder > > > >> whether we would have similar issues as those=20 > mentioned above. If >=20 > > > >> this were an issue, then FIPS certification of any CAPWAP > > > based system could become impossible. > > > >> > > > >> Your comments are appreciated, > > > >> > > > >> Pat Calhoun > > > >> CTO, Wireless Networking Business Unit Cisco Systems=20 > > > >> _______________________________________________ > > > >> Capwap mailing list > > > >> Capwap@frascone.com > > > >> http://mail.frascone.com/mailman/listinfo/capwap > > > >> > > > > _______________________________________________ > > > > Capwap mailing list > > > > Capwap@frascone.com > > > > http://mail.frascone.com/mailman/listinfo/capwap > > > > > > > > > > > > > _______________________________________________ > > > Capwap mailing list > > > Capwap@frascone.com > > > http://mail.frascone.com/mailman/listinfo/capwap > > > > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap >=20 _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Wed Oct 05 15:02:24 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENEX2-00060C-Cw for capwap-archive@megatron.ietf.org; Wed, 05 Oct 2005 15:02:24 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10681 for ; Wed, 5 Oct 2005 15:02:18 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 3AECB20462; Wed, 5 Oct 2005 15:02:04 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by mail.frascone.com (Postfix) with ESMTP id 4983E20440 for ; Wed, 5 Oct 2005 15:01:11 -0400 (EDT) Message-ID: <078a01c5c9df$2670e4f0$196115ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Scott G. Kelly" , "Pat Calhoun (pacalhou)" , "Nancy Winget (ncamwing)" , "Darren Loher" , "Dan Harkins" Cc: References: <25077991.1128538809129.JavaMail.root@elwamui-norfolk.atl.sa.earthlink.net> Subject: Re: [Capwap] Change Request 9.1.2 (Control Channel Security) MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit 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-Unsubscribe: , List-Id: A list for CAPWAP technical discussions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 5 Oct 2005 12:01:10 -0700 Content-Transfer-Encoding: 7bit Me too. But I can't be the point man with fingers on the keyboard. jak ----- Original Message ----- From: "Scott G. Kelly" To: "Pat Calhoun (pacalhou)" ; "James Kempf" ; "Nancy Winget (ncamwing)" ; "Darren Loher" ; "Dan Harkins" Cc: Sent: Wednesday, October 05, 2005 12:00 PM Subject: RE: [Capwap] Change Request 9.1.2 (Control Channel Security) > I'd be willing to help with this. > > -----Original Message----- > From: "Pat Calhoun (pacalhou)" > Sent: Oct 5, 2005 11:56 AM > To: James Kempf , "Nancy Winget (ncamwing)" > , Darren Loher , Dan Harkins > > Cc: capwap@frascone.com > Subject: RE: [Capwap] Change Request 9.1.2 (Control Channel Security) > > Great idea. Anyone willing to sign up? > > Pat Calhoun > CTO, Wireless Networking Business Unit > Cisco Systems > > > >> -----Original Message----- >> From: James Kempf [mailto:Kempf@docomolabs-usa.com] >> Sent: Wednesday, October 05, 2005 11:55 AM >> To: Nancy Winget (ncamwing); Darren Loher; Pat Calhoun >> (pacalhou); Dan Harkins >> Cc: capwap@frascone.com >> Subject: Re: [Capwap] Change Request 9.1.2 (Control Channel Security) >> >> Nancy, >> >> I think it is only fair to ask for a written proposal (i.e. a >> draft) about how DTLS would be applied to LWAPP before the WG >> makes a decision, if only to ensure that the technical >> details are in order. >> >> jak >> >> >> ----- Original Message ----- >> From: "Nancy Winget (ncamwing)" >> To: "Darren Loher" ; "Pat Calhoun >> (pacalhou)" >> ; "James Kempf" >> ; "Dan Harkins" >> Cc: >> Sent: Wednesday, October 05, 2005 11:35 AM >> Subject: RE: [Capwap] Change Request 9.1.2 (Control Channel Security) >> >> >> >> NIST's concern is that care and (re)review is taken when >> security protocols that were designed for one application are >> applied to another. >> In the case of RADIUS, NIST pointed out that both RADIUS and >> IPSec were complex enough that it was not clearly obvious to >> them how the use of IPSec would address the key transport >> security....nor has there been any security analysis to >> demonstrate what security properties and vulnerabilities >> IPSec provides when used with RADIUS. >> >> As for CAPWAP/LWAPP, it seems that the LWAPP protocol has >> already undergone security review and has been shown to meet >> this group's security requirements. So, how does DTLS >> improve upon the currently proposed security? >> >> My concern is that thus far, the adoption of DTLS has been >> suggested but I've not readily seen how it would be applied. >> I believe modifications will have to be made to DTLS to >> ensure it's appropriate use for this group's application. >> DTLS is fairly open in how it achieves authentication to the >> point that it does not guarantee (identity) authenticity, so >> I think that additional specification for how DTLS is applied >> will be needed. That is, strong recommendations of the >> options of credential and cipher suites will have to be >> defined to ensure that this group's security requirements are met. >> >> Nancy. >> >> -----Original Message----- >> From: capwap-admin@frascone.com >> [mailto:capwap-admin@frascone.com] On Behalf Of Darren Loher >> Sent: Wednesday, October 05, 2005 7:36 AM >> To: Pat Calhoun (pacalhou); James Kempf; Dan Harkins >> Cc: capwap@frascone.com >> Subject: RE: [Capwap] Change Request 9.1.2 (Control Channel Security) >> >> I think the main difference between NIST's concern and our >> scenario is the following: >> >> As Pat relayed to us in the RADIUS with IPSec case, there is >> no way for RADIUS to really know it's using IPSec and >> therefore does not know if it's transport is secure or not. >> >> In the CAPWAP/LWAPP case the control channel is guaranteed to >> be secure, so it's okay to carry to PTK/GTK within the >> control channel. So within the context of CAPWAP, there is >> implicit knowledge that transient keys are using secure transport. >> >> -Darren >> >> > -----Original Message----- >> > From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com] >> > Sent: Wednesday, October 05, 2005 8:08 AM >> > To: Darren Loher; James Kempf; Dan Harkins >> > Cc: capwap@frascone.com >> > Subject: RE: [Capwap] Change Request 9.1.2 (Control Channel >> Security) >> > >> > I think you meant PTK/GTK, but I was just making an observation that >> the >> > use of IPSec to carry keys was considered suspicious by >> NIST. I see a >> > parallel here in our proposed direction. >> > >> > I will follow what the WG feels is right, I was just making >> sure folks >> >> > had additional info I thought was useful. >> > >> > Pat Calhoun >> > CTO, Wireless Networking Business Unit Cisco Systems >> > >> > >> > >> > > -----Original Message----- >> > > From: Darren Loher [mailto:DLoher@rovingplanet.com] >> > > Sent: Sunday, October 02, 2005 12:17 PM >> > > To: James Kempf; Pat Calhoun (pacalhou); Dan Harkins >> > > Cc: capwap@frascone.com >> > > Subject: RE: [Capwap] Change Request 9.1.2 (Control Channel >> Security) >> > > >> > > Regarding secure distribtion of PMK/GMK between AC and WTP, it is >> > > mandatory that these attributes are sent over the secured control >> > > channel. So we should be covered on the AC <-> WTP communication. >> > > >> > > Isn't the transmission of RADIUS attributes an issue >> between the AC >> > > and a AAA server and therefore outside the scope of CAPWAP? >> > > >> > > -Darren >> > > >> > > ________________________________ >> > > >> > > From: capwap-admin@frascone.com on behalf of James Kempf >> > > Sent: Thu 9/29/2005 9:54 AM >> > > To: Pat Calhoun (pacalhou); Dan Harkins >> > > Cc: capwap@frascone.com >> > > Subject: Re: [Capwap] Change Request 9.1.2 (Control Channel >> Security) >> > > >> > > >> > > >> > > I agree with Dan. I think the risk from doing DTLS >> post-discovery is >> >> > > minimal. >> > > >> > > Security protocols have a history of bugs turning up after some >> > > years of deployment. An added benefit of using DTLS is that LWAPP >> > > benefits from the attention given to DTLS by users of other >> > > protocols, so any bugs will most likely be found more >> quickly than >> > > if LWAPP designs its own, specialized protocol. >> > > >> > > Regarding IPsec v.s. DTLS v.s. encryption of the Radius attribute >> > > for PMK distribution, I don't have any real opinion on this. >> > > Actually, I think I would prefer to leave this as a deployment >> > > option, with appropriate text in the Security >> Considerations section >> >> > > about the requirement to use one of these method, and the methods >> > > are described. I realize that there is an >> interoperability concern >> > > here, but I can imagine cases where a network operator >> might prefer >> > > one method over another due to their existing deployment. As Dan >> > > mentioned, the concerns expressed about using IPsec related to >> > > particular implementation issues rather than any fundamental >> > > architectural or design issue with the protocol. But I >> don't have a >> > > real strong opinion on this, and I can think of reasons >> why it might >> >> > > be a good idea to include a particular "required to implement" >> > > method too. >> > > >> > > >> > > jak >> > > >> > > >> > > >> > > ----- Original Message ----- >> > > From: "Dan Harkins" >> > > To: "Pat Calhoun (pacalhou)" >> > > Cc: >> > > Sent: Wednesday, September 28, 2005 3:16 PM >> > > Subject: Re: [Capwap] Change Request 9.1.2 (Control Channel >> Security) >> > > >> > > >> > > > Pat, >> > > > >> > > > I agree that the information in the discovery phase is >> > > benign. Also, >> > > > anything an attacker could do to at that point is the same >> > > as what an >> > > > attacker could do during the DTLS "hello" exchange-- modify >> > > packets in >> > > > flight, redirect packets-- and the result would be the same: an >> > > > unsuccessful DTLS exchange or unsuccessful discovery. >> An attacker >> > > > could deny service-- prevent a successful DTLS exchange or >> > > successful >> > > > discovery of AC-- but any middlebox can start dropping >> packets on >> a >> > > > whim and do the same thing. I don't believe there is a >> > > possibility of >> > > > a resource exhaustion attack or launch a >> man-in-the-middle attack >> > > > against the AC or WTP. >> > > > >> > > > I don't think we really need to worry about doing DTLS >> > > post-discovery. >> > > > >> > > > To address your call for wider WG response to this >> recommendation: >> > > > I strongly believe that (D)TLS should be used for the key >> > > exchange and >> > > > authentication protocol. >> > > > >> > > > My understanding on the reason that NIST preferred >> > > AES-KeyWrap over >> > > > IPsec for the transporting of PMKs had nothing to do with any >> > > > preceived weakness in IPsec. It was because there is nothing in >> the >> > > > IPsec standard to allow a user-space app-- like a RADIUS >> > > client-- to >> > > > know whether the packets it is sending are in the clear or >> > > are IPsec- >> > > > protected. Therefore a mis-configuration could result in PMKs >> being >> > > > sent over-the-wire in-the-clear. (There are IPsec >> > > implementations that >> > > > do allow for such queries of the SADB but that isn't part >> > > of the IPsec >> > > > standard and therefore there isn't a guarantee that such a >> > > capability >> > > > will be available everywhere). Putting the security for passing >> the >> > > > PMKs directly into the RADIUS app-- i.e. using >> > > AES-KeyWrap-- addresses >> > > > that concern. Therefore I don't believe NIST would have >> a problem >> > > > sending PTKs down a (D)TLS-protected link because the >> app that is >> > > > sending and receiving them knows whether that link is >> > > protected or not. >> > > > >> > > > Dan. >> > > > >> > > > On Wed, 28 Sep 2005 14:32:16 PDT you wrote >> > > >> The evaluation team has made a request to modify >> LWAPP's built-in >> >> > > >> security mechanism with DTLS instead. This specific change >> > > is tricky >> > > >> as we first need to identify whether the DTLS session >> should be >> > > >> created prior to, or post, the discovery phase. >> > > >> >> > > >> Here are my high level thoughts on the issue: >> > > >> 1. Pre-Discovery DTLS. >> > > >> >> > > >> One of the LWAPP features is load balancing of WTPs among >> > > ACs. This >> > > >> load balancing can occur within, or across multiple, ACs. How >> this >> > > >> works is that a WTP would perform the discovery phase by >> > > initiating a >> > > >> Discovery Request packet to one or more ACs. The receiving ACs >> > > >> respond with a Discovery Response, which also includes >> the total >> > > >> number of WTPs supported (see section 5.2.2), as well as >> > > its current >> > > >> WTP load (see section 5.2.3). The WTP collects all of the >> > > Discovery >> > > >> Responses, and then decides which AC it wishes to connect >> > > to based on >> > > >> its policy. The policy can be either least loaded AC, >> or through >> a >> > > >> list of preferred ACs (see section 7.2.3). Further, the >> > > WTP can opt >> > > >> to not establish a session with the AC if it determines >> > > that it does >> > > >> not have the basic capabilities required by the AC. >> > > >> >> > > >> Performing DTLS prior to the Discovery Request would mean that >> the >> > > >> WTP would mean one of two things: >> > > >> a. The WTP establishes a DTLS session with every AC it >> > > knows about. >> > > >> The side effect here is the LWAPP connect time on the >> WTP, not to >> >> > > >> mention the CPU load imposed on the AC. >> > > >> b. The LWAPP protocol eliminates this feature altogether. >> > > This means >> > > >> that a WTP would only connect to the AC of its choice, >> > > regardless of >> > > >> the AC's current load of configuration. >> > > >> >> > > >> 2. Post-Discovery DTLS. In this mode, the above >> limitations are >> > > >> removed, and the Discovery phase is done in the clear. While it >> is >> > > >> true that this raises some security concerns, the >> > > information in the >> > > >> Discovery Response is relatively benign, and therefore any >> > > malicious >> > > >> tweaking (or altering) of the response packet has >> created limited >> >> > > >> damage (although the WG needs to evaluate this, but it was >> > > not found >> > > >> to be problematic during the security review). >> > > >> >> > > >> This change would also require that the the Discovery >> packets be >> > > >> exchanged on a separate UDP port, which is not a big change to >> the >> > > >> protocol. >> > > >> >> > > >> while I understand the evaluation team's >> recommendation to adopt >> > > >> DTLS, I would also like to get a larger WG rough consensus >> > > on whether >> > > >> we feel that this change should be made. While I will make >> > > the change >> > > >> based on rough consensus, I want to make sure that we >> > > think and agree >> > > >> on this decision through as a group. I understand the >> > > concerns raised >> > > >> about increasing the time of the protocol development >> > > phase in having >> > > >> our own security approach, there are strategies that can >> > > be done to >> > > >> help us. For instance, initiate another security review >> > > with another >> > > >> reviewer identified by Russ Housely asap (he did recommend >> > > Charles Clancy, btw). >> > > >> >> > > >> I think that another important point here is that >> during a recent >> >> > > >> meeting with NIST, we discussed the transport of 802.11i >> > > PMKs within >> > > >> the RADIUS protocol. During this discussion, we proposed >> > > two methods. >> > > >> The first would explicitely encrypt the PMK using >> > > AES-KeyWrap within >> > > >> a RADIUS attribute. The second approach was simply to >> encrypt the >> >> > > >> whole RADIUS transaction with IPSec. It was NIST's opinion at >> that >> > > >> time that they felt comfortable with option one, while >> option two >> >> > > >> would require them to evaluate whether IPSec would be >> > > appropriate for >> > > >> the transport of PMKs. Given that CAPWAP has a requirement >> > > to allow >> > > >> the WTP to perform encryption, this means that PTKs (and >> > > GTKs) would >> > > >> have to be transported over a DTLS session, and therefore I >> wonder >> > > >> whether we would have similar issues as those >> mentioned above. If >> >> > > >> this were an issue, then FIPS certification of any CAPWAP >> > > based system could become impossible. >> > > >> >> > > >> Your comments are appreciated, >> > > >> >> > > >> Pat Calhoun >> > > >> CTO, Wireless Networking Business Unit Cisco Systems >> > > >> _______________________________________________ >> > > >> Capwap mailing list >> > > >> Capwap@frascone.com >> > > >> http://mail.frascone.com/mailman/listinfo/capwap >> > > >> >> > > > _______________________________________________ >> > > > Capwap mailing list >> > > > Capwap@frascone.com >> > > > http://mail.frascone.com/mailman/listinfo/capwap >> > > > >> > > >> > > >> > > _______________________________________________ >> > > Capwap mailing list >> > > Capwap@frascone.com >> > > http://mail.frascone.com/mailman/listinfo/capwap >> > > >> _______________________________________________ >> Capwap mailing list >> Capwap@frascone.com >> http://mail.frascone.com/mailman/listinfo/capwap >> > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap > > _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Wed Oct 05 15:05:25 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENEZx-0006Vt-9w for capwap-archive@megatron.ietf.org; Wed, 05 Oct 2005 15:05:25 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10908 for ; Wed, 5 Oct 2005 15:05:17 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id BCC342046F; Wed, 5 Oct 2005 15:05:03 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by mail.frascone.com (Postfix) with ESMTP id 00A2C20440 for ; Wed, 5 Oct 2005 15:04:19 -0400 (EDT) Message-ID: <078f01c5c9df$966b46b0$196115ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Susan Hares" , "Nancy Winget (ncamwing)" , "Darren Loher" , "Pat Calhoun (pacalhou)" , "Dan Harkins" Cc: References: <6F44D7F6B24A8F4DA0AB46C9BE924F02017DCCFC@VS4.EXCHPROD.USA.NET> Subject: Re: [Capwap] Change Request 9.1.2 (Control Channel Security) MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit 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-Unsubscribe: , List-Id: A list for CAPWAP technical discussions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 5 Oct 2005 12:04:18 -0700 Content-Transfer-Encoding: 7bit Sue, Sure, that's why I think we need something written. It is entirely possible that the process of trying to figure out how it would work would result in realizing that it won't work (something which did, in fact, happen to me recently on another draft). On the other hand, the technical details may be surmountable, thereby allowing LWAPP to accrue the benefits of using what appears likely to be a widely implemented and used security protocol. jak ----- Original Message ----- From: "Susan Hares" To: "James Kempf" ; "Nancy Winget (ncamwing)" ; "Darren Loher" ; "Pat Calhoun (pacalhou)" ; "Dan Harkins" Cc: Sent: Wednesday, October 05, 2005 11:59 AM Subject: RE: [Capwap] Change Request 9.1.2 (Control Channel Security) James: The issues regarding DTLS state machine interaction are not 100% spelled out in the SLAPP proposal. Sue Dan - I believe I've gone through my reasons with you 8-9 months ago. Glad to provide you offline with this information again. -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of James Kempf Sent: Wednesday, October 05, 2005 2:55 PM To: Nancy Winget (ncamwing); Darren Loher; Pat Calhoun (pacalhou); Dan Harkins Cc: capwap@frascone.com Subject: Re: [Capwap] Change Request 9.1.2 (Control Channel Security) Nancy, I think it is only fair to ask for a written proposal (i.e. a draft) about how DTLS would be applied to LWAPP before the WG makes a decision, if only to ensure that the technical details are in order. jak ----- Original Message ----- From: "Nancy Winget (ncamwing)" To: "Darren Loher" ; "Pat Calhoun (pacalhou)" ; "James Kempf" ; "Dan Harkins" Cc: Sent: Wednesday, October 05, 2005 11:35 AM Subject: RE: [Capwap] Change Request 9.1.2 (Control Channel Security) NIST's concern is that care and (re)review is taken when security protocols that were designed for one application are applied to another. In the case of RADIUS, NIST pointed out that both RADIUS and IPSec were complex enough that it was not clearly obvious to them how the use of IPSec would address the key transport security....nor has there been any security analysis to demonstrate what security properties and vulnerabilities IPSec provides when used with RADIUS. As for CAPWAP/LWAPP, it seems that the LWAPP protocol has already undergone security review and has been shown to meet this group's security requirements. So, how does DTLS improve upon the currently proposed security? My concern is that thus far, the adoption of DTLS has been suggested but I've not readily seen how it would be applied. I believe modifications will have to be made to DTLS to ensure it's appropriate use for this group's application. DTLS is fairly open in how it achieves authentication to the point that it does not guarantee (identity) authenticity, so I think that additional specification for how DTLS is applied will be needed. That is, strong recommendations of the options of credential and cipher suites will have to be defined to ensure that this group's security requirements are met. Nancy. -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Darren Loher Sent: Wednesday, October 05, 2005 7:36 AM To: Pat Calhoun (pacalhou); James Kempf; Dan Harkins Cc: capwap@frascone.com Subject: RE: [Capwap] Change Request 9.1.2 (Control Channel Security) I think the main difference between NIST's concern and our scenario is the following: As Pat relayed to us in the RADIUS with IPSec case, there is no way for RADIUS to really know it's using IPSec and therefore does not know if it's transport is secure or not. In the CAPWAP/LWAPP case the control channel is guaranteed to be secure, so it's okay to carry to PTK/GTK within the control channel. So within the context of CAPWAP, there is implicit knowledge that transient keys are using secure transport. -Darren > -----Original Message----- > From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com] > Sent: Wednesday, October 05, 2005 8:08 AM > To: Darren Loher; James Kempf; Dan Harkins > Cc: capwap@frascone.com > Subject: RE: [Capwap] Change Request 9.1.2 (Control Channel Security) > > I think you meant PTK/GTK, but I was just making an observation that the > use of IPSec to carry keys was considered suspicious by NIST. I see a > parallel here in our proposed direction. > > I will follow what the WG feels is right, I was just making sure folks > had additional info I thought was useful. > > Pat Calhoun > CTO, Wireless Networking Business Unit Cisco Systems > > > > > -----Original Message----- > > From: Darren Loher [mailto:DLoher@rovingplanet.com] > > Sent: Sunday, October 02, 2005 12:17 PM > > To: James Kempf; Pat Calhoun (pacalhou); Dan Harkins > > Cc: capwap@frascone.com > > Subject: RE: [Capwap] Change Request 9.1.2 (Control Channel Security) > > > > Regarding secure distribtion of PMK/GMK between AC and WTP, it is > > mandatory that these attributes are sent over the secured control > > channel. So we should be covered on the AC <-> WTP communication. > > > > Isn't the transmission of RADIUS attributes an issue between the AC > > and a AAA server and therefore outside the scope of CAPWAP? > > > > -Darren > > > > ________________________________ > > > > From: capwap-admin@frascone.com on behalf of James Kempf > > Sent: Thu 9/29/2005 9:54 AM > > To: Pat Calhoun (pacalhou); Dan Harkins > > Cc: capwap@frascone.com > > Subject: Re: [Capwap] Change Request 9.1.2 (Control Channel Security) > > > > > > > > I agree with Dan. I think the risk from doing DTLS post-discovery is > > minimal. > > > > Security protocols have a history of bugs turning up after some > > years of deployment. An added benefit of using DTLS is that LWAPP > > benefits from the attention given to DTLS by users of other > > protocols, so any bugs will most likely be found more quickly than > > if LWAPP designs its own, specialized protocol. > > > > Regarding IPsec v.s. DTLS v.s. encryption of the Radius attribute > > for PMK distribution, I don't have any real opinion on this. > > Actually, I think I would prefer to leave this as a deployment > > option, with appropriate text in the Security Considerations section > > about the requirement to use one of these method, and the methods > > are described. I realize that there is an interoperability concern > > here, but I can imagine cases where a network operator might prefer > > one method over another due to their existing deployment. As Dan > > mentioned, the concerns expressed about using IPsec related to > > particular implementation issues rather than any fundamental > > architectural or design issue with the protocol. But I don't have a > > real strong opinion on this, and I can think of reasons why it might > > be a good idea to include a particular "required to implement" > > method too. > > > > > > jak > > > > > > > > ----- Original Message ----- > > From: "Dan Harkins" > > To: "Pat Calhoun (pacalhou)" > > Cc: > > Sent: Wednesday, September 28, 2005 3:16 PM > > Subject: Re: [Capwap] Change Request 9.1.2 (Control Channel Security) > > > > > > > Pat, > > > > > > I agree that the information in the discovery phase is > > benign. Also, > > > anything an attacker could do to at that point is the same > > as what an > > > attacker could do during the DTLS "hello" exchange-- modify > > packets in > > > flight, redirect packets-- and the result would be the same: an > > > unsuccessful DTLS exchange or unsuccessful discovery. An attacker > > > could deny service-- prevent a successful DTLS exchange or > > successful > > > discovery of AC-- but any middlebox can start dropping packets on a > > > whim and do the same thing. I don't believe there is a > > possibility of > > > a resource exhaustion attack or launch a man-in-the-middle attack > > > against the AC or WTP. > > > > > > I don't think we really need to worry about doing DTLS > > post-discovery. > > > > > > To address your call for wider WG response to this recommendation: > > > I strongly believe that (D)TLS should be used for the key > > exchange and > > > authentication protocol. > > > > > > My understanding on the reason that NIST preferred > > AES-KeyWrap over > > > IPsec for the transporting of PMKs had nothing to do with any > > > preceived weakness in IPsec. It was because there is nothing in the > > > IPsec standard to allow a user-space app-- like a RADIUS > > client-- to > > > know whether the packets it is sending are in the clear or > > are IPsec- > > > protected. Therefore a mis-configuration could result in PMKs being > > > sent over-the-wire in-the-clear. (There are IPsec > > implementations that > > > do allow for such queries of the SADB but that isn't part > > of the IPsec > > > standard and therefore there isn't a guarantee that such a > > capability > > > will be available everywhere). Putting the security for passing the > > > PMKs directly into the RADIUS app-- i.e. using > > AES-KeyWrap-- addresses > > > that concern. Therefore I don't believe NIST would have a problem > > > sending PTKs down a (D)TLS-protected link because the app that is > > > sending and receiving them knows whether that link is > > protected or not. > > > > > > Dan. > > > > > > On Wed, 28 Sep 2005 14:32:16 PDT you wrote > > >> The evaluation team has made a request to modify LWAPP's built-in > > >> security mechanism with DTLS instead. This specific change > > is tricky > > >> as we first need to identify whether the DTLS session should be > > >> created prior to, or post, the discovery phase. > > >> > > >> Here are my high level thoughts on the issue: > > >> 1. Pre-Discovery DTLS. > > >> > > >> One of the LWAPP features is load balancing of WTPs among > > ACs. This > > >> load balancing can occur within, or across multiple, ACs. How this > > >> works is that a WTP would perform the discovery phase by > > initiating a > > >> Discovery Request packet to one or more ACs. The receiving ACs > > >> respond with a Discovery Response, which also includes the total > > >> number of WTPs supported (see section 5.2.2), as well as > > its current > > >> WTP load (see section 5.2.3). The WTP collects all of the > > Discovery > > >> Responses, and then decides which AC it wishes to connect > > to based on > > >> its policy. The policy can be either least loaded AC, or through a > > >> list of preferred ACs (see section 7.2.3). Further, the > > WTP can opt > > >> to not establish a session with the AC if it determines > > that it does > > >> not have the basic capabilities required by the AC. > > >> > > >> Performing DTLS prior to the Discovery Request would mean that the > > >> WTP would mean one of two things: > > >> a. The WTP establishes a DTLS session with every AC it > > knows about. > > >> The side effect here is the LWAPP connect time on the WTP, not to > > >> mention the CPU load imposed on the AC. > > >> b. The LWAPP protocol eliminates this feature altogether. > > This means > > >> that a WTP would only connect to the AC of its choice, > > regardless of > > >> the AC's current load of configuration. > > >> > > >> 2. Post-Discovery DTLS. In this mode, the above limitations are > > >> removed, and the Discovery phase is done in the clear. While it is > > >> true that this raises some security concerns, the > > information in the > > >> Discovery Response is relatively benign, and therefore any > > malicious > > >> tweaking (or altering) of the response packet has created limited > > >> damage (although the WG needs to evaluate this, but it was > > not found > > >> to be problematic during the security review). > > >> > > >> This change would also require that the the Discovery packets be > > >> exchanged on a separate UDP port, which is not a big change to the > > >> protocol. > > >> > > >> while I understand the evaluation team's recommendation to adopt > > >> DTLS, I would also like to get a larger WG rough consensus > > on whether > > >> we feel that this change should be made. While I will make > > the change > > >> based on rough consensus, I want to make sure that we > > think and agree > > >> on this decision through as a group. I understand the > > concerns raised > > >> about increasing the time of the protocol development > > phase in having > > >> our own security approach, there are strategies that can > > be done to > > >> help us. For instance, initiate another security review > > with another > > >> reviewer identified by Russ Housely asap (he did recommend > > Charles Clancy, btw). > > >> > > >> I think that another important point here is that during a recent > > >> meeting with NIST, we discussed the transport of 802.11i > > PMKs within > > >> the RADIUS protocol. During this discussion, we proposed > > two methods. > > >> The first would explicitely encrypt the PMK using > > AES-KeyWrap within > > >> a RADIUS attribute. The second approach was simply to encrypt the > > >> whole RADIUS transaction with IPSec. It was NIST's opinion at that > > >> time that they felt comfortable with option one, while option two > > >> would require them to evaluate whether IPSec would be > > appropriate for > > >> the transport of PMKs. Given that CAPWAP has a requirement > > to allow > > >> the WTP to perform encryption, this means that PTKs (and > > GTKs) would > > >> have to be transported over a DTLS session, and therefore I wonder > > >> whether we would have similar issues as those mentioned above. If > > >> this were an issue, then FIPS certification of any CAPWAP > > based system could become impossible. > > >> > > >> Your comments are appreciated, > > >> > > >> Pat Calhoun > > >> CTO, Wireless Networking Business Unit Cisco Systems > > >> _______________________________________________ > > >> Capwap mailing list > > >> Capwap@frascone.com > > >> http://mail.frascone.com/mailman/listinfo/capwap > > >> > > > _______________________________________________ > > > Capwap mailing list > > > Capwap@frascone.com > > > http://mail.frascone.com/mailman/listinfo/capwap > > > > > > > > > _______________________________________________ > > Capwap mailing list > > Capwap@frascone.com > > http://mail.frascone.com/mailman/listinfo/capwap > > _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Wed Oct 05 15:26:28 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENEuJ-0000Ve-3Q for capwap-archive@megatron.ietf.org; Wed, 05 Oct 2005 15:26:28 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12790 for ; Wed, 5 Oct 2005 15:26:20 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 9822C20440; Wed, 5 Oct 2005 15:26:04 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by mail.frascone.com (Postfix) with ESMTP id B7F62203E7 for ; Wed, 5 Oct 2005 15:25:40 -0400 (EDT) Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-2.cisco.com with ESMTP; 05 Oct 2005 12:25:39 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j95JPWKG022915; Wed, 5 Oct 2005 12:25:37 -0700 (PDT) Received: from xmb-sjc-222.amer.cisco.com ([128.107.191.106]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 5 Oct 2005 12:25:34 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Capwap] Change Request 9.1.2 (Control Channel Security) Message-ID: <08A9A3213527A6428774900A80DBD8D8BB8252@xmb-sjc-222.amer.cisco.com> Thread-Topic: [Capwap] Change Request 9.1.2 (Control Channel Security) Thread-Index: AcXJ37Y5YHL/82NnRK+IEd1dvEm18QAAoQpw From: "Nancy Winget (ncamwing)" To: "James Kempf" , "Susan Hares" , "Darren Loher" , "Pat Calhoun (pacalhou)" , "Dan Harkins" Cc: X-OriginalArrivalTime: 05 Oct 2005 19:25:34.0906 (UTC) FILETIME=[8F0309A0:01C5C9E2] 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-Unsubscribe: , List-Id: A list for CAPWAP technical discussions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 5 Oct 2005 12:25:33 -0700 Content-Transfer-Encoding: quoted-printable I wholly agree.....unless we see the proposed integration detailed (and written), it will be hard to assess it's viability not to mention its security properties. It is still not clear to me though, what added benefits DTLS would provide over what has already been proposed in LWAPP? It would be useful to have that data as well. Thanks, Nancy.=20 -----Original Message----- From: James Kempf [mailto:Kempf@docomolabs-usa.com]=20 Sent: Wednesday, October 05, 2005 12:04 PM To: Susan Hares; Nancy Winget (ncamwing); Darren Loher; Pat Calhoun (pacalhou); Dan Harkins Cc: capwap@frascone.com Subject: Re: [Capwap] Change Request 9.1.2 (Control Channel Security)=20 Sue, Sure, that's why I think we need something written. It is entirely possible that the process of trying to figure out how it would work would result in realizing that it won't work (something which did, in fact, happen to me recently on another draft). On the other hand, the technical details may be surmountable, thereby allowing LWAPP to accrue the benefits of using what appears likely to be a widely implemented and used security protocol. jak ----- Original Message ----- From: "Susan Hares" To: "James Kempf" ; "Nancy Winget (ncamwing)"=20 ; "Darren Loher" ; "Pat Calhoun (pacalhou)" ; "Dan Harkins" Cc: Sent: Wednesday, October 05, 2005 11:59 AM Subject: RE: [Capwap] Change Request 9.1.2 (Control Channel Security) James: The issues regarding DTLS state machine interaction are not 100% spelled out in the SLAPP proposal. Sue Dan - I believe I've gone through my reasons with you 8-9 months ago. Glad to provide you offline with this information again. -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of James Kempf Sent: Wednesday, October 05, 2005 2:55 PM To: Nancy Winget (ncamwing); Darren Loher; Pat Calhoun (pacalhou); Dan Harkins Cc: capwap@frascone.com Subject: Re: [Capwap] Change Request 9.1.2 (Control Channel Security) Nancy, I think it is only fair to ask for a written proposal (i.e. a draft) about how DTLS would be applied to LWAPP before the WG makes a decision, if only to ensure that the technical details are in order. jak ----- Original Message ----- From: "Nancy Winget (ncamwing)" To: "Darren Loher" ; "Pat Calhoun (pacalhou)" ; "James Kempf" ; "Dan Harkins" Cc: Sent: Wednesday, October 05, 2005 11:35 AM Subject: RE: [Capwap] Change Request 9.1.2 (Control Channel Security) NIST's concern is that care and (re)review is taken when security protocols that were designed for one application are applied to another. In the case of RADIUS, NIST pointed out that both RADIUS and IPSec were complex enough that it was not clearly obvious to them how the use of IPSec would address the key transport security....nor has there been any security analysis to demonstrate what security properties and vulnerabilities IPSec provides when used with RADIUS. As for CAPWAP/LWAPP, it seems that the LWAPP protocol has already undergone security review and has been shown to meet this group's security requirements. So, how does DTLS improve upon the currently proposed security? My concern is that thus far, the adoption of DTLS has been suggested but I've not readily seen how it would be applied. I believe modifications will have to be made to DTLS to ensure it's appropriate use for this group's application. DTLS is fairly open in how it achieves authentication to the point that it does not guarantee (identity) authenticity, so I think that additional specification for how DTLS is applied will be needed. That is, strong recommendations of the options of credential and cipher suites will have to be defined to ensure that this group's security requirements are met. Nancy. -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Darren Loher Sent: Wednesday, October 05, 2005 7:36 AM To: Pat Calhoun (pacalhou); James Kempf; Dan Harkins Cc: capwap@frascone.com Subject: RE: [Capwap] Change Request 9.1.2 (Control Channel Security) I think the main difference between NIST's concern and our scenario is the following: As Pat relayed to us in the RADIUS with IPSec case, there is no way for RADIUS to really know it's using IPSec and therefore does not know if it's transport is secure or not. In the CAPWAP/LWAPP case the control channel is guaranteed to be secure, so it's okay to carry to PTK/GTK within the control channel. So within the context of CAPWAP, there is implicit knowledge that transient keys are using secure transport. -Darren > -----Original Message----- > From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com] > Sent: Wednesday, October 05, 2005 8:08 AM > To: Darren Loher; James Kempf; Dan Harkins > Cc: capwap@frascone.com > Subject: RE: [Capwap] Change Request 9.1.2 (Control Channel Security) > > I think you meant PTK/GTK, but I was just making an observation that the > use of IPSec to carry keys was considered suspicious by NIST. I see a > parallel here in our proposed direction. > > I will follow what the WG feels is right, I was just making sure folks > had additional info I thought was useful. > > Pat Calhoun > CTO, Wireless Networking Business Unit Cisco Systems > > > > > -----Original Message----- > > From: Darren Loher [mailto:DLoher@rovingplanet.com] > > Sent: Sunday, October 02, 2005 12:17 PM > > To: James Kempf; Pat Calhoun (pacalhou); Dan Harkins > > Cc: capwap@frascone.com > > Subject: RE: [Capwap] Change Request 9.1.2 (Control Channel Security) > > > > Regarding secure distribtion of PMK/GMK between AC and WTP, it is > > mandatory that these attributes are sent over the secured control > > channel. So we should be covered on the AC <-> WTP communication. > > > > Isn't the transmission of RADIUS attributes an issue between the AC > > and a AAA server and therefore outside the scope of CAPWAP? > > > > -Darren > > > > ________________________________ > > > > From: capwap-admin@frascone.com on behalf of James Kempf > > Sent: Thu 9/29/2005 9:54 AM > > To: Pat Calhoun (pacalhou); Dan Harkins > > Cc: capwap@frascone.com > > Subject: Re: [Capwap] Change Request 9.1.2 (Control Channel Security) > > > > > > > > I agree with Dan. I think the risk from doing DTLS post-discovery is > > minimal. > > > > Security protocols have a history of bugs turning up after some > > years of deployment. An added benefit of using DTLS is that LWAPP > > benefits from the attention given to DTLS by users of other > > protocols, so any bugs will most likely be found more quickly than > > if LWAPP designs its own, specialized protocol. > > > > Regarding IPsec v.s. DTLS v.s. encryption of the Radius attribute > > for PMK distribution, I don't have any real opinion on this. > > Actually, I think I would prefer to leave this as a deployment > > option, with appropriate text in the Security Considerations section > > about the requirement to use one of these method, and the methods > > are described. I realize that there is an interoperability concern > > here, but I can imagine cases where a network operator might prefer > > one method over another due to their existing deployment. As Dan > > mentioned, the concerns expressed about using IPsec related to > > particular implementation issues rather than any fundamental > > architectural or design issue with the protocol. But I don't have a > > real strong opinion on this, and I can think of reasons why it might > > be a good idea to include a particular "required to implement" > > method too. > > > > > > jak > > > > > > > > ----- Original Message ----- > > From: "Dan Harkins" > > To: "Pat Calhoun (pacalhou)" > > Cc: > > Sent: Wednesday, September 28, 2005 3:16 PM > > Subject: Re: [Capwap] Change Request 9.1.2 (Control Channel Security) > > > > > > > Pat, > > > > > > I agree that the information in the discovery phase is > > benign. Also, > > > anything an attacker could do to at that point is the same > > as what an > > > attacker could do during the DTLS "hello" exchange-- modify > > packets in > > > flight, redirect packets-- and the result would be the same: an > > > unsuccessful DTLS exchange or unsuccessful discovery. An attacker > > > could deny service-- prevent a successful DTLS exchange or > > successful > > > discovery of AC-- but any middlebox can start dropping packets on a > > > whim and do the same thing. I don't believe there is a > > possibility of > > > a resource exhaustion attack or launch a man-in-the-middle attack > > > against the AC or WTP. > > > > > > I don't think we really need to worry about doing DTLS > > post-discovery. > > > > > > To address your call for wider WG response to this recommendation: > > > I strongly believe that (D)TLS should be used for the key > > exchange and > > > authentication protocol. > > > > > > My understanding on the reason that NIST preferred > > AES-KeyWrap over > > > IPsec for the transporting of PMKs had nothing to do with any > > > preceived weakness in IPsec. It was because there is nothing in the > > > IPsec standard to allow a user-space app-- like a RADIUS > > client-- to > > > know whether the packets it is sending are in the clear or > > are IPsec- > > > protected. Therefore a mis-configuration could result in PMKs being > > > sent over-the-wire in-the-clear. (There are IPsec > > implementations that > > > do allow for such queries of the SADB but that isn't part > > of the IPsec > > > standard and therefore there isn't a guarantee that such a > > capability > > > will be available everywhere). Putting the security for passing the > > > PMKs directly into the RADIUS app-- i.e. using > > AES-KeyWrap-- addresses > > > that concern. Therefore I don't believe NIST would have a problem > > > sending PTKs down a (D)TLS-protected link because the app that is > > > sending and receiving them knows whether that link is > > protected or not. > > > > > > Dan. > > > > > > On Wed, 28 Sep 2005 14:32:16 PDT you wrote > > >> The evaluation team has made a request to modify LWAPP's built-in > > >> security mechanism with DTLS instead. This specific change > > is tricky > > >> as we first need to identify whether the DTLS session should be > > >> created prior to, or post, the discovery phase. > > >> > > >> Here are my high level thoughts on the issue: > > >> 1. Pre-Discovery DTLS. > > >> > > >> One of the LWAPP features is load balancing of WTPs among > > ACs. This > > >> load balancing can occur within, or across multiple, ACs. How this > > >> works is that a WTP would perform the discovery phase by > > initiating a > > >> Discovery Request packet to one or more ACs. The receiving ACs > > >> respond with a Discovery Response, which also includes the total > > >> number of WTPs supported (see section 5.2.2), as well as > > its current > > >> WTP load (see section 5.2.3). The WTP collects all of the > > Discovery > > >> Responses, and then decides which AC it wishes to connect > > to based on > > >> its policy. The policy can be either least loaded AC, or through a > > >> list of preferred ACs (see section 7.2.3). Further, the > > WTP can opt > > >> to not establish a session with the AC if it determines > > that it does > > >> not have the basic capabilities required by the AC. > > >> > > >> Performing DTLS prior to the Discovery Request would mean that the > > >> WTP would mean one of two things: > > >> a. The WTP establishes a DTLS session with every AC it > > knows about. > > >> The side effect here is the LWAPP connect time on the WTP, not to > > >> mention the CPU load imposed on the AC. > > >> b. The LWAPP protocol eliminates this feature altogether. > > This means > > >> that a WTP would only connect to the AC of its choice, > > regardless of > > >> the AC's current load of configuration. > > >> > > >> 2. Post-Discovery DTLS. In this mode, the above limitations are > > >> removed, and the Discovery phase is done in the clear. While it is > > >> true that this raises some security concerns, the > > information in the > > >> Discovery Response is relatively benign, and therefore any > > malicious > > >> tweaking (or altering) of the response packet has created limited > > >> damage (although the WG needs to evaluate this, but it was > > not found > > >> to be problematic during the security review). > > >> > > >> This change would also require that the the Discovery packets be > > >> exchanged on a separate UDP port, which is not a big change to the > > >> protocol. > > >> > > >> while I understand the evaluation team's recommendation to adopt > > >> DTLS, I would also like to get a larger WG rough consensus > > on whether > > >> we feel that this change should be made. While I will make > > the change > > >> based on rough consensus, I want to make sure that we > > think and agree > > >> on this decision through as a group. I understand the > > concerns raised > > >> about increasing the time of the protocol development > > phase in having > > >> our own security approach, there are strategies that can > > be done to > > >> help us. For instance, initiate another security review > > with another > > >> reviewer identified by Russ Housely asap (he did recommend > > Charles Clancy, btw). > > >> > > >> I think that another important point here is that during a recent > > >> meeting with NIST, we discussed the transport of 802.11i > > PMKs within > > >> the RADIUS protocol. During this discussion, we proposed > > two methods. > > >> The first would explicitely encrypt the PMK using > > AES-KeyWrap within > > >> a RADIUS attribute. The second approach was simply to encrypt the > > >> whole RADIUS transaction with IPSec. It was NIST's opinion at that > > >> time that they felt comfortable with option one, while option two > > >> would require them to evaluate whether IPSec would be > > appropriate for > > >> the transport of PMKs. Given that CAPWAP has a requirement > > to allow > > >> the WTP to perform encryption, this means that PTKs (and > > GTKs) would > > >> have to be transported over a DTLS session, and therefore I wonder > > >> whether we would have similar issues as those mentioned above. If > > >> this were an issue, then FIPS certification of any CAPWAP > > based system could become impossible. > > >> > > >> Your comments are appreciated, > > >> > > >> Pat Calhoun > > >> CTO, Wireless Networking Business Unit Cisco Systems > > >> _______________________________________________ > > >> Capwap mailing list > > >> Capwap@frascone.com > > >> http://mail.frascone.com/mailman/listinfo/capwap > > >> > > > _______________________________________________ > > > Capwap mailing list > > > Capwap@frascone.com > > > http://mail.frascone.com/mailman/listinfo/capwap > > > > > > > > > _______________________________________________ > > Capwap mailing list > > Capwap@frascone.com > > http://mail.frascone.com/mailman/listinfo/capwap > > _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Wed Oct 05 15:59:26 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENFQD-0008F8-Nb for capwap-archive@megatron.ietf.org; Wed, 05 Oct 2005 15:59:26 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14058 for ; Wed, 5 Oct 2005 15:59:19 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id F16CD2044C; Wed, 5 Oct 2005 15:59:03 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from homebrew.trpz.com (66-7-225-40.cust.telepacific.net [66.7.225.40]) by mail.frascone.com (Postfix) with ESMTP id DDCE6203E7 for ; Wed, 5 Oct 2005 15:58:03 -0400 (EDT) Received: from trpz.com (localhost.trpz.com [127.0.0.1]) by homebrew.trpz.com (8.13.1/8.13.1) with ESMTP id j95JpCWW080607; Wed, 5 Oct 2005 12:51:12 -0700 (PDT) (envelope-from dharkins@trpz.com) Message-Id: <200510051951.j95JpCWW080607@homebrew.trpz.com> To: "Nancy Winget (ncamwing)" Cc: "Darren Loher" , "Pat Calhoun (pacalhou)" , "James Kempf" , capwap@frascone.com, ekr@rtfm.com Subject: Re: [Capwap] Change Request 9.1.2 (Control Channel Security) In-Reply-To: Your message of "Wed, 05 Oct 2005 11:35:39 PDT." <08A9A3213527A6428774900A80DBD8D8BB821E@xmb-sjc-222.amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <80605.1128541872.1@trpz.com> From: Dan Harkins 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-Unsubscribe: , List-Id: A list for CAPWAP technical discussions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 05 Oct 2005 12:51:12 -0700 Nancy, IPsec was designed to protect IP and anything that rides on top of it, it was not designed for one specific "application". Much care and review was put into it to ensure that it met its design goals. If you know of any security analysis that demonstrate a vulnerability that IPsec has with respect to that design than please tell us. Since RADIUS uses UDP which rides on top of IP then IPsec is designed to protect it. If you know of anything specific to RADIUS that would make it vulnerable if protected by IPsec then please tell us, it would be a great service to the industry. TLS has had much more security review than LWAPP (whose security was deemed "adequate"). You say that modifications will have to be made to DTLS to ensure it's appropriate for use with CAPWAP. Please elaborate. What parts of DTLS need modification and why? Having a strong recommendation in CAPWAP on which ciphersuites to use is a fantastic idea but the necessity of that should not derail the whole idea of using a secure, standards-based protocol. I think the onus is on someone who insists on reinventing the wheel on why it is necessary or why this new wheel will be more round than the one we already have. Dan. On Wed, 05 Oct 2005 11:35:39 PDT you wrote > > NIST's concern is that care and (re)review is taken when security > protocols that were designed for one application are applied to another. > In the case of RADIUS, NIST pointed out that both RADIUS and IPSec were > complex enough that it was not clearly obvious to them how the use of > IPSec would address the key transport security....nor has there been any > security analysis to demonstrate what security properties and > vulnerabilities IPSec provides when used with RADIUS. > > As for CAPWAP/LWAPP, it seems that the LWAPP protocol has already > undergone security review and has been shown to meet this group's > security requirements. So, how does DTLS improve upon the currently > proposed security? > > My concern is that thus far, the adoption of DTLS has been suggested but > I've not readily seen how it would be applied. I believe modifications > will have to be made to DTLS to ensure it's appropriate use for this > group's application. DTLS is fairly open in how it achieves > authentication to the point that it does not guarantee (identity) > authenticity, so I think that additional specification for how DTLS is > applied will be needed. That is, strong recommendations of the options > of credential and cipher suites will have to be defined to ensure that > this group's security requirements are met. > > Nancy. > > -----Original Message----- > From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On > Behalf Of Darren Loher > Sent: Wednesday, October 05, 2005 7:36 AM > To: Pat Calhoun (pacalhou); James Kempf; Dan Harkins > Cc: capwap@frascone.com > Subject: RE: [Capwap] Change Request 9.1.2 (Control Channel Security) > > I think the main difference between NIST's concern and our scenario is > the following: > > As Pat relayed to us in the RADIUS with IPSec case, there is no way for > RADIUS to really know it's using IPSec and therefore does not know if > it's transport is secure or not. > > In the CAPWAP/LWAPP case the control channel is guaranteed to be secure, > so it's okay to carry to PTK/GTK within the control channel. So within > the context of CAPWAP, there is implicit knowledge that transient keys > are using secure transport. > > -Darren > > > -----Original Message----- > > From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com] > > Sent: Wednesday, October 05, 2005 8:08 AM > > To: Darren Loher; James Kempf; Dan Harkins > > Cc: capwap@frascone.com > > Subject: RE: [Capwap] Change Request 9.1.2 (Control Channel Security) > > > > I think you meant PTK/GTK, but I was just making an observation that > the > > use of IPSec to carry keys was considered suspicious by NIST. I see a > > parallel here in our proposed direction. > > > > I will follow what the WG feels is right, I was just making sure folks > > > had additional info I thought was useful. > > > > Pat Calhoun > > CTO, Wireless Networking Business Unit Cisco Systems > > > > > > > > > -----Original Message----- > > > From: Darren Loher [mailto:DLoher@rovingplanet.com] > > > Sent: Sunday, October 02, 2005 12:17 PM > > > To: James Kempf; Pat Calhoun (pacalhou); Dan Harkins > > > Cc: capwap@frascone.com > > > Subject: RE: [Capwap] Change Request 9.1.2 (Control Channel > Security) > > > > > > Regarding secure distribtion of PMK/GMK between AC and WTP, it is > > > mandatory that these attributes are sent over the secured control > > > channel. So we should be covered on the AC <-> WTP communication. > > > > > > Isn't the transmission of RADIUS attributes an issue between the AC > > > and a AAA server and therefore outside the scope of CAPWAP? > > > > > > -Darren > > > > > > ________________________________ > > > > > > From: capwap-admin@frascone.com on behalf of James Kempf > > > Sent: Thu 9/29/2005 9:54 AM > > > To: Pat Calhoun (pacalhou); Dan Harkins > > > Cc: capwap@frascone.com > > > Subject: Re: [Capwap] Change Request 9.1.2 (Control Channel > Security) > > > > > > > > > > > > I agree with Dan. I think the risk from doing DTLS post-discovery is > > > > minimal. > > > > > > Security protocols have a history of bugs turning up after some > > > years of deployment. An added benefit of using DTLS is that LWAPP > > > benefits from the attention given to DTLS by users of other > > > protocols, so any bugs will most likely be found more quickly than > > > if LWAPP designs its own, specialized protocol. > > > > > > Regarding IPsec v.s. DTLS v.s. encryption of the Radius attribute > > > for PMK distribution, I don't have any real opinion on this. > > > Actually, I think I would prefer to leave this as a deployment > > > option, with appropriate text in the Security Considerations section > > > > about the requirement to use one of these method, and the methods > > > are described. I realize that there is an interoperability concern > > > here, but I can imagine cases where a network operator might prefer > > > one method over another due to their existing deployment. As Dan > > > mentioned, the concerns expressed about using IPsec related to > > > particular implementation issues rather than any fundamental > > > architectural or design issue with the protocol. But I don't have a > > > real strong opinion on this, and I can think of reasons why it might > > > > be a good idea to include a particular "required to implement" > > > method too. > > > > > > > > > jak > > > > > > > > > > > > ----- Original Message ----- > > > From: "Dan Harkins" > > > To: "Pat Calhoun (pacalhou)" > > > Cc: > > > Sent: Wednesday, September 28, 2005 3:16 PM > > > Subject: Re: [Capwap] Change Request 9.1.2 (Control Channel > Security) > > > > > > > > > > Pat, > > > > > > > > I agree that the information in the discovery phase is > > > benign. Also, > > > > anything an attacker could do to at that point is the same > > > as what an > > > > attacker could do during the DTLS "hello" exchange-- modify > > > packets in > > > > flight, redirect packets-- and the result would be the same: an > > > > unsuccessful DTLS exchange or unsuccessful discovery. An attacker > > > > could deny service-- prevent a successful DTLS exchange or > > > successful > > > > discovery of AC-- but any middlebox can start dropping packets on > a > > > > whim and do the same thing. I don't believe there is a > > > possibility of > > > > a resource exhaustion attack or launch a man-in-the-middle attack > > > > against the AC or WTP. > > > > > > > > I don't think we really need to worry about doing DTLS > > > post-discovery. > > > > > > > > To address your call for wider WG response to this > recommendation: > > > > I strongly believe that (D)TLS should be used for the key > > > exchange and > > > > authentication protocol. > > > > > > > > My understanding on the reason that NIST preferred > > > AES-KeyWrap over > > > > IPsec for the transporting of PMKs had nothing to do with any > > > > preceived weakness in IPsec. It was because there is nothing in > the > > > > IPsec standard to allow a user-space app-- like a RADIUS > > > client-- to > > > > know whether the packets it is sending are in the clear or > > > are IPsec- > > > > protected. Therefore a mis-configuration could result in PMKs > being > > > > sent over-the-wire in-the-clear. (There are IPsec > > > implementations that > > > > do allow for such queries of the SADB but that isn't part > > > of the IPsec > > > > standard and therefore there isn't a guarantee that such a > > > capability > > > > will be available everywhere). Putting the security for passing > the > > > > PMKs directly into the RADIUS app-- i.e. using > > > AES-KeyWrap-- addresses > > > > that concern. Therefore I don't believe NIST would have a problem > > > > sending PTKs down a (D)TLS-protected link because the app that is > > > > sending and receiving them knows whether that link is > > > protected or not. > > > > > > > > Dan. > > > > > > > > On Wed, 28 Sep 2005 14:32:16 PDT you wrote > > > >> The evaluation team has made a request to modify LWAPP's built-in > > > > >> security mechanism with DTLS instead. This specific change > > > is tricky > > > >> as we first need to identify whether the DTLS session should be > > > >> created prior to, or post, the discovery phase. > > > >> > > > >> Here are my high level thoughts on the issue: > > > >> 1. Pre-Discovery DTLS. > > > >> > > > >> One of the LWAPP features is load balancing of WTPs among > > > ACs. This > > > >> load balancing can occur within, or across multiple, ACs. How > this > > > >> works is that a WTP would perform the discovery phase by > > > initiating a > > > >> Discovery Request packet to one or more ACs. The receiving ACs > > > >> respond with a Discovery Response, which also includes the total > > > >> number of WTPs supported (see section 5.2.2), as well as > > > its current > > > >> WTP load (see section 5.2.3). The WTP collects all of the > > > Discovery > > > >> Responses, and then decides which AC it wishes to connect > > > to based on > > > >> its policy. The policy can be either least loaded AC, or through > a > > > >> list of preferred ACs (see section 7.2.3). Further, the > > > WTP can opt > > > >> to not establish a session with the AC if it determines > > > that it does > > > >> not have the basic capabilities required by the AC. > > > >> > > > >> Performing DTLS prior to the Discovery Request would mean that > the > > > >> WTP would mean one of two things: > > > >> a. The WTP establishes a DTLS session with every AC it > > > knows about. > > > >> The side effect here is the LWAPP connect time on the WTP, not to > > > > >> mention the CPU load imposed on the AC. > > > >> b. The LWAPP protocol eliminates this feature altogether. > > > This means > > > >> that a WTP would only connect to the AC of its choice, > > > regardless of > > > >> the AC's current load of configuration. > > > >> > > > >> 2. Post-Discovery DTLS. In this mode, the above limitations are > > > >> removed, and the Discovery phase is done in the clear. While it > is > > > >> true that this raises some security concerns, the > > > information in the > > > >> Discovery Response is relatively benign, and therefore any > > > malicious > > > >> tweaking (or altering) of the response packet has created limited > > > > >> damage (although the WG needs to evaluate this, but it was > > > not found > > > >> to be problematic during the security review). > > > >> > > > >> This change would also require that the the Discovery packets be > > > >> exchanged on a separate UDP port, which is not a big change to > the > > > >> protocol. > > > >> > > > >> while I understand the evaluation team's recommendation to adopt > > > >> DTLS, I would also like to get a larger WG rough consensus > > > on whether > > > >> we feel that this change should be made. While I will make > > > the change > > > >> based on rough consensus, I want to make sure that we > > > think and agree > > > >> on this decision through as a group. I understand the > > > concerns raised > > > >> about increasing the time of the protocol development > > > phase in having > > > >> our own security approach, there are strategies that can > > > be done to > > > >> help us. For instance, initiate another security review > > > with another > > > >> reviewer identified by Russ Housely asap (he did recommend > > > Charles Clancy, btw). > > > >> > > > >> I think that another important point here is that during a recent > > > > >> meeting with NIST, we discussed the transport of 802.11i > > > PMKs within > > > >> the RADIUS protocol. During this discussion, we proposed > > > two methods. > > > >> The first would explicitely encrypt the PMK using > > > AES-KeyWrap within > > > >> a RADIUS attribute. The second approach was simply to encrypt the > > > > >> whole RADIUS transaction with IPSec. It was NIST's opinion at > that > > > >> time that they felt comfortable with option one, while option two > > > > >> would require them to evaluate whether IPSec would be > > > appropriate for > > > >> the transport of PMKs. Given that CAPWAP has a requirement > > > to allow > > > >> the WTP to perform encryption, this means that PTKs (and > > > GTKs) would > > > >> have to be transported over a DTLS session, and therefore I > wonder > > > >> whether we would have similar issues as those mentioned above. If > > > > >> this were an issue, then FIPS certification of any CAPWAP > > > based system could become impossible. > > > >> > > > >> Your comments are appreciated, > > > >> > > > >> Pat Calhoun > > > >> CTO, Wireless Networking Business Unit Cisco Systems > > > >> _______________________________________________ > > > >> Capwap mailing list > > > >> Capwap@frascone.com > > > >> http://mail.frascone.com/mailman/listinfo/capwap > > > >> > > > > _______________________________________________ > > > > Capwap mailing list > > > > Capwap@frascone.com > > > > http://mail.frascone.com/mailman/listinfo/capwap > > > > > > > > > > > > > _______________________________________________ > > > Capwap mailing list > > > Capwap@frascone.com > > > http://mail.frascone.com/mailman/listinfo/capwap > > > > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap > _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Wed Oct 05 16:10:50 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENFaw-0000Cn-FX for capwap-archive@megatron.ietf.org; Wed, 05 Oct 2005 16:10:50 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14447 for ; Wed, 5 Oct 2005 16:10:22 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 505D520477; Wed, 5 Oct 2005 16:10:05 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from homebrew.trpz.com (66-7-225-40.cust.telepacific.net [66.7.225.40]) by mail.frascone.com (Postfix) with ESMTP id 527F2203E7 for ; Wed, 5 Oct 2005 16:09:55 -0400 (EDT) Received: from trpz.com (localhost.trpz.com [127.0.0.1]) by homebrew.trpz.com (8.13.1/8.13.1) with ESMTP id j95K3Y3T080672; Wed, 5 Oct 2005 13:03:34 -0700 (PDT) (envelope-from dharkins@trpz.com) Message-Id: <200510052003.j95K3Y3T080672@homebrew.trpz.com> To: "Scott G. Kelly" Cc: "Nancy Winget (ncamwing)" , James Kempf , Susan Hares , Darren Loher , "Pat Calhoun (pacalhou)" , capwap@frascone.com Subject: Re: [Capwap] Change Request 9.1.2 (Control Channel Security) In-Reply-To: Your message of "Wed, 05 Oct 2005 12:33:18 PDT." <11270185.1128540798568.JavaMail.root@elwamui-norfolk.atl.sa.earthlink.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <80670.1128542614.1@trpz.com> From: Dan Harkins 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-Unsubscribe: , List-Id: A list for CAPWAP technical discussions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 05 Oct 2005 13:03:34 -0700 Scott, I agree 100%. We don't need to reinvent the wheel. Dan. On Wed, 05 Oct 2005 12:33:18 PDT you wrote > [This reply won't hit the capwap list until the admin releases it, since I'm >using webmail and the account address is not the one from which I'm suscribed] > > Here are a few benefits: > > - DTLS is based on TLS (which is based on SSL); this suite has been around fo >r quite some time, and has received extensive ongoing review by a large commun >ity. This is valuable. > > - DTLS supports parameter negotiation. If one of the crypto algorithms used b >y LWAPP is broken (or found to have weaknesses), we have but to change the rec >ommended ciphers (not forklift the protocol). > > I think these alone are strong enough justification for contemplating the cha >nge. > > Scott > > -----Original Message----- > From: "Nancy Winget (ncamwing)" > Sent: Oct 5, 2005 12:25 PM > To: James Kempf , Susan Hares , Da >rren Loher , "Pat Calhoun (pacalhou)" .com>, Dan Harkins > Cc: capwap@frascone.com > Subject: RE: [Capwap] Change Request 9.1.2 (Control Channel Security) > > > I wholly agree.....unless we see the proposed integration detailed (and > written), it will be hard to assess it's viability not to mention its > security properties. It is still not clear to me though, what added > benefits DTLS would provide over what has already been proposed in > LWAPP? It would be useful to have that data as well. > > Thanks, > > Nancy. > > -----Original Message----- > From: James Kempf [mailto:Kempf@docomolabs-usa.com] > Sent: Wednesday, October 05, 2005 12:04 PM > To: Susan Hares; Nancy Winget (ncamwing); Darren Loher; Pat Calhoun > (pacalhou); Dan Harkins > Cc: capwap@frascone.com > Subject: Re: [Capwap] Change Request 9.1.2 (Control Channel Security) > > Sue, > > Sure, that's why I think we need something written. It is entirely > possible that the process of trying to figure out how it would work > would result in realizing that it won't work (something which did, in > fact, happen to me recently on another draft). On the other hand, the > technical details may be surmountable, thereby allowing LWAPP to accrue > the benefits of using what appears likely to be a widely implemented and > used security protocol. > > jak > > ----- Original Message ----- > From: "Susan Hares" > To: "James Kempf" ; "Nancy Winget (ncamwing)" > ; "Darren Loher" ; "Pat > Calhoun (pacalhou)" ; "Dan Harkins" > > Cc: > Sent: Wednesday, October 05, 2005 11:59 AM > Subject: RE: [Capwap] Change Request 9.1.2 (Control Channel Security) > > > James: > > The issues regarding DTLS state machine interaction are not 100% spelled > out in the SLAPP proposal. > > Sue > > Dan - I believe I've gone through my reasons with you 8-9 months ago. > Glad to provide you offline with this information again. > > -----Original Message----- > From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On > Behalf Of James Kempf > Sent: Wednesday, October 05, 2005 2:55 PM > To: Nancy Winget (ncamwing); Darren Loher; Pat Calhoun (pacalhou); Dan > Harkins > Cc: capwap@frascone.com > Subject: Re: [Capwap] Change Request 9.1.2 (Control Channel Security) > > Nancy, > > I think it is only fair to ask for a written proposal (i.e. a draft) > about how DTLS would be applied to LWAPP before the WG makes a decision, > if only to ensure that the technical details are in order. > > jak > > > ----- Original Message ----- > From: "Nancy Winget (ncamwing)" > To: "Darren Loher" ; "Pat Calhoun (pacalhou)" > ; "James Kempf" ; "Dan > Harkins" > Cc: > Sent: Wednesday, October 05, 2005 11:35 AM > Subject: RE: [Capwap] Change Request 9.1.2 (Control Channel Security) > > > > NIST's concern is that care and (re)review is taken when security > protocols that were designed for one application are applied to another. > In the case of RADIUS, NIST pointed out that both RADIUS and IPSec were > complex enough that it was not clearly obvious to them how the use of > IPSec would address the key transport security....nor has there been any > security analysis to demonstrate what security properties and > vulnerabilities IPSec provides when used with RADIUS. > > As for CAPWAP/LWAPP, it seems that the LWAPP protocol has already > undergone security review and has been shown to meet this group's > security requirements. So, how does DTLS improve upon the currently > proposed security? > > My concern is that thus far, the adoption of DTLS has been suggested but > I've not readily seen how it would be applied. I believe modifications > will have to be made to DTLS to ensure it's appropriate use for this > group's application. DTLS is fairly open in how it achieves > authentication to the point that it does not guarantee (identity) > authenticity, so I think that additional specification for how DTLS is > applied will be needed. That is, strong recommendations of the options > of credential and cipher suites will have to be defined to ensure that > this group's security requirements are met. > > Nancy. > > -----Original Message----- > From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On > Behalf Of Darren Loher > Sent: Wednesday, October 05, 2005 7:36 AM > To: Pat Calhoun (pacalhou); James Kempf; Dan Harkins > Cc: capwap@frascone.com > Subject: RE: [Capwap] Change Request 9.1.2 (Control Channel Security) > > I think the main difference between NIST's concern and our scenario is > the following: > > As Pat relayed to us in the RADIUS with IPSec case, there is no way for > RADIUS to really know it's using IPSec and therefore does not know if > it's transport is secure or not. > > In the CAPWAP/LWAPP case the control channel is guaranteed to be secure, > so it's okay to carry to PTK/GTK within the control channel. So within > the context of CAPWAP, there is implicit knowledge that transient keys > are using secure transport. > > -Darren > > > -----Original Message----- > > From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com] > > Sent: Wednesday, October 05, 2005 8:08 AM > > To: Darren Loher; James Kempf; Dan Harkins > > Cc: capwap@frascone.com > > Subject: RE: [Capwap] Change Request 9.1.2 (Control Channel Security) > > > > I think you meant PTK/GTK, but I was just making an observation that > the > > use of IPSec to carry keys was considered suspicious by NIST. I see a > > parallel here in our proposed direction. > > > > I will follow what the WG feels is right, I was just making sure folks > > > had additional info I thought was useful. > > > > Pat Calhoun > > CTO, Wireless Networking Business Unit Cisco Systems > > > > > > > > > -----Original Message----- > > > From: Darren Loher [mailto:DLoher@rovingplanet.com] > > > Sent: Sunday, October 02, 2005 12:17 PM > > > To: James Kempf; Pat Calhoun (pacalhou); Dan Harkins > > > Cc: capwap@frascone.com > > > Subject: RE: [Capwap] Change Request 9.1.2 (Control Channel > Security) > > > > > > Regarding secure distribtion of PMK/GMK between AC and WTP, it is > > > mandatory that these attributes are sent over the secured control > > > channel. So we should be covered on the AC <-> WTP communication. > > > > > > Isn't the transmission of RADIUS attributes an issue between the AC > > > and a AAA server and therefore outside the scope of CAPWAP? > > > > > > -Darren > > > > > > ________________________________ > > > > > > From: capwap-admin@frascone.com on behalf of James Kempf > > > Sent: Thu 9/29/2005 9:54 AM > > > To: Pat Calhoun (pacalhou); Dan Harkins > > > Cc: capwap@frascone.com > > > Subject: Re: [Capwap] Change Request 9.1.2 (Control Channel > Security) > > > > > > > > > > > > I agree with Dan. I think the risk from doing DTLS post-discovery is > > > > minimal. > > > > > > Security protocols have a history of bugs turning up after some > > > years of deployment. An added benefit of using DTLS is that LWAPP > > > benefits from the attention given to DTLS by users of other > > > protocols, so any bugs will most likely be found more quickly than > > > if LWAPP designs its own, specialized protocol. > > > > > > Regarding IPsec v.s. DTLS v.s. encryption of the Radius attribute > > > for PMK distribution, I don't have any real opinion on this. > > > Actually, I think I would prefer to leave this as a deployment > > > option, with appropriate text in the Security Considerations section > > > > about the requirement to use one of these method, and the methods > > > are described. I realize that there is an interoperability concern > > > here, but I can imagine cases where a network operator might prefer > > > one method over another due to their existing deployment. As Dan > > > mentioned, the concerns expressed about using IPsec related to > > > particular implementation issues rather than any fundamental > > > architectural or design issue with the protocol. But I don't have a > > > real strong opinion on this, and I can think of reasons why it might > > > > be a good idea to include a particular "required to implement" > > > method too. > > > > > > > > > jak > > > > > > > > > > > > ----- Original Message ----- > > > From: "Dan Harkins" > > > To: "Pat Calhoun (pacalhou)" > > > Cc: > > > Sent: Wednesday, September 28, 2005 3:16 PM > > > Subject: Re: [Capwap] Change Request 9.1.2 (Control Channel Security) > > > > > > > > > > Pat, > > > > > > > > I agree that the information in the discovery phase is > > > benign. Also, > > > > anything an attacker could do to at that point is the same > > > as what an > > > > attacker could do during the DTLS "hello" exchange-- modify > > > packets in > > > > flight, redirect packets-- and the result would be the same: an > > > > unsuccessful DTLS exchange or unsuccessful discovery. An attacker > > > > could deny service-- prevent a successful DTLS exchange or > > > successful > > > > discovery of AC-- but any middlebox can start dropping packets on > a > > > > whim and do the same thing. I don't believe there is a > > > possibility of > > > > a resource exhaustion attack or launch a man-in-the-middle attack > > > > against the AC or WTP. > > > > > > > > I don't think we really need to worry about doing DTLS > > > post-discovery. > > > > > > > > To address your call for wider WG response to this > recommendation: > > > > I strongly believe that (D)TLS should be used for the key > > > exchange and > > > > authentication protocol. > > > > > > > > My understanding on the reason that NIST preferred > > > AES-KeyWrap over > > > > IPsec for the transporting of PMKs had nothing to do with any > > > > preceived weakness in IPsec. It was because there is nothing in > the > > > > IPsec standard to allow a user-space app-- like a RADIUS > > > client-- to > > > > know whether the packets it is sending are in the clear or > > > are IPsec- > > > > protected. Therefore a mis-configuration could result in PMKs > being > > > > sent over-the-wire in-the-clear. (There are IPsec > > > implementations that > > > > do allow for such queries of the SADB but that isn't part > > > of the IPsec > > > > standard and therefore there isn't a guarantee that such a > > > capability > > > > will be available everywhere). Putting the security for passing > the > > > > PMKs directly into the RADIUS app-- i.e. using > > > AES-KeyWrap-- addresses > > > > that concern. Therefore I don't believe NIST would have a problem > > > > sending PTKs down a (D)TLS-protected link because the app that is > > > > sending and receiving them knows whether that link is > > > protected or not. > > > > > > > > Dan. > > > > > > > > On Wed, 28 Sep 2005 14:32:16 PDT you wrote > > > >> The evaluation team has made a request to modify LWAPP's built-in > > > > >> security mechanism with DTLS instead. This specific change > > > is tricky > > > >> as we first need to identify whether the DTLS session should be > > > >> created prior to, or post, the discovery phase. > > > >> > > > >> Here are my high level thoughts on the issue: > > > >> 1. Pre-Discovery DTLS. > > > >> > > > >> One of the LWAPP features is load balancing of WTPs among > > > ACs. This > > > >> load balancing can occur within, or across multiple, ACs. How > this > > > >> works is that a WTP would perform the discovery phase by > > > initiating a > > > >> Discovery Request packet to one or more ACs. The receiving ACs > > > >> respond with a Discovery Response, which also includes the total > > > >> number of WTPs supported (see section 5.2.2), as well as > > > its current > > > >> WTP load (see section 5.2.3). The WTP collects all of the > > > Discovery > > > >> Responses, and then decides which AC it wishes to connect > > > to based on > > > >> its policy. The policy can be either least loaded AC, or through > a > > > >> list of preferred ACs (see section 7.2.3). Further, the > > > WTP can opt > > > >> to not establish a session with the AC if it determines > > > that it does > > > >> not have the basic capabilities required by the AC. > > > >> > > > >> Performing DTLS prior to the Discovery Request would mean that > the > > > >> WTP would mean one of two things: > > > >> a. The WTP establishes a DTLS session with every AC it > > > knows about. > > > >> The side effect here is the LWAPP connect time on the WTP, not to > > > > >> mention the CPU load imposed on the AC. > > > >> b. The LWAPP protocol eliminates this feature altogether. > > > This means > > > >> that a WTP would only connect to the AC of its choice, > > > regardless of > > > >> the AC's current load of configuration. > > > >> > > > >> 2. Post-Discovery DTLS. In this mode, the above limitations are > > > >> removed, and the Discovery phase is done in the clear. While it > is > > > >> true that this raises some security concerns, the > > > information in the > > > >> Discovery Response is relatively benign, and therefore any > > > malicious > > > >> tweaking (or altering) of the response packet has created limited > > > > >> damage (although the WG needs to evaluate this, but it was > > > not found > > > >> to be problematic during the security review). > > > >> > > > >> This change would also require that the the Discovery packets be > > > >> exchanged on a separate UDP port, which is not a big change to > the > > > >> protocol. > > > >> > > > >> while I understand the evaluation team's recommendation to adopt > > > >> DTLS, I would also like to get a larger WG rough consensus > > > on whether > > > >> we feel that this change should be made. While I will make > > > the change > > > >> based on rough consensus, I want to make sure that we > > > think and agree > > > >> on this decision through as a group. I understand the > > > concerns raised > > > >> about increasing the time of the protocol development > > > phase in having > > > >> our own security approach, there are strategies that can > > > be done to > > > >> help us. For instance, initiate another security review > > > with another > > > >> reviewer identified by Russ Housely asap (he did recommend > > > Charles Clancy, btw). > > > >> > > > >> I think that another important point here is that during a recent > > > > >> meeting with NIST, we discussed the transport of 802.11i > > > PMKs within > > > >> the RADIUS protocol. During this discussion, we proposed > > > two methods. > > > >> The first would explicitely encrypt the PMK using > > > AES-KeyWrap within > > > >> a RADIUS attribute. The second approach was simply to encrypt the > > > > >> whole RADIUS transaction with IPSec. It was NIST's opinion at > that > > > >> time that they felt comfortable with option one, while option two > > > > >> would require them to evaluate whether IPSec would be > > > appropriate for > > > >> the transport of PMKs. Given that CAPWAP has a requirement > > > to allow > > > >> the WTP to perform encryption, this means that PTKs (and > > > GTKs) would > > > >> have to be transported over a DTLS session, and therefore I > wonder > > > >> whether we would have similar issues as those mentioned above. If > > > > >> this were an issue, then FIPS certification of any CAPWAP > > > based system could become impossible. > > > >> > > >> Your comments are appreciated, > > > >> > > > >> Pat Calhoun > > > >> CTO, Wireless Networking Business Unit Cisco Systems > > > >> _______________________________________________ > > > >> Capwap mailing list > > > >> Capwap@frascone.com > > > >> http://mail.frascone.com/mailman/listinfo/capwap > > > >> > > > > _______________________________________________ > > > > Capwap mailing list > > > > Capwap@frascone.com > > > > http://mail.frascone.com/mailman/listinfo/capwap > > > > > > > > > > > > > _______________________________________________ > > > Capwap mailing list > > > Capwap@frascone.com > > > http://mail.frascone.com/mailman/listinfo/capwap > > > > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap > > > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap > > > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap > _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Wed Oct 05 16:10:51 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENFbG-0000KE-7c for capwap-archive@megatron.ietf.org; Wed, 05 Oct 2005 16:10:51 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14405 for ; Wed, 5 Oct 2005 16:09:16 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 37A0620462; Wed, 5 Oct 2005 16:09:04 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from homebrew.trpz.com (66-7-225-40.cust.telepacific.net [66.7.225.40]) by mail.frascone.com (Postfix) with ESMTP id 4955B203E7 for ; Wed, 5 Oct 2005 16:08:19 -0400 (EDT) Received: from trpz.com (localhost.trpz.com [127.0.0.1]) by homebrew.trpz.com (8.13.1/8.13.1) with ESMTP id j95K1sg1080658; Wed, 5 Oct 2005 13:01:59 -0700 (PDT) (envelope-from dharkins@trpz.com) Message-Id: <200510052001.j95K1sg1080658@homebrew.trpz.com> To: "Susan Hares" Cc: "James Kempf" , "Nancy Winget (ncamwing)" , "Darren Loher" , "Pat Calhoun (pacalhou)" , capwap@frascone.com, ekr@rtfm.com Subject: Re: [Capwap] Change Request 9.1.2 (Control Channel Security) In-Reply-To: Your message of "Wed, 05 Oct 2005 12:59:52 MDT." <6F44D7F6B24A8F4DA0AB46C9BE924F02017DCCFC@VS4.EXCHPROD.USA.NET> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <80656.1128542514.1@trpz.com> From: Dan Harkins 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-Unsubscribe: , List-Id: A list for CAPWAP technical discussions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 05 Oct 2005 13:01:54 -0700 Sue, Yes you did go through your reasons. I didn't agree with them then and I don't think providing me with them offline would serve a purpose. If there are any issues with using DTLS with LWAPP-- spelling out some state machine interactions, for instance-- then please help out with text to complete it. Nancy, To suggest that DTLS cannot be used with LWAPP because it has not already been written up is a bizarre proposition. It's like saying we can't start doing something because it hasn't been completed yet. Yes, we have to ensure that the technical details are in order to use DTLS to protect LWAPP. Are you going to help out? Dan. On Wed, 05 Oct 2005 12:59:52 MDT you wrote > James: > > The issues regarding DTLS state machine interaction are not 100% spelled > out in the SLAPP proposal. > > Sue > > Dan - I believe I've gone through my reasons with you 8-9 months ago. > Glad to provide you offline with this information again. > > -----Original Message----- > From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On > Behalf Of James Kempf > Sent: Wednesday, October 05, 2005 2:55 PM > To: Nancy Winget (ncamwing); Darren Loher; Pat Calhoun (pacalhou); Dan > Harkins > Cc: capwap@frascone.com > Subject: Re: [Capwap] Change Request 9.1.2 (Control Channel Security) > > Nancy, > > I think it is only fair to ask for a written proposal (i.e. a draft) > about > how DTLS would be applied to LWAPP before the WG makes a decision, if > only > to ensure that the technical details are in order. > > jak > > > ----- Original Message ----- > From: "Nancy Winget (ncamwing)" > To: "Darren Loher" ; "Pat Calhoun (pacalhou)" > ; "James Kempf" ; "Dan > Harkins" > Cc: > Sent: Wednesday, October 05, 2005 11:35 AM > Subject: RE: [Capwap] Change Request 9.1.2 (Control Channel Security) > > > > NIST's concern is that care and (re)review is taken when security > protocols that were designed for one application are applied to another. > In the case of RADIUS, NIST pointed out that both RADIUS and IPSec were > complex enough that it was not clearly obvious to them how the use of > IPSec would address the key transport security....nor has there been any > security analysis to demonstrate what security properties and > vulnerabilities IPSec provides when used with RADIUS. > > As for CAPWAP/LWAPP, it seems that the LWAPP protocol has already > undergone security review and has been shown to meet this group's > security requirements. So, how does DTLS improve upon the currently > proposed security? > > My concern is that thus far, the adoption of DTLS has been suggested but > I've not readily seen how it would be applied. I believe modifications will have to be made to DTLS to ensure it's appropriate use for this > group's application. DTLS is fairly open in how it achieves > authentication to the point that it does not guarantee (identity) > authenticity, so I think that additional specification for how DTLS is > applied will be needed. That is, strong recommendations of the options > of credential and cipher suites will have to be defined to ensure that > this group's security requirements are met. > > Nancy. > > -----Original Message----- > From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On > Behalf Of Darren Loher > Sent: Wednesday, October 05, 2005 7:36 AM > To: Pat Calhoun (pacalhou); James Kempf; Dan Harkins > Cc: capwap@frascone.com > Subject: RE: [Capwap] Change Request 9.1.2 (Control Channel Security) > > I think the main difference between NIST's concern and our scenario is > the following: > > As Pat relayed to us in the RADIUS with IPSec case, there is no way for > RADIUS to really know it's using IPSec and therefore does not know if > it's transport is secure or not. > > In the CAPWAP/LWAPP case the control channel is guaranteed to be secure, > so it's okay to carry to PTK/GTK within the control channel. So within > the context of CAPWAP, there is implicit knowledge that transient keys > are using secure transport. > > -Darren > > > -----Original Message----- > > From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com] > > Sent: Wednesday, October 05, 2005 8:08 AM > > To: Darren Loher; James Kempf; Dan Harkins > > Cc: capwap@frascone.com > > Subject: RE: [Capwap] Change Request 9.1.2 (Control Channel Security) > > > > I think you meant PTK/GTK, but I was just making an observation that > the > > use of IPSec to carry keys was considered suspicious by NIST. I see a > > parallel here in our proposed direction. > > > > I will follow what the WG feels is right, I was just making sure folks > > > had additional info I thought was useful. > > > > Pat Calhoun > > CTO, Wireless Networking Business Unit Cisco Systems > > > > > > > > > -----Original Message----- > > > From: Darren Loher [mailto:DLoher@rovingplanet.com] > > > Sent: Sunday, October 02, 2005 12:17 PM > > > To: James Kempf; Pat Calhoun (pacalhou); Dan Harkins > > > Cc: capwap@frascone.com > > > Subject: RE: [Capwap] Change Request 9.1.2 (Control Channel > Security) > > > > > > Regarding secure distribtion of PMK/GMK between AC and WTP, it is > > > mandatory that these attributes are sent over the secured control > > > channel. So we should be covered on the AC <-> WTP communication. > > > > > > Isn't the transmission of RADIUS attributes an issue between the AC > > > and a AAA server and therefore outside the scope of CAPWAP? > > > > > > -Darren > > > > > > ________________________________ > > > > > > From: capwap-admin@frascone.com on behalf of James Kempf > > > Sent: Thu 9/29/2005 9:54 AM > > > To: Pat Calhoun (pacalhou); Dan Harkins > > > Cc: capwap@frascone.com > > > Subject: Re: [Capwap] Change Request 9.1.2 (Control Channel > Security) > > > > > > > > > > > > I agree with Dan. I think the risk from doing DTLS post-discovery is > > > > minimal. > > > > > > Security protocols have a history of bugs turning up after some > > > years of deployment. An added benefit of using DTLS is that LWAPP > > > benefits from the attention given to DTLS by users of other > > > protocols, so any bugs will most likely be found more quickly than > > > if LWAPP designs its own, specialized protocol. > > > > > > Regarding IPsec v.s. DTLS v.s. encryption of the Radius attribute > > > for PMK distribution, I don't have any real opinion on this. > > > Actually, I think I would prefer to leave this as a deployment > > > option, with appropriate text in the Security Considerations section > > > > about the requirement to use one of these method, and the methods > > > are described. I realize that there is an interoperability concern > > > here, but I can imagine cases where a network operator might prefer > > > one method over another due to their existing deployment. As Dan > > > mentioned, the concerns expressed about using IPsec related to > > > particular implementation issues rather than any fundamental > > > architectural or design issue with the protocol. But I don't have a > > > real strong opinion on this, and I can think of reasons why it might > > > > be a good idea to include a particular "required to implement" > > > method too. > > > > > > > > > jak > > > > > > > > > > > > ----- Original Message ----- > > > From: "Dan Harkins" > > > To: "Pat Calhoun (pacalhou)" > > > Cc: > > > Sent: Wednesday, September 28, 2005 3:16 PM > > > Subject: Re: [Capwap] Change Request 9.1.2 (Control Channel > Security) > > > > > > > > > > Pat, > > > > > > > > I agree that the information in the discovery phase is > > > benign. Also, > > > > anything an attacker could do to at that point is the same > > > as what an > > > > attacker could do during the DTLS "hello" exchange-- modify > > > packets in > > > > flight, redirect packets-- and the result would be the same: an > > > > unsuccessful DTLS exchange or unsuccessful discovery. An attacker > > > > could deny service-- prevent a successful DTLS exchange or > > > successful > > > > discovery of AC-- but any middlebox can start dropping packets on > a > > > > whim and do the same thing. I don't believe there is a > > > possibility of > > > > a resource exhaustion attack or launch a man-in-the-middle attack > > > > against the AC or WTP. > > > > > > > > I don't think we really need to worry about doing DTLS > > > post-discovery. > > > > > > > > To address your call for wider WG response to this > recommendation: > > > > I strongly believe that (D)TLS should be used for the key > > > exchange and > > > > authentication protocol. > > > > > > > > My understanding on the reason that NIST preferred > > > AES-KeyWrap over > > > > IPsec for the transporting of PMKs had nothing to do with any > > > > preceived weakness in IPsec. It was because there is nothing in > the > > > > IPsec standard to allow a user-space app-- like a RADIUS > > > client-- to > > > > know whether the packets it is sending are in the clear or > > > are IPsec- > > > > protected. Therefore a mis-configuration could result in PMKs > being > > > > sent over-the-wire in-the-clear. (There are IPsec > > > implementations that > > > do allow for such queries of the SADB but that isn't part > > > of the IPsec > > > > standard and therefore there isn't a guarantee that such a > > > capability > > > > will be available everywhere). Putting the security for passing > the > > > > PMKs directly into the RADIUS app-- i.e. using > > > AES-KeyWrap-- addresses > > > > that concern. Therefore I don't believe NIST would have a problem > > > > sending PTKs down a (D)TLS-protected link because the app that is > > > > sending and receiving them knows whether that link is > > > protected or not. > > > > > > > > Dan. > > > > > > > > On Wed, 28 Sep 2005 14:32:16 PDT you wrote > > > >> The evaluation team has made a request to modify LWAPP's built-in > > > > >> security mechanism with DTLS instead. This specific change > > > is tricky > > > >> as we first need to identify whether the DTLS session should be > > > >> created prior to, or post, the discovery phase. > > > >> > > > >> Here are my high level thoughts on the issue: > > > >> 1. Pre-Discovery DTLS. > > > >> > > > >> One of the LWAPP features is load balancing of WTPs among > > > ACs. This > > > >> load balancing can occur within, or across multiple, ACs. How > this > > > >> works is that a WTP would perform the discovery phase by > > > initiating a > > > >> Discovery Request packet to one or more ACs. The receiving ACs > > > >> respond with a Discovery Response, which also includes the total > > > >> number of WTPs supported (see section 5.2.2), as well as > > > its current > > > >> WTP load (see section 5.2.3). The WTP collects all of the > > > Discovery > > > >> Responses, and then decides which AC it wishes to connect > > > to based on > > > >> its policy. The policy can be either least loaded AC, or through > a > > > >> list of preferred ACs (see section 7.2.3). Further, the > > > WTP can opt > > > >> to not establish a session with the AC if it determines > > > that it does > > > >> not have the basic capabilities required by the AC. > > > >> > > > >> Performing DTLS prior to the Discovery Request would mean that > the > > > >> WTP would mean one of two things: > > > >> a. The WTP establishes a DTLS session with every AC it > > > knows about. > > > >> The side effect here is the LWAPP connect time on the WTP, not to > > > > >> mention the CPU load imposed on the AC. > > > >> b. The LWAPP protocol eliminates this feature altogether. > > > This means > > > >> that a WTP would only connect to the AC of its choice, > > > regardless of > > > >> the AC's current load of configuration. > > > >> > > > >> 2. Post-Discovery DTLS. In this mode, the above limitations are > > > >> removed, and the Discovery phase is done in the clear. While it > is > > > >> true that this raises some security concerns, the > > > information in the > > > >> Discovery Response is relatively benign, and therefore any > > > malicious > > > >> tweaking (or altering) of the response packet has created limited > > > > >> damage (although the WG needs to evaluate this, but it was > > > not found > > > >> to be problematic during the security review). > > > >> > > > >> This change would also require that the the Discovery packets be > > > >> exchanged on a separate UDP port, which is not a big change to > the > > > >> protocol. > > > >> > > > >> while I understand the evaluation team's recommendation to adopt > > > >> DTLS, I would also like to get a larger WG rough consensus > > > on whether > > > >> we feel that this change should be made. While I will make > > > the change > > > >> based on rough consensus, I want to make sure that we > > > think and agree > > > >> on this decision through as a group. I understand the > > > concerns raised > > > >> about increasing the time of the protocol development > > > phase in having > > > >> our own security approach, there are strategies that can > > > be done to > > > >> help us. For instance, initiate another security review > > > with another > > > >> reviewer identified by Russ Housely asap (he did recommend > > > Charles Clancy, btw). > > > >> > > > >> I think that another important point here is that during a recent > > > > >> meeting with NIST, we discussed the transport of 802.11i > > > PMKs within > > > >> the RADIUS protocol. During this discussion, we proposed > > > two methods. > > > >> The first would explicitely encrypt the PMK using > > > AES-KeyWrap within > > > >> a RADIUS attribute. The second approach was simply to encrypt the > > > > >> whole RADIUS transaction with IPSec. It was NIST's opinion at > that > > > >> time that they felt comfortable with option one, while option two > > > > >> would require them to evaluate whether IPSec would be > > > appropriate for > > > >> the transport of PMKs. Given that CAPWAP has a requirement > > > to allow > > > >> the WTP to perform encryption, this means that PTKs (and > > > GTKs) would > > > >> have to be transported over a DTLS session, and therefore I > wonder > > > >> whether we would have similar issues as those mentioned above. If > > > > >> this were an issue, then FIPS certification of any CAPWAP > > > based system could become impossible. > > > >> > > > >> Your comments are appreciated, > > > >> > > > >> Pat Calhoun > > > >> CTO, Wireless Networking Business Unit Cisco Systems > > > >> _______________________________________________ > > > >> Capwap mailing list > > > >> Capwap@frascone.com > > > >> http://mail.frascone.com/mailman/listinfo/capwap > > > >> > > > > _______________________________________________ > > > > Capwap mailing list > > > > Capwap@frascone.com > > > > http://mail.frascone.com/mailman/listinfo/capwap > > > > > > > > > > > > > _______________________________________________ > > > Capwap mailing list > > > Capwap@frascone.com > > > http://mail.frascone.com/mailman/listinfo/capwap > > > > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap > > > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap > > > > > _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Wed Oct 05 16:21:52 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENFlW-0002dt-Sn for capwap-archive@megatron.ietf.org; Wed, 05 Oct 2005 16:21:52 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15099 for ; Wed, 5 Oct 2005 16:21:19 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 8F23020477; Wed, 5 Oct 2005 16:21:04 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from typhoon.trangosoft.com (unknown [209.82.51.154]) by mail.frascone.com (Postfix) with ESMTP id 4B9D5203E7 for ; Wed, 5 Oct 2005 16:20:41 -0400 (EDT) Received: from phantom-out.trangosoft.com ([136.157.233.22]) by 136.157.233.32 with trend_isnt_name_B; Wed, 05 Oct 2005 16:21:15 -0400 Received: from troll3.trangosoft.com (troll3.trangosoft.com [136.157.233.13]) by phantom-out.trangosoft.com (Postfix) with ESMTP id 3923525028; Wed, 5 Oct 2005 16:17:29 -0400 (EDT) Received: by troll3.trangosoft.com with Internet Mail Service (5.5.2653.19) id <4DWMKJP0>; Wed, 5 Oct 2005 16:14:09 -0400 Message-ID: <1652EBA28502ED4393B9BC9B8A4B601335A5A6@mism121a.toronto.chantrynetworks.com> From: Michael Montemurro To: James Kempf , Susan Hares , "Nancy Winget (ncamwing)" , Darren Loher , "Pat Calhoun (pacalhou)" , Dan Harkins Cc: capwap@frascone.com Subject: RE: [Capwap] Change Request 9.1.2 (Control Channel Security) MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain 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-Unsubscribe: , List-Id: A list for CAPWAP technical discussions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 5 Oct 2005 16:19:44 -0400 All, There seems to be a number of people in favour of DTLS. I think that for this topic, I would like to see a detailed description for how DTLS would be applied to the CAPWAP protocol and how it compares to the solution documented in LWAPP. Simply stating that we should "use DTLS" does not provide enough information to compare with what has been proposed. Could one of the people in favour of DTLS provide this detail? Thanks, Mike > -----Original Message----- > From: capwap-admin@frascone.com > [mailto:capwap-admin@frascone.com] On Behalf Of James Kempf > Sent: October 5, 2005 3:04 PM > To: Susan Hares; Nancy Winget (ncamwing); Darren Loher; Pat > Calhoun (pacalhou); Dan Harkins > Cc: capwap@frascone.com > Subject: Re: [Capwap] Change Request 9.1.2 (Control Channel Security) > > Sue, > > Sure, that's why I think we need something written. It is > entirely possible that the process of trying to figure out > how it would work would result in realizing that it won't > work (something which did, in fact, happen to me recently on > another draft). On the other hand, the technical details may > be surmountable, thereby allowing LWAPP to accrue the > benefits of using what appears likely to be a widely > implemented and used security protocol. > > jak > > ----- Original Message ----- > From: "Susan Hares" > To: "James Kempf" ; "Nancy Winget > (ncamwing)" > ; "Darren Loher" > ; "Pat Calhoun (pacalhou)" > ; "Dan Harkins" > Cc: > Sent: Wednesday, October 05, 2005 11:59 AM > Subject: RE: [Capwap] Change Request 9.1.2 (Control Channel Security) > > > James: > > The issues regarding DTLS state machine interaction are not > 100% spelled out in the SLAPP proposal. > > Sue > > Dan - I believe I've gone through my reasons with you 8-9 months ago. > Glad to provide you offline with this information again. > > -----Original Message----- > From: capwap-admin@frascone.com > [mailto:capwap-admin@frascone.com] On Behalf Of James Kempf > Sent: Wednesday, October 05, 2005 2:55 PM > To: Nancy Winget (ncamwing); Darren Loher; Pat Calhoun > (pacalhou); Dan Harkins > Cc: capwap@frascone.com > Subject: Re: [Capwap] Change Request 9.1.2 (Control Channel Security) > > Nancy, > > I think it is only fair to ask for a written proposal (i.e. a > draft) about how DTLS would be applied to LWAPP before the WG > makes a decision, if only to ensure that the technical > details are in order. > > jak > > > ----- Original Message ----- > From: "Nancy Winget (ncamwing)" > To: "Darren Loher" ; "Pat Calhoun (pacalhou)" > ; "James Kempf" > ; "Dan Harkins" > Cc: > Sent: Wednesday, October 05, 2005 11:35 AM > Subject: RE: [Capwap] Change Request 9.1.2 (Control Channel Security) > > > > NIST's concern is that care and (re)review is taken when security > protocols that were designed for one application are applied > to another. > In the case of RADIUS, NIST pointed out that both RADIUS and > IPSec were > complex enough that it was not clearly obvious to them how the use of > IPSec would address the key transport security....nor has > there been any > security analysis to demonstrate what security properties and > vulnerabilities IPSec provides when used with RADIUS. > > As for CAPWAP/LWAPP, it seems that the LWAPP protocol has already > undergone security review and has been shown to meet this group's > security requirements. So, how does DTLS improve upon the currently > proposed security? > > My concern is that thus far, the adoption of DTLS has been > suggested but > I've not readily seen how it would be applied. I believe > modifications > will have to be made to DTLS to ensure it's appropriate use for this > group's application. DTLS is fairly open in how it achieves > authentication to the point that it does not guarantee (identity) > authenticity, so I think that additional specification for how DTLS is > applied will be needed. That is, strong recommendations of > the options > of credential and cipher suites will have to be defined to ensure that > this group's security requirements are met. > > Nancy. > > -----Original Message----- > From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On > Behalf Of Darren Loher > Sent: Wednesday, October 05, 2005 7:36 AM > To: Pat Calhoun (pacalhou); James Kempf; Dan Harkins > Cc: capwap@frascone.com > Subject: RE: [Capwap] Change Request 9.1.2 (Control Channel Security) > > I think the main difference between NIST's concern and our scenario is > the following: > > As Pat relayed to us in the RADIUS with IPSec case, there is > no way for > RADIUS to really know it's using IPSec and therefore does not know if > it's transport is secure or not. > > In the CAPWAP/LWAPP case the control channel is guaranteed to > be secure, > so it's okay to carry to PTK/GTK within the control channel. > So within > the context of CAPWAP, there is implicit knowledge that transient keys > are using secure transport. > > -Darren > > > -----Original Message----- > > From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com] > > Sent: Wednesday, October 05, 2005 8:08 AM > > To: Darren Loher; James Kempf; Dan Harkins > > Cc: capwap@frascone.com > > Subject: RE: [Capwap] Change Request 9.1.2 (Control Channel > Security) > > > > I think you meant PTK/GTK, but I was just making an observation that > the > > use of IPSec to carry keys was considered suspicious by > NIST. I see a > > parallel here in our proposed direction. > > > > I will follow what the WG feels is right, I was just making > sure folks > > > had additional info I thought was useful. > > > > Pat Calhoun > > CTO, Wireless Networking Business Unit Cisco Systems > > > > > > > > > -----Original Message----- > > > From: Darren Loher [mailto:DLoher@rovingplanet.com] > > > Sent: Sunday, October 02, 2005 12:17 PM > > > To: James Kempf; Pat Calhoun (pacalhou); Dan Harkins > > > Cc: capwap@frascone.com > > > Subject: RE: [Capwap] Change Request 9.1.2 (Control Channel > Security) > > > > > > Regarding secure distribtion of PMK/GMK between AC and WTP, it is > > > mandatory that these attributes are sent over the secured control > > > channel. So we should be covered on the AC <-> WTP communication. > > > > > > Isn't the transmission of RADIUS attributes an issue > between the AC > > > and a AAA server and therefore outside the scope of CAPWAP? > > > > > > -Darren > > > > > > ________________________________ > > > > > > From: capwap-admin@frascone.com on behalf of James Kempf > > > Sent: Thu 9/29/2005 9:54 AM > > > To: Pat Calhoun (pacalhou); Dan Harkins > > > Cc: capwap@frascone.com > > > Subject: Re: [Capwap] Change Request 9.1.2 (Control Channel > Security) > > > > > > > > > > > > I agree with Dan. I think the risk from doing DTLS > post-discovery is > > > > minimal. > > > > > > Security protocols have a history of bugs turning up after some > > > years of deployment. An added benefit of using DTLS is that LWAPP > > > benefits from the attention given to DTLS by users of other > > > protocols, so any bugs will most likely be found more quickly than > > > if LWAPP designs its own, specialized protocol. > > > > > > Regarding IPsec v.s. DTLS v.s. encryption of the Radius attribute > > > for PMK distribution, I don't have any real opinion on this. > > > Actually, I think I would prefer to leave this as a deployment > > > option, with appropriate text in the Security > Considerations section > > > > about the requirement to use one of these method, and the methods > > > are described. I realize that there is an interoperability concern > > > here, but I can imagine cases where a network operator > might prefer > > > one method over another due to their existing deployment. As Dan > > > mentioned, the concerns expressed about using IPsec related to > > > particular implementation issues rather than any fundamental > > > architectural or design issue with the protocol. But I > don't have a > > > real strong opinion on this, and I can think of reasons > why it might > > > > be a good idea to include a particular "required to implement" > > > method too. > > > > > > > > > jak > > > > > > > > > > > > ----- Original Message ----- > > > From: "Dan Harkins" > > > To: "Pat Calhoun (pacalhou)" > > > Cc: > > > Sent: Wednesday, September 28, 2005 3:16 PM > > > Subject: Re: [Capwap] Change Request 9.1.2 (Control Channel > Security) > > > > > > > > > > Pat, > > > > > > > > I agree that the information in the discovery phase is > > > benign. Also, > > > > anything an attacker could do to at that point is the same > > > as what an > > > > attacker could do during the DTLS "hello" exchange-- modify > > > packets in > > > > flight, redirect packets-- and the result would be the same: an > > > > unsuccessful DTLS exchange or unsuccessful discovery. > An attacker > > > > could deny service-- prevent a successful DTLS exchange or > > > successful > > > > discovery of AC-- but any middlebox can start dropping > packets on > a > > > > whim and do the same thing. I don't believe there is a > > > possibility of > > > > a resource exhaustion attack or launch a > man-in-the-middle attack > > > > against the AC or WTP. > > > > > > > > I don't think we really need to worry about doing DTLS > > > post-discovery. > > > > > > > > To address your call for wider WG response to this > recommendation: > > > > I strongly believe that (D)TLS should be used for the key > > > exchange and > > > > authentication protocol. > > > > > > > > My understanding on the reason that NIST preferred > > > AES-KeyWrap over > > > > IPsec for the transporting of PMKs had nothing to do with any > > > > preceived weakness in IPsec. It was because there is nothing in > the > > > > IPsec standard to allow a user-space app-- like a RADIUS > > > client-- to > > > > know whether the packets it is sending are in the clear or > > > are IPsec- > > > > protected. Therefore a mis-configuration could result in PMKs > being > > > > sent over-the-wire in-the-clear. (There are IPsec > > > implementations that > > > > do allow for such queries of the SADB but that isn't part > > > of the IPsec > > > > standard and therefore there isn't a guarantee that such a > > > capability > > > > will be available everywhere). Putting the security for passing > the > > > > PMKs directly into the RADIUS app-- i.e. using > > > AES-KeyWrap-- addresses > > > > that concern. Therefore I don't believe NIST would have > a problem > > > > sending PTKs down a (D)TLS-protected link because the > app that is > > > > sending and receiving them knows whether that link is > > > protected or not. > > > > > > > > Dan. > > > > > > > > On Wed, 28 Sep 2005 14:32:16 PDT you wrote > > > >> The evaluation team has made a request to modify > LWAPP's built-in > > > > >> security mechanism with DTLS instead. This specific change > > > is tricky > > > >> as we first need to identify whether the DTLS session should be > > > >> created prior to, or post, the discovery phase. > > > >> > > > >> Here are my high level thoughts on the issue: > > > >> 1. Pre-Discovery DTLS. > > > >> > > > >> One of the LWAPP features is load balancing of WTPs among > > > ACs. This > > > >> load balancing can occur within, or across multiple, ACs. How > this > > > >> works is that a WTP would perform the discovery phase by > > > initiating a > > > >> Discovery Request packet to one or more ACs. The receiving ACs > > > >> respond with a Discovery Response, which also includes > the total > > > >> number of WTPs supported (see section 5.2.2), as well as > > > its current > > > >> WTP load (see section 5.2.3). The WTP collects all of the > > > Discovery > > > >> Responses, and then decides which AC it wishes to connect > > > to based on > > > >> its policy. The policy can be either least loaded AC, > or through > a > > > >> list of preferred ACs (see section 7.2.3). Further, the > > > WTP can opt > > > >> to not establish a session with the AC if it determines > > > that it does > > > >> not have the basic capabilities required by the AC. > > > >> > > > >> Performing DTLS prior to the Discovery Request would mean that > the > > > >> WTP would mean one of two things: > > > >> a. The WTP establishes a DTLS session with every AC it > > > knows about. > > > >> The side effect here is the LWAPP connect time on the > WTP, not to > > > > >> mention the CPU load imposed on the AC. > > > >> b. The LWAPP protocol eliminates this feature altogether. > > > This means > > > >> that a WTP would only connect to the AC of its choice, > > > regardless of > > > >> the AC's current load of configuration. > > > >> > > > >> 2. Post-Discovery DTLS. In this mode, the above limitations are > > > >> removed, and the Discovery phase is done in the clear. While it > is > > > >> true that this raises some security concerns, the > > > information in the > > > >> Discovery Response is relatively benign, and therefore any > > > malicious > > > >> tweaking (or altering) of the response packet has > created limited > > > > >> damage (although the WG needs to evaluate this, but it was > > > not found > > > >> to be problematic during the security review). > > > >> > > > >> This change would also require that the the Discovery > packets be > > > >> exchanged on a separate UDP port, which is not a big change to > the > > > >> protocol. > > > >> > > > >> while I understand the evaluation team's > recommendation to adopt > > > >> DTLS, I would also like to get a larger WG rough consensus > > > on whether > > > >> we feel that this change should be made. While I will make > > > the change > > > >> based on rough consensus, I want to make sure that we > > > think and agree > > > >> on this decision through as a group. I understand the > > > concerns raised > > > >> about increasing the time of the protocol development > > > phase in having > > > >> our own security approach, there are strategies that can > > > be done to > > > >> help us. For instance, initiate another security review > > > with another > > > >> reviewer identified by Russ Housely asap (he did recommend > > > Charles Clancy, btw). > > > >> > > > >> I think that another important point here is that > during a recent > > > > >> meeting with NIST, we discussed the transport of 802.11i > > > PMKs within > > > >> the RADIUS protocol. During this discussion, we proposed > > > two methods. > > > >> The first would explicitely encrypt the PMK using > > > AES-KeyWrap within > > > >> a RADIUS attribute. The second approach was simply to > encrypt the > > > > >> whole RADIUS transaction with IPSec. It was NIST's opinion at > that > > > >> time that they felt comfortable with option one, while > option two > > > > >> would require them to evaluate whether IPSec would be > > > appropriate for > > > >> the transport of PMKs. Given that CAPWAP has a requirement > > > to allow > > > >> the WTP to perform encryption, this means that PTKs (and > > > GTKs) would > > > >> have to be transported over a DTLS session, and therefore I > wonder > > > >> whether we would have similar issues as those > mentioned above. If > > > > >> this were an issue, then FIPS certification of any CAPWAP > > > based system could become impossible. > > > >> > > > >> Your comments are appreciated, > > > >> > > > >> Pat Calhoun > > > >> CTO, Wireless Networking Business Unit Cisco Systems > > > >> _______________________________________________ > > > >> Capwap mailing list > > > >> Capwap@frascone.com > > > >> http://mail.frascone.com/mailman/listinfo/capwap > > > >> > > > > _______________________________________________ > > > > Capwap mailing list > > > > Capwap@frascone.com > > > > http://mail.frascone.com/mailman/listinfo/capwap > > > > > > > > > > > > > _______________________________________________ > > > Capwap mailing list > > > Capwap@frascone.com > > > http://mail.frascone.com/mailman/listinfo/capwap > > > > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap > > > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap > > > > > > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap > _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Wed Oct 05 19:06:12 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENIKy-0004LJ-6V for capwap-archive@megatron.ietf.org; Wed, 05 Oct 2005 19:06:12 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08242 for ; Wed, 5 Oct 2005 19:06:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 9385120400; Wed, 5 Oct 2005 19:06:04 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by mail.frascone.com (Postfix) with ESMTP id 45B7E203D7 for ; Wed, 5 Oct 2005 19:05:11 -0400 (EDT) Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-5.cisco.com with ESMTP; 05 Oct 2005 16:05:08 -0700 X-IronPort-AV: i="3.97,179,1125903600"; d="scan'208"; a="217348815:sNHT25546066" Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j95N534w012762; Wed, 5 Oct 2005 16:05:05 -0700 (PDT) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 5 Oct 2005 16:05:04 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Capwap] Cisco IPR Statement Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2C47B64@xmb-sjc-235.amer.cisco.com> Thread-Topic: [Capwap] Cisco IPR Statement Thread-Index: AcXJUDWF/mb18WNmSJ6TVP2DVLEBhwAdlkEA From: "Pat Calhoun (pacalhou)" To: "Dan Harkins" Cc: X-OriginalArrivalTime: 05 Oct 2005 23:05:04.0953 (UTC) FILETIME=[38F8BA90:01C5CA01] 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-Unsubscribe: , List-Id: A list for CAPWAP technical discussions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 5 Oct 2005 16:05:03 -0700 Content-Transfer-Encoding: quoted-printable > Cisco believe [the LWAPP IPR statement's license] is better than > the traditional RAND IPR statement often used in other cases in > standard organizations as what is reasonable terms is not known > at the time of (according to the IETF process) last call of a > document, and it is not clear the license terms, if known, will > be exactly the same for all time.=20 >=20 > Yet Cisco is granting RAND terms on the IPR is claims to have=20 > that is necessary to implement CTP, WiCOP, and SLAPP, not the=20 > kind of terms it believes are better. Cisco feels that making its own contribution royalty free is generous. We do not have a policy to do the same for contributions brought in by others. >=20 > You also said: >=20 > Cisco believes anyone having IPR on a technology they bring to > the IETF should let anyone implement the technology without any > need for explicit license, payments and other kind of=20 > uncertainties. >=20 > Yet Cisco is demanding an explicit license, payments and=20 > other kinds of uncertainties for the right to use the IPR it=20 > claims to have that is necessary to implement CTP, WiCOP, and SLAPP. >=20 > Can you please explain why the actions Cisco is taking with=20 > respect to its IPR on CTP, WiCOP and SLAPP does not match its=20 > stated beliefs on IPR in the IETF? Please see above. >=20 > Can you also explain why the terms for Cisco's IPR on LWAPP=20 > are more favorable than the terms for Cisco's IPR on CTP,=20 > WiCOP and SLAPP? Please see above. > It would also be extremely helpful to the working group to=20 > know exactly what is being claimed because the changes=20 > recommended to LWAPP are in the protocols on which Cisco has=20 > given RAND terms.=20 >=20 > If the working group knows what is being claimed then we=20 > can ensure that any changes made to LWAPP will not include=20 > the technology being claimed. Not only is this not part of the IETF process, but to my knowledge this=20 has this never occurred in another IETF Working Group.=20 > If you are unable to tell the working group then there is a=20 > possibility that the resulting CAPWAP protocol will have RAND=20 > terms on it because it may include the technology from SLAPP=20 > that was covered by your IPR statement of 7 September 2005. I do not know about any Cisco IPR against the features being requested by the evaluation team, as documented in draft-ietf-capwap-eval-00.txt. That said, as with any protocol being designed, we cannot guarantee that any future feature added will not infringe on Cisco (or someone else's) patents - it's just part of the game :( Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Wed Oct 05 19:19:32 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENIXr-0001PA-Vv for capwap-archive@megatron.ietf.org; Wed, 05 Oct 2005 19:19:32 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08845 for ; Wed, 5 Oct 2005 19:19:21 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 07449203FE; Wed, 5 Oct 2005 19:19:04 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from smtp4.centerbeam.com (smtp4.centerbeam.com [63.120.115.248]) by mail.frascone.com (Postfix) with ESMTP id B6A92203F7 for ; Wed, 5 Oct 2005 19:18:43 -0400 (EDT) Received: from CBA0E2K01.CBA0.centerbeam.com ([64.95.101.24]) by smtp4.centerbeam.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 5 Oct 2005 16:23:15 -0700 Received: from CBA0E2K06.CBA0.centerbeam.com ([64.95.101.40]) by CBA0E2K01.CBA0.centerbeam.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 5 Oct 2005 16:18:19 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Capwap] Change Request 9.1.2 (Control Channel Security) Message-ID: Thread-Topic: [Capwap] Change Request 9.1.2 (Control Channel Security) Thread-Index: AcXJ6k1UaWBkSi0GS8i1Q4CmJMrh0AAEbQng From: "Darren Loher" To: X-OriginalArrivalTime: 05 Oct 2005 23:18:19.0720 (UTC) FILETIME=[12B08C80:01C5CA03] 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-Unsubscribe: , List-Id: A list for CAPWAP technical discussions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 5 Oct 2005 16:18:19 -0700 Content-Transfer-Encoding: quoted-printable I propose the following process for making a decision about 9.1.2 (Control Channel Security) would be to gather WG consensus on the following points:=20 1. Is using DTLS instead of the currently proposed LWAPP security channel a good enough idea that it is worth the effort to develop a new, DTLS based control channel security mechanism? 2. If so, a proposal must be developed which can replace LWAPP's security mechanism. We need volunteers from the working group to develop this. 3. Does this proposal meet the WG objectives and will it meet the IETF requirements better than the original LWAPP security mechanism? 4. If yes, officially adopt the DTLS based control channel specification for LWAPP. In order to help address question #1, the evaluation draft 9.1.2 points out a few benefits that using DTLS should bring and detractors from using the LWAPP developed security mechanism. =20 At best, the proposed LWAPP security protocol will face a longer, slower approval process from the Security Area Directorate and the IESG. Use of an existing security mechanism would also need to be reviewed, but if properly specified, it will likely be quickly accepted. =20 In particular, the following questions will be asked of the LWAPP security mechanism. It is these questions that lead the evaluation team to recommend the replacement of the LWAPP mechanism with DTLS. =20 - What is uniquely required by CAPWAP that is not available from an existing standard protocol? - How will CAPWAP's security protocol meet security area requirements for extensibility, such as the ability to support future cipher suites and new key exchange methods? - How does this ability compare to established security protocols which have these capabilities? All these issues could be addressed by adopting an appropriate, existing security protocol. DTLS appears to be the leading candidate protocol. =20 If we can get consensus that this is true, then we should proceed to step #2, creation of a proposal for use of DTLS in CAPWAP. Section 9.1.2 of the evaluation draft specifically recommends that a detailed specification of the application of DTLS be developed. The specification should include a detailed description of the authentication procedure and a mandatory cipher suite. A proper development of this specification should address Nancy's concerns.=20 -Darren > -----Original Message----- > From: Michael Montemurro [mailto:michael.montemurro@siemens.com] > Sent: Wednesday, October 05, 2005 2:20 PM > To: James Kempf; Susan Hares; Nancy Winget (ncamwing); Darren Loher; Pat > Calhoun (pacalhou); Dan Harkins > Cc: capwap@frascone.com > Subject: RE: [Capwap] Change Request 9.1.2 (Control Channel Security) >=20 > All, >=20 > There seems to be a number of people in favour of DTLS. I think that for > this topic, I would like to see a detailed description for how DTLS would > be > applied to the CAPWAP protocol and how it compares to the solution > documented in LWAPP. Simply stating that we should "use DTLS" does not > provide enough information to compare with what has been proposed. >=20 > Could one of the people in favour of DTLS provide this detail? >=20 > Thanks, >=20 > Mike >=20 > > -----Original Message----- > > From: capwap-admin@frascone.com > > [mailto:capwap-admin@frascone.com] On Behalf Of James Kempf > > Sent: October 5, 2005 3:04 PM > > To: Susan Hares; Nancy Winget (ncamwing); Darren Loher; Pat > > Calhoun (pacalhou); Dan Harkins > > Cc: capwap@frascone.com > > Subject: Re: [Capwap] Change Request 9.1.2 (Control Channel Security) > > > > Sue, > > > > Sure, that's why I think we need something written. It is > > entirely possible that the process of trying to figure out > > how it would work would result in realizing that it won't > > work (something which did, in fact, happen to me recently on > > another draft). On the other hand, the technical details may > > be surmountable, thereby allowing LWAPP to accrue the > > benefits of using what appears likely to be a widely > > implemented and used security protocol. > > > > jak > > > > ----- Original Message ----- > > From: "Susan Hares" > > To: "James Kempf" ; "Nancy Winget > > (ncamwing)" > > ; "Darren Loher" > > ; "Pat Calhoun (pacalhou)" > > ; "Dan Harkins" > > Cc: > > Sent: Wednesday, October 05, 2005 11:59 AM > > Subject: RE: [Capwap] Change Request 9.1.2 (Control Channel Security) > > > > > > James: > > > > The issues regarding DTLS state machine interaction are not > > 100% spelled out in the SLAPP proposal. > > > > Sue > > > > Dan - I believe I've gone through my reasons with you 8-9 months ago. > > Glad to provide you offline with this information again. > > > > -----Original Message----- > > From: capwap-admin@frascone.com > > [mailto:capwap-admin@frascone.com] On Behalf Of James Kempf > > Sent: Wednesday, October 05, 2005 2:55 PM > > To: Nancy Winget (ncamwing); Darren Loher; Pat Calhoun > > (pacalhou); Dan Harkins > > Cc: capwap@frascone.com > > Subject: Re: [Capwap] Change Request 9.1.2 (Control Channel Security) > > > > Nancy, > > > > I think it is only fair to ask for a written proposal (i.e. a > > draft) about how DTLS would be applied to LWAPP before the WG > > makes a decision, if only to ensure that the technical > > details are in order. > > > > jak > > > > > > ----- Original Message ----- > > From: "Nancy Winget (ncamwing)" > > To: "Darren Loher" ; "Pat Calhoun (pacalhou)" > > ; "James Kempf" > > ; "Dan Harkins" > > Cc: > > Sent: Wednesday, October 05, 2005 11:35 AM > > Subject: RE: [Capwap] Change Request 9.1.2 (Control Channel Security) > > > > > > > > NIST's concern is that care and (re)review is taken when security > > protocols that were designed for one application are applied > > to another. > > In the case of RADIUS, NIST pointed out that both RADIUS and > > IPSec were > > complex enough that it was not clearly obvious to them how the use of > > IPSec would address the key transport security....nor has > > there been any > > security analysis to demonstrate what security properties and > > vulnerabilities IPSec provides when used with RADIUS. > > > > As for CAPWAP/LWAPP, it seems that the LWAPP protocol has already > > undergone security review and has been shown to meet this group's > > security requirements. So, how does DTLS improve upon the currently > > proposed security? > > > > My concern is that thus far, the adoption of DTLS has been > > suggested but > > I've not readily seen how it would be applied. I believe > > modifications > > will have to be made to DTLS to ensure it's appropriate use for this > > group's application. DTLS is fairly open in how it achieves > > authentication to the point that it does not guarantee (identity) > > authenticity, so I think that additional specification for how DTLS is > > applied will be needed. That is, strong recommendations of > > the options > > of credential and cipher suites will have to be defined to ensure that > > this group's security requirements are met. > > > > Nancy. > > > > -----Original Message----- > > From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On > > Behalf Of Darren Loher > > Sent: Wednesday, October 05, 2005 7:36 AM > > To: Pat Calhoun (pacalhou); James Kempf; Dan Harkins > > Cc: capwap@frascone.com > > Subject: RE: [Capwap] Change Request 9.1.2 (Control Channel Security) > > > > I think the main difference between NIST's concern and our scenario is > > the following: > > > > As Pat relayed to us in the RADIUS with IPSec case, there is > > no way for > > RADIUS to really know it's using IPSec and therefore does not know if > > it's transport is secure or not. > > > > In the CAPWAP/LWAPP case the control channel is guaranteed to > > be secure, > > so it's okay to carry to PTK/GTK within the control channel. > > So within > > the context of CAPWAP, there is implicit knowledge that transient keys > > are using secure transport. > > > > -Darren > > > > > -----Original Message----- > > > From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com] > > > Sent: Wednesday, October 05, 2005 8:08 AM > > > To: Darren Loher; James Kempf; Dan Harkins > > > Cc: capwap@frascone.com > > > Subject: RE: [Capwap] Change Request 9.1.2 (Control Channel > > Security) > > > > > > I think you meant PTK/GTK, but I was just making an observation that > > the > > > use of IPSec to carry keys was considered suspicious by > > NIST. I see a > > > parallel here in our proposed direction. > > > > > > I will follow what the WG feels is right, I was just making > > sure folks > > > > > had additional info I thought was useful. > > > > > > Pat Calhoun > > > CTO, Wireless Networking Business Unit Cisco Systems > > > > > > > > > > > > > -----Original Message----- > > > > From: Darren Loher [mailto:DLoher@rovingplanet.com] > > > > Sent: Sunday, October 02, 2005 12:17 PM > > > > To: James Kempf; Pat Calhoun (pacalhou); Dan Harkins > > > > Cc: capwap@frascone.com > > > > Subject: RE: [Capwap] Change Request 9.1.2 (Control Channel > > Security) > > > > > > > > Regarding secure distribtion of PMK/GMK between AC and WTP, it is > > > > mandatory that these attributes are sent over the secured control > > > > channel. So we should be covered on the AC <-> WTP communication. > > > > > > > > Isn't the transmission of RADIUS attributes an issue > > between the AC > > > > and a AAA server and therefore outside the scope of CAPWAP? > > > > > > > > -Darren > > > > > > > > ________________________________ > > > > > > > > From: capwap-admin@frascone.com on behalf of James Kempf > > > > Sent: Thu 9/29/2005 9:54 AM > > > > To: Pat Calhoun (pacalhou); Dan Harkins > > > > Cc: capwap@frascone.com > > > > Subject: Re: [Capwap] Change Request 9.1.2 (Control Channel > > Security) > > > > > > > > > > > > > > > > I agree with Dan. I think the risk from doing DTLS > > post-discovery is > > > > > > minimal. > > > > > > > > Security protocols have a history of bugs turning up after some > > > > years of deployment. An added benefit of using DTLS is that LWAPP > > > > benefits from the attention given to DTLS by users of other > > > > protocols, so any bugs will most likely be found more quickly than > > > > if LWAPP designs its own, specialized protocol. > > > > > > > > Regarding IPsec v.s. DTLS v.s. encryption of the Radius attribute > > > > for PMK distribution, I don't have any real opinion on this. > > > > Actually, I think I would prefer to leave this as a deployment > > > > option, with appropriate text in the Security > > Considerations section > > > > > > about the requirement to use one of these method, and the methods > > > > are described. I realize that there is an interoperability concern > > > > here, but I can imagine cases where a network operator > > might prefer > > > > one method over another due to their existing deployment. As Dan > > > > mentioned, the concerns expressed about using IPsec related to > > > > particular implementation issues rather than any fundamental > > > > architectural or design issue with the protocol. But I > > don't have a > > > > real strong opinion on this, and I can think of reasons > > why it might > > > > > > be a good idea to include a particular "required to implement" > > > > method too. > > > > > > > > > > > > jak > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > From: "Dan Harkins" > > > > To: "Pat Calhoun (pacalhou)" > > > > Cc: > > > > Sent: Wednesday, September 28, 2005 3:16 PM > > > > Subject: Re: [Capwap] Change Request 9.1.2 (Control Channel > > Security) > > > > > > > > > > > > > Pat, > > > > > > > > > > I agree that the information in the discovery phase is > > > > benign. Also, > > > > > anything an attacker could do to at that point is the same > > > > as what an > > > > > attacker could do during the DTLS "hello" exchange-- modify > > > > packets in > > > > > flight, redirect packets-- and the result would be the same: an > > > > > unsuccessful DTLS exchange or unsuccessful discovery. > > An attacker > > > > > could deny service-- prevent a successful DTLS exchange or > > > > successful > > > > > discovery of AC-- but any middlebox can start dropping > > packets on > > a > > > > > whim and do the same thing. I don't believe there is a > > > > possibility of > > > > > a resource exhaustion attack or launch a > > man-in-the-middle attack > > > > > against the AC or WTP. > > > > > > > > > > I don't think we really need to worry about doing DTLS > > > > post-discovery. > > > > > > > > > > To address your call for wider WG response to this > > recommendation: > > > > > I strongly believe that (D)TLS should be used for the key > > > > exchange and > > > > > authentication protocol. > > > > > > > > > > My understanding on the reason that NIST preferred > > > > AES-KeyWrap over > > > > > IPsec for the transporting of PMKs had nothing to do with any > > > > > preceived weakness in IPsec. It was because there is nothing in > > the > > > > > IPsec standard to allow a user-space app-- like a RADIUS > > > > client-- to > > > > > know whether the packets it is sending are in the clear or > > > > are IPsec- > > > > > protected. Therefore a mis-configuration could result in PMKs > > being > > > > > sent over-the-wire in-the-clear. (There are IPsec > > > > implementations that > > > > > do allow for such queries of the SADB but that isn't part > > > > of the IPsec > > > > > standard and therefore there isn't a guarantee that such a > > > > capability > > > > > will be available everywhere). Putting the security for passing > > the > > > > > PMKs directly into the RADIUS app-- i.e. using > > > > AES-KeyWrap-- addresses > > > > > that concern. Therefore I don't believe NIST would have > > a problem > > > > > sending PTKs down a (D)TLS-protected link because the > > app that is > > > > > sending and receiving them knows whether that link is > > > > protected or not. > > > > > > > > > > Dan. > > > > > > > > > > On Wed, 28 Sep 2005 14:32:16 PDT you wrote > > > > >> The evaluation team has made a request to modify > > LWAPP's built-in > > > > > > >> security mechanism with DTLS instead. This specific change > > > > is tricky > > > > >> as we first need to identify whether the DTLS session should be > > > > >> created prior to, or post, the discovery phase. > > > > >> > > > > >> Here are my high level thoughts on the issue: > > > > >> 1. Pre-Discovery DTLS. > > > > >> > > > > >> One of the LWAPP features is load balancing of WTPs among > > > > ACs. This > > > > >> load balancing can occur within, or across multiple, ACs. How > > this > > > > >> works is that a WTP would perform the discovery phase by > > > > initiating a > > > > >> Discovery Request packet to one or more ACs. The receiving ACs > > > > >> respond with a Discovery Response, which also includes > > the total > > > > >> number of WTPs supported (see section 5.2.2), as well as > > > > its current > > > > >> WTP load (see section 5.2.3). The WTP collects all of the > > > > Discovery > > > > >> Responses, and then decides which AC it wishes to connect > > > > to based on > > > > >> its policy. The policy can be either least loaded AC, > > or through > > a > > > > >> list of preferred ACs (see section 7.2.3). Further, the > > > > WTP can opt > > > > >> to not establish a session with the AC if it determines > > > > that it does > > > > >> not have the basic capabilities required by the AC. > > > > >> > > > > >> Performing DTLS prior to the Discovery Request would mean that > > the > > > > >> WTP would mean one of two things: > > > > >> a. The WTP establishes a DTLS session with every AC it > > > > knows about. > > > > >> The side effect here is the LWAPP connect time on the > > WTP, not to > > > > > > >> mention the CPU load imposed on the AC. > > > > >> b. The LWAPP protocol eliminates this feature altogether. > > > > This means > > > > >> that a WTP would only connect to the AC of its choice, > > > > regardless of > > > > >> the AC's current load of configuration. > > > > >> > > > > >> 2. Post-Discovery DTLS. In this mode, the above limitations are > > > > >> removed, and the Discovery phase is done in the clear. While it > > is > > > > >> true that this raises some security concerns, the > > > > information in the > > > > >> Discovery Response is relatively benign, and therefore any > > > > malicious > > > > >> tweaking (or altering) of the response packet has > > created limited > > > > > > >> damage (although the WG needs to evaluate this, but it was > > > > not found > > > > >> to be problematic during the security review). > > > > >> > > > > >> This change would also require that the the Discovery > > packets be > > > > >> exchanged on a separate UDP port, which is not a big change to > > the > > > > >> protocol. > > > > >> > > > > >> while I understand the evaluation team's > > recommendation to adopt > > > > >> DTLS, I would also like to get a larger WG rough consensus > > > > on whether > > > > >> we feel that this change should be made. While I will make > > > > the change > > > > >> based on rough consensus, I want to make sure that we > > > > think and agree > > > > >> on this decision through as a group. I understand the > > > > concerns raised > > > > >> about increasing the time of the protocol development > > > > phase in having > > > > >> our own security approach, there are strategies that can > > > > be done to > > > > >> help us. For instance, initiate another security review > > > > with another > > > > >> reviewer identified by Russ Housely asap (he did recommend > > > > Charles Clancy, btw). > > > > >> > > > > >> I think that another important point here is that > > during a recent > > > > > > >> meeting with NIST, we discussed the transport of 802.11i > > > > PMKs within > > > > >> the RADIUS protocol. During this discussion, we proposed > > > > two methods. > > > > >> The first would explicitely encrypt the PMK using > > > > AES-KeyWrap within > > > > >> a RADIUS attribute. The second approach was simply to > > encrypt the > > > > > > >> whole RADIUS transaction with IPSec. It was NIST's opinion at > > that > > > > >> time that they felt comfortable with option one, while > > option two > > > > > > >> would require them to evaluate whether IPSec would be > > > > appropriate for > > > > >> the transport of PMKs. Given that CAPWAP has a requirement > > > > to allow > > > > >> the WTP to perform encryption, this means that PTKs (and > > > > GTKs) would > > > > >> have to be transported over a DTLS session, and therefore I > > wonder > > > > >> whether we would have similar issues as those > > mentioned above. If > > > > > > >> this were an issue, then FIPS certification of any CAPWAP > > > > based system could become impossible. > > > > >> > > > > >> Your comments are appreciated, > > > > >> > > > > >> Pat Calhoun > > > > >> CTO, Wireless Networking Business Unit Cisco Systems > > > > >> _______________________________________________ > > > > >> Capwap mailing list > > > > >> Capwap@frascone.com > > > > >> http://mail.frascone.com/mailman/listinfo/capwap > > > > >> > > > > > _______________________________________________ > > > > > Capwap mailing list > > > > > Capwap@frascone.com > > > > > http://mail.frascone.com/mailman/listinfo/capwap > > > > > > > > > > > > > > > > > _______________________________________________ > > > > Capwap mailing list > > > > Capwap@frascone.com > > > > http://mail.frascone.com/mailman/listinfo/capwap > > > > > > _______________________________________________ > > Capwap mailing list > > Capwap@frascone.com > > http://mail.frascone.com/mailman/listinfo/capwap > > > > > > _______________________________________________ > > Capwap mailing list > > Capwap@frascone.com > > http://mail.frascone.com/mailman/listinfo/capwap > > > > > > > > > > > > _______________________________________________ > > Capwap mailing list > > Capwap@frascone.com > > http://mail.frascone.com/mailman/listinfo/capwap > > _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Wed Oct 05 19:54:28 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENJ5g-0005qi-EZ for capwap-archive@megatron.ietf.org; Wed, 05 Oct 2005 19:54:28 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09937 for ; Wed, 5 Oct 2005 19:54:20 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id C5F00203FD; Wed, 5 Oct 2005 19:54:03 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by mail.frascone.com (Postfix) with ESMTP id 3B457203D7 for ; Wed, 5 Oct 2005 19:53:01 -0400 (EDT) Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-5.cisco.com with ESMTP; 05 Oct 2005 16:53:01 -0700 X-IronPort-AV: i="3.97,179,1125903600"; d="scan'208"; a="217364010:sNHT58368526" Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j95NqYvA020587; Wed, 5 Oct 2005 16:53:00 -0700 (PDT) Received: from xmb-sjc-222.amer.cisco.com ([128.107.191.106]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 5 Oct 2005 16:52:58 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Capwap] Change Request 9.1.2 (Control Channel Security) Message-ID: <08A9A3213527A6428774900A80DBD8D8C27D45@xmb-sjc-222.amer.cisco.com> Thread-Topic: [Capwap] Change Request 9.1.2 (Control Channel Security) Thread-Index: AcXJ5xe1Huiv0HF0TKeh//SsrpTiGAAHlJlw From: "Nancy Winget (ncamwing)" To: "Dan Harkins" Cc: "Darren Loher" , "Pat Calhoun (pacalhou)" , "James Kempf" , , X-OriginalArrivalTime: 05 Oct 2005 23:52:58.0184 (UTC) FILETIME=[E98CFC80:01C5CA07] 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-Unsubscribe: , List-Id: A list for CAPWAP technical discussions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 5 Oct 2005 16:52:56 -0700 Content-Transfer-Encoding: quoted-printable Hi Dan, The devil is in the details. We can state that particular protocols are secure because they have been deemed secure. But just because they are secure does not mean that when they are applied to some other context, their security properties are retained or that it meets the security requirements posed on the applied context. That is the gist of what NIST conveyed and I am trying to reiterate the same for our context, e.g. CAPWAP/LWAPP and DTLS. DTLS carries its own state machine that am not sure how it fits in the CAPWAP realm. DTLS depending on selected cipher suites, credential types provides a range of security properties. Thus, my comment/request is that those that are proposing DTLS provide more information of how it fits into the CAPWAP model and how it addresses the groups requirements. As a proposer of LWAPP, I can state that the group of proposers did put the "onus" on ourselves to ensure that both the draft be as complete and descriptive of how it meets the CAPWAP model as well as ensuring that it be fully reviewed inclusive of its security properties. It's not clear to me how DTLS fits into the CAPWAP model....so, as I am not a proposer of this suggestion, I am requesting those who are to provide one. Nancy. =20 -----Original Message----- From: Dan Harkins [mailto:dharkins@trpz.com]=20 Sent: Wednesday, October 05, 2005 12:51 PM To: Nancy Winget (ncamwing) Cc: Darren Loher; Pat Calhoun (pacalhou); James Kempf; capwap@frascone.com; ekr@rtfm.com Subject: Re: [Capwap] Change Request 9.1.2 (Control Channel Security)=20 Nancy, IPsec was designed to protect IP and anything that rides on top of it, it was not designed for one specific "application". Much care and review was put into it to ensure that it met its design goals. If you know of any security analysis that demonstrate a vulnerability that IPsec has with respect to that design than please tell us. Since RADIUS uses UDP which rides on top of IP then IPsec is designed to protect it. If you know of anything specific to RADIUS that would make it vulnerable if protected by IPsec then please tell us, it would be a great service to the industry. TLS has had much more security review than LWAPP (whose security was deemed "adequate").=20 You say that modifications will have to be made to DTLS to ensure it's appropriate for use with CAPWAP. Please elaborate. What parts of DTLS need modification and why? Having a strong recommendation in CAPWAP on which ciphersuites to use is a fantastic idea but the necessity of that should not derail the whole idea of using a secure, standards-based protocol. I think the onus is on someone who insists on reinventing the wheel on why it is necessary or why this new wheel will be more round than the one we already have. Dan. On Wed, 05 Oct 2005 11:35:39 PDT you wrote >=20 > NIST's concern is that care and (re)review is taken when security=20 > protocols that were designed for one application are applied to another. > In the case of RADIUS, NIST pointed out that both RADIUS and IPSec=20 > were complex enough that it was not clearly obvious to them how the=20 > use of IPSec would address the key transport security....nor has there > been any security analysis to demonstrate what security properties and > vulnerabilities IPSec provides when used with RADIUS. >=20 > As for CAPWAP/LWAPP, it seems that the LWAPP protocol has already=20 > undergone security review and has been shown to meet this group's=20 > security requirements. So, how does DTLS improve upon the currently=20 > proposed security? >=20 > My concern is that thus far, the adoption of DTLS has been suggested=20 > but I've not readily seen how it would be applied. I believe=20 > modifications will have to be made to DTLS to ensure it's appropriate=20 > use for this group's application. DTLS is fairly open in how it=20 > achieves authentication to the point that it does not guarantee=20 > (identity) authenticity, so I think that additional specification for=20 > how DTLS is applied will be needed. That is, strong recommendations=20 > of the options of credential and cipher suites will have to be defined > to ensure that this group's security requirements are met. >=20 > Nancy.=20 >=20 > -----Original Message----- > From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On=20 > Behalf Of Darren Loher > Sent: Wednesday, October 05, 2005 7:36 AM > To: Pat Calhoun (pacalhou); James Kempf; Dan Harkins > Cc: capwap@frascone.com > Subject: RE: [Capwap] Change Request 9.1.2 (Control Channel Security) >=20 > I think the main difference between NIST's concern and our scenario is > the following: >=20 > As Pat relayed to us in the RADIUS with IPSec case, there is no way=20 > for RADIUS to really know it's using IPSec and therefore does not know > if it's transport is secure or not. >=20 > In the CAPWAP/LWAPP case the control channel is guaranteed to be=20 > secure, so it's okay to carry to PTK/GTK within the control channel. =20 > So within the context of CAPWAP, there is implicit knowledge that=20 > transient keys are using secure transport. >=20 > -Darren >=20 > > -----Original Message----- > > From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com] > > Sent: Wednesday, October 05, 2005 8:08 AM > > To: Darren Loher; James Kempf; Dan Harkins > > Cc: capwap@frascone.com > > Subject: RE: [Capwap] Change Request 9.1.2 (Control Channel=20 > > Security) > >=20 > > I think you meant PTK/GTK, but I was just making an observation that > the > > use of IPSec to carry keys was considered suspicious by NIST. I see=20 > > a parallel here in our proposed direction. > >=20 > > I will follow what the WG feels is right, I was just making sure=20 > > folks >=20 > > had additional info I thought was useful. > >=20 > > Pat Calhoun > > CTO, Wireless Networking Business Unit Cisco Systems > >=20 > >=20 > >=20 > > > -----Original Message----- > > > From: Darren Loher [mailto:DLoher@rovingplanet.com] > > > Sent: Sunday, October 02, 2005 12:17 PM > > > To: James Kempf; Pat Calhoun (pacalhou); Dan Harkins > > > Cc: capwap@frascone.com > > > Subject: RE: [Capwap] Change Request 9.1.2 (Control Channel > Security) > > > > > > Regarding secure distribtion of PMK/GMK between AC and WTP, it is=20 > > > mandatory that these attributes are sent over the secured control=20 > > > channel. So we should be covered on the AC <-> WTP communication. > > > > > > Isn't the transmission of RADIUS attributes an issue between the=20 > > > AC and a AAA server and therefore outside the scope of CAPWAP? > > > > > > -Darren > > > > > > ________________________________ > > > > > > From: capwap-admin@frascone.com on behalf of James Kempf > > > Sent: Thu 9/29/2005 9:54 AM > > > To: Pat Calhoun (pacalhou); Dan Harkins > > > Cc: capwap@frascone.com > > > Subject: Re: [Capwap] Change Request 9.1.2 (Control Channel > Security) > > > > > > > > > > > > I agree with Dan. I think the risk from doing DTLS post-discovery=20 > > > is >=20 > > > minimal. > > > > > > Security protocols have a history of bugs turning up after some=20 > > > years of deployment. An added benefit of using DTLS is that LWAPP=20 > > > benefits from the attention given to DTLS by users of other=20 > > > protocols, so any bugs will most likely be found more quickly than > > > if LWAPP designs its own, specialized protocol. > > > > > > Regarding IPsec v.s. DTLS v.s. encryption of the Radius attribute=20 > > > for PMK distribution, I don't have any real opinion on this. > > > Actually, I think I would prefer to leave this as a deployment=20 > > > option, with appropriate text in the Security Considerations=20 > > > section >=20 > > > about the requirement to use one of these method, and the methods=20 > > > are described. I realize that there is an interoperability concern > > > here, but I can imagine cases where a network operator might=20 > > > prefer one method over another due to their existing deployment.=20 > > > As Dan mentioned, the concerns expressed about using IPsec related > > > to particular implementation issues rather than any fundamental=20 > > > architectural or design issue with the protocol. But I don't have=20 > > > a real strong opinion on this, and I can think of reasons why it=20 > > > might >=20 > > > be a good idea to include a particular "required to implement"=20 > > > method too. > > > > > > > > > jak > > > > > > > > > > > > ----- Original Message ----- > > > From: "Dan Harkins" > > > To: "Pat Calhoun (pacalhou)" > > > Cc: > > > Sent: Wednesday, September 28, 2005 3:16 PM > > > Subject: Re: [Capwap] Change Request 9.1.2 (Control Channel > Security) > > > > > > > > > > Pat, > > > > > > > > I agree that the information in the discovery phase is > > > benign. Also, > > > > anything an attacker could do to at that point is the same > > > as what an > > > > attacker could do during the DTLS "hello" exchange-- modify > > > packets in > > > > flight, redirect packets-- and the result would be the same: an=20 > > > > unsuccessful DTLS exchange or unsuccessful discovery. An=20 > > > > attacker could deny service-- prevent a successful DTLS exchange > > > > or > > > successful > > > > discovery of AC-- but any middlebox can start dropping packets=20 > > > > on > a > > > > whim and do the same thing. I don't believe there is a > > > possibility of > > > > a resource exhaustion attack or launch a man-in-the-middle=20 > > > > attack against the AC or WTP. > > > > > > > > I don't think we really need to worry about doing DTLS > > > post-discovery. > > > > > > > > To address your call for wider WG response to this > recommendation: > > > > I strongly believe that (D)TLS should be used for the key > > > exchange and > > > > authentication protocol. > > > > > > > > My understanding on the reason that NIST preferred > > > AES-KeyWrap over > > > > IPsec for the transporting of PMKs had nothing to do with any=20 > > > > preceived weakness in IPsec. It was because there is nothing in > the > > > > IPsec standard to allow a user-space app-- like a RADIUS > > > client-- to > > > > know whether the packets it is sending are in the clear or > > > are IPsec- > > > > protected. Therefore a mis-configuration could result in PMKs > being > > > > sent over-the-wire in-the-clear. (There are IPsec > > > implementations that > > > > do allow for such queries of the SADB but that isn't part > > > of the IPsec > > > > standard and therefore there isn't a guarantee that such a > > > capability > > > > will be available everywhere). Putting the security for passing > the > > > > PMKs directly into the RADIUS app-- i.e. using > > > AES-KeyWrap-- addresses > > > > that concern. Therefore I don't believe NIST would have a=20 > > > > problem sending PTKs down a (D)TLS-protected link because the=20 > > > > app that is sending and receiving them knows whether that link=20 > > > > is > > > protected or not. > > > > > > > > Dan. > > > > > > > > On Wed, 28 Sep 2005 14:32:16 PDT you wrote > > > >> The evaluation team has made a request to modify LWAPP's=20 > > > >> built-in >=20 > > > >> security mechanism with DTLS instead. This specific change > > > is tricky > > > >> as we first need to identify whether the DTLS session should be > > > >> created prior to, or post, the discovery phase. > > > >> > > > >> Here are my high level thoughts on the issue: > > > >> 1. Pre-Discovery DTLS. > > > >> > > > >> One of the LWAPP features is load balancing of WTPs among > > > ACs. This > > > >> load balancing can occur within, or across multiple, ACs. How > this > > > >> works is that a WTP would perform the discovery phase by > > > initiating a > > > >> Discovery Request packet to one or more ACs. The receiving ACs=20 > > > >> respond with a Discovery Response, which also includes the=20 > > > >> total number of WTPs supported (see section 5.2.2), as well as > > > its current > > > >> WTP load (see section 5.2.3). The WTP collects all of the > > > Discovery > > > >> Responses, and then decides which AC it wishes to connect > > > to based on > > > >> its policy. The policy can be either least loaded AC, or=20 > > > >> through > a > > > >> list of preferred ACs (see section 7.2.3). Further, the > > > WTP can opt > > > >> to not establish a session with the AC if it determines > > > that it does > > > >> not have the basic capabilities required by the AC. > > > >> > > > >> Performing DTLS prior to the Discovery Request would mean that > the > > > >> WTP would mean one of two things: > > > >> a. The WTP establishes a DTLS session with every AC it > > > knows about. > > > >> The side effect here is the LWAPP connect time on the WTP, not=20 > > > >> to >=20 > > > >> mention the CPU load imposed on the AC. > > > >> b. The LWAPP protocol eliminates this feature altogether. > > > This means > > > >> that a WTP would only connect to the AC of its choice, > > > regardless of > > > >> the AC's current load of configuration. > > > >> > > > >> 2. Post-Discovery DTLS. In this mode, the above limitations are > > > >> removed, and the Discovery phase is done in the clear. While it > is > > > >> true that this raises some security concerns, the > > > information in the > > > >> Discovery Response is relatively benign, and therefore any > > > malicious > > > >> tweaking (or altering) of the response packet has created=20 > > > >> limited >=20 > > > >> damage (although the WG needs to evaluate this, but it was > > > not found > > > >> to be problematic during the security review). > > > >> > > > >> This change would also require that the the Discovery packets=20 > > > >> be exchanged on a separate UDP port, which is not a big change=20 > > > >> to > the > > > >> protocol. > > > >> > > > >> while I understand the evaluation team's recommendation to=20 > > > >> adopt DTLS, I would also like to get a larger WG rough=20 > > > >> consensus > > > on whether > > > >> we feel that this change should be made. While I will make > > > the change > > > >> based on rough consensus, I want to make sure that we > > > think and agree > > > >> on this decision through as a group. I understand the > > > concerns raised > > > >> about increasing the time of the protocol development > > > phase in having > > > >> our own security approach, there are strategies that can > > > be done to > > > >> help us. For instance, initiate another security review > > > with another > > > >> reviewer identified by Russ Housely asap (he did recommend > > > Charles Clancy, btw). > > > >> > > > >> I think that another important point here is that during a=20 > > > >> recent >=20 > > > >> meeting with NIST, we discussed the transport of 802.11i > > > PMKs within > > > >> the RADIUS protocol. During this discussion, we proposed > > > two methods. > > > >> The first would explicitely encrypt the PMK using > > > AES-KeyWrap within > > > >> a RADIUS attribute. The second approach was simply to encrypt=20 > > > >> the >=20 > > > >> whole RADIUS transaction with IPSec. It was NIST's opinion at > that > > > >> time that they felt comfortable with option one, while option=20 > > > >> two >=20 > > > >> would require them to evaluate whether IPSec would be > > > appropriate for > > > >> the transport of PMKs. Given that CAPWAP has a requirement > > > to allow > > > >> the WTP to perform encryption, this means that PTKs (and > > > GTKs) would > > > >> have to be transported over a DTLS session, and therefore I > wonder > > > >> whether we would have similar issues as those mentioned above.=20 > > > >> If >=20 > > > >> this were an issue, then FIPS certification of any CAPWAP > > > based system could become impossible. > > > >> > > > >> Your comments are appreciated, > > > >> > > > >> Pat Calhoun > > > >> CTO, Wireless Networking Business Unit Cisco Systems=20 > > > >> _______________________________________________ > > > >> Capwap mailing list > > > >> Capwap@frascone.com > > > >> http://mail.frascone.com/mailman/listinfo/capwap > > > >> > > > > _______________________________________________ > > > > Capwap mailing list > > > > Capwap@frascone.com > > > > http://mail.frascone.com/mailman/listinfo/capwap > > > > > > > > > > > > > _______________________________________________ > > > Capwap mailing list > > > Capwap@frascone.com > > > http://mail.frascone.com/mailman/listinfo/capwap > > > > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap >=20 _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Wed Oct 05 22:09:09 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENLC0-0005JF-TF for capwap-archive@megatron.ietf.org; Wed, 05 Oct 2005 22:09:08 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA16131 for ; Wed, 5 Oct 2005 22:09:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 7EC3F20400; Wed, 5 Oct 2005 22:09:03 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from smtp1.mei.co.jp (smtp.mei.co.jp [133.183.129.25]) by mail.frascone.com (Postfix) with ESMTP id D5127203FD for ; Wed, 5 Oct 2005 22:08:49 -0400 (EDT) Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp1.mei.co.jp (8.12.10/3.7W/jazz) with ESMTP id j9628k4S027721 for ; Thu, 6 Oct 2005 11:08:46 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx3) with ESMTP id j9628lg03529 for ; Thu, 6 Oct 2005 11:08:47 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/bluejays) with ESMTP id j9628kM25351 for ; Thu, 6 Oct 2005 11:08:47 +0900 (JST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message-ID: <5F09D220B62F79418461A978CA0921BD6DE6AA@pslexc01.psl.local> Thread-topic: CAPWAP Protocol Attributes Thread-Index: AcXKGofNHWbrSLVBSbq5B+Co9Mpp3A== From: "Saravanan Govindan" To: Subject: [Capwap] CAPWAP Protocol Attributes 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-Unsubscribe: , List-Id: A list for CAPWAP technical discussions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 6 Oct 2005 10:06:14 +0800 Content-Transfer-Encoding: quoted-printable All, The recent discussions on the Evaluation draft recommendations are of great use.=20 At the same time, it is important to realize that there are other recommendations made in the Evaluation draft. It would be of great use towards protocol development to list these other protocol attributes and capabilities based on the evaluation.=20 For example, Section 6.5 of the Evaluation highlights the need to incororate firmware checks independent of other functions. This needs to be included in the list of recommended attributes for the final protocol. Also, there was a recent discussion on how sequence counters are managed for the IEEE 802.11i key handshake in the CAPWAP framework. This is an important attribute for the protocol.=20 One way to capture all of these is to extend the recommendations section (Section 9) with a list of recommended attributes. This helps focus WG efforts towards producing a solid protocol. Saravanan=20 _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Thu Oct 06 01:09:32 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENO0a-0000Js-H4 for capwap-archive@megatron.ietf.org; Thu, 06 Oct 2005 01:09:32 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA23909 for ; Thu, 6 Oct 2005 01:09:24 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id EC7F020435; Thu, 6 Oct 2005 01:09:04 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from huawei-3com.com (smtp.huawei-3com.com [219.133.0.19]) by mail.frascone.com (Postfix) with ESMTP id B7410203FD for ; Thu, 6 Oct 2005 01:08:05 -0400 (EDT) Received: from smtp.huawei-3com.com (localhost [127.0.0.1]) by smtp.huawei-3com.com (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTP id <0INX006EL7BV6D@smtp.huawei-3com.com> for capwap@frascone.com; Thu, 06 Oct 2005 12:04:43 +0800 (CST) Received: from CAODONGHAI827 ([10.18.4.63]) by smtp.huawei-3com.com (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTPA id <0INX00MBT7BT1D@smtp.huawei-3com.com> for capwap@frascone.com; Thu, 06 Oct 2005 12:04:42 +0800 (CST) From: Bruce <02416@huawei-3com.com> To: capwap@frascone.com Message-id: <000001c5ca2b$a80a9f00$3f04120a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook, Build 10.0.3416 Content-type: multipart/related; boundary="Boundary_(ID_CC1kp5+u5Mx+9Yfy1BMw6w)" Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Subject: [Capwap] 7.8 Clear Config Indication & 8.1.1 Image Download 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-Unsubscribe: , List-Id: A list for CAPWAP technical discussions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 06 Oct 2005 09:38:49 +0530 This is a multi-part message in MIME format. --Boundary_(ID_CC1kp5+u5Mx+9Yfy1BMw6w) Content-type: multipart/alternative; boundary="Boundary_(ID_43wWtHMpy0C1OnI+kOa91g)" --Boundary_(ID_43wWtHMpy0C1OnI+kOa91g) Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7BIT Dear all, We have two question: 8.1.1Image Download Why does this element(TLV) have no type definition? 7.8 Clear Config Indication Why does this message have no response? Best wishes, Bruce --Boundary_(ID_43wWtHMpy0C1OnI+kOa91g) Content-type: text/html; charset=us-ascii Content-Transfer-Encoding: 7BIT

Dear all,

We have two question:

8.1.1Image Download

Why does this element(TLV) have no type definition?

7.8      Clear Config Indication

Why does this message have no response?

 

Best wishes,

Bruce

--Boundary_(ID_43wWtHMpy0C1OnI+kOa91g)-- --Boundary_(ID_CC1kp5+u5Mx+9Yfy1BMw6w) Content-id: Content-type: text/html; name=header.htm Content-transfer-encoding: quoted-printable Content-disposition: attachment; filename=header.htm Content-Transfer-Encoding: quoted-printable

 

 

Document Title

Security Level

 

 

2003-11-19

Confidential Information of Huawei-3Com.

 No Spreading without = Permission

Page1, Total1

 

 

 

--Boundary_(ID_CC1kp5+u5Mx+9Yfy1BMw6w) Content-id: Content-type: text/html; name=header.htm Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=header.htm Content-Transfer-Encoding: 7BIT

 

 

Document Title

Security Level

 

 

2003-11-19

Confidential Information of Huawei-3Com.

 No Spreading without Permission

Page1, Total1

 

 

 

--Boundary_(ID_CC1kp5+u5Mx+9Yfy1BMw6w)-- _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Thu Oct 06 05:32:38 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENS76-0003VU-UJ for capwap-archive@megatron.ietf.org; Thu, 06 Oct 2005 05:32:38 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA21001 for ; Thu, 6 Oct 2005 05:32:18 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A7E6020435; Thu, 6 Oct 2005 05:32:04 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from pop-tawny.atl.sa.earthlink.net (pop-tawny.atl.sa.earthlink.net [207.69.195.67]) by mail.frascone.com (Postfix) with ESMTP id C0CDE20440 for ; Wed, 5 Oct 2005 15:00:18 -0400 (EDT) Received: from elwamui-norfolk.atl.sa.earthlink.net ([209.86.224.43]) by pop-tawny.atl.sa.earthlink.net with esmtp (Exim 3.36 #10) id 1ENEUr-0005ds-00; Wed, 05 Oct 2005 15:00:09 -0400 Message-ID: <25077991.1128538809129.JavaMail.root@elwamui-norfolk.atl.sa.earthlink.net> From: "Scott G. Kelly" Reply-To: "Scott G. Kelly" To: "Pat Calhoun (pacalhou)" , James Kempf , "Nancy Winget (ncamwing)" , Darren Loher , Dan Harkins Subject: RE: [Capwap] Change Request 9.1.2 (Control Channel Security) Cc: capwap@frascone.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: EarthLink Zoo Mail 1.0 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-Unsubscribe: , List-Id: A list for CAPWAP technical discussions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 5 Oct 2005 12:00:09 -0700 (GMT-07:00) Content-Transfer-Encoding: 7bit I'd be willing to help with this. -----Original Message----- From: "Pat Calhoun (pacalhou)" Sent: Oct 5, 2005 11:56 AM To: James Kempf , "Nancy Winget (ncamwing)" , Darren Loher , Dan Harkins Cc: capwap@frascone.com Subject: RE: [Capwap] Change Request 9.1.2 (Control Channel Security) Great idea. Anyone willing to sign up? Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems > -----Original Message----- > From: James Kempf [mailto:Kempf@docomolabs-usa.com] > Sent: Wednesday, October 05, 2005 11:55 AM > To: Nancy Winget (ncamwing); Darren Loher; Pat Calhoun > (pacalhou); Dan Harkins > Cc: capwap@frascone.com > Subject: Re: [Capwap] Change Request 9.1.2 (Control Channel Security) > > Nancy, > > I think it is only fair to ask for a written proposal (i.e. a > draft) about how DTLS would be applied to LWAPP before the WG > makes a decision, if only to ensure that the technical > details are in order. > > jak > > > ----- Original Message ----- > From: "Nancy Winget (ncamwing)" > To: "Darren Loher" ; "Pat Calhoun > (pacalhou)" > ; "James Kempf" > ; "Dan Harkins" > Cc: > Sent: Wednesday, October 05, 2005 11:35 AM > Subject: RE: [Capwap] Change Request 9.1.2 (Control Channel Security) > > > > NIST's concern is that care and (re)review is taken when > security protocols that were designed for one application are > applied to another. > In the case of RADIUS, NIST pointed out that both RADIUS and > IPSec were complex enough that it was not clearly obvious to > them how the use of IPSec would address the key transport > security....nor has there been any security analysis to > demonstrate what security properties and vulnerabilities > IPSec provides when used with RADIUS. > > As for CAPWAP/LWAPP, it seems that the LWAPP protocol has > already undergone security review and has been shown to meet > this group's security requirements. So, how does DTLS > improve upon the currently proposed security? > > My concern is that thus far, the adoption of DTLS has been > suggested but I've not readily seen how it would be applied. > I believe modifications will have to be made to DTLS to > ensure it's appropriate use for this group's application. > DTLS is fairly open in how it achieves authentication to the > point that it does not guarantee (identity) authenticity, so > I think that additional specification for how DTLS is applied > will be needed. That is, strong recommendations of the > options of credential and cipher suites will have to be > defined to ensure that this group's security requirements are met. > > Nancy. > > -----Original Message----- > From: capwap-admin@frascone.com > [mailto:capwap-admin@frascone.com] On Behalf Of Darren Loher > Sent: Wednesday, October 05, 2005 7:36 AM > To: Pat Calhoun (pacalhou); James Kempf; Dan Harkins > Cc: capwap@frascone.com > Subject: RE: [Capwap] Change Request 9.1.2 (Control Channel Security) > > I think the main difference between NIST's concern and our > scenario is the following: > > As Pat relayed to us in the RADIUS with IPSec case, there is > no way for RADIUS to really know it's using IPSec and > therefore does not know if it's transport is secure or not. > > In the CAPWAP/LWAPP case the control channel is guaranteed to > be secure, so it's okay to carry to PTK/GTK within the > control channel. So within the context of CAPWAP, there is > implicit knowledge that transient keys are using secure transport. > > -Darren > > > -----Original Message----- > > From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com] > > Sent: Wednesday, October 05, 2005 8:08 AM > > To: Darren Loher; James Kempf; Dan Harkins > > Cc: capwap@frascone.com > > Subject: RE: [Capwap] Change Request 9.1.2 (Control Channel > Security) > > > > I think you meant PTK/GTK, but I was just making an observation that > the > > use of IPSec to carry keys was considered suspicious by > NIST. I see a > > parallel here in our proposed direction. > > > > I will follow what the WG feels is right, I was just making > sure folks > > > had additional info I thought was useful. > > > > Pat Calhoun > > CTO, Wireless Networking Business Unit Cisco Systems > > > > > > > > > -----Original Message----- > > > From: Darren Loher [mailto:DLoher@rovingplanet.com] > > > Sent: Sunday, October 02, 2005 12:17 PM > > > To: James Kempf; Pat Calhoun (pacalhou); Dan Harkins > > > Cc: capwap@frascone.com > > > Subject: RE: [Capwap] Change Request 9.1.2 (Control Channel > Security) > > > > > > Regarding secure distribtion of PMK/GMK between AC and WTP, it is > > > mandatory that these attributes are sent over the secured control > > > channel. So we should be covered on the AC <-> WTP communication. > > > > > > Isn't the transmission of RADIUS attributes an issue > between the AC > > > and a AAA server and therefore outside the scope of CAPWAP? > > > > > > -Darren > > > > > > ________________________________ > > > > > > From: capwap-admin@frascone.com on behalf of James Kempf > > > Sent: Thu 9/29/2005 9:54 AM > > > To: Pat Calhoun (pacalhou); Dan Harkins > > > Cc: capwap@frascone.com > > > Subject: Re: [Capwap] Change Request 9.1.2 (Control Channel > Security) > > > > > > > > > > > > I agree with Dan. I think the risk from doing DTLS > post-discovery is > > > > minimal. > > > > > > Security protocols have a history of bugs turning up after some > > > years of deployment. An added benefit of using DTLS is that LWAPP > > > benefits from the attention given to DTLS by users of other > > > protocols, so any bugs will most likely be found more > quickly than > > > if LWAPP designs its own, specialized protocol. > > > > > > Regarding IPsec v.s. DTLS v.s. encryption of the Radius attribute > > > for PMK distribution, I don't have any real opinion on this. > > > Actually, I think I would prefer to leave this as a deployment > > > option, with appropriate text in the Security > Considerations section > > > > about the requirement to use one of these method, and the methods > > > are described. I realize that there is an > interoperability concern > > > here, but I can imagine cases where a network operator > might prefer > > > one method over another due to their existing deployment. As Dan > > > mentioned, the concerns expressed about using IPsec related to > > > particular implementation issues rather than any fundamental > > > architectural or design issue with the protocol. But I > don't have a > > > real strong opinion on this, and I can think of reasons > why it might > > > > be a good idea to include a particular "required to implement" > > > method too. > > > > > > > > > jak > > > > > > > > > > > > ----- Original Message ----- > > > From: "Dan Harkins" > > > To: "Pat Calhoun (pacalhou)" > > > Cc: > > > Sent: Wednesday, September 28, 2005 3:16 PM > > > Subject: Re: [Capwap] Change Request 9.1.2 (Control Channel > Security) > > > > > > > > > > Pat, > > > > > > > > I agree that the information in the discovery phase is > > > benign. Also, > > > > anything an attacker could do to at that point is the same > > > as what an > > > > attacker could do during the DTLS "hello" exchange-- modify > > > packets in > > > > flight, redirect packets-- and the result would be the same: an > > > > unsuccessful DTLS exchange or unsuccessful discovery. > An attacker > > > > could deny service-- prevent a successful DTLS exchange or > > > successful > > > > discovery of AC-- but any middlebox can start dropping > packets on > a > > > > whim and do the same thing. I don't believe there is a > > > possibility of > > > > a resource exhaustion attack or launch a > man-in-the-middle attack > > > > against the AC or WTP. > > > > > > > > I don't think we really need to worry about doing DTLS > > > post-discovery. > > > > > > > > To address your call for wider WG response to this > recommendation: > > > > I strongly believe that (D)TLS should be used for the key > > > exchange and > > > > authentication protocol. > > > > > > > > My understanding on the reason that NIST preferred > > > AES-KeyWrap over > > > > IPsec for the transporting of PMKs had nothing to do with any > > > > preceived weakness in IPsec. It was because there is nothing in > the > > > > IPsec standard to allow a user-space app-- like a RADIUS > > > client-- to > > > > know whether the packets it is sending are in the clear or > > > are IPsec- > > > > protected. Therefore a mis-configuration could result in PMKs > being > > > > sent over-the-wire in-the-clear. (There are IPsec > > > implementations that > > > > do allow for such queries of the SADB but that isn't part > > > of the IPsec > > > > standard and therefore there isn't a guarantee that such a > > > capability > > > > will be available everywhere). Putting the security for passing > the > > > > PMKs directly into the RADIUS app-- i.e. using > > > AES-KeyWrap-- addresses > > > > that concern. Therefore I don't believe NIST would have > a problem > > > > sending PTKs down a (D)TLS-protected link because the > app that is > > > > sending and receiving them knows whether that link is > > > protected or not. > > > > > > > > Dan. > > > > > > > > On Wed, 28 Sep 2005 14:32:16 PDT you wrote > > > >> The evaluation team has made a request to modify > LWAPP's built-in > > > > >> security mechanism with DTLS instead. This specific change > > > is tricky > > > >> as we first need to identify whether the DTLS session > should be > > > >> created prior to, or post, the discovery phase. > > > >> > > > >> Here are my high level thoughts on the issue: > > > >> 1. Pre-Discovery DTLS. > > > >> > > > >> One of the LWAPP features is load balancing of WTPs among > > > ACs. This > > > >> load balancing can occur within, or across multiple, ACs. How > this > > > >> works is that a WTP would perform the discovery phase by > > > initiating a > > > >> Discovery Request packet to one or more ACs. The receiving ACs > > > >> respond with a Discovery Response, which also includes > the total > > > >> number of WTPs supported (see section 5.2.2), as well as > > > its current > > > >> WTP load (see section 5.2.3). The WTP collects all of the > > > Discovery > > > >> Responses, and then decides which AC it wishes to connect > > > to based on > > > >> its policy. The policy can be either least loaded AC, > or through > a > > > >> list of preferred ACs (see section 7.2.3). Further, the > > > WTP can opt > > > >> to not establish a session with the AC if it determines > > > that it does > > > >> not have the basic capabilities required by the AC. > > > >> > > > >> Performing DTLS prior to the Discovery Request would mean that > the > > > >> WTP would mean one of two things: > > > >> a. The WTP establishes a DTLS session with every AC it > > > knows about. > > > >> The side effect here is the LWAPP connect time on the > WTP, not to > > > > >> mention the CPU load imposed on the AC. > > > >> b. The LWAPP protocol eliminates this feature altogether. > > > This means > > > >> that a WTP would only connect to the AC of its choice, > > > regardless of > > > >> the AC's current load of configuration. > > > >> > > > >> 2. Post-Discovery DTLS. In this mode, the above > limitations are > > > >> removed, and the Discovery phase is done in the clear. While it > is > > > >> true that this raises some security concerns, the > > > information in the > > > >> Discovery Response is relatively benign, and therefore any > > > malicious > > > >> tweaking (or altering) of the response packet has > created limited > > > > >> damage (although the WG needs to evaluate this, but it was > > > not found > > > >> to be problematic during the security review). > > > >> > > > >> This change would also require that the the Discovery > packets be > > > >> exchanged on a separate UDP port, which is not a big change to > the > > > >> protocol. > > > >> > > > >> while I understand the evaluation team's > recommendation to adopt > > > >> DTLS, I would also like to get a larger WG rough consensus > > > on whether > > > >> we feel that this change should be made. While I will make > > > the change > > > >> based on rough consensus, I want to make sure that we > > > think and agree > > > >> on this decision through as a group. I understand the > > > concerns raised > > > >> about increasing the time of the protocol development > > > phase in having > > > >> our own security approach, there are strategies that can > > > be done to > > > >> help us. For instance, initiate another security review > > > with another > > > >> reviewer identified by Russ Housely asap (he did recommend > > > Charles Clancy, btw). > > > >> > > > >> I think that another important point here is that > during a recent > > > > >> meeting with NIST, we discussed the transport of 802.11i > > > PMKs within > > > >> the RADIUS protocol. During this discussion, we proposed > > > two methods. > > > >> The first would explicitely encrypt the PMK using > > > AES-KeyWrap within > > > >> a RADIUS attribute. The second approach was simply to > encrypt the > > > > >> whole RADIUS transaction with IPSec. It was NIST's opinion at > that > > > >> time that they felt comfortable with option one, while > option two > > > > >> would require them to evaluate whether IPSec would be > > > appropriate for > > > >> the transport of PMKs. Given that CAPWAP has a requirement > > > to allow > > > >> the WTP to perform encryption, this means that PTKs (and > > > GTKs) would > > > >> have to be transported over a DTLS session, and therefore I > wonder > > > >> whether we would have similar issues as those > mentioned above. If > > > > >> this were an issue, then FIPS certification of any CAPWAP > > > based system could become impossible. > > > >> > > > >> Your comments are appreciated, > > > >> > > > >> Pat Calhoun > > > >> CTO, Wireless Networking Business Unit Cisco Systems > > > >> _______________________________________________ > > > >> Capwap mailing list > > > >> Capwap@frascone.com > > > >> http://mail.frascone.com/mailman/listinfo/capwap > > > >> > > > > _______________________________________________ > > > > Capwap mailing list > > > > Capwap@frascone.com > > > > http://mail.frascone.com/mailman/listinfo/capwap > > > > > > > > > > > > > _______________________________________________ > > > Capwap mailing list > > > Capwap@frascone.com > > > http://mail.frascone.com/mailman/listinfo/capwap > > > > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap > _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Thu Oct 06 05:32:47 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENS7L-0003WC-CX for capwap-archive@megatron.ietf.org; Thu, 06 Oct 2005 05:32:47 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA21017 for ; Thu, 6 Oct 2005 05:32:40 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 23B082045B; Thu, 6 Oct 2005 05:32:08 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from pop-tawny.atl.sa.earthlink.net (pop-tawny.atl.sa.earthlink.net [207.69.195.67]) by mail.frascone.com (Postfix) with ESMTP id 9CB94203E7 for ; Wed, 5 Oct 2005 15:34:35 -0400 (EDT) Received: from elwamui-norfolk.atl.sa.earthlink.net ([209.86.224.43]) by pop-tawny.atl.sa.earthlink.net with esmtp (Exim 3.36 #10) id 1ENF0w-0000aY-00; Wed, 05 Oct 2005 15:33:18 -0400 Message-ID: <11270185.1128540798568.JavaMail.root@elwamui-norfolk.atl.sa.earthlink.net> From: "Scott G. Kelly" Reply-To: "Scott G. Kelly" To: "Nancy Winget (ncamwing)" , James Kempf , Susan Hares , Darren Loher , "Pat Calhoun (pacalhou)" , Dan Harkins Subject: RE: [Capwap] Change Request 9.1.2 (Control Channel Security) Cc: capwap@frascone.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: EarthLink Zoo Mail 1.0 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-Unsubscribe: , List-Id: A list for CAPWAP technical discussions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 5 Oct 2005 12:33:18 -0700 (GMT-07:00) Content-Transfer-Encoding: 7bit [This reply won't hit the capwap list until the admin releases it, since I'm using webmail and the account address is not the one from which I'm suscribed] Here are a few benefits: - DTLS is based on TLS (which is based on SSL); this suite has been around for quite some time, and has received extensive ongoing review by a large community. This is valuable. - DTLS supports parameter negotiation. If one of the crypto algorithms used by LWAPP is broken (or found to have weaknesses), we have but to change the recommended ciphers (not forklift the protocol). I think these alone are strong enough justification for contemplating the change. Scott -----Original Message----- From: "Nancy Winget (ncamwing)" Sent: Oct 5, 2005 12:25 PM To: James Kempf , Susan Hares , Darren Loher , "Pat Calhoun (pacalhou)" , Dan Harkins Cc: capwap@frascone.com Subject: RE: [Capwap] Change Request 9.1.2 (Control Channel Security) I wholly agree.....unless we see the proposed integration detailed (and written), it will be hard to assess it's viability not to mention its security properties. It is still not clear to me though, what added benefits DTLS would provide over what has already been proposed in LWAPP? It would be useful to have that data as well. Thanks, Nancy. -----Original Message----- From: James Kempf [mailto:Kempf@docomolabs-usa.com] Sent: Wednesday, October 05, 2005 12:04 PM To: Susan Hares; Nancy Winget (ncamwing); Darren Loher; Pat Calhoun (pacalhou); Dan Harkins Cc: capwap@frascone.com Subject: Re: [Capwap] Change Request 9.1.2 (Control Channel Security) Sue, Sure, that's why I think we need something written. It is entirely possible that the process of trying to figure out how it would work would result in realizing that it won't work (something which did, in fact, happen to me recently on another draft). On the other hand, the technical details may be surmountable, thereby allowing LWAPP to accrue the benefits of using what appears likely to be a widely implemented and used security protocol. jak ----- Original Message ----- From: "Susan Hares" To: "James Kempf" ; "Nancy Winget (ncamwing)" ; "Darren Loher" ; "Pat Calhoun (pacalhou)" ; "Dan Harkins" Cc: Sent: Wednesday, October 05, 2005 11:59 AM Subject: RE: [Capwap] Change Request 9.1.2 (Control Channel Security) James: The issues regarding DTLS state machine interaction are not 100% spelled out in the SLAPP proposal. Sue Dan - I believe I've gone through my reasons with you 8-9 months ago. Glad to provide you offline with this information again. -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of James Kempf Sent: Wednesday, October 05, 2005 2:55 PM To: Nancy Winget (ncamwing); Darren Loher; Pat Calhoun (pacalhou); Dan Harkins Cc: capwap@frascone.com Subject: Re: [Capwap] Change Request 9.1.2 (Control Channel Security) Nancy, I think it is only fair to ask for a written proposal (i.e. a draft) about how DTLS would be applied to LWAPP before the WG makes a decision, if only to ensure that the technical details are in order. jak ----- Original Message ----- From: "Nancy Winget (ncamwing)" To: "Darren Loher" ; "Pat Calhoun (pacalhou)" ; "James Kempf" ; "Dan Harkins" Cc: Sent: Wednesday, October 05, 2005 11:35 AM Subject: RE: [Capwap] Change Request 9.1.2 (Control Channel Security) NIST's concern is that care and (re)review is taken when security protocols that were designed for one application are applied to another. In the case of RADIUS, NIST pointed out that both RADIUS and IPSec were complex enough that it was not clearly obvious to them how the use of IPSec would address the key transport security....nor has there been any security analysis to demonstrate what security properties and vulnerabilities IPSec provides when used with RADIUS. As for CAPWAP/LWAPP, it seems that the LWAPP protocol has already undergone security review and has been shown to meet this group's security requirements. So, how does DTLS improve upon the currently proposed security? My concern is that thus far, the adoption of DTLS has been suggested but I've not readily seen how it would be applied. I believe modifications will have to be made to DTLS to ensure it's appropriate use for this group's application. DTLS is fairly open in how it achieves authentication to the point that it does not guarantee (identity) authenticity, so I think that additional specification for how DTLS is applied will be needed. That is, strong recommendations of the options of credential and cipher suites will have to be defined to ensure that this group's security requirements are met. Nancy. -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Darren Loher Sent: Wednesday, October 05, 2005 7:36 AM To: Pat Calhoun (pacalhou); James Kempf; Dan Harkins Cc: capwap@frascone.com Subject: RE: [Capwap] Change Request 9.1.2 (Control Channel Security) I think the main difference between NIST's concern and our scenario is the following: As Pat relayed to us in the RADIUS with IPSec case, there is no way for RADIUS to really know it's using IPSec and therefore does not know if it's transport is secure or not. In the CAPWAP/LWAPP case the control channel is guaranteed to be secure, so it's okay to carry to PTK/GTK within the control channel. So within the context of CAPWAP, there is implicit knowledge that transient keys are using secure transport. -Darren > -----Original Message----- > From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com] > Sent: Wednesday, October 05, 2005 8:08 AM > To: Darren Loher; James Kempf; Dan Harkins > Cc: capwap@frascone.com > Subject: RE: [Capwap] Change Request 9.1.2 (Control Channel Security) > > I think you meant PTK/GTK, but I was just making an observation that the > use of IPSec to carry keys was considered suspicious by NIST. I see a > parallel here in our proposed direction. > > I will follow what the WG feels is right, I was just making sure folks > had additional info I thought was useful. > > Pat Calhoun > CTO, Wireless Networking Business Unit Cisco Systems > > > > > -----Original Message----- > > From: Darren Loher [mailto:DLoher@rovingplanet.com] > > Sent: Sunday, October 02, 2005 12:17 PM > > To: James Kempf; Pat Calhoun (pacalhou); Dan Harkins > > Cc: capwap@frascone.com > > Subject: RE: [Capwap] Change Request 9.1.2 (Control Channel Security) > > > > Regarding secure distribtion of PMK/GMK between AC and WTP, it is > > mandatory that these attributes are sent over the secured control > > channel. So we should be covered on the AC <-> WTP communication. > > > > Isn't the transmission of RADIUS attributes an issue between the AC > > and a AAA server and therefore outside the scope of CAPWAP? > > > > -Darren > > > > ________________________________ > > > > From: capwap-admin@frascone.com on behalf of James Kempf > > Sent: Thu 9/29/2005 9:54 AM > > To: Pat Calhoun (pacalhou); Dan Harkins > > Cc: capwap@frascone.com > > Subject: Re: [Capwap] Change Request 9.1.2 (Control Channel Security) > > > > > > > > I agree with Dan. I think the risk from doing DTLS post-discovery is > > minimal. > > > > Security protocols have a history of bugs turning up after some > > years of deployment. An added benefit of using DTLS is that LWAPP > > benefits from the attention given to DTLS by users of other > > protocols, so any bugs will most likely be found more quickly than > > if LWAPP designs its own, specialized protocol. > > > > Regarding IPsec v.s. DTLS v.s. encryption of the Radius attribute > > for PMK distribution, I don't have any real opinion on this. > > Actually, I think I would prefer to leave this as a deployment > > option, with appropriate text in the Security Considerations section > > about the requirement to use one of these method, and the methods > > are described. I realize that there is an interoperability concern > > here, but I can imagine cases where a network operator might prefer > > one method over another due to their existing deployment. As Dan > > mentioned, the concerns expressed about using IPsec related to > > particular implementation issues rather than any fundamental > > architectural or design issue with the protocol. But I don't have a > > real strong opinion on this, and I can think of reasons why it might > > be a good idea to include a particular "required to implement" > > method too. > > > > > > jak > > > > > > > > ----- Original Message ----- > > From: "Dan Harkins" > > To: "Pat Calhoun (pacalhou)" > > Cc: > > Sent: Wednesday, September 28, 2005 3:16 PM > > Subject: Re: [Capwap] Change Request 9.1.2 (Control Channel Security) > > > > > > > Pat, > > > > > > I agree that the information in the discovery phase is > > benign. Also, > > > anything an attacker could do to at that point is the same > > as what an > > > attacker could do during the DTLS "hello" exchange-- modify > > packets in > > > flight, redirect packets-- and the result would be the same: an > > > unsuccessful DTLS exchange or unsuccessful discovery. An attacker > > > could deny service-- prevent a successful DTLS exchange or > > successful > > > discovery of AC-- but any middlebox can start dropping packets on a > > > whim and do the same thing. I don't believe there is a > > possibility of > > > a resource exhaustion attack or launch a man-in-the-middle attack > > > against the AC or WTP. > > > > > > I don't think we really need to worry about doing DTLS > > post-discovery. > > > > > > To address your call for wider WG response to this recommendation: > > > I strongly believe that (D)TLS should be used for the key > > exchange and > > > authentication protocol. > > > > > > My understanding on the reason that NIST preferred > > AES-KeyWrap over > > > IPsec for the transporting of PMKs had nothing to do with any > > > preceived weakness in IPsec. It was because there is nothing in the > > > IPsec standard to allow a user-space app-- like a RADIUS > > client-- to > > > know whether the packets it is sending are in the clear or > > are IPsec- > > > protected. Therefore a mis-configuration could result in PMKs being > > > sent over-the-wire in-the-clear. (There are IPsec > > implementations that > > > do allow for such queries of the SADB but that isn't part > > of the IPsec > > > standard and therefore there isn't a guarantee that such a > > capability > > > will be available everywhere). Putting the security for passing the > > > PMKs directly into the RADIUS app-- i.e. using > > AES-KeyWrap-- addresses > > > that concern. Therefore I don't believe NIST would have a problem > > > sending PTKs down a (D)TLS-protected link because the app that is > > > sending and receiving them knows whether that link is > > protected or not. > > > > > > Dan. > > > > > > On Wed, 28 Sep 2005 14:32:16 PDT you wrote > > >> The evaluation team has made a request to modify LWAPP's built-in > > >> security mechanism with DTLS instead. This specific change > > is tricky > > >> as we first need to identify whether the DTLS session should be > > >> created prior to, or post, the discovery phase. > > >> > > >> Here are my high level thoughts on the issue: > > >> 1. Pre-Discovery DTLS. > > >> > > >> One of the LWAPP features is load balancing of WTPs among > > ACs. This > > >> load balancing can occur within, or across multiple, ACs. How this > > >> works is that a WTP would perform the discovery phase by > > initiating a > > >> Discovery Request packet to one or more ACs. The receiving ACs > > >> respond with a Discovery Response, which also includes the total > > >> number of WTPs supported (see section 5.2.2), as well as > > its current > > >> WTP load (see section 5.2.3). The WTP collects all of the > > Discovery > > >> Responses, and then decides which AC it wishes to connect > > to based on > > >> its policy. The policy can be either least loaded AC, or through a > > >> list of preferred ACs (see section 7.2.3). Further, the > > WTP can opt > > >> to not establish a session with the AC if it determines > > that it does > > >> not have the basic capabilities required by the AC. > > >> > > >> Performing DTLS prior to the Discovery Request would mean that the > > >> WTP would mean one of two things: > > >> a. The WTP establishes a DTLS session with every AC it > > knows about. > > >> The side effect here is the LWAPP connect time on the WTP, not to > > >> mention the CPU load imposed on the AC. > > >> b. The LWAPP protocol eliminates this feature altogether. > > This means > > >> that a WTP would only connect to the AC of its choice, > > regardless of > > >> the AC's current load of configuration. > > >> > > >> 2. Post-Discovery DTLS. In this mode, the above limitations are > > >> removed, and the Discovery phase is done in the clear. While it is > > >> true that this raises some security concerns, the > > information in the > > >> Discovery Response is relatively benign, and therefore any > > malicious > > >> tweaking (or altering) of the response packet has created limited > > >> damage (although the WG needs to evaluate this, but it was > > not found > > >> to be problematic during the security review). > > >> > > >> This change would also require that the the Discovery packets be > > >> exchanged on a separate UDP port, which is not a big change to the > > >> protocol. > > >> > > >> while I understand the evaluation team's recommendation to adopt > > >> DTLS, I would also like to get a larger WG rough consensus > > on whether > > >> we feel that this change should be made. While I will make > > the change > > >> based on rough consensus, I want to make sure that we > > think and agree > > >> on this decision through as a group. I understand the > > concerns raised > > >> about increasing the time of the protocol development > > phase in having > > >> our own security approach, there are strategies that can > > be done to > > >> help us. For instance, initiate another security review > > with another > > >> reviewer identified by Russ Housely asap (he did recommend > > Charles Clancy, btw). > > >> > > >> I think that another important point here is that during a recent > > >> meeting with NIST, we discussed the transport of 802.11i > > PMKs within > > >> the RADIUS protocol. During this discussion, we proposed > > two methods. > > >> The first would explicitely encrypt the PMK using > > AES-KeyWrap within > > >> a RADIUS attribute. The second approach was simply to encrypt the > > >> whole RADIUS transaction with IPSec. It was NIST's opinion at that > > >> time that they felt comfortable with option one, while option two > > >> would require them to evaluate whether IPSec would be > > appropriate for > > >> the transport of PMKs. Given that CAPWAP has a requirement > > to allow > > >> the WTP to perform encryption, this means that PTKs (and > > GTKs) would > > >> have to be transported over a DTLS session, and therefore I wonder > > >> whether we would have similar issues as those mentioned above. If > > >> this were an issue, then FIPS certification of any CAPWAP > > based system could become impossible. > > >> > > >> Your comments are appreciated, > > >> > > >> Pat Calhoun > > >> CTO, Wireless Networking Business Unit Cisco Systems > > >> _______________________________________________ > > >> Capwap mailing list > > >> Capwap@frascone.com > > >> http://mail.frascone.com/mailman/listinfo/capwap > > >> > > > _______________________________________________ > > > Capwap mailing list > > > Capwap@frascone.com > > > http://mail.frascone.com/mailman/listinfo/capwap > > > > > > > > > _______________________________________________ > > Capwap mailing list > > Capwap@frascone.com > > http://mail.frascone.com/mailman/listinfo/capwap > > _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Thu Oct 06 06:50:13 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENTKH-0007TV-Sb for capwap-archive@megatron.ietf.org; Thu, 06 Oct 2005 06:50:13 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23999 for ; Thu, 6 Oct 2005 06:50:09 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D191B20435; Thu, 6 Oct 2005 06:50:04 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from ihemail2.lucent.com (ihemail2.lucent.com [192.11.222.163]) by mail.frascone.com (Postfix) with ESMTP id B3F5E203FD for ; Thu, 6 Oct 2005 06:49:42 -0400 (EDT) Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id j96AncIN007494; Thu, 6 Oct 2005 05:49:39 -0500 (CDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Thu, 6 Oct 2005 12:49:37 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155083CEB4A@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "Pat Calhoun (pacalhou)" Cc: capwap@frascone.com Subject: RE: [Capwap] Cisco IPR Statement MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain 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-Unsubscribe: , List-Id: A list for CAPWAP technical discussions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 6 Oct 2005 12:49:36 +0200 Inline (as an individual participant) > -----Original Message----- > From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com]On > Behalf Of Pat Calhoun (pacalhou) > Sent: Thursday, October 06, 2005 01:05 > To: Dan Harkins > Cc: capwap@frascone.com > Subject: RE: [Capwap] Cisco IPR Statement > > > > Cisco believe [the LWAPP IPR statement's license] is better than > > the traditional RAND IPR statement often used in other cases in > > standard organizations as what is reasonable terms is not known > > at the time of (according to the IETF process) last call of a > > document, and it is not clear the license terms, if known, will > > be exactly the same for all time. > > > > Yet Cisco is granting RAND terms on the IPR is claims to have > > that is necessary to implement CTP, WiCOP, and SLAPP, not the > > kind of terms it believes are better. > > Cisco feels that making its own contribution royalty free is generous. > We do not have a policy to do the same for contributions brought in by > others. > Pat, can I try to translate in my own words, so that I can veryify if I understand your statements correctly: 1.You say that there are some techniques/mechanisms/algorithms that Cisco has IPR on and that those do probably cover the current candidate protocols on the table in the CAPWAP WG. So they cover the technology/protocol that this WG wants to standardize. 2.You say that the LWAPP protocol (one of the candidates, submitted by Cisco) does include some of the techniques/mechanisms/algorithms that Cisco has IPR on. 3.You say that the 3 other (CTP, WiCOP, SLAPP) protocols (all 3 are candidates, but submitted by others (non-Cisco)) also include some of the techniques/mechanisms/algorithms that Cisco has IPR on. 4.You say (below) that: Cisco believes anyone having IPR on a technology they bring to the IETF should let anyone implement the technology without any need for explicit license, payments and other kind of uncertainties. So now I start to wonder: a.Is Cisco (or better individuals who work at Cisco) bringing technology (i.e. techniques/mechanisms/algorithms) to the CAPWAP WG in order for the WG to develop a standardized CAPWAP protocol? or, b.Is Cisco (or better individuals who work at Cisco) bringing an implementation of some specific technology (i.e. LWAPP) that contains those specific techniques/mechanisms/algorithms (on which Cisco has IPR) to the CAPWAP WG? c.It sounds like you are stating the answer is b. and that only if the CAPWAP WG selects the LWAPP candidate, only then will Cisco live up to its believes as listed in point 4. above. d.Does that imply that if the WG wants the "generous IPR conditions" of point 4. above, that they basically can only choose LWAPP, possibly with some additions? Pls do not read any of this as a complaint or value judgement. I ask those questions in order to make sure I understand what exactly is being stated/posted, and it seems I can best do that by translating what I think I am reading into my own words. If I got it wrong, pls explain where I make an error in my thinking/reading. more below > > > > You also said: > > > > Cisco believes anyone having IPR on a technology they bring to > > the IETF should let anyone implement the technology without any > > need for explicit license, payments and other kind of uncertainties. > > > > Yet Cisco is demanding an explicit license, payments and > > other kinds of uncertainties for the right to use the IPR it > > claims to have that is necessary to implement CTP, WiCOP, and SLAPP. > > > > Can you please explain why the actions Cisco is taking with > > respect to its IPR on CTP, WiCOP and SLAPP does not match its > > stated beliefs on IPR in the IETF? > > Please see above. > > > > > Can you also explain why the terms for Cisco's IPR on LWAPP > > are more favorable than the terms for Cisco's IPR on CTP, > > WiCOP and SLAPP? > > Please see above. > > > It would also be extremely helpful to the working group to > > know exactly what is being claimed because the changes > > recommended to LWAPP are in the protocols on which Cisco has > > given RAND terms. > > > > If the working group knows what is being claimed then we > > can ensure that any changes made to LWAPP will not include > > the technology being claimed. > > Not only is this not part of the IETF process, but to my > knowledge this > has this never occurred in another IETF Working Group. > > > If you are unable to tell the working group then there is a > > possibility that the resulting CAPWAP protocol will have RAND > > terms on it because it may include the technology from SLAPP > > that was covered by your IPR statement of 7 September 2005. > > I do not know about any Cisco IPR against the features being requested > by the evaluation team, as documented in draft-ietf-capwap-eval-00.txt. That sounds great. That sort of detail is very helpful for the WG in deciding which things it wants to add (or skip) in the final CAPWAP protocol. Would be good if you could also list details as to which pieces of each of the CAPWAP protocol candidates you do think are covered by IPR. So that does not mean detailing the IPR itself, but detailing which pieces of the documents on the table are covered/impacted. > That said, as with any protocol being designed, we cannot guarantee that > any future feature added will not infringe on Cisco (or someone else's) > patents - it's just part of the game :( > Yep... such is life. Bert (again, I spoke as an individual participant) > Pat Calhoun > CTO, Wireless Networking Business Unit > Cisco Systems > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap > _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Thu Oct 06 09:42:10 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENW0g-0004gb-6Y for capwap-archive@megatron.ietf.org; Thu, 06 Oct 2005 09:42:10 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03737 for ; Thu, 6 Oct 2005 09:42:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 704EE20462; Thu, 6 Oct 2005 09:42:04 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by mail.frascone.com (Postfix) with ESMTP id 3F27F203FD for ; Thu, 6 Oct 2005 09:41:27 -0400 (EDT) Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-3.cisco.com with ESMTP; 06 Oct 2005 06:41:27 -0700 X-IronPort-AV: i="3.97,182,1125903600"; d="scan'208"; a="348895590:sNHT24768912" Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j96DfA4j010672; Thu, 6 Oct 2005 06:41:24 -0700 (PDT) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 6 Oct 2005 06:40:32 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Capwap] Change Request 9.1.2 (Control Channel Security) Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2C47CA9@xmb-sjc-235.amer.cisco.com> Thread-Topic: [Capwap] Change Request 9.1.2 (Control Channel Security) Thread-Index: AcXJ6k1UaWBkSi0GS8i1Q4CmJMrh0AAEbQngAB/Sk+A= From: "Pat Calhoun (pacalhou)" To: "Darren Loher" , X-OriginalArrivalTime: 06 Oct 2005 13:40:32.0249 (UTC) FILETIME=[85AE0690:01C5CA7B] 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-Unsubscribe: , List-Id: A list for CAPWAP technical discussions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 6 Oct 2005 06:40:31 -0700 Content-Transfer-Encoding: quoted-printable Note that I am not pushing specifically against DTLS in this response, but want to address one of your comments: > At best, the proposed LWAPP security protocol will face a=20 > longer, slower approval process from the Security Area=20 > Directorate and the IESG. Use of an existing security=20 > mechanism would also need to be reviewed, but if properly=20 > specified, it will likely be quickly accepted. =20 I do believe that if we were to aggressively pursue security reviews today, we could alleviate some backend delays. The issues generally occur when the review occurs as part of (or post) the WG last call. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Thu Oct 06 09:46:10 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENW4Y-0006Vr-Sy for capwap-archive@megatron.ietf.org; Thu, 06 Oct 2005 09:46:10 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03968 for ; Thu, 6 Oct 2005 09:46:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 95D302046F; Thu, 6 Oct 2005 09:46:04 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from twoface.cisco.frascone.com (sj-natpool-220.cisco.com [128.107.248.220]) by mail.frascone.com (Postfix) with ESMTP id 84989203FD for ; Thu, 6 Oct 2005 09:45:15 -0400 (EDT) From: David Frascone To: capwap@frascone.com Subject: Re: [Capwap] Change Request 9.1.2 (Control Channel Security) Message-ID: <20051006084643.472ecea2@twoface.cisco.frascone.com> In-Reply-To: <4FF84B0BC277FF45AA27FE969DD956A2C47CA9@xmb-sjc-235.amer.cisco.com> References: <4FF84B0BC277FF45AA27FE969DD956A2C47CA9@xmb-sjc-235.amer.cisco.com> X-Mailer: Sylpheed-Claws 1.0.4a (GTK+ 1.2.10; x86_64-unknown-linux-gnu) X-Face: BZe8R&S)}GEDsLp@ay#IT{'D/X6}Xu/])^zA7D2W{)kwVA7)IhgW*{QSX6W(\BWhSON`p7% e3xQ1oJ=Qb@cQf#x[_Qas)'1f0;9DQJ>02}F_!.`'y>LE~`8e'{XO=fNX{n#\1:s:`Xy Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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-Unsubscribe: , List-Id: A list for CAPWAP technical discussions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 6 Oct 2005 08:46:43 -0500 Content-Transfer-Encoding: 7bit I had some mail server issues this weekend. Did you notice? -Dave On Thu, 6 Oct 2005 06:40:31 -0700 "Pat Calhoun (pacalhou)" wrote: >Note that I am not pushing specifically against DTLS in this response, >but want to address one of your comments: > >> At best, the proposed LWAPP security protocol will face a >> longer, slower approval process from the Security Area >> Directorate and the IESG. Use of an existing security >> mechanism would also need to be reviewed, but if properly >> specified, it will likely be quickly accepted. > >I do believe that if we were to aggressively pursue security reviews >today, we could alleviate some backend delays. The issues generally >occur when the review occurs as part of (or post) the WG last call. > >Pat Calhoun >CTO, Wireless Networking Business Unit >Cisco Systems >_______________________________________________ >Capwap mailing list >Capwap@frascone.com >http://mail.frascone.com/mailman/listinfo/capwap > -- David Frascone I had my coat hangers spayed. _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Thu Oct 06 09:48:09 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENW6S-0007B1-UG for capwap-archive@megatron.ietf.org; Thu, 06 Oct 2005 09:48:09 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04123 for ; Thu, 6 Oct 2005 09:48:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id EA2FF20474; Thu, 6 Oct 2005 09:48:03 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by mail.frascone.com (Postfix) with ESMTP id 20818203FD for ; Thu, 6 Oct 2005 09:47:29 -0400 (EDT) Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-2.cisco.com with ESMTP; 06 Oct 2005 06:47:29 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j96Dk54p014074; Thu, 6 Oct 2005 06:47:26 -0700 (PDT) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 6 Oct 2005 06:47:25 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Capwap] 7.8 Clear Config Indication & 8.1.1 Image Download Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2C47CAD@xmb-sjc-235.amer.cisco.com> Thread-Topic: [Capwap] 7.8 Clear Config Indication & 8.1.1 Image Download Thread-Index: AcXKNCc6k9OHQNmaSYi4skydvMUvdgAR9pnw From: "Pat Calhoun (pacalhou)" To: "Bruce" <02416@huawei-3com.com>, X-OriginalArrivalTime: 06 Oct 2005 13:47:25.0432 (UTC) FILETIME=[7BF4BF80:01C5CA7C] 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-Unsubscribe: , List-Id: A list for CAPWAP technical discussions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 6 Oct 2005 06:47:24 -0700 Content-Transfer-Encoding: quoted-printable =20 > 8.1.1Image Download > > Why does this element(TLV) have no type definition? Well, the text stated it was a non-NULL terminated variable length ASCII. That said, I have added the graphic to be more explicit. Will show up in the next version of the draft. > > 7.8 Clear Config Indication >=20 > Why does this message have no response? The packet is explicitely acknowledged, so there wasn't a need for an application level acknowledgement. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 ________________________________ From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Bruce Sent: Wednesday, October 05, 2005 9:09 PM To: capwap@frascone.com Subject: [Capwap] 7.8 Clear Config Indication & 8.1.1 Image Download =09 =09 Dear all, We have two question: 8.1.1Image Download Why does this element(TLV) have no type definition? 7.8 Clear Config Indication Why does this message have no response? =20 Best wishes, Bruce _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Thu Oct 06 13:21:32 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENZQv-0002pY-61 for capwap-archive@megatron.ietf.org; Thu, 06 Oct 2005 13:21:30 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16265 for ; Thu, 6 Oct 2005 13:21:19 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 983582049E; Thu, 6 Oct 2005 13:21:04 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from tierw.net.avaya.com (tierw.net.avaya.com [198.152.13.100]) by mail.frascone.com (Postfix) with ESMTP id AACD52048D for ; Thu, 6 Oct 2005 13:20:30 -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 j96H6opd029024 for ; Thu, 6 Oct 2005 13:06:51 -0400 (EDT) Received: from nj7460avexu2.global.avaya.com (h198-152-6-52.avaya.com [198.152.6.52]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id j96H4epd026438 for ; Thu, 6 Oct 2005 13:05:27 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5CA99.E225E39D" Subject: RE: [Capwap] Change Request 9.1.3.1. Support for Local MAC User Data Tunneling Message-ID: <5844A41F4E146044A2E8356C6328588009BAD5FD@nj7460avexu2.global.avaya.com> Thread-Topic: [Capwap] Change Request 9.1.3.1. Support for Local MAC User Data Tunneling Thread-Index: AcXEZkqBuwf+LMdnQ8KyHVKiUjMwyAA02ebAAAHWmtAAJ8HLcAAM1MswASFdofA= From: "Sadot, Emek (Emek)" To: "Pat Calhoun (pacalhou)" , 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-Unsubscribe: , List-Id: A list for CAPWAP technical discussions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 6 Oct 2005 13:17:52 -0400 This is a multi-part message in MIME format. ------_=_NextPart_001_01C5CA99.E225E39D Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Pat, =20 Yes, that's how I interpreted it, with a disclaimer for 802.11 control and management frames only. It goes for option #3 and #2. =20 Regards, Emek _____ =20 From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com]=20 Sent: Saturday, October 01, 2005 4:26 PM To: Sadot, Emek (Emek); capwap@frascone.com Subject: RE: [Capwap] Change Request 9.1.3.1. Support for Local MAC User Data Tunneling Emek, =20 In option 3, when a user associates with the WTP, the association is handled locally, but the packet is tunneled to the AC in order for the AC to have access to usage information (and make overriding policy decisions). So 802.11 needs to be supported on the AC regardless, right? =20 Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 _____ =20 From: Sadot, Emek (Emek) [mailto:esadot@avaya.com]=20 Sent: Friday, September 30, 2005 10:16 AM To: Pat Calhoun (pacalhou); capwap@frascone.com Subject: RE: [Capwap] Change Request 9.1.3.1. Support for Local MAC User Data Tunneling =09 =09 Regarding the points you raised I believe option #2 and #3 share the same qualities. In both options 802.11 encryption and 11e cannot be implemented at the AC. In both options a mechanism shall be design to extract RF and data-traffic statistics either (a) appended in the tunneling (option #3 only) or (b) exposed by the WTP as read-only values for the AC inquiries (both options). =20 Am I missing something? =20 On the other hand one can respect the unique merits that these options offer: - option 2: non-appliance product. meaning a software based AC that can be executed on any server / platform. - option 3: avoid parse 802.11 traffic in silicon at the AC. Leverage existing products (e.g. routers) with "only" add-on 802.11 code running at the Cpu. =20 Emek _____ =20 From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com]=20 Sent: Thursday, September 29, 2005 6:01 PM To: Sadot, Emek (Emek); capwap@frascone.com Subject: RE: [Capwap] Change Request 9.1.3.1. Support for Local MAC User Data Tunneling =09 =09 In terms of option 2, no traffic is sent to the AC, so the model is quite different. =20 Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 _____ =20 From: Sadot, Emek (Emek) [mailto:esadot@avaya.com]=20 Sent: Thursday, September 29, 2005 2:16 PM To: Pat Calhoun (pacalhou); capwap@frascone.com Subject: RE: [Capwap] Change Request 9.1.3.1. Support for Local MAC User Data Tunneling =09 =09 Pat, you certainly raise valid questions w.r.t. option #3, however I am curious as to the differences between the challenges you listed between options #2 and #3. In other words, in what sense option #2 and #3 are differ w.r.t. encryption and 11e at the AC, as well as RSSI/SNR/data-rate/other monitoring support? =20 Regards, Emek =20 _____ =20 From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Pat Calhoun (pacalhou) Sent: Wednesday, September 28, 2005 5:32 PM To: capwap@frascone.com Subject: [Capwap] Change Request 9.1.3.1. Support for Local MAC User Data Tunneling =09 =09 This change request is to allow for 802.3 tunneling of user data in local bridging mode. I believe that the changes should be relatively straightforward, but do introduce an interesting set of complications that need to be evaluated and agreed upon as a group. =20 The LWAPP protocol currently allows for 802.11 tunneling in Split-MAC mode, allowing for such things as centralized encryption of user data frames. However, the current definition of the protocol is that when running in Local-MAC mode, no traffic is tunneled to the controller. =20 If we were to introduce this change, the LWAPP protocol would have three modes of operation: 1. Split-MAC: Tunnel native MAC frames in UDP (e.g., 802.11) 2. Local-MAC w/ Local Bridge: Do not tunnel 802.3 frames 3. Local-MAC w/ Tunnel: Tunnel 802.3 frames in UDP =20 The issue that we need to decide as a group is whether we really want a protocol that has three modes of operation, and if so, which one is mandatory. The evaluation draft states that option 3 is useful for support of non 802.11 technologies, but this introduces a set of restrictions. For instance, today the LWAPP protocol allows for centralized control of various 802.11 functions, including encryption and 802.11e. This function is not possible with option 3, and therefore any new technology that assumes this option would not be able to provide centralization of data frame functions. =20 There is a comment in the recommendation that LWAPP could retain the RSSI/SNR fields, and then perform 802.3 encapsulation, allowing the AC to have more visibility. However, I have had some requests to expand these fields to also include the data rate. Further, there are possible fields in the header (of technologies we know nothing about) that the WTP may want to extract and expose to the AC - and how could this be done with 802.3? Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 ------_=_NextPart_001_01C5CA99.E225E39D Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Pat,
 
Yes,=20 that's how I interpreted it, with a disclaimer for 802.11 control=20 and management frames only.
It=20 goes for option #3 and #2.
 
Regards,
Emek

From: Pat Calhoun (pacalhou)=20 [mailto:pcalhoun@cisco.com]
Sent: Saturday, October 01, 2005 = 4:26=20 PM
To: Sadot, Emek (Emek); = capwap@frascone.com
Subject: RE:=20 [Capwap] Change Request 9.1.3.1. Support for Local MAC User Data=20 Tunneling

Emek,
 
In option 3, when a user associates with the = WTP, the=20 association is handled locally, but the packet is tunneled to the AC in = order=20 for the AC to have access to usage information (and make overriding = policy=20 decisions). So 802.11 needs to be supported on the AC regardless,=20 right?
 

Pat Calhoun
CTO, Wireless Networking = Business=20 Unit
Cisco Systems

 

From: Sadot, Emek (Emek)=20 [mailto:esadot@avaya.com]
Sent: Friday, September 30, 2005 = 10:16=20 AM
To: Pat Calhoun (pacalhou);=20 capwap@frascone.com
Subject: RE: [Capwap] Change Request = 9.1.3.1.=20 Support for Local MAC User Data Tunneling

Regarding the points you raised I believe option #2 and #3 = share the=20 same qualities.
In=20 both options 802.11 encryption and 11e cannot be implemented at = the=20 AC.
In=20 both options a mechanism shall be design to extract RF and = data-traffic=20 statistics either (a) appended in the tunneling (option #3 only) = or=20 (b) exposed by the WTP as read-only values for the AC = inquiries=20 (both options).
 
Am I=20 missing something?
 
On=20 the other hand one can respect the unique merits that these=20 options offer:
-=20 option 2: non-appliance product. meaning a software based AC that can = be=20 executed on any server / platform.
-=20 option 3: avoid parse 802.11 traffic in silicon at the AC. Leverage = existing=20 products (e.g. routers) with "only" add-on 802.11 code running at the=20 Cpu.
 
Emek

From: Pat Calhoun (pacalhou)=20 [mailto:pcalhoun@cisco.com]
Sent: Thursday, September 29, = 2005 6:01=20 PM
To: Sadot, Emek (Emek); = capwap@frascone.com
Subject:=20 RE: [Capwap] Change Request 9.1.3.1. Support for Local MAC User Data=20 Tunneling

In terms of option 2, no traffic is sent to = the AC, so=20 the model is quite different.
 

Pat Calhoun
CTO, Wireless Networking = Business=20 Unit
Cisco Systems

 

From: Sadot, Emek (Emek)=20 [mailto:esadot@avaya.com]
Sent: Thursday, September 29, = 2005 2:16=20 PM
To: Pat Calhoun (pacalhou);=20 capwap@frascone.com
Subject: RE: [Capwap] Change Request = 9.1.3.1.=20 Support for Local MAC User Data Tunneling

Pat, you certainly raise valid questions w.r.t. option #3, = however I=20 am curious as to the differences between the challenges you = listed=20 between options #2 and #3. In other words, in what = sense option #2=20 and #3 are differ w.r.t. encryption and 11e at the AC, as well as=20 RSSI/SNR/data-rate/other monitoring support?
 
Regards,
Emek
 
From: = capwap-admin@frascone.com=20 [mailto:capwap-admin@frascone.com] On Behalf Of Pat Calhoun=20 (pacalhou)
Sent: Wednesday, September 28, 2005 5:32=20 PM
To: capwap@frascone.com
Subject: [Capwap] = Change=20 Request 9.1.3.1. Support for Local MAC User Data=20 Tunneling

This change=20 request is to allow for 802.3 tunneling of user data in local = bridging mode.=20 I believe that the changes should be relatively straightforward, but = do=20 introduce an interesting set of complications that need to be = evaluated and=20 agreed upon as a group.
 
The LWAPP=20 protocol currently allows for 802.11 tunneling in Split-MAC mode, = allowing=20 for such things as centralized encryption of user data frames. = However, the=20 current definition of the protocol is that when running in Local-MAC = mode,=20 no traffic is tunneled to the controller.
 
If = we were to=20 introduce this change, the LWAPP protocol would have three modes of=20 operation:
1. = Split-MAC:=20 Tunnel native MAC frames in UDP (e.g., = 802.11)
2. = Local-MAC w/=20 Local Bridge: Do not tunnel 802.3 frames
3. = Local-MAC w/=20 Tunnel: Tunnel 802.3 frames in UDP
 
The issue that=20 we need to decide as a group is whether we really want a protocol = that has=20 three modes of operation, and if so, which one is mandatory. The = evaluation=20 draft states that option 3 is useful for support of non 802.11 = technologies,=20 but this introduces a set of restrictions. For instance, today the = LWAPP=20 protocol allows for centralized control of various 802.11 functions, = including encryption and 802.11e. This function is not possible = with=20 option 3, and therefore any new technology that assumes this option = would=20 not be able to provide centralization of data frame=20 functions.
 
There is a=20 comment in the recommendation that LWAPP could retain the RSSI/SNR = fields,=20 and then perform 802.3 encapsulation, allowing the AC to have more=20 visibility. However, I have had some requests to expand these fields = to also=20 include the data rate. Further, there are possible fields in the = header (of=20 technologies we know nothing about) that the WTP may want to extract = and=20 expose to the AC - and how could this be done with=20 802.3?

Pat Calhoun
CTO, Wireless = Networking Business=20 Unit
Cisco Systems

 
------_=_NextPart_001_01C5CA99.E225E39D-- _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Thu Oct 06 13:23:10 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENZSY-0003DS-4R for capwap-archive@megatron.ietf.org; Thu, 06 Oct 2005 13:23:10 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16357 for ; Thu, 6 Oct 2005 13:23:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 87491204AA; Thu, 6 Oct 2005 13:23:04 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from homebrew.trpz.com (66-7-225-40.cust.telepacific.net [66.7.225.40]) by mail.frascone.com (Postfix) with ESMTP id C03632048D for ; Thu, 6 Oct 2005 13:22:15 -0400 (EDT) Received: from trpz.com (localhost.trpz.com [127.0.0.1]) by homebrew.trpz.com (8.13.1/8.13.1) with ESMTP id j96HFS7q084392; Thu, 6 Oct 2005 10:15:28 -0700 (PDT) (envelope-from dharkins@trpz.com) Message-Id: <200510061715.j96HFS7q084392@homebrew.trpz.com> To: "Nancy Winget (ncamwing)" Cc: "Darren Loher" , "Pat Calhoun (pacalhou)" , "James Kempf" , capwap@frascone.com, ekr@rtfm.com Subject: Re: [Capwap] Change Request 9.1.2 (Control Channel Security) In-Reply-To: Your message of "Wed, 05 Oct 2005 16:52:56 PDT." <08A9A3213527A6428774900A80DBD8D8C27D45@xmb-sjc-222.amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <84390.1128618928.1@trpz.com> From: Dan Harkins 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-Unsubscribe: , List-Id: A list for CAPWAP technical discussions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 06 Oct 2005 10:15:28 -0700 Hi Nancy, On Wed, 05 Oct 2005 16:52:56 PDT you wrote > Hi Dan, > > The devil is in the details. We can state that particular protocols are > secure because they have been deemed secure. But just because they are > secure does not mean that when they are applied to some other context, > their security properties are retained or that it meets the security > requirements posed on the applied context. That is the gist of what > NIST conveyed and I am trying to reiterate the same for our context, > e.g. CAPWAP/LWAPP and DTLS. Yes, a good example of a protocol being secure in one context and problematic when used in a another context is IPsec protecting RADIUS. And the _specific_ complaint NIST had was that the RADIUS app (client or server) did not have a standard way of knowing whether the keys being transmitted (received or sent, respectively) were IPsec-protected or not. It was possible for a mis-configuration to not be noticed by the entities taking part in the key dissemination. That is a FIPS-140 no no. Now, when you think about that _specific_ example in our context-- CAPWAP and DTLS-- it becomes obvious that the entities taking part in the key dissemination, the AC and WTP, will know whether that transmission is protected by DTLS or not because they took part in the exchange. The DTLS exchange will be a mandatory step in CAPWAP and a mis-configuration of the AC or WTP that resulted in a DTLS failure will not allow for the AC to manage the WTP. > DTLS carries its own state machine that am not sure how it fits in the > CAPWAP realm. DTLS depending on selected cipher suites, credential > types provides a range of security properties. Thus, my comment/request > is that those that are proposing DTLS provide more information of how it > fits into the CAPWAP model and how it addresses the groups requirements. It will fit in very nicely. As has been discussed on this list it should be post-discovery which is basically where the exchange it is replacing resides. It's probably not a simple ker-splat drop in, some loose ends may have to be tied up but that is straightforward and not difficult. I'm surprised by your request for more information on how DTLS fits into this group's requirements. It is widely accepted that it does fit the group's requirements and the evalution team even recommended it. Can you be more specific in your request for information? > As a proposer of LWAPP, I can state that the group of proposers did put > the "onus" on ourselves to ensure that both the draft be as complete and > descriptive of how it meets the CAPWAP model as well as ensuring that it > be fully reviewed inclusive of its security properties. It's not clear > to me how DTLS fits into the CAPWAP model....so, as I am not a proposer > of this suggestion, I am requesting those who are to provide one. I know the the proposers of LWAPP considered DTLS. Can you tell me why you chose not to use it? Perhaps you were not on the team back then so maybe one of the other proposers can chime in. Again, if you can be more specific about what is not clear to you perhaps your questions can be answered. Dan. _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Thu Oct 06 13:47:10 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENZpm-00015t-6B for capwap-archive@megatron.ietf.org; Thu, 06 Oct 2005 13:47:10 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17671 for ; Thu, 6 Oct 2005 13:47:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 6E080204B2; Thu, 6 Oct 2005 13:47:03 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from ctron-dnm.enterasys.com (ctron-dnm.enterasys.com [12.25.1.120]) by mail.frascone.com (Postfix) with ESMTP id 84EB82048D for ; Thu, 6 Oct 2005 13:46:51 -0400 (EDT) Received: (from uucp@localhost) by ctron-dnm.enterasys.com (8.8.7/8.8.7) id NAA02300 for ; Thu, 6 Oct 2005 13:50:00 -0400 (EDT) Received: from nhrocavg2(134.141.79.124) by ctron-dnm.enterasys.com via smap (4.1) id xma002278; Thu, 6 Oct 05 13:49:11 -0400 Received: from NHROCCNC1.ets.enterasys.com ([134.141.79.124]) by 134.141.79.124 with InterScan Messaging Security Suite; Thu, 06 Oct 2005 13:45:56 -0400 Received: from source ([134.141.77.90]) by host ([134.141.79.124]) with SMTP; Thu, 06 Oct 2005 13:45:56 -0400 Received: from maandmbx2 ([134.141.93.31]) by NHROCCNC1.ets.enterasys.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 6 Oct 2005 13:45:56 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Capwap] Change Request 9.1.2 (Control Channel Security) Message-ID: <2A5E4540D4D5934D9A1E7E0B0FDB2D69010325C9@MAANDMBX2.ets.enterasys.com> Thread-Topic: [Capwap] Change Request 9.1.2 (Control Channel Security) Thread-Index: AcXJ6k1UaWBkSi0GS8i1Q4CmJMrh0AAEbQngAB/Sk+AACBD4AA== From: "Nelson, David" To: X-OriginalArrivalTime: 06 Oct 2005 17:45:56.0302 (UTC) FILETIME=[CDE636E0:01C5CA9D] X-pstn-version: pmps:sps_win32_1_1_0c1 pase:2.8 X-pstn-levels: (C:93.2377 M:91.9762 P:95.9108 R:95.9108 S:99.9000 ) X-pstn-settings: 4 (0.2500:0.2500) p:13 m:13 c:14 r:13 X-pstn-addresses: from forward (org good) 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-Unsubscribe: , List-Id: A list for CAPWAP technical discussions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 6 Oct 2005 13:45:55 -0400 Content-Transfer-Encoding: quoted-printable Pat Calhoun writes... > I do believe that if we were to aggressively pursue security reviews > today, we could alleviate some backend delays. Certainly. However, this remains me of an old saying: "With sufficient thrust, even a Buick can be made to fly." The relevant question is: "What's the level of return-on-investment for the effort required?". This comment isn't intended to disparage the engineering quality of the current LWAPP security mechanism, but rather to question where the WG should allocate its energies. There are good reasons for the IETF community to prefer well-used security mechanisms in its protocols. Formal security review addresses some of them. There is also some value in commonality for commonality's sake, such as the benefit of ongoing review of the protocols and ongoing attempts to find attacks. The commonly used protocols will receive more scrutiny that more specialized ones. The reasons of suggesting a non-novel security mechanism for CAPWAP included the onus of undertaking multiple, independent security reviews, as well as the general preference for re-use of common mechanisms. The potential desire to achieve external certification of CAPWAP implementations, e.g. NIST/FIPS, is another reason for choosing a commonly used security mechanism.=20 _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From hightower@it21.com Thu Oct 06 17:42:06 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENdV8-0007Aj-L7; Thu, 06 Oct 2005 17:42:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19364; Thu, 6 Oct 2005 17:42:01 -0400 (EDT) Received: from 24-216-241-17.dhcp.mdfd.or.charter.com ([24.216.241.17]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1ENdeC-0001fk-EZ; Thu, 06 Oct 2005 17:51:32 -0400 Received: from 24.216.241.17 ([24.216.241.17]) by localhost.localdomain (8.12.10/8.12.10) with ESMTP id cWYpe5NZ (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=YES check=NO) for ; Thu, 06 Oct 2005 16:41:38 -0600 X-BrightmailFiltered: true X-Brightmail-Tracker: JJCVD== X-IronPort-AV: i="3.96,160,4332280334"; d="scan'640"; a="3283847:sNHT403616237" Message-Id: <6.0.3.63.0.15910912344029.44517086@gelatine.hotmail.com> X-Sender: hightower@it21.com X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.64 Date: Thu, 06 Oct 2005 16:41:38 -0600 To: capwap-archive@ietf.org From: "Kara Baird" Subject: Ratess approved Mime-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="=====================_RPTATT19815439.Exime" X-Spam-Score: 4.8 (++++) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 --=====================_RPTATT19815439.Exime Content-Type: multipart/alternative; boundary="=====================_RPTATT53822550.Exime" --=====================_RPTATT53822550.Exime Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: 7bit whale is prague forthcome barrymore and communicable disburse but affirmative alloy a brazier tangible brae, amp clapeyron and icon thud, asperity upholster say try itinerary beret but bedtime dustbin is increase badge again and otter soapsud but estate --=====================_RPTATT53822550.Exime Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: 7bit

eject in under some dooley it budd some dukedom on jacky try touchdown see bindweed may sheridan ! oracular a someplace a antisemitism it's ravel it jesse see leopard it leninist it karate be mynah some annual not beneficent but agenda try sam ! lubricate the xavier it collude it brain the dollar see sealant or graybeard not clausius a philanthropic it prayerful ! brickbat not bitten it's memoir not aviatrix and.
Not, go here http://www.ahmort.com/book.php
--=====================_RPTATT53822550.Exime-- --=====================_RPTATT19815439.Exime Content-Type: image/gif; name="auxiliary.09.gif"; x-mac-type="1A320018"; x-mac-creator="6A478011" Content-ID: <7.0.0.39.0.88271600751736.29994862@binuclear.msn.com.2> Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="auxiliary.09.gif" Content-Transfer-Encoding: base64 R0lGODlhTgIqAZEAAP///wAAAP8AAAAAmSH5BAAAAAAALAAAAABOAioBAAL/RIB4yb3Wopy0 2ouz3rz7D4biSJbmiabqymaPgj1vS9f2jef6zvf+r5u9AkRhQlgEKpfMpvMJjUqDjiNjaM3C ptyu9wsOi8eOYnKLhqSx5Lb7DY/L40aFma1ez/f8vv8PKFKXFyFzdRiYqLjI2Ng1OINIiOdY aXmJmQkCKZlHGakZKjpKCjhocKaFRFRV6voKGxsKKltre4sLRpvL2+v7CxwsPExcbHyMnKy8 zNzs/AwdLT1NXW19jZ2tvc3d7f0NHi4+Tl5ufo6err7O3u7+Dh8vP09fb3+Pn6+/z9/v/w8w oMCBBAsaPIgwocKFDBs6fAgxosSJFCtavIgxIx0J/7s2dFTxcUlICiMLVWD1pKQJlRZYatHI 5FQIlyNo7rCZRsMunDV4fvDZCeYbQ0dS6eGIKpKZl5OMVnGadJURqFdQVrVKKGoZGUaXXs1a 1KpXK1i3fiJLS6oqVVBTjX3KFevYtyZhUM05xOnbA3LLTiQ6qVNawIGzEh78Es8nwpLOHkUD +FTknYKrnmzcuKPjyI89MS1TOXHQzJ/xin5clvHfwp3Tjl7beoJjyKFzlmY9G5Tk00h5g21F GzbJ2nwhHH6t+bJvyp2Bz3ZeF+Zu37XDcrbut/Ud7M+3mhV71W1v7tSrUxrvWbhs4sY9bf96 27bWxO/Hn8dMPnzpuxKnN/+nfpxM65Un33/R/cYacEG5Ft9zHymG33C8FVdcgdBJGGGCymn4 lIIXImghRP5xGJtoAqJ3n4UpKshggbp5SGCJIeKWIYqYURhfjR466EKMdsGI2oYWjcjVgKgJ uCJ4E5pnZG7sBbekHRgm+GCESk7p5HLqHegek02+RhaLbH2m2mpmFcJKi4alCSRdh7Sll15g JoWmXGfCZ0deqbFpZJ4n3hlWelPOt6WbXWUHVhJ6WrfhivvFWeFvclYnVKXMAGVppulgqmmn 4iDqaaiijkpqqaaeimqqqq7KaquuvgprrLLOSmuttt6Ka6667sprr77+Cmywwg5LbLHGHots ssr/Lstss84+C2200k5LbbXWXtsHqEJpG5Ff3CqB6LceiHuTm0XVqZS54aUL6bf89SBWXpad C0R9frJ76LtO9HUSp2Lw+whiKZCbw1LZxSklvaiQVKTC8SrMkb8ogApwwj4Y3PDC84JmMRcV R4wJSn0h3DG66Mrb8cj63qGnyjvthXJUUunG18sfc6wxyCln/LBsc9Fl78mA+uwwxmfsqa/M Q6OZc9Eb48xt0CcDDXPVIktNMB9XO821zhX33HTP717Nc8w65www2HQSHW7NT0P9MsRgq810 12szzLW2an/8tWZll2xZ1C333S/EddI5d1w7w7dnJjDLnXHdkie+Md1w/9utd+RbW3yzySC7 jIThlcdMOd6Yu2Q50YtDPrpOkffbduOcv1646Zuj/TfrJWedbeirN43z5bO3DjjxMnduvMbx 2isu1TsvQLjqYecOfPB7l8T8ypqbDXpI2TfPH8XUMzw29OZ3fX3y1Tsi+/Siv4/76XZPTjv8 w+tnP/jx/x792f2nrjv3XeB2bxPe7wTogvNJDm9tM93+bOe3hJXugQhs3yXa178FGi9995Me ANc3v8dJr3DLqw8HQUjBCWYuee6q3woPyDeVpK6FD/xf/ebHsdupkHuv453WfCfA8Cmwg2Qj XvnyJD8HeguIyDuXuipIurjxb3wLPCEEG/ZCBP9q8YPKE1vcRBjEKNbuiF1E3/bUJ4olwumJ hMLOd3jIxuOta2lz1KDSCvid2rkxj0/DGtW0x0f7ratlLdke2YZ4rwF+70GGamS7vCe1eREw e5DTIRAL4kMoZPInEgvHJrHlwU424pOgxGQcS4nKVKpylaxspStfCctYynKWtKylLW+Jy1zq cpe87KUvfwnMYApzmMQspjGPicxkKnOZzGymM58JzWhKc5rUrKY1vyCAbGpTAB/I5g68iQBw hpObG9imNkkgTieY0wLmTOc3yTnOFrjTnSigJw/s2YVzxrME+HxCOvt5gX/Cs5wDvUE/ASoB gY4AofeEJ0AV2gOIrmD/ngWtZ0UbOgaGhkCjSpBoBzy6zga0k536HGdJQ8qAke4TACgN6EAF WlKTxlSc4EQpTR3aUpkmAKI3rQBFRbpNoMaUpUNV6UpzutN20tOmQSXqSZsq04tOAKY8JSc+ W8rUmUJVpyTVqlcPCtWa4jSlW3XqUIVa1LJGQKkU/So3sbrVdUq0p0k1qU+titOXjrWuTuXr SjMw173alah8vWlB6dpXwhYWr2RNqFT/qtijCpauMJVsYylwzszq1a8/5WxeOYBYyjLWsYed bGk9C1mgeva0qfWrZQO72McmNrSy1exbTXtZyNI2r2p1LWIdC9zcwvavHE0qUn2LW49adrmt /xVrcDHLWubSdqqCXWttRwtW10Y2sr8FLG6Ne9zWCje63fWudrn72M4SdrjovStqxbtP5z53 u+r9rXLhet7c6tesWn0vfKm7X/xKVr3+te9F5bvf+dLXtHCtb3qvG9+KMlW14H3qR78b1bPm l7/aVSpZNTphtGpYt3otbYi3a90CQ1ixbQWpicO6WeQSt7oprvGG2ztj0MY4wuOtcIKnm2PS Sli2Hd5xeW2MYwVTGME8JnGC/wtg5vJ3xChuMooZilAEL5XIRf4whW38UAyH2cos3vGVpepi /yZZyWeGrpqLG+Q1A7m8QF4wdbeMAQLX2c1q/nJwmbxnO7OZpG/2cP+Ue+xkQvN5zVDucjyV 2+cvB3rJo5WzmascZxz3N7FR7q6BBytoDQx305qmcZk/K2iqguC+Yt4re5FcY0DjlcbshbN0 WTtmStP6u7m2sKQf/OtQi3bFSe51pcVqZgcjN6dGzXBXL81hEVcXxndltoCLXekPP1Wt3D4w l6fs7bSKm7wPvip2X2xY3vr4vLmOaqyJre10xxutLqW2dancZkuPu91UJbJ8+13iWQcc2pWw tTq/PWhuGPyaim7DwjHdjYczHBAGx/fEL47xjGt84xzvuMc/Xo2F4xnktBL5kEmOqn8LfMvb hjTKQ6Xywdb65C83FVsjHWmJ13wiN5eyu1P/q/OdR6TnjNYyzYUuKqJ/2ucQR7qlZC1jTgfd 6RaBOolh7HKqa33rXO+6178O9rCLfexkL7vZz472tKt97Wxvu9vfDve4y33udK+73e+O97zr fe9877vf/w74wAt+8IQvvOEPj/jEK37xjG+84x8P+chLfvKUr7zlL4/5zGt+85zvvOc/f4kB iH70osdB6U8w+kScPgKrB0DrP9D616Oe9A2QfQJeT/oBsF73DLC963mPgNjnfvXDx33xjeX7 FiTfA8ufg++bz3zg04D40k++8G8v/d/3Pvvb7z72KWB87ytL9rm/wPC3n/rg0x78659A+X+f fvXHX/7Qr/370Q/9//vDf/7Xx3776Q9872d8/Kd/EhB+6sd+3yd+2oeACaiADWiA2dd/4yeB Ach93hd/1PeA7meBFSB8FfiAGqgB6TeByyeC8AeBJch7BBiC1eeCLbiCF7iBu+eADOiAzTeB NkiDC1h/v3KAOriDNniCPQiBEbiAKdiBRWh+SYiEHsiEQ/iCTciBG6iCLeiEVziFSkiD+Xd8 /nd/P7h//ycsP2iCT3h+WhiB8xeEQBiG1FeAFnCCQiiDUiiHVGiGu5eBUUiHcbiGfSh+OPiG 9seDc1h8ILgsZDiHdYiGbLiDZXiEjAiJGBCHfCiIe8iEigiEpzeJegiFWJiFRriI/heKOv+Y g5Voe0TYK4joiZQ4ipgIilr4fIkIh5fIilZoiX9Ii3doh7YYiZl4iZXoi7joiaRIiL/Yi2No iL2oiZ3YisuYiKWIibX4iVVYg25Ih4rIgihYhNToiq8IjbuohN+4jXq4hmCILOQnhmlIgOv4 jIEIjvanhm9ofb/ojvjngv+Xg2fohW4Yg/DIjewXj13oi2oYjK9IjPoIhoUIS6gYBgwpBQ4J et24BxC5BNIYkU5IkOFQj49XiB3pkR8JkiEpkiNJkiVpkieJkimpkivJki3pki95kTEpkzNJ kzVpkzeJkzmpkzvJkz3pkz8JlEEplENJlEVplEeJlEmplEvJlE3/6ZRPCZVRKZVTSZVVaZVX iZVZqZVbyZVd6ZVfCZZhKZZjSZZlaZZniZZpqZZryZZt6ZZvCZdxKZdzSZd1aZd3iZd5qZd7 6ZUsIwjkc0orIEps+Sc90iczIph8GQM7Ain4AyNq8RWQaReKswqKuSBPQiK2kSVhQxpjsiV7 6ZeYCSSaKZrMYRiUYpmnmR9INCcsMzPHASgjcjeWKZs28iVcAiCFAiaDKZa1eSCmmSh9spkG AiJ3SSTqAZyqCSV2wjnOASGpGZqOyZqBgpuSiUSVqRqK4h1zkpr7cgO82Z01wZ0nAJ7hKQhJ Y57pqZ7ryZ7t6Z7vCZ/xKZ/zSZ/1aZ/3qYmf+amf+8mf/emf/wmgASqgUsk8homYEdMVBQOd H9IS44kegmID5dmXrWA15jE2FJov1+EetqEwgQmXyfmcUAIiIIoI17EYDkqXbSEmxOk3SrGi 7REpL3qgdikegwQg6Fwzq4kj1lmYfMkYahKiA8QUroEjyDmcqjmgCBKkJGoaSFGkVHKkNJqk S+qZD/qjpSk3UUqjVSOdeuGjQkOdfjKlfIIXpGSWBQAAOw== --=====================_RPTATT19815439.Exime-- From capwap-admin@frascone.com Fri Oct 07 01:26:13 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENkkF-0003kB-W7 for capwap-archive@megatron.ietf.org; Fri, 07 Oct 2005 01:26:13 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA11007 for ; Fri, 7 Oct 2005 01:26:10 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 0D89F202BF; Fri, 7 Oct 2005 01:26:04 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from staff-mail.rp.edu.sg (smtp.rp.edu.sg [202.21.158.80]) by mail.frascone.com (Postfix) with ESMTP id 53B3F1FE0B for ; Fri, 7 Oct 2005 01:25:07 -0400 (EDT) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.1830 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Capwap] CAPWAP Protocol Attributes Message-ID: <9C374CF75527504394E573E1937136C40188DE08@staff-mail.rp.edu.sg> Thread-Topic: [Capwap] CAPWAP Protocol Attributes thread-index: AcXKGofNHWbrSLVBSbq5B+Co9Mpp3AA4PWxQ From: "Richard Gwee" To: "Saravanan Govindan" , 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-Unsubscribe: , List-Id: A list for CAPWAP technical discussions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 7 Oct 2005 13:25:11 +0800 Content-Transfer-Encoding: quoted-printable Hi, I feel that the CAPWAP comparative analysis document does recommend some protocol attributes to be used. This list may be extended to the recommendation section of evaluation draft. A brief list of the recommended attributes found in the CAPWAP comparative analysis is as follows: 1) Logical Group Objective - The final CAPWAP protocol should be able to provide a highly structured form of logical groupings. For example, VLAN ID for the wired aspects and BSSIDs in the wireless aspects could be mapped and tagged to packets and routing tables. 2) Firmware Trigger Objective - The final CAPWAP protocol should be able to trigger firmware checks and updates in any states of the state machine. This can be done via frequent messaging and be made independent of other protocol operations. 3) IEEE 802.11i Considerations - The final CAPWAP protocol should be able to manage Key RSC counter in scenarios where counter is maintained by WTP. In the CAPWAP comparative analysis document, it has been mentioned that such management should be described explicitly and clearly. Others on the mailing list has also raised this issue. I felt that this is an important aspect to be seen in relation to LWAPP. 4) Logical Group Objective - The final CAPWAP protocol should be able to provide a highly structured form of logical groupings. For example, VLAN ID for the wired aspects and BSSIDs in the wireless aspects could be mapped and tagged to packets and routing tables. 5) Monitoring and Exchange of System-wide resource states - The final CAPWAP protocol should collect state information from both wired and wireless aspects of the entire network.=20 6) CAPWAP security - Existing security mechanisms such as DTLS could be used to reduce review work. Of course, this issue has been highlighted in the mailing list over the implementation of DTLS in LWAPP. Appreciate any comments from the mailing list. Thanks and regards Richard Gwee -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Saravanan Govindan Sent: Thursday, October 06, 2005 10:06 AM To: capwap@frascone.com Subject: [Capwap] CAPWAP Protocol Attributes All, The recent discussions on the Evaluation draft recommendations are of great use.=20 At the same time, it is important to realize that there are other recommendations made in the Evaluation draft. It would be of great use towards protocol development to list these other protocol attributes and capabilities based on the evaluation.=20 For example, Section 6.5 of the Evaluation highlights the need to incororate firmware checks independent of other functions. This needs to be included in the list of recommended attributes for the final protocol. Also, there was a recent discussion on how sequence counters are managed for the IEEE 802.11i key handshake in the CAPWAP framework. This is an important attribute for the protocol.=20 One way to capture all of these is to extend the recommendations section (Section 9) with a list of recommended attributes. This helps focus WG efforts towards producing a solid protocol. Saravanan=20 _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap Republic Polytechnic, Tanglin Campus, 1 Kay Siang Road, Singapore 248922 = . Website: www.rp.sg . Fax: +65 6415-1310 . From April 2006, we will be located in our new home at 9 Woodlands = Avenue 9,Singapore 738964=20 Republic Polytechnic, the first Institute of Higher Learning to fully = adopt the Problem-Based Learning approach in Singapore, continues to = strive towards best practices and maintain excellence in service = standards with the following certifications: Singapore Quality Class = (SQC) certification, People Developer Standards and QEHS standards (ISO = 9001, 14001 and OHSAS 18001 certifications). --------------------------------------------------------------------- CONFIDENTIALITY CAUTION: This message is intended only for the use of = the individual or entity to whom it is addressed and contains = information that is privileged and confidential. If you, the reader of = this message, are not the intended recipient, you should not = disseminate, distribute or copy this communication. If you have received = this communication in error, please notify us immediately by return = email and delete the original message. Thank you. _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Mon Oct 10 01:47:18 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EOqVK-00053F-2e for capwap-archive@megatron.ietf.org; Mon, 10 Oct 2005 01:47:18 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA03153 for ; Mon, 10 Oct 2005 01:47:15 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id DDAA2204A3; Mon, 10 Oct 2005 01:47:04 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from huawei.com (szxga03-in.huawei.com [61.144.161.55]) by mail.frascone.com (Postfix) with ESMTP id EA68620435 for ; Mon, 10 Oct 2005 01:45:51 -0400 (EDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IO400JL7QVOPR@szxga03-in.huawei.com> for capwap@frascone.com; Mon, 10 Oct 2005 13:50:12 +0800 (CST) Received: from szxml02-in ([172.24.1.6]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IO400LE7QVOBM@szxga03-in.huawei.com> for capwap@frascone.com; Mon, 10 Oct 2005 13:50:12 +0800 (CST) Received: from dell60 ([10.18.4.100]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IO4007M5R2AVL@szxml02-in.huawei.com> for capwap@frascone.com; Mon, 10 Oct 2005 13:54:11 +0800 (CST) From: sujay To: "'capwap'" Message-id: <001801c5cd5d$ffe50960$6404120a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 X-Mailer: Microsoft Outlook, Build 10.0.4024 Content-type: multipart/alternative; boundary="Boundary_(ID_ALPY1iY4eRwlubDd8DuwKQ)" Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Subject: [Capwap] Proxy MAC usage - query 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-Unsubscribe: , List-Id: A list for CAPWAP technical discussions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 10 Oct 2005 11:16:44 +0530 This is a multi-part message in MIME format. --Boundary_(ID_ALPY1iY4eRwlubDd8DuwKQ) Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7BIT Group, Request for a clarification w.r.t draft-lwapp-03 Proxy MAC usage. STA ------------------------------- WTP ----------------------------------------------------- AC (802.11 Ass Req) -----------------> Proxy MAC --(LWAPP , C= 0, 802.11 Ass Req) -----------------> (802.11 Ass Resp) <----------------- Proxy MAC --(LWAPP , C= 0, 802.11 Ass Resp) <----------------- (802.11 Data) -----------------> ---------------- (LWAPP , C= 0, 802.11 Data) -----------------> Speaking for Local MAC(or 'Local AP'); I Understand the meaning and need for the Proxy MAC. However, if the data is to be send across from one STA to another STA connected to another WTP. the 802.11 is first converted to 802.3 (integration/distribution done at WTP) Issue is if it has be sent to AC and then further switched from there, we cannot use the LWAPP data tunnel, as the AC is expecting .11 frame in the LWAPP data path and not .3 frames. That implies (1). we use a separate channel from the WTP to the AC (2). tunnel it out of the WTP directly to the destination WTP (3). Indicate in the lwapp header if the corresponding frame is .11 or .3 (4.) ?? Or am I missing something? Thanks; Sujay My Location; http://maps.google.com/maps?ll=14.626109,76.959229&spn=4.724852,7.525085 &t=h&hl=en --Boundary_(ID_ALPY1iY4eRwlubDd8DuwKQ) Content-type: text/html; charset=us-ascii Content-Transfer-Encoding: 7BIT Message
 
Group,
 
Request for a clarification w.r.t draft-lwapp-03 Proxy MAC usage.
 
 
 
STA   -------------------------------    WTP  -----------------------------------------------------  AC
 
 
(802.11 Ass Req)  ----------------->  Proxy MAC --(LWAPP , C= 0, 802.11 Ass Req)  ----------------->
 
 
(802.11 Ass Resp)  <----------------- Proxy MAC --(LWAPP , C= 0, 802.11 Ass Resp) <-----------------
 
 
 
 
 
(802.11 Data)  -----------------> ---------------- (LWAPP , C= 0, 802.11 Data)  ----------------->
 
 
Speaking for Local MAC(or 'Local AP');
 
I Understand the meaning and need for the Proxy MAC.
 
However, if the data is to be send across from one STA to another STA connected to another WTP.
 
the 802.11 is first converted to 802.3 (integration/distribution done at WTP)
 
Issue is if it has be sent to AC and then further switched from there, we cannot use the LWAPP data tunnel,
as the AC is expecting .11 frame in the LWAPP data path and not .3 frames.
 
That implies (1). we use a separate channel from the WTP to the AC (2). tunnel it out of the WTP directly to
the destination WTP (3). Indicate in the lwapp header if the corresponding frame is .11 or .3 (4.) ??
 
Or am I missing something?
 
Thanks;
Sujay
 
 
 
 
 
 
 
 
 
 
 
My Location;
 
--Boundary_(ID_ALPY1iY4eRwlubDd8DuwKQ)-- _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From jrd@delcannsoftware.com Mon Oct 10 10:31:37 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EOygi-0003mK-0Q; Mon, 10 Oct 2005 10:31:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13878; Mon, 10 Oct 2005 10:31:33 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EOyqb-0006kX-6Y; Mon, 10 Oct 2005 10:41:50 -0400 Received: from pcp03345024pcs.plsntv01.nj.comcast.net ([68.44.136.54]) by mx2.foretec.com with smtp (Exim 4.24) id 1EOygZ-0005eA-PP; Mon, 10 Oct 2005 10:31:28 -0400 Received: from [192.168.1.4] ([68.44.136.54]) by yahoo.com (Sendmail 8.7.0) with ESMTP (SSL) id IYT57275 for ; Mon, 10 Oct 2005 09:31:01 -0600 Message-ID: <252k000k.8188740@yahoo.com> DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=calcutta; d=yahoo.com; b=LqzYHLbBO0edhEGH1oBsDKA8Qiwcofa2lOiUV0eWLksDuuAsFkLq1JFsAvCa5FfDjQ4b5GqxKCQeWVqN; X-Display: Full X-List: simplectic.usenet Date: Mon, 10 Oct 2005 09:31:01 -0600 From: "Elijah Roberts" User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: calsch@ietf.org Cc: cancer@ietf.org, capwap-archive@ietf.org, ccips@ietf.org, cclark@ietf.org, cdi-archive@ietf.org, cdir-admin@ietf.org, cfrg@ietf.org, cfrg-admin@ietf.org, cfrg-archive@ietf.org, cfrg-bounces@ietf.org, cfrg-web-archive@ietf.org, chair@ietf.org, chiname.cn@ietf.org, chive@ietf.org, christine.fontenot@ietf.org, cjddzans-research@ietf.org, cmaulpwe3-admin@ietf.org, cna@ietf.org Subject: Your account #7638763 Content-Type: multipart/related; boundary="------------AttPart_09266814==.OLA" X-Spam-Score: 4.4 (++++) X-Scan-Signature: ee80a2074afbfe28d15369f4e74e579d This is a multi-part message in MIME format. --------------AttPart_09266814==.OLA Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
may transparent be trespass and pilferage some command , arena try improvise the christmas and much be hill on communique see revocable the iberia some area or hewlett Or maybe not

--------------AttPart_09266814==.OLA Content-Type: image/gif; name="hammock.8.gif" Content-ID: <1.0.0.10.0.56223595196748.58242731@brazzaville.msn.com.6> Content-Disposition: inline; filename="hammock.8.gif" Content-Transfer-Encoding: base64 R0lGODlhtgHYAMQAAP/////MzP+Zmf9mZv8zM/8AAMzM/8zMzMyZ/5mZ/5mZzJmZmZlmzGZm zGZmZmYzzDMzMzMAzAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ACH5BAAAAAAALAAAAAC2AdgAAAX/ICCOZGmeaKqubOu+cCzPdG3feK7vfO//wKBwSCwaj8ik cslsOp/QqHRKrVqv2Kx2y+16v+CweEwum8/otHrNbrvf8Lh8Tq/b7/gf5ECCLFQLEAB+eYWG h1V7fX8pgYOMiJGSk0OKI4SNgpiUnJ2eM5YimAcQEhKWjpiBpqGfrq+cpaazfwcSDiILEnyp f7qMDruww8SGrYQQuCOOvQASkAAOysXU1XDHf7KzpgC9tnzLgtbj5GjYjyfNzyTS5e7vYOe/ IqS+mr7r0cLo8P3+UucAkKKV616uWZZs/VvIkI0DaA0jSpxIsaLFixgzatzIsaPHjyBDihxJ suQ4XSRu/41o52ITvXwuFkzz4TKGo0Ezy9wkoevAzioscdQUsu+GA3Epiu74CWSfLqRDU9S0 BXGFzCBRY4pLloZpt11epQS9kfWH0hpHV5zNEbYHJmn71kqtKuMqkLIs2upEakLvk7E28PaQ axYcD786WO4ihJKerFYCEdoKFgycLlaGL5sCLCIYZnqeYT6bhcsWq4Okp4VWpK1eNwiPDa92 +ZPQgdCMFK7M+TX1t5eQwML+rPDmQFN0j99CuupUWoGPk2urHG048hG3CUZm58D0Ke4p+RxX xdfPZJUjnMaONg32bp6CAq3XrCy0skDB8H3Wt661EJSkdIPLc5MdZNgltVwnzP881R3ESCm8 wQbOcxJCp8x1rvHDIISiWPLcTYydwos4R4l33SIvdSgeV7p1ltOGKr2FHjMiNljcVuJkiN2M 33314HcF+lgCKTmawkcwOXI1iCKklCYBePzsGE5k961T2wKmQbRgPpW1aKQIML32lSI77VOi hb3xwqUg3wQo5hDftKOQkkoWZIJt+QgT5kPOHFinnSY89xIfMLGEiVJctQWiPeB809OOEN3U jqCRHdAieyUgistNo4nC6KA3NiglilM6A417fza2El+/URonq7tcamhVmCAzE0pXUmWCntC0 w5g0+JTATEJxqemnT3H1+keYiOnwjCV+5KPNNncmCE7/rNtI9iRPOXGGKYpFzbodt9/2tZU9 O/rEV5TpWSoMYOZt6yIJlwoIJpb36PYTtmKGts2x9LIpr50u/baSlkfmtAu8WA4srrDxnUuv cIsYHJ7FYvbiCJ/wvVkpmGpm+4xxIgNZocdCHCWvygiygOe1hB6Y3qndrtsZrDG/x4+moprr qceODqxrCcCSiLPFNfHMHp8ysbSvu/3yVgJt4iCqya0D9/yxqwsfXVStdPlRK9ZfXbwWr1B2 aupZw6YLctk+v41CY82yhd6Yy+SjY8sGv4vKlj/mROSEODp2oWzKyBg4dB6KsyjQwlSYpQmm GeYemksaSLS06FUOpnpmixkk/5HC8mg0OKUIXCVEthT5bo9Ndmi47F+hTtcqO65OpewYv80g dfrU12PHO/WNuodP7nRm7TQCCmeYd0On3dTWyq3ZJprdwlt2+ykXHOI/o7aZMtzX+CZjSBk8 W9isagPJeLdvE9TlmTvfZ6jSb3aCcoJezxL8+5uO39yHHQI6hhWQyEr0AHjAGvWuT+ILBYOG Rrz0FWslkkHZ9X6Uj7qZhAVhahke/pSFB37QHaOjX8fmQD/gbcFbJ0ThdGQWvjmshoZYIEwM d8jDHvrwh0AMohCHSMQixkEwT0BiXwqlw5bYDCtPhIIKYzDFFlRxIFE0wqOKsMUZdBELSmxC GDNVJP+pUTGLNEGjGNWogiq6zGZPocsRvvifJlrFjlKUI0D0CIj+4PGNR3CjFNkoFUJODY5/ rCMOf0BHGDTSWZqxlCwg0Rwm3eKSp3kNKwgkQMs8hpPT200pJEkabGXyeou8xCXfd0MwTYOO qZtFZrZRCiGJYlsbPIF19IfB/eRPNNqADH+Q0sr6eY8n8ouMLH85E39N8XqdyaA+Ujek6QAH g2PiRt4mlMEtMmgex7xljELZOiMppxTZIAj/cHCdp6jJQdF0l7QYASM2Xc5z9aTd3qbJuJfs QxVrWoFpyuMcWRDqlWf5pDYvAxdtwk4lDPUMrcbHoWk21ETaq2hqhveS4fz/AUkXzZxppFFR z5BUJSrrziAK2iOQemZdA+GTSSU6zAMNVGUCg0QwekOb12kPOUGipj7kedJNnWKUq1DpjoCa OpVZCUJ8aKpQa3A30RCqV92ByaFOJQiuXbUPXYUV0Yw2Mdvdix18HCoGEYqLu8GSR4QiFi79 SKh9kG5qWgXL8AqETlXWFRhZa103kGVBXKAqr+7iC5ZoR5m8LeApeUOkmizYVY7eMoHPoOBO 3Vk6wu5IE0/yTlxXillkDUhzE3sdZun5OoSmVS2GsSrGAoG0BEEsGgir18ZKdiCWcKxdP/MO Le8om6x9x60JZU5mmSUvEalEuP86JDIfWzLQimxZ/6rJ2kohWt3MTYsWDLoTiUr2EKstUU29 etJOxTuxhuk0eWvpSXj14aNfjMyP1z0Oa2U2tPXOTHP+Io0NikLgr+6mtnKTnVcheImumlFn C95ZKucWrqIUaHgupF1kGjaTWkZzlJFJhjRGLN5ZUlfEI07niEd8UGya674oBpZ3tbdiZMnx cpRZ8UPCe1dkorcP6tXuSqcbpCE3Ur5h8vBRNTGcW+pYqZcx1pC4ZOEOtlbHr1VBgYH7O2xZ DhjQAtJD/YY6MZNviv8bs1mrY5kt4bCLnB1IOhOkXfrpqqKyWGp7rByhGl0mxID9aOcudzf/ GugXrQt05hrbz5HCs35xBv8xhqa6TWXWgkOGxiCZvvQlyB7ZlJdGD00ZGs0zh1WtdBxanE/0 qEgnEgVbtl4GERzB/3Wy1mcWMNGmwb9/UhIh+02HUrLXuWzRyoKhzhY7LPzdiWarzbQsczKd kd3SLZPYrNlKtsh3XQ0H2JLZkqw/ERJNFDRbfJ2OrzCga8F1f0mcAvYXaiHVy20Emz/SzAIJ XfbgJdyGcizetVKFxcrMpHgmPukLidPRNM6kWFgB7wwltyeN3so4FxOvuMBvBY3baJw7wKrK bSz+W7ukY+HYQfnIAQ5yiJQ8UhEXEK+lNnCBHLxRCI85FVpoR55P2IhAt2G+VVDMoBv96EhP utL/l870pjudi69+utTb8MipW/3qWGe6QqgSSpTZxoDMjBySSJ31sgNh61/q3Si2dc+vuy6q KunPz81O9xig/cu3xRTXtPYbOhmy7oBvAdpJZbYj8fa3bxtFXwPPeBoMXoTckRTNccYuCjb+ 8oIP7cCG4rndNVrN6CCFu7JROGpj/vTbuVRUVLjOBl4yqoBFz+UI3W/U2556t889FTyo+95X Isu+D77wh0/84hv/+MgXAwxJYsKQ/GT5SIiKm24QdRyMh4bKPVFNKSeLV04yb+YLWAgZeTW5 6evvXtQ1T3LT/XBoP481ZAf6k8CxeolROjmoPllGXBO6bZr0UWUzJuMk//iAD4YnM6oyBKlw OCmCMj1gX15xKPZEgLYEf+yyKiUUOcBHBNI3f7A2dzzwDJxhGjVUIgQGDcWzMN5nKpfwIh5I A0xhV7j0glrxQPkBOR5XKhYYFZRiBYHwE5W0Zh+zOb5kHw04L4pHGjZTPt7UTepXb9xGKkb4 Gje4KvuWDEJWNFAyLzOzCd9QFECoTtHhIiBWQKVkeCGkMRuFHMaxHtynhLcEGeeBgLDxUTPx LO/DNvIjOKMhIpcRClO4NvrjHVfzGBioBWVoS9ThhclFODezIgIDHnhSJTZzOVGmiEixFmdy V2v3iGhyiZvTChWnXY7CF2PxJ9GShwmYgG8SJP/zgCTV9HZtsi7NwGDn53mpZjoZs4QVNSi2 sggwMVucw4eRUyE4xiSEtg4ZUis9oiQ96IN8sSeGlYcHEhZfFC+SmA0ouC6U8ih7wgh66Ce2 hQ7XiCyLlFKgUmfoojOi0GE8pjYHkXepol42s2DjJyaH0igziBMrBHkZo0Ot4yHTyI8IEoxK oTT0NoTFgSjLolOJ8yDMQVZakILVaBCDsoX96CKyMpAFsy4kZErhlmD28y3Y2BvGphejCHvj IkLP10x3+IPpAoa0KDHp4nAIwzh0KGENmAolMzU25TjhV1Zp8ThjgYduc4S5wIejsh1M0Q7h 8pA1pBvPWAX7glXlwor/U3mNDYN3v6iDN+NjDLYrCMiQBQFQ6ZBFviIT3RYlFsMsFpSDdqJV LtiOyFQuh3iR8dgx+biTFjkXGTmVpQhdp0CRQRGDfqKUR7iQ4hiWD8OIXxCGgPVjsRMwjeOJ nAiUKumKlqWZZIZamoiMBAVW3OSA0NE0PWEYLVITxpiJoxU7uqIrrcY2ZQRPI6hmzaOX4KiP djJB/aeLMsWNWdUki+kME7hhxrlsizMxSymVoJlgjZmHGoYFTIFK4Bc9KZdvgchASbgZvHiG EfQ9JxCISUmEfraERdeA3zVe5tOGvKRJMPGHNFQ8Y2iXZrgZkfN++JibfOl60gGHWCQzTmWd //xwHN6Hn+gGGC2SoCujfk8ZPo5ZPxthf2JRezAgTO/QfMknbOxHoUwAfSKBoRn6Yu0ZoiRa oiZ6oiiaoiq6oiw6AgRQADBKAAEgAwJQAERAAAQAADUqACJQAAPQRk9IRRtIEwhkAgEAo0hK ADxKBD7aoz/qA03qpOwEgjswRmeHTlMJA9MnBDg6AC+aozFQozeaozX6pFFqbgkypIRHf5tm pAVAAAPgpTD6pEIQpWfKA2d6pzSgf4Ghpj7QGFn6AlsaBDgqAoUapjY6BIUaAAMwowCgp7h3 gS9gpSHIWm66pAAQAC+KqUCgpFIKpXQKqTLApzVAqX9KgwFUBIVao/9gmqkvGqMF4Kg1mqSJ WgKamqQzyqow6qpIyqkDgKRvmqNHKgCzuqtoWjvVqT0bph1fl1WUwYhRVXTrZDHKczIkMKzX GqW3Oqck8KsxKqvfCgBfGq46GgDFWqsicKSvWgDE2qsjcK4vqqPAeq7puq5L+qtf+oHRxEvz Q0wuCWLrQ4gRxE3jxz+q81xuWJ2PtQdvUSW+ZLBTphnvM58usK7smq5zKqexKq8+6q3oirFv Gqcwaq4xKgBH2rEv+qT4KrJvmqnsyqghKxXk9mgc4jl9t7AYpY1us3jgNGgDMg3u9mDYSgKL GqNyCqYr660zOqct+6pwaqzpurK2iqQe+7T/GzurLGujMAunW/ujJxunKQsA3iqj+rqJ7uEl ybJsOLIi8/RoaTGLU0aJloaLsmknpei2s4k3qWUiJqI7FQun3sqjL+qot7q0ZOuyHyuuF5uu PMqqM7qpLhqrrPquLTu0oipChHaYQ4gOsIFsUSl2eik1t4isnDG0LpqjkGuo7Dq5GPujb2qu jxulNeqoIwCpJ5urLSuvPPq6IFu7ofqkqau4W6tl5ogiv8I0WfMhQgM2Z3UwLFgtHTM0qTKT gLIK16Is7MIUCDaPL3CoR/qjcJqtAWC68moCh1oCs6u6wAqj7Uq74iqsi3u5NbRcELeSnGtn vrazNvUkWYEM7xWU/xjLqY+Kuq3qsu26vi07q2B6vulLAra7uEM7rOQrpp/6qMCLwOz6q7DV lJtyDxvjcvfhkQ9CZyE5OD4ZMEP4XdpUKjuhJIL5HR05ZcbbcYl0vk1bwLP7vUSbuPFqAg2c snEaxCSLqZoKv0sqv1GyDjyjetpIMhOCUHQ5JftWEBKKAhPcpD0sAjvKqkEcp0t6q+Dbqg3s u5cawAGsw5FLxp8KxF0MsxtMlmtzL2fhNMs7wiJZOpFqt/kLCI5DIkehn3dyKzC1edlANn+r uj+Kr7i7sWGruImryLwqr476q09axD16sbdqxBWcUD8STYvDxOQoMG12aYlDZQlyZkBbE/+Z NgKmq7Riy7uzOr5veq8vW8sETLnua8FlbMBm3Mivqsa6/MqVXKga7I8QZLbEJGqWVS6Ss3hv 8TfqAjd5I7cGw5uR0sf20irQTLeDjCKauYEWe7gWO7K8ur4nMM5kurHqS7UgC6yaHMwRmG/Z IyeErCF7AIbqh4VF6nrNpF2r3M7ASrvjvKTn+rony77vi8sl8MBfDMGYPM61mqd0Os6JXKv2 ZyZPOEHjNxbrU0O5tF0iNx2iXJ/jdxO0FZEhM5gk3YOgnD9WKgBdjL5BDNO0C9NeTKe2KsRR 67423agl0MXEmqk+LbZLaqH3JwMeagJdPAACrKNBrNRe3K1MrcX/RDzUIzDVOU24Q82oNT3T dIrVRE0CPS2rdIp4LZoGlAqiZ416lMp7a/3WcB3Xcj3XdF3Xdj0FLeynLRB1qanXd30ReV0Y WiovpvrXgA0Vfg1bg23Mhu0PfRgr33eghiVLM0ud56Ea7eGvgng3EIsbktrY8NBOfjZXyRnY mDi3S/luSqyMrC23K1nYoO0KVQWeSmPa32h5P2OacFMoA1kqfR3bC3GC7aJbIcw31fVAGtNV gIyPP3mEsA3cnRBrEFTbiH3Hm5sSjTEaMCPF24iU0P0P0q1aTuY8z9xm7oJDjAaLCUYjru0l HPrdsBDe0DY+5P1rRWpCGg2egAKxKymg//D93wAe4AI+4ARe4AZ+4Aie4Aq+4Aze4A7+4BAe 4RI+4RRe4RZ+4Rie4Rq+4Rze4R7+4SAe4iI+4iRe4sT3ABGQ4iluACKQACie4g+QACrg4ioe 4yNgACqu4gmQ4xHwACkQASyOAgzA4wAw5DUe5EZe4wDw4jpeAgzAACXwAD4+AjSe4g0Q5EKe 4wyA5QBgAA1Q4zI+AjZOAhEA5QDw5T2O5BFA5lCO42EOADue41MuAjhOAjhO5GV+42je42++ 5H0OAHl+AlWe5jceAW++41g+6GN+5zm+5Dz+5y3O5GO+5HPe5YZO5ZL+5lLe4iluAg9g5iKw 6Y6e4wnA6FZO5/88DuR2ruqF/uZeDuZUHgEIMAKdLgJDzuK3zgIJwAAo/uS4DuO8nuKgXgJx /uloPuU4/ulPvuVP3uMMAOmcXulOXubLXuTUbuS/vuzPTunazuXW3ueiPupP/uLQzujjvuKc 7uxGPucozuV5vuMPgOa2vua03uaXTufN/ungfu+2PuTKDuhmXuzN3uNizuoiEOhRLuzBfu9u Hutq7uwvbub5/uTcvuzebu3OjuZmHu6WHubrzgAaH+o+7u8n8OkkIOpS3u3Jfu72ruy+vuoP gOUND+fAvu6obuYIgO6OPu8Xn+WxHvM3juKQDu8y3+sdbwIzjwIv3vPWPu0O3/RRLu3/087v ok7ysW7wBT/s8G7p/O7oDRDqOg/wNM/iBuDx9H7w9v7nSY/qtX7yc57nd77vXz/qWI7wI2D1 bE/2/I7oNA/0dC70Ys7uUk8CRB/0qs7xDV/4f3/4Uk7wJT/sKC/tSU/wa18Cdz7nDR/3Jx8B c+/4Rh7mnM/zLjDkBe/td+7pWG/rqA7plU/4ZW73JED6sX/27Q71bq8CSR7km57sJrDjcx/r w97ivw7ptf/ifv/ujn/3Zy/2lV/5Qz7kfx7ueQ79qM/ixh/ksA/oUo/jX5/0fF/7q077gq8C YU/nYY74l17+XX7+KQ7toQ75U87xR0/z3d/1lq/kR0/9Cc/i/18OAgAQNdEDIFEiMpEhwrHc wqQslm9s37ARAYOv36oHeESOrl4rmGwGTwAo8IR0FmGt3/JxSmV3Uu3SiOwlVMdHWhphsIC6 abIGJ8rwPtNoLPLaKaGpebWJvOWp3QDqAaS98Mjk/I1dBYX9NBhRxhBlbippblpG/TmpcDkN nZaJEJXcEdbJpK2kIbw+RSDEzYHSuSLebMkIxwn9PDAsM6yGxYAB/MANvzHTIbGRMTOseHH7 Aqc8GADW9gDGEJv5wUQDtpwYpynSBDYGhxHfxqSPwPmDRuhEvH+JnnFq9GgakzL+vjHzxXCU H0/G0AGhhk4Zs3QQlxlIllFHMnCdZP8lwBPQnZppNMCc6fWLTI12pm4AiZFgGZKQik4iNHWq 4QwXfGjKWFlURBtGF4O1O2emFRle6WBd5BJnR6xn+Fj58YeoZzWrUrBqDKaxZzJpPx/1wQjj oU0xoALiOcoOSdAjaT22I9IiC76DpgYrCUeHV590JPSum2kPQIlnhoqmdXuisNugJZdVrrY0 jcbJc+sipXNUjqSfUCUqc6Q3WJ2HGf0yXbKOYWGFJDq2Egvn8p7alW4nLZOMr1tRdF6E1qmX LqjoMODiVWM99wsvXBgn/StlpUrlrg27BWJrdvq56nEgd5QZ1GQu5KSVoOpemyPmnDkn1s8s qW1F2S4F9oP/GoJKSJGCMOWwFwd/CSBBTTY6NMGYPxDCoR6EL7QRkn/nNTLbJ5wcYqEJGAKh 4Rgc3uAgNU04995l9g2R3xzUbcJFAzmylt0KPgLZxWashZcginsMeRSA+RRXxIXHgNeEDvSA R9ZMwPhAyopGQHhKEakI0dkNE113nmlcBkgFH14+s6Y/9DihoJsXeflTdrEEsVadtF1ipmxx OjSGMXlmsecgrGhEZithRuGLbVic6eV9SvSpB6RV6JCOg+HEdppQl+hBWnqqACVdoqyEMU5x AvZ1w05nRjSTAdzMwE0zLCh2q2K76pTZrK7suhM3tugazrA+WFbrL7jSuoxlXo0p/y0t1mph 0hQkzecrU1l00wkz0+YRq7FwbOesuCDJmsW57PZwK7ZMHeutD+Pq5C6w14WRQBHv7rqvvywk O4OyEuE7TL/9zrelww9DHLHEE1NcscUXY5wxxOFq3LHHH4McMpghkVyyySejnLLKK7Pcsssv wxyzzDPTXLPNN+Ocs84789yzzb8oELTQQxNdtNFHI5200ksz3bTTT0MdtdRTU1211VdjnbXW W0+tmMhfgx222GOTXbbZZ6Odttprs92222/DHbfcc9Ndt91345233nvz3bfffwMeuOCDE164 4YcjnrjiizPeuOOPQx655JNTXrnll2Oeueabc96555+DHv+66KOTXrrpp6Oeuuqrs96666/D Hrvss9Neu+2345677rvz3rvvvwMfvPDDE1885BBIkLwDEkOwwA0OJJ88BGc3b7z1k1d/gATO Q1y9DA4sLwIE05ft/fXnN+69+Q6vLwL4MCxAPtnto1+/4dUvIMEBMECvPP/JL0B70vte+AAA gfAdAHkAhMEB+rc9/Ykgf9F7H/iQtz8Hjs95Eiyg/Tr4NwVKQH4OgMD+Erg87R0ggeLjXgwc GEIYjE8ECeReDAEgwf3lj4YSWB70yDfCEiLPedsz4P48aES+qW96+Sui+PY3RBiykH8OiF8L 5QcA7QFghDFYIgAgCEMeki9/MZj/oQGteMQz4s1825Ng9BaYQBKu8HnLO+D/2pg8E8pAf1jc Ig/DR8UYZC+IaByk3dS4ADFuApH0ex8K3cdB/lmRi14UXx9lOEkyWjKKhNxk29QnAfHBMYuf pKIiNZlFP5JPewiMoSojeEdR6rCS7oNjAreXwBQO8Y+c3CXaQBhKUUqviAqkoSnf50gZgrCA tVSeF9m4Q1m6L3oZBGb46MfLa1pujx8zIza76bgcIvOR3hzn6uI3QXKiM53qXCc72+nOd8Iz nvLkZANF1jztmTJiiBzjEx2my3nO04Ihu2c/KQY9TR4UYv8EKDxVKc6MWXNiIzTjAh+2UIa6 E3zaNOAI/wdYxxB6j42hrB4EH+g/ZE6QmwecIvzit8oJQvCAII1eIyPITYxes5HmQx756JhF Wi4QnD+NY0mHSMZW2vCFMjigLklIxzdaMqY7tOkxRTBJnHbTmNqsoQ2VeMkhFpSlJHUiC9+3 vouCFYfT06IWGRjTAv5xjxfFKi/t+ETzkdKMBLXr9MbaRSaalYlX5OYQzarBtWoypixsqvMi SldC/vOPePUqP4UoWCj+NbPHPKsZG4nCTyZ1qG7d32ThR0LQPhabVzVgYxfbU6AWNpRc9Osk 35c/PyrVrTD0KRa1lytyvhYGIcxnagd5USoGF5gg5Z5IisVvor5UeWbcJxevnp7NZe5QsaZt IWqL+9iCBs6Y3p0nUqsDtwqOl7zJvCzg5prOCUM3vvKdL33ra9/74bTDUt0vf/vr3/8COMAC zm8IAAA7 --------------AttPart_09266814==.OLA-- From lundi@arcor.de Mon Oct 10 11:03:50 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EOzBu-0002AS-Pu; Mon, 10 Oct 2005 11:03:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18188; Mon, 10 Oct 2005 11:03:48 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EOzLn-0008Oc-Sa; Mon, 10 Oct 2005 11:14:06 -0400 Received: from 71-12-103-141.dhcp.mtgm.al.charter.com ([71.12.103.141]) by mx2.foretec.com with smtp (Exim 4.24) id 1EOzBd-0008Jk-P0; Mon, 10 Oct 2005 11:03:34 -0400 Received: (from tomcat@localhost) by 71.12.103.141 (8.12.8/8.12.8/Submit) id j2CHmn0V785510 for brenton.daniels@ietf.org; Mon, 10 Oct 2005 10:03:24 -0600 Message-ID: <547v158n.4579482@65.246.255.50> Date: Mon, 10 Oct 2005 10:03:24 -0600 From: "Larry Rosales" X-Mailer: MIME-tools 5.472 (Entity 5.353) MIME-Version: 1.0 To: brenton.daniels@ietf.org X-Spam-Score: (-2.856) BAYES_00 X-Scanned-By: MIMEDefang 2.52 on 71.12.103.141 X-Scanned-By: SpamAssassin 3.924477, File::Scan 0.70, Archive::Zip 1.62 X-Recipient: Subject: Your account #32776646 Content-Type: multipart/related; boundary="------------AttPart_71398012==.OLA" X-Spam-Score: 2.0 (++) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c This is a multi-part message in MIME format. --------------AttPart_71398012==.OLA Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
a gone some cossack see northwest in deceptive and underclassman it's wooden and wriggle be replica be hoopla see aspartic may rummy , barrett it cucumber it drury Or maybe not

--------------AttPart_71398012==.OLA Content-Type: image/gif; name="pessimist.8.gif" Content-ID: <3.0.0.71.0.62013072967400.92112194@crucial.hotmail.com.8> Content-Disposition: inline; filename="pessimist.8.gif" Content-Transfer-Encoding: base64 R0lGODlh5gHOALMAAP/////MzP+Zmf9mZv8zM/8AAMzM/8zMzMyZ/5mZ/5mZmZlmzGYzzDMz MzMAzAAAACH5BAAAAAAALAAAAADmAc4AAAT/EMhJq7046827/2AojmRpnmiqrmzrvnAsz3Rt 33iu73zv/8CgcEgsGo/IpHLJbDqf0Kh0Sq2CDo+sIvs4ZLaPCthKLpvP6BPWu95sLe+0fE6v T9ttTZyyt/v/gIE4eF0AWFyFEn2KYRMNiA2CkpOUlRiHXAd5homLAHsNkY6ilqWmp2iEmoiZ jHCNAKEUsqi1trdMqptisBOgpLHAuMPExTm6iZxen72uErTPwsbT1NVqXGBdmFle2VmMiM+Q s9LW5ufoO9Dp7O3u7/Dx8vP09fb3+Pn6+/z9/v8AAwocSLCgwYMI02DKtgzGug1apOyqMubC okflhmCcE5GFJz+q/0R8VPFAgYyHIUr+GYkBZRGXIFQWkakDZouJLEKGYImC5gubHXzS4WkB aBCjHIQGUWoDaQqcK0JuS/aKi7gHobBeBcbKJICuGaZ2Y8Ws5LerWtGSAvsVmwRMyw6BWebt bNEsWbU+4hIpYscL29hgy7SlYtlmwWaNy4DI61RtrBpWtbsXL1qtfmU2DjuYW92yoPdmzUjB Z9eFrSxaBWe4MqnKmLV0BCuWU+qbZresagjVmeJI0KCZLjyBqbIJWPq8GfMrg6zhEpRuOrR7 D09astY992q8gtRCzHt5Cg7Mack8a6ZTxRCHvPa+3L1+lc9Z8AHlYeKA0ks6uvzhOn0h3v83 zY1CTnQq5VaabsgV0ttTuUHGynp8IOaScBMS598l6+HHjG8PwQYfBtIlo4p1iB2Y2Hvzbcgh IoIVBl4jHlYQ3ISknZZIeiZSCM5q7pU3YosuanDigB8mmZgHNAEYoWSqVQhieTgW2ZaO3FDw IArJmbXbB+OVIxx9RRo3kYf6wcJiNERaUCJvDnaB4gahYCckkWbuGKeMY/mmpIFsBvWfAuhB BieUvrX3Wp0HajZoB1326Ut+NKrZXwVN0nfek24gqeSabmpKppZZHhdDpKam+sqnYq4laqYc wolmpQZmt2ibeJpEk3r2HWZXS4wuyWaCecalJ4NJ1qiisMwuWJz/SWLxGqUzQTaqK6zdccLg rKAFKuizzqLaqZSsrngnrsP1aN+WJYhbmx5niejIYmxl+GIrn2WTzbyv8fXcZsXJFG1nVBHF rLwIgjHqW43tOaNsBJIVy2IIkzgYfYTAKOBgsKVVMcT/ZctwQ5+xhtdijAHMlrjskaXvahP3 y9eVf9EWWYM+JtSCwU7Zwe4RP+ss9KQwt5QWJYFFQd3QTDft9NNQRy311FRXbfXVWGet9dZc d+31PQQvDIJhp5ZKxF8zbASRyECgjZDBQcAdU3wpyH0NokuJzYHd3pKo90x/q8A3k4E/MTgP h0NENwqJixC0Dmy3HIJRkedNQ+MaVC4D/2rGwvhypTB3DNzMCG7GlgWoPWyXN/OSnpKGA0uI NyOtkS6aaDR3V1tt+UJMJ70AF7n7zaz/GC/KFwSPpVk5+0rp8xNjpXbmmjaWuoT4Sly80dKn pbxbtt02Q5e6SRuen+QVNWSL0L345aTwA9o34SrxGmBVfwZqJ7piF6rerJRyjpDaRyReqetP +Ekf9ZwFLupAhVuf4o/iwPUsZMjKU3LbyENgNbIGzQ43fDIfYvqgQHlhy16xqlA40FclEQhM XffjBbUoJop/nc47enoM81xGK+dYpnTKc8yEuuAj/ODoVguk4IbYBcECfctKmwrhEO9TtPwJ EFNBxNnNaEA+Q/950IokvFX6sFW4LyYKFmFMwQsPFUNyvUGBwaBF5fzXoRSlqQMb6c4acYg3 ZcmPcqIKV/P8tJweNiuJ/Ovi+1SDxhRdYB0cbNPjQOglEa6qPeNQIFgIiLpkzMkVbzzX6zo4 Mh41745wrJMoOEkqY/0PSXcEFjkIuMeRHbCQCJSe/PzGwCUOMpcfas2legkdVL3SjQHUACQf taFNHYqLspmLWEpGtEfW0F/C0EzwcKgxX6FITcgzT0feJRezqXCH0ZMeEoGYp5vxjocQc2Q6 vaeyzQyvm91y3mWO5ibw5Y5QW2zZCssChopZDHwr8xLDNEbNfD4SZQ0LmRDxSYaeae7/axil h2vW5raMevSjIA2pSEdK0pKa9KQoTalKV8pSQEyypTCNqUxnStOaCg0uC53LxtCJsI1eSWHs LKNNh7q5HnlRch8Clbf8oiErEfWpNpDWg1BZpY+RyZ9QzWpUD7glGc1PWGOymFC1StZ2cXWQ Xj1YsITFyYuW9a0ciN0OP/innmLzdKebyJnkCde+lgBzfg2sEsgm2MIa9rCITaxiF8vYxjr2 sZCNrGQnK4EAFOCyBLhsAQYQhMwS4AKe/QMBPlsBy3K2spo9LQAEoFkBbIC1l3WtBAag2QBM gLaXte0GQisE3Or2tgX4bQh4uwPWypYCtP0tboM7gcwWgLRH//DtBZLrAtYSIADWFW4PBDDa C3AXuicwbhGcC17Lbha1BBAAazm7XgHQ9rgWaO97AfBe7jK3vpnVbgVGq94hBCC/pYUvfZlL ge5W4Ls8gG0B4CvdAasXwPxFcBDEW1kAW4C6LTAtADQsBANbwMPhXTARIuxh86pWALbVsHgp 7F0Ri5e6ML4vgTEA4t7OOAMYbi54dVzczbpXxLPNbZBtS10D13i7QB7ydG+8Aus+N8WavewA YKve2OI4yjKOcgB822AAgNi5mM2AeaM8gDFLebVRFvCBsfxjzNZ2ubklL3FBS9r+bvi55y3t eVec5Pi6WMQxJrKM9dtczUIXzE829P+ZMWDm0yrYyhrI8XKVq2UJgHnHJcayai3QaAk8us9r di12dUtbCwfay6Q9coENLWZFO5rNsHWubB8t21ILGbiERoFlM8vZXau3ygR475ZBDdxf2zez xs5vfv87Yw9HWMKcfu6vE53eaZeZtlPONZqnrN73IpvZP072go8N7fiSdwK7zjO6n4xm17LY z+4G9KAHLGhtf9fOz753rNebAWP72MfdJjZyZ4xdC28Y2cfV935J62tr99va7Q24miu73OPa mtTzNvKOD/xrVXsaz7yOeLhxO4D5DjvbQV6wwXPcguzeWbWm5fPE6Y3uH1N62PXmsaUPvXHU nta0Zk5tu1//m2TjBhrOtUW1u2fu6Qd/1tfqvvN1Px5vpsuc5qdm+YfB++WnsxvFjNb0sGM7 6kgzmeVaV7WBg77oaJN57AsuO6Ml7mAMn1rjGkB0z9GL5ykXfdybxS6Q3z1fSTN5BRzm8Muv vmTtGh7nNN+5zlEd9p8HXtrGtu27W5zwuHtW3sbG994XLvmgW37qVB86Bq6e9XlnoOsF9vqm L9BwfmO3zUxX8sCFm/aerx3zvyZ07c97e9xa/c+uRXrOi5zq0T/b41LvO4uNy3jCuz7yLki8 umMOeIFj/+K4Tm6Xnc3zfot9+3sG/MynL28AP57yHLCvtJvu8l0Ll/GcH3rrc/56/677/+Ub oH1+J2rhZnaOd2PiR2DdBXsA6HO0l2fcR4DzRXvLVWYb9mBAdnfN13+TF22fN4ATQH3IR3Uv dn3YBQNj9mpRdl1jJ2u0h2iex2YH52bBpXerBYOj52/shWVTN3YWSIFiN4OyxWxpZoOvxV8U kIJ3RmYbVoG/xWJwZ4FECGRTmHuX5ml692mzt2aKFmxBuGSVpnwVBmk3OH9etoJotoK59mie hXQ/CIRvOGBCVoVYiFlWd2mqZl6f91xuqGBgJmokB3dghnHaFl7q9YSZV1mHeIhzZ2yK6IiP eHurFXr0B4kawGGh91u3V4i3F3w1l4SUGHq5F4Jq5omTaP+KnfiEgQeKjPiI8NWJr2WJoniK rfhwixgAnViLnEaJF2iJvchxCceLmagBmYdiuQh2l4iMNWdnvQhfvuhdswiNo3aIx4iLwYeK jJiKv/aJ52BmqIcKckdZWpOI4liO5niO6JiO6riO7NiO7viO9/AYdAUONfAXL6VMrDBMWDRW P/FDB9VRLtAzVgCQxDA9ThUCS4MbrrQ3fMUC2XKPf6SPvVQTNdQfjpI2wiCQHrBXN+BWK6CR PQCSHwCRcZVDDGkDD/lLV/RVEwQEQBFJP5GREjmSddSR/MgCIqkOM4mQKuk4OZQ0+uRDM3M7 9IRQ9nQbQAkC6eNTIAMuWpA6qyD/O3UBOlZBlPx0SMQEUBrzTuGgML/yUP6YPNG0UKUClNvz GUS5k70kVwzBSMyjFq1zNPWyTdyUJZ9jPHzlUz8VMDukla3wLlVRO65DKhSlDJ9kTSqiQY/w KsykKiQ5T9IgRwlCN7vCDTzSKyjiIfuzLLzkH+rSIwBkRTaijxFCJv4jQ/EzQ8Chli5iP3FC V+ezLMu0IKwEGJ0QMX6kPskTSPNhQAspUEklSmZkSoTRSCupm3wZUUq0C4+5lPSyOApiRh3U BpmZIpvJkpgyKJ85IVT0K7F0nNSjIORUk0QjMTnJQK7JJ/BiIygDSfaCVbbZTUYkMbIUKlhU P1NkkkgV/0qcSUprkEOHiZwCiitlIh/M2ZOIGQ2aBJ1oc6CY2UgjoUqjmRTaeSindBbfWZ+K kxunqSrAlKAlUEvKoEjrGZG7lC0E2aG5SSflIBRuoVf6OS38uUv+SUSuFKATCiiz+SyR5KD3 WC2BcpHsY6BUYUqSwgw1IqEuFB++2SBN1JC2Ep6F0aGXCUrJRC2smZ2kdBwsg1TespTrMx+1 aSp54EfX0aK86UweFKOrEpz9KY/h4yVTKZSW8TH1ZD0BlZB+Apa2c1fxBFRtURdwwjzduRoN hRKUAzD3lD1dSTC/Y5ERsimD0TmSYRhoiTxYeZ8RMZ7I4paUgU38kpzaBJ+EGf9N9NlQd+GP m/Sniyo+5bkvBrUSDRk3s9qf+nCe8FgH+8IBBpmrvvqrwBqswjqsxFqsxnqsyJqsT6WnJABY yjo0nuCskIKgHyGtz5oQ0Vqrd+MB1aqt1woQnEOWtwkz2yMvaZkyfdklepIa27On35oQJNpK 7ppGOipBnYmfR2VG3fquTEOi75KtipGP2Jmd4vmacXqb08KvOqNIKjpCvQAT5iEj0PKaDZuw CosQDKufuGSlajWwBCtE66KxV3qxQ1NO0tQwdPGVglmnmLqb+DpX24AshGWtJFuzNnuzOJuz OruzPNuzPvuzQBu0Qju0RFu0Rnu0SJu0Sru0TNu0Tvv/tFAbtVI7tVRbtVZ7tVibtVq7tVzb tV67WAbgAGLrAAsQtmN7tmgrtgmQAQsgtgagAW2btmnLAADAAHNrt2hLtx6QAGrLt2oLAH7r AGsLt2f7tgAQtw7wtnZLt3jLuGfruA7AAHibtgsAAGaLtpXrt4MbuGebAJwruBKAuG8btwYg uhnQuBLQuKh7uZV7uY8rt5V7AZ+bAKRruhZAuofrtpMbuXXLu7srtpP7u8ALu7M7AXw7uP8Q tgzguXy7AHy7vJ47tgvQttMLuhhgAHZruNdrt8zLvZLbvQyAAN/ruZIrvtCbAJL7AaUruOtb ts1Lu9Z7AW3bvYk7v+ibuOYL/wDma77Mi77hW777G73L+7bK+7zNa7nzKwHNS73zawDw67yj K7j3awDYm7gVjLwWML7pu7/7W8DNW8CR+74hHL2xawEOTL0JQMHZe8Hbm7i5u7YI4L8JgAD6 u8Hl+7wOHLkgvLxka8DRK7bO67kJDLjx2w/Kq70pHLYlnMJMzL4pTLjaiwFta7gOXLd6a8VY LAEIQMPpq8U0/AGae7wfjMBFPAFDbLnwO7gVXMGM28YUsMVZ3MVKTAFJTLaAa7jHKwEOnMNM jMfWO8RrXLsufAHlq8Xp28WSe8QK3MMUbMd1vMRRbAF5HLpuO8VsO7yDnMWp67t0O8dz/Mh3 PMcKPP/JaOzHGMwPokwBSpzKRHzK8hu5mfzK62u4XYzFh3zFtywCYSzB8UvKFGDJv5zJU7y4 tnzFFIDIesvKemzHxgvLGOzLrUzJ2jvFghzJE1DLxZy6DJDKoszNZKvMshu/1XzJsJzJ2EzM 6evJzGy567zKjlzGzezK+gDOrlvC0bwBbZu9hDu2tPy4XDy2uAzQugzL3EvK0CzNFQDMuYu9 ktvQNfy42hzR7GzPy2zPz1vE0DzJCk3NBB3Lx2zMuWzF3hy73iy9HEDK+QzL1mzGHa2959zQ 6WzHIz0B9UzGnRvPAKHOQAzCFg3PCc2++izFghvU31vIVuy/17y82Ly3ghv/t9GLvAe90D89 zYlbvsSsv/0b0nK8zjS9zh98xhn9x8Jcvw4gvm6LAS8dx9vczszszTxM0eGMvG1r1h4dzItr ziD9v7yrziXs1geMxsw7xFGdD6JMwp8cxYPN0oV7yRSMvCGNxXAc0ZENAmLct73s0wqN0NJ8 yLybwW6cxfTs1WgL1WWs0WM9y7hLyHmt1jM90V2duStdAShN1nXN0jGs0GlNzHz92rz9xJJs vYmND3/tziTNzMH9whPM2BVgw3pby4+91BtwvOubwgk8xiYc1MPswgnM3JqczaAt020t2s4L 1qVtvWv8wgt93heQv1bMxc1NtwesyK5d0fSdAbOt/8K1jdC4vdr5u9v1Pd+XS9pq7NsAwblr TblE/LdCjcm1jbiDjLqLK7ySO7f/Hc6Wvbbru9MZUMFji+GTu7YQTrd0Dbw0TNfh67omzboJ Xs6gG7ibO9qW++G5W8n5/dCR+8Um/sWBu83LDMTsjOAW3uGim9nBzOAcDry9y8mLDLxUnOJy ywAO/s2LLM/80L9v27/MS8BZvuFZzrzX278TEMMzjNVbjOUzLOb9S8Py/eWe29hUvOUa4MBe rsdzLuYljuNpHuaeq+NmjsdtDthM/Ody7tuD/ueATueei8YbEOGdbed0bOij7NtmTuAVUOhJ 7OVVzOaBDsN57uiTDeeR7v/nWN7YVk7TlL5Ypz4QMVzmX/y1rs40MB3rsj7rtF7rtn7ruJ7r ur7rvN7rvv7rwB7swj7sxF7sxm7rcP3qyr7szN7szv7s0B7t0j7t1F7t1n7t2J7t2r7t3N7t 3v7t4B7u4j7u5F7u5n7u6A60cNqPLesChJXuSsOmHQA3cBQDNAvvO9ChYFKr9Q4D947vx/CT xKM9A6WhNjQbyxMnEDMWK4SqAG8EA3NByIRH45AujVmjkDEnK/rwQ0BH3LmrqalMq8lOY+lL 3bQJnwTyHI8EdPRBlsrvI0+gbaKmZOpJxqlCK8/yOQSaGDSyyLkdzqIjv4nyxrnxOe8DcMqV RfPV7gE7On1Bly0Ss0QknxMSlB579LfgkUqZpVgfCFDf9WAf9mI/9mRf9mZ/9u+YlP14KQSJ 9mbwmFtPoSbw726fEwhqAkih9SFf9x2/royKob7DopJ5LdxxlDAClb7C90QQILuQJj6vPmGV Kzz6TA4091lKBBkTGSWToT+/St8yBBzpoXR/+SPwHVCS8obEp97hlqnvm6fvraQPA6bvpDfP +TkqR4RfoGfESoqZ+zWAU+KqOpGKTmCZNC5nPFM5sYcfUA7l+8yYI9Af/dI//dRf/dZPUhEA ADs= --------------AttPart_71398012==.OLA-- From capwap-admin@frascone.com Mon Oct 10 12:00:16 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EP04W-0000CT-Jv for capwap-archive@megatron.ietf.org; Mon, 10 Oct 2005 12:00:16 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02380 for ; Mon, 10 Oct 2005 12:00:12 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 6B413203E2; Mon, 10 Oct 2005 12:00:07 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by mail.frascone.com (Postfix) with ESMTP id 07AE62038E for ; Mon, 10 Oct 2005 11:59:58 -0400 (EDT) Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-2.cisco.com with ESMTP; 10 Oct 2005 08:59:58 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j9AFxO4x006099; Mon, 10 Oct 2005 08:59:55 -0700 (PDT) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 10 Oct 2005 08:59:43 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Capwap] Proxy MAC usage - query Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2C48601@xmb-sjc-235.amer.cisco.com> Thread-Topic: [Capwap] Proxy MAC usage - query Thread-Index: AcXNXh2tO0uMrMZAQAisQO6IDnE3QgAVWuGw From: "Pat Calhoun (pacalhou)" To: "sujay" Cc: "capwap" X-OriginalArrivalTime: 10 Oct 2005 15:59:43.0843 (UTC) FILETIME=[A1452330:01C5CDB3] 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-Unsubscribe: , List-Id: A list for CAPWAP technical discussions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 10 Oct 2005 08:59:43 -0700 Content-Transfer-Encoding: quoted-printable Folks, I hate to stop this discussion, but I think we may be putting the cart before the horse. The CAPWAP WG has yet to actually decide on the base draft. My understanding is that we are supposed to provide our comments on the contents of the evaluation draft. Of course, if folks have recommended changes for the LWAPP protocol, please send them to me directly instead.=20 Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems ________________________________ From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of sujay Sent: Sunday, October 09, 2005 10:47 PM To: 'capwap' Subject: [Capwap] Proxy MAC usage - query =09 =09 =20 Group, =20 Request for a clarification w.r.t draft-lwapp-03 Proxy MAC usage. =20 =20 =20 STA ------------------------------- WTP ----------------------------------------------------- AC =20 =20 (802.11 Ass Req) -----------------> Proxy MAC --(LWAPP , C=3D 0, 802.11 Ass Req) -----------------> =20 =20 (802.11 Ass Resp) <----------------- Proxy MAC --(LWAPP , C=3D 0, 802.11 Ass Resp) <----------------- =20 =20 =20 =20 =20 (802.11 Data) -----------------> ---------------- (LWAPP , C=3D 0, 802.11 Data) -----------------> =20 =20 Speaking for Local MAC(or 'Local AP'); =20 I Understand the meaning and need for the Proxy MAC. =20 However, if the data is to be send across from one STA to another STA connected to another WTP. =20 the 802.11 is first converted to 802.3 (integration/distribution done at WTP) =20 Issue is if it has be sent to AC and then further switched from there, we cannot use the LWAPP data tunnel, as the AC is expecting .11 frame in the LWAPP data path and not .3 frames. =20 That implies (1). we use a separate channel from the WTP to the AC (2). tunnel it out of the WTP directly to=20 the destination WTP (3). Indicate in the lwapp header if the corresponding frame is .11 or .3 (4.) ?? =20 Or am I missing something? =20 Thanks; Sujay =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 My Location; =09 http://maps.google.com/maps?ll=3D14.626109,76.959229&spn=3D4.724852,7.525= 085 &t=3Dh&hl=3Den =20 _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Mon Oct 10 21:47:13 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EP9EW-0001kH-C8 for capwap-archive@megatron.ietf.org; Mon, 10 Oct 2005 21:47:13 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA07482 for ; Mon, 10 Oct 2005 21:47:09 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E379320477; Mon, 10 Oct 2005 21:47:04 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from staff-mail.rp.edu.sg (smtp.rp.edu.sg [202.21.158.80]) by mail.frascone.com (Postfix) with ESMTP id 18A52203FB for ; Mon, 10 Oct 2005 21:46:29 -0400 (EDT) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.1830 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Capwap] Proxy MAC usage - query Message-ID: <9C374CF75527504394E573E1937136C4018CA70F@staff-mail.rp.edu.sg> Thread-Topic: [Capwap] Proxy MAC usage - query thread-index: AcXNXh2tO0uMrMZAQAisQO6IDnE3QgAVWuGwABP9kfA= From: "Richard Gwee" To: "Pat Calhoun (pacalhou)" , "sujay" Cc: "capwap" 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-Unsubscribe: , List-Id: A list for CAPWAP technical discussions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 11 Oct 2005 09:46:33 +0800 Content-Transfer-Encoding: quoted-printable Hi, I do agree to the need to focus on the evaluation draft. I feel that there is a need for the Evaluation draft to include specific protocol attributes in their recommendation. As a matter of fact, I have sent an earlier email providing a list of attributes that can be considered. I am still waiting for comments. Thanks and regards Richard Gwee -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Pat Calhoun (pacalhou) Sent: Tuesday, October 11, 2005 12:00 AM To: sujay Cc: capwap Subject: RE: [Capwap] Proxy MAC usage - query Folks, I hate to stop this discussion, but I think we may be putting the cart before the horse. The CAPWAP WG has yet to actually decide on the base draft. My understanding is that we are supposed to provide our comments on the contents of the evaluation draft. Of course, if folks have recommended changes for the LWAPP protocol, please send them to me directly instead.=20 Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems ________________________________ From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of sujay Sent: Sunday, October 09, 2005 10:47 PM To: 'capwap' Subject: [Capwap] Proxy MAC usage - query =09 =09 =20 Group, =20 Request for a clarification w.r.t draft-lwapp-03 Proxy MAC usage. =20 =20 =20 STA ------------------------------- WTP ----------------------------------------------------- AC =20 =20 (802.11 Ass Req) -----------------> Proxy MAC --(LWAPP , C=3D 0, 802.11 Ass Req) -----------------> =20 =20 (802.11 Ass Resp) <----------------- Proxy MAC --(LWAPP , C=3D 0, 802.11 Ass Resp) <----------------- =20 =20 =20 =20 =20 (802.11 Data) -----------------> ---------------- (LWAPP , C=3D 0, 802.11 Data) -----------------> =20 =20 Speaking for Local MAC(or 'Local AP'); =20 I Understand the meaning and need for the Proxy MAC. =20 However, if the data is to be send across from one STA to another STA connected to another WTP. =20 the 802.11 is first converted to 802.3 (integration/distribution done at WTP) =20 Issue is if it has be sent to AC and then further switched from there, we cannot use the LWAPP data tunnel, as the AC is expecting .11 frame in the LWAPP data path and not .3 frames. =20 That implies (1). we use a separate channel from the WTP to the AC (2). tunnel it out of the WTP directly to=20 the destination WTP (3). Indicate in the lwapp header if the corresponding frame is .11 or .3 (4.) ?? =20 Or am I missing something? =20 Thanks; Sujay =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 My Location; =09 http://maps.google.com/maps?ll=3D14.626109,76.959229&spn=3D4.724852,7.525= 085 &t=3Dh&hl=3Den =20 _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap Republic Polytechnic, Tanglin Campus, 1 Kay Siang Road, Singapore 248922 = . Website: www.rp.sg . Fax: +65 6415-1310 . From April 2006, we will be located in our new home at 9 Woodlands = Avenue 9,Singapore 738964=20 Republic Polytechnic, the first Institute of Higher Learning to fully = adopt the Problem-Based Learning approach in Singapore, continues to = strive towards best practices and maintain excellence in service = standards with the following certifications: Singapore Quality Class = (SQC) certification, People Developer Standards and QEHS standards (ISO = 9001, 14001 and OHSAS 18001 certifications). --------------------------------------------------------------------- CONFIDENTIALITY CAUTION: This message is intended only for the use of = the individual or entity to whom it is addressed and contains = information that is privileged and confidential. If you, the reader of = this message, are not the intended recipient, you should not = disseminate, distribute or copy this communication. If you have received = this communication in error, please notify us immediately by return = email and delete the original message. Thank you. _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Tue Oct 11 11:18:26 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPLtZ-0000WL-Le for capwap-archive@megatron.ietf.org; Tue, 11 Oct 2005 11:18:26 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07665 for ; Tue, 11 Oct 2005 11:18:22 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 6529D200B0; Tue, 11 Oct 2005 11:18:04 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from huawei.com (szxga01-in.huawei.com [61.144.161.53]) by mail.frascone.com (Postfix) with ESMTP id 977AC1FE58 for ; Tue, 11 Oct 2005 11:17:55 -0400 (EDT) Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IO700C08C5CLL@szxga01-in.huawei.com> for capwap@frascone.com; Tue, 11 Oct 2005 23:24:48 +0800 (CST) Received: from szxml01-in ([172.24.1.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IO700A1VC3ISV@szxga01-in.huawei.com> for capwap@frascone.com; Tue, 11 Oct 2005 23:24:48 +0800 (CST) Received: from dell60 ([10.18.4.100]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IO700GM9AWHNL@szxml01-in.huawei.com>; Tue, 11 Oct 2005 22:57:54 +0800 (CST) From: sujay Subject: RE: [Capwap] Proxy MAC usage - query In-reply-to: <4FF84B0BC277FF45AA27FE969DD956A2C48601@xmb-sjc-235.amer.cisco.com> To: "'Pat Calhoun (pacalhou)'" Cc: "'capwap'" Message-id: <007201c5ce72$a7c0ef40$6404120a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 X-Mailer: Microsoft Outlook, Build 10.0.4024 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal 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-Unsubscribe: , List-Id: A list for CAPWAP technical discussions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 11 Oct 2005 20:17:07 +0530 Content-Transfer-Encoding: 7BIT Agreed; Going in line with the recommendation draft therefore, the base protocol should have a support for "Local MAC User Data Tunnelling" (as in Section 9.1.3.1.) Sujay -----Original Message----- From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com] Sent: Monday, October 10, 2005 9:30 PM To: sujay Cc: capwap Subject: RE: [Capwap] Proxy MAC usage - query Folks, I hate to stop this discussion, but I think we may be putting the cart before the horse. The CAPWAP WG has yet to actually decide on the base draft. My understanding is that we are supposed to provide our comments on the contents of the evaluation draft. Of course, if folks have recommended changes for the LWAPP protocol, please send them to me directly instead. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems ________________________________ From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of sujay Sent: Sunday, October 09, 2005 10:47 PM To: 'capwap' Subject: [Capwap] Proxy MAC usage - query Group, Request for a clarification w.r.t draft-lwapp-03 Proxy MAC usage. STA ------------------------------- WTP ----------------------------------------------------- AC (802.11 Ass Req) -----------------> Proxy MAC --(LWAPP , C= 0, 802.11 Ass Req) -----------------> (802.11 Ass Resp) <----------------- Proxy MAC --(LWAPP , C= 0, 802.11 Ass Resp) <----------------- (802.11 Data) -----------------> ---------------- (LWAPP , C= 0, 802.11 Data) -----------------> Speaking for Local MAC(or 'Local AP'); I Understand the meaning and need for the Proxy MAC. However, if the data is to be send across from one STA to another STA connected to another WTP. the 802.11 is first converted to 802.3 (integration/distribution done at WTP) Issue is if it has be sent to AC and then further switched from there, we cannot use the LWAPP data tunnel, as the AC is expecting .11 frame in the LWAPP data path and not .3 frames. That implies (1). we use a separate channel from the WTP to the AC (2). tunnel it out of the WTP directly to the destination WTP (3). Indicate in the lwapp header if the corresponding frame is .11 or .3 (4.) ?? Or am I missing something? Thanks; Sujay My Location; http://maps.google.com/maps?ll=14.626109,76.959229&spn=4.724852,7.525085 &t=h&hl=en _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From postmaster@blueshift.com Wed Oct 12 04:30:14 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPc06-0008LA-7k; Wed, 12 Oct 2005 04:30:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05915; Wed, 12 Oct 2005 04:30:09 -0400 (EDT) Received: from cpe-69-76-61-91.new.res.rr.com ([69.76.61.91]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EPcAF-0002KV-Qk; Wed, 12 Oct 2005 04:40:49 -0400 Received: (from tomcat@localhost) by 69.76.61.91 (8.12.8/8.12.8/Submit) id j0CHmn9V840564 for bpana@ietf.org; Wed, 12 Oct 2005 03:29:42 -0600 Message-ID: <610o941y.4718068@132.151.6.1> Date: Wed, 12 Oct 2005 03:29:42 -0600 From: "Darius Nicholson" X-Mailer: MIME-tools 5.467 (Entity 5.042) MIME-Version: 1.0 To: bpana@ietf.org, brenton.daniels@ietf.org, bridge-mib@ietf.org, bridge-mib-admin@ietf.org, business@ietf.org, calsch@ietf.org, cancer@ietf.org, capwap-archive@ietf.org, ccips@ietf.org, cclark@ietf.org, cdi-archive@ietf.org, cdir-admin@ietf.org, cfrg@ietf.org, cfrg-admin@ietf.org, cfrg-archive@ietf.org, cfrg-bounces@ietf.org X-Spam-Score: (-2.519) BAYES_00 X-Scanned-By: MIMEDefang 2.52 on 69.76.61.91 X-Scanned-By: SpamAssassin 3.024149, File::Scan 0.92, Archive::Zip 1.83 X-Recipient: Subject: Pre-approved Application #47640728 Wed, 12 Oct 2005 03:29:42 -0600 Content-Type: multipart/related; boundary="------------AttPart_68123533==.OLA" X-Spam-Score: 4.1 (++++) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c This is a multi-part message in MIME format. --------------AttPart_68123533==.OLA Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
be unique ! consul and roof on monogamy but verve on timeout the feel it's canterbury see mulligan be papillary it's j's or break and dobbs see dreamlike Or maybe not

--------------AttPart_68123533==.OLA Content-Type: image/gif; name="methodic.9.gif" Content-ID: <3.0.0.44.0.10527170957115.91404936@preclude.hotmail.com.3> Content-Disposition: inline; filename="methodic.9.gif" Content-Transfer-Encoding: base64 R0lGODlh5gHOALMAAP/////MzP+Zmf9mZv8zM/8AAMzM/8zMzMyZ/5mZ/5mZmZlmzGYzzDMz MzMAzAAAACH5BAAAAAAALAAAAADmAc4AAAT/EMhJq7046827/2AojmRpnmiqrmzrvnAsz3Rt 33iu73zv/8CgcEgsGo/IpHLJbDqf0Kh0Sq2CDo+sIvs4ZLaPCthKLpvP6BPWu95sLe+0fE6v T9ttTZyyt/v/gIE4eF0AWFyFEn2KYRMNiA2CkpOUlRiHXAd5homLAHsNkY6ilqWmp2iEmoiZ jHCNAKEUsqi1trdMqptisBOgpLHAuMPExTm6iZxen72uErTPwsbT1NVqXGBdmFle2VmMiM+Q s9LW5ufoO9Dp7O3u7/Dx8vP09fb3+Pn6+/z9/v8AAwocSLCgwYMI02DKtgzGug1apOyqMubC okflhmCcE5GFJz+q/0R8VPFAgYyHIUr+GYkBZRGXIFQWkakDZouJLEKGYImC5gubHXzS4WkB aBCjHIQGUWoDaQqcK0JuS/aKi7gHobBeBcbKJICuGaZ2Y8Ws5LerWtGSAvsVmwRMyw6BWebt bNEsWbU+4hIpYscL29hgy7SlYtlmwWaNy4DI61RtrBpWtbsXL1qtfmU2DjuYW92yoPdmzUjB Z9eFrSxaBWe4MqnKmLV0BCuWU+qbZresagjVmeJI0KCZLjyBqbIJWPq8GfMrg6zhEpRuOrR7 D09astY992q8gtRCzHt5Cg7Mack8a6ZTxRCHvPa+3L1+lc9Z8AHlYeKA0ks6uvzhOn0h3v83 zY1CTnQq5VaabsgV0ttTuUHGynp8IOaScBMS598l6+HHjG8PwQYfBtIlo4p1iB2Y2Hvzbcgh IoIVBl4jHlYQ3ISknZZIeiZSCM5q7pU3YosuanDigB8mmZgHNAEYoWSqVQhieTgW2ZaO3FDw IArJmbXbB+OVIxx9RRo3kYf6wcJiNERaUCJvDnaB4gahYCckkWbuGKeMY/mmpIFsBvWfAuhB BieUvrX3Wp0HajZoB1326Ut+NKrZXwVN0nfek24gqeSabmpKppZZHhdDpKam+sqnYq4laqYc wolmpQZmt2ibeJpEk3r2HWZXS4wuyWaCecalJ4NJ1qiisMwuWJz/SWLxGqUzQTaqK6zdccLg rKAFKuizzqLaqZSsrngnrsP1aN+WJYhbmx5niejIYmxl+GIrn2WTzbyv8fXcZsXJFG1nVBHF rLwIgjHqW43tOaNsBJIVy2IIkzgYfYTAKOBgsKVVMcT/ZctwQ5+xhtdijAHMlrjskaXvahP3 y9eVf9EWWYM+JtSCwU7Zwe4RP+ss9KQwt5QWJYFFQd3QTDft9NNQRy311FRXbfXVWGet9dZc d+31PQQvDIJhp5ZKxF8zbASRyECgjZDBQcAdU3wpyH0NokuJzYHd3pKo90x/q8A3k4E/MTgP h0NENwqJixC0Dmy3HIJRkedNQ+MaVC4D/2rGwvhypTB3DNzMCG7GlgWoPWyXN/OSnpKGA0uI NyOtkS6aaDR3V1tt+UJMJ70AF7n7zaz/GC/KFwSPpVk5+0rp8xNjpXbmmjaWuoT4Sly80dKn pbxbtt02Q5e6SRuen+QVNWSL0L345aTwA9o34SrxGmBVfwZqJ7piF6rerJRyjpDaRyReqetP +Ekf9ZwFLupAhVuf4o/iwPUsZMjKU3LbyENgNbIGzQ43fDIfYvqgQHlhy16xqlA40FclEQhM XffjBbUoJop/nc47enoM81xGK+dYpnTKc8yEuuAj/ODoVguk4IbYBcECfctKmwrhEO9TtPwJ EFNBxNnNaEA+Q/950IokvFX6sFW4LyYKFmFMwQsPFUNyvUGBwaBF5fzXoRSlqQMb6c4acYg3 ZcmPcqIKV/P8tJweNiuJ/Ovi+1SDxhRdYB0cbNPjQOglEa6qPeNQIFgIiLpkzMkVbzzX6zo4 Mh41745wrJMoOEkqY/0PSXcEFjkIuMeRHbCQCJSe/PzGwCUOMpcfas2legkdVL3SjQHUACQf taFNHYqLspmLWEpGtEfW0F/C0EzwcKgxX6FITcgzT0feJRezqXCH0ZMeEoGYp5vxjocQc2Q6 vaeyzQyvm91y3mWO5ibw5Y5QW2zZCssChopZDHwr8xLDNEbNfD4SZQ0LmRDxSYaeae7/axil h2vW5raMevSjIA2pSEdK0pKa9KQoTalKV8pSQEyypTCNqUxnStOaCg0uC53LxtCJsI1eSWHs LKNNh7q5HnlRch8Clbf8oiErEfWpNpDWg1BZpY+RyZ9QzWpUD7glGc1PWGOymFC1StZ2cXWQ Xj1YsITFyYuW9a0ciN0OP/innmLzdKebyJnkCde+lgBzfg2sEsgm2MIa9rCITaxiF8vYxjr2 sZCNrGQnK4EAFOCyBLhsAQYQhMwS4AKe/QMBPlsBy3K2spo9LQAEoFkBbIC1l3WtBAag2QBM gLaXte0GQisE3Or2tgX4bQh4uwPWypYCtP0tboM7gcwWgLRH//DtBZLrAtYSIADWFW4PBDDa C3AXuicwbhGcC17Lbha1BBAAazm7XgHQ9rgWaO97AfBe7jK3vpnVbgVGq94hBCC/pYUvfZlL ge5W4Ls8gG0B4CvdAasXwPxFcBDEW1kAW4C6LTAtADQsBANbwMPhXTARIuxh86pWALbVsHgp 7F0Ri5e6ML4vgTEA4t7OOAMYbi54dVzczbpXxLPNbZBtS10D13i7QB7ydG+8Aus+N8WavewA YKve2OI4yjKOcgB822AAgNi5mM2AeaM8gDFLebVRFvCBsfxjzNZ2ubklL3FBS9r+bvi55y3t eVec5Pi6WMQxJrKM9dtczUIXzE829P+ZMWDm0yrYyhrI8XKVq2UJgHnHJcayai3QaAk8us9r di12dUtbCwfay6Q9coENLWZFO5rNsHWubB8t21ILGbiERoFlM8vZXau3ygR475ZBDdxf2zez xs5vfv87Yw9HWMKcfu6vE53eaZeZtlPONZqnrN73IpvZP072go8N7fiSdwK7zjO6n4xm17LY z+4G9KAHLGhtf9fOz753rNebAWP72MfdJjZyZ4xdC28Y2cfV935J62tr99va7Q24miu73OPa mtTzNvKOD/xrVXsaz7yOeLhxO4D5DjvbQV6wwXPcguzeWbWm5fPE6Y3uH1N62PXmsaUPvXHU nta0Zk5tu1//m2TjBhrOtUW1u2fu6Qd/1tfqvvN1Px5vpsuc5qdm+YfB++WnsxvFjNb0sGM7 6kgzmeVaV7WBg77oaJN57AsuO6Ml7mAMn1rjGkB0z9GL5ykXfdybxS6Q3z1fSTN5BRzm8Muv vmTtGh7nNN+5zlEd9p8HXtrGtu27W5zwuHtW3sbG994XLvmgW37qVB86Bq6e9XlnoOsF9vqm L9BwfmO3zUxX8sCFm/aerx3zvyZ07c97e9xa/c+uRXrOi5zq0T/b41LvO4uNy3jCuz7yLki8 umMOeIFj/+K4Tm6Xnc3zfot9+3sG/MynL28AP57yHLCvtJvu8l0Ll/GcH3rrc/56/677/+Ub oH1+J2rhZnaOd2PiR2DdBXsA6HO0l2fcR4DzRXvLVWYb9mBAdnfN13+TF22fN4ATQH3IR3Uv dn3YBQNj9mpRdl1jJ2u0h2iex2YH52bBpXerBYOj52/shWVTN3YWSIFiN4OyxWxpZoOvxV8U kIJ3RmYbVoG/xWJwZ4FECGRTmHuX5ml692mzt2aKFmxBuGSVpnwVBmk3OH9etoJotoK59mie hXQ/CIRvOGBCVoVYiFlWd2mqZl6f91xuqGBgJmokB3dghnHaFl7q9YSZV1mHeIhzZ2yK6IiP eHurFXr0B4kawGGh91u3V4i3F3w1l4SUGHq5F4Jq5omTaP+KnfiEgQeKjPiI8NWJr2WJoniK rfhwixgAnViLnEaJF2iJvchxCceLmagBmYdiuQh2l4iMNWdnvQhfvuhdswiNo3aIx4iLwYeK jJiKv/aJ52BmqIcKckdZWpOI4liO5niO6JiO6riO7NiO7viO9/AYdAUONfAXL6VMrDBMWDRW P/FDB9VRLtAzVgCQxDA9ThUCS4MbrrQ3fMUC2XKPf6SPvVQTNdQfjpI2wiCQHrBXN+BWK6CR PQCSHwCRcZVDDGkDD/lLV/RVEwQEQBFJP5GREjmSddSR/MgCIqkOM4mQKuk4OZQ0+uRDM3M7 9IRQ9nQbQAkC6eNTIAMuWpA6qyD/O3UBOlZBlPx0SMQEUBrzTuGgML/yUP6YPNG0UKUClNvz GUS5k70kVwzBSMyjFq1zNPWyTdyUJZ9jPHzlUz8VMDukla3wLlVRO65DKhSlDJ9kTSqiQY/w KsykKiQ5T9IgRwlCN7vCDTzSKyjiIfuzLLzkH+rSIwBkRTaijxFCJv4jQ/EzQ8Chli5iP3FC V+ezLMu0IKwEGJ0QMX6kPskTSPNhQAspUEklSmZkSoTRSCupm3wZUUq0C4+5lPSyOApiRh3U BpmZIpvJkpgyKJ85IVT0K7F0nNSjIORUk0QjMTnJQK7JJ/BiIygDSfaCVbbZTUYkMbIUKlhU P1NkkkgV/0qcSUprkEOHiZwCiitlIh/M2ZOIGQ2aBJ1oc6CY2UgjoUqjmRTaeSindBbfWZ+K kxunqSrAlKAlUEvKoEjrGZG7lC0E2aG5SSflIBRuoVf6OS38uUv+SUSuFKATCiiz+SyR5KD3 WC2BcpHsY6BUYUqSwgw1IqEuFB++2SBN1JC2Ep6F0aGXCUrJRC2smZ2kdBwsg1TespTrMx+1 aSp54EfX0aK86UweFKOrEpz9KY/h4yVTKZSW8TH1ZD0BlZB+Apa2c1fxBFRtURdwwjzduRoN hRKUAzD3lD1dSTC/Y5ERsimD0TmSYRhoiTxYeZ8RMZ7I4paUgU38kpzaBJ+EGf9N9NlQd+GP m/Sniyo+5bkvBrUSDRk3s9qf+nCe8FgH+8IBBpmrvvqrwBqswjqsxFqsxnqsyJqsT6WnJABY yjo0nuCskIKgHyGtz5oQ0Vqrd+MB1aqt1woQnEOWtwkz2yMvaZkyfdklepIa27On35oQJNpK 7ppGOipBnYmfR2VG3fquTEOi75KtipGP2Jmd4vmacXqb08KvOqNIKjpCvQAT5iEj0PKaDZuw CosQDKufuGSlajWwBCtE66KxV3qxQ1NO0tQwdPGVglmnmLqb+DpX24AshGWtJFuzNnuzOJuz OruzPNuzPvuzQBu0Qju0RFu0Rnu0SJu0Sru0TNu0Tvv/tFAbtVI7tVRbtVZ7tVibtVq7tVzb tV67WAbgAGLrAAsQtmN7tmgrtgmQAQsgtgagAW2btmnLAADAAHNrt2hLtx6QAGrLt2oLAH7r AGsLt2f7tgAQtw7wtnZLt3jLuGfruA7AAHibtgsAAGaLtpXrt4MbuGebAJwruBKAuG8btwYg uhnQuBLQuKh7uZV7uY8rt5V7AZ+bAKRruhZAuofrtpMbuXXLu7srtpP7u8ALu7M7AXw7uP8Q tgzguXy7AHy7vJ47tgvQttMLuhhgAHZruNdrt8zLvZLbvQyAAN/ruZIrvtCbAJL7AaUruOtb ts1Lu9Z7AW3bvYk7v+ibuOYL/wDma77Mi77hW777G73L+7bK+7zNa7nzKwHNS73zawDw67yj K7j3awDYm7gVjLwWML7pu7/7W8DNW8CR+74hHL2xawEOTL0JQMHZe8Hbm7i5u7YI4L8JgAD6 u8Hl+7wOHLkgvLxka8DRK7bO67kJDLjx2w/Kq70pHLYlnMJMzL4pTLjaiwFta7gOXLd6a8VY LAEIQMPpq8U0/AGae7wfjMBFPAFDbLnwO7gVXMGM28YUsMVZ3MVKTAFJTLaAa7jHKwEOnMNM jMfWO8RrXLsufAHlq8Xp28WSe8QK3MMUbMd1vMRRbAF5HLpuO8VsO7yDnMWp67t0O8dz/Mh3 PMcKPP/JaOzHGMwPokwBSpzKRHzK8hu5mfzK62u4XYzFh3zFtywCYSzB8UvKFGDJv5zJU7y4 tnzFFIDIesvKemzHxgvLGOzLrUzJ2jvFghzJE1DLxZy6DJDKoszNZKvMshu/1XzJsJzJ2EzM 6evJzGy567zKjlzGzezK+gDOrlvC0bwBbZu9hDu2tPy4XDy2uAzQugzL3EvK0CzNFQDMuYu9 ktvQNfy42hzR7GzPy2zPz1vE0DzJCk3NBB3Lx2zMuWzF3hy73iy9HEDK+QzL1mzGHa2959zQ 6WzHIz0B9UzGnRvPAKHOQAzCFg3PCc2++izFghvU31vIVuy/17y82Ly3ghv/t9GLvAe90D89 zYlbvsSsv/0b0nK8zjS9zh98xhn9x8Jcvw4gvm6LAS8dx9vczszszTxM0eGMvG1r1h4dzItr ziD9v7yrziXs1geMxsw7xFGdD6JMwp8cxYPN0oV7yRSMvCGNxXAc0ZENAmLct73s0wqN0NJ8 yLybwW6cxfTs1WgL1WWs0WM9y7hLyHmt1jM90V2duStdAShN1nXN0jGs0GlNzHz92rz9xJJs vYmND3/tziTNzMH9whPM2BVgw3pby4+91BtwvOubwgk8xiYc1MPswgnM3JqczaAt020t2s4L 1qVtvWv8wgt93heQv1bMxc1NtwesyK5d0fSdAbOt/8K1jdC4vdr5u9v1Pd+XS9pq7NsAwblr TblE/LdCjcm1jbiDjLqLK7ySO7f/Hc6Wvbbru9MZUMFji+GTu7YQTrd0Dbw0TNfh67omzboJ Xs6gG7ibO9qW++G5W8n5/dCR+8Um/sWBu83LDMTsjOAW3uGim9nBzOAcDry9y8mLDLxUnOJy ywAO/s2LLM/80L9v27/MS8BZvuFZzrzX278TEMMzjNVbjOUzLOb9S8Py/eWe29hUvOUa4MBe rsdzLuYljuNpHuaeq+NmjsdtDthM/Ody7tuD/ueATueei8YbEOGdbed0bOij7NtmTuAVUOhJ 7OVVzOaBDsN57uiTDeeR7v/nWN7YVk7TlL5Ypz4QMVzmX/y1rs40MB3rsj7rtF7rtn7ruJ7r ur7rvN7rvv7rwB7swj7sxF7sxm7rcP3qyr7szN7szv7s0B7t0j7t1F7t1n7t2J7t2r7t3N7t 3v7t4B7u4j7u5F7u5n7u6A60cNqPLesChJXuSsOmHQA3cBQDNAvvO9ChYFKr9Q4D947vx/CT xKM9A6WhNjQbyxMnEDMWK4SqAG8EA3NByIRH45AujVmjkDEnK/rwQ0BH3LmrqalMq8lOY+lL 3bQJnwTyHI8EdPRBlsrvI0+gbaKmZOpJxqlCK8/yOQSaGDSyyLkdzqIjv4nyxrnxOe8DcMqV RfPV7gE7On1Bly0Ss0QknxMSlB579LfgkUqZpVgfCFDf9WAf9mI/9mRf9mZ/9u+YlP14KQSJ 9mbwmFtPoSbw726fEwhqAkih9SFf9x2/royKob7DopJ5LdxxlDAClb7C90QQILuQJj6vPmGV Kzz6TA40CPJmBBkTGSWToT+/StKnIozpoXR/+SPwHVCS8obEp97eBTFvm6fvraQPA6bvpDfP +TkqR4RfoGfWsTjZ+zWAU+KqOpGKTmCZ99JWPFM5sYcfUA7l+8kcaEAf/dI//dRf/dZPUhEA ADs= --------------AttPart_68123533==.OLA-- From capwap-admin@frascone.com Wed Oct 12 09:12:12 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPgOy-0007FG-QR for capwap-archive@megatron.ietf.org; Wed, 12 Oct 2005 09:12:12 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20286 for ; Wed, 12 Oct 2005 09:12:09 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 95E20203DF; Wed, 12 Oct 2005 09:12:04 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by mail.frascone.com (Postfix) with ESMTP id D759F1FE0B for ; Wed, 12 Oct 2005 09:11:39 -0400 (EDT) Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-5.cisco.com with ESMTP; 12 Oct 2005 06:11:38 -0700 X-IronPort-AV: i="3.97,206,1125903600"; d="scan'208"; a="219413870:sNHT26377476" Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j9CDBAVO021746; Wed, 12 Oct 2005 06:11:36 -0700 (PDT) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 12 Oct 2005 06:11:29 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Capwap] Cisco IPR Statement Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2CA4453@xmb-sjc-235.amer.cisco.com> Thread-Topic: [Capwap] Cisco IPR Statement Thread-Index: AcXKY7K4DtDNrKZSTY2n/jiUkLVY2gDRU6Jg From: "Pat Calhoun (pacalhou)" To: "Wijnen, Bert (Bert)" Cc: X-OriginalArrivalTime: 12 Oct 2005 13:11:29.0202 (UTC) FILETIME=[7538A920:01C5CF2E] 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-Unsubscribe: , List-Id: A list for CAPWAP technical discussions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 12 Oct 2005 06:11:27 -0700 Content-Transfer-Encoding: quoted-printable > Pat, can I try to translate in my own words, so that I can=20 > veryify if I understand your statements correctly: >=20 > 1.You say that there are some techniques/mechanisms/algorithms that > Cisco has IPR on and that those do probably cover the current > candidate protocols on the table in the CAPWAP WG. So they cover > the technology/protocol that this WG wants to standardize. > 2.You say that the LWAPP protocol (one of the candidates, submitted > by Cisco) does include some of the techniques/mechanisms/algorithms > that Cisco has IPR on. > 3.You say that the 3 other (CTP, WiCOP, SLAPP) protocols (all 3 are > candidates, but submitted by others (non-Cisco)) also include > some of the techniques/mechanisms/algorithms that Cisco has IPR on. > 4.You say (below) that: Cisco believes anyone having IPR on a=20 > technology > they bring to the IETF should let anyone implement the technology > without any need for explicit license, payments and other kind of > uncertainties. Correct on all points. >=20 > So now I start to wonder: > a.Is Cisco (or better individuals who work at Cisco) bringing=20 > technology > (i.e. techniques/mechanisms/algorithms) to the CAPWAP WG in=20 > order for > the WG to develop a standardized CAPWAP protocol? or,=20 > b.Is=20 > Cisco (or better individuals who work at Cisco) bringing an > implementation of some specific technology (i.e. LWAPP)=20 > that contains > those specific techniques/mechanisms/algorithms (on which=20 > Cisco has IPR) > to the CAPWAP WG? > c.It sounds like you are stating the answer is b. and that only if the > CAPWAP WG selects the LWAPP candidate, only then will Cisco live up > to its believes as listed in point 4. above. > d.Does that imply that if the WG wants the "generous IPR=20 > conditions" of > point 4. above, that they basically can only choose LWAPP,=20 > possibly with > some additions? Actually, the answer is (a) *and* (b). However, to answer your additional question, Airespace had made an IPR statement that is much more generous than Cisco typically provides, and is one that Cisco will fully support on its own implementation (b). Cisco feels the Airespace statement should help technology adoption through free licensing, but for those that would prefer other RAND related terms, this is also possible. As we all know, IPR is just one of many criteria to use in a protocol selection process. The fact that the evaluation team has recommended LWAPP means that the protocol is viable. Further, I had previously stated that the recommended changes by the evaluation team did not infringe on any additional Cisco technology that I am aware of. > Would be good if you could also list details as to which=20 > pieces of each of the CAPWAP protocol candidates you do think=20 > are covered by IPR. So that does not mean detailing the IPR=20 > itself, but detailing which pieces of the documents on the=20 > table are covered/impacted. Bert, I understand the request, and this is one of those tricky situations where acting as an invidivual contributor doesn't work very well, because these types of issues are corporate in nature. My legal counsel has informed me that Cisco has followed all of the IETF's policies, but if the IETF changes its policy, we would be happy to accomodate. The sentiment being that if the policy were to change, then all companies would have to compete on an equal footing - making this a fairer process. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Wed Oct 12 14:07:15 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPl0U-0007FF-UY for capwap-archive@megatron.ietf.org; Wed, 12 Oct 2005 14:07:15 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08469 for ; Wed, 12 Oct 2005 14:07:09 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 65F5420418; Wed, 12 Oct 2005 14:07:04 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from typhoon.trangosoft.com (unknown [209.82.51.154]) by mail.frascone.com (Postfix) with ESMTP id DA7BF1FE0B for ; Wed, 12 Oct 2005 14:06:56 -0400 (EDT) Received: from phantom-out.trangosoft.com ([136.157.233.22]) by 136.157.233.32 with trend_isnt_name_B; Wed, 12 Oct 2005 14:07:10 -0400 Received: from troll3.trangosoft.com (troll3.trangosoft.com [136.157.233.13]) by phantom-out.trangosoft.com (Postfix) with ESMTP id 6EB5224FF6; Wed, 12 Oct 2005 14:02:38 -0400 (EDT) Received: by troll3.trangosoft.com with Internet Mail Service (5.5.2653.19) id <4DWMLK46>; Wed, 12 Oct 2005 13:59:57 -0400 Message-ID: <1652EBA28502ED4393B9BC9B8A4B601335AC4B@mism121a.toronto.chantrynetworks.com> From: Michael Montemurro To: Dorothy.Gellert@nokia.com, capwap@frascone.com Cc: mmani@avaya.com, bwijnen@lucent.com, david.kessens@nokia.com Subject: RE: [Capwap] CAPWAP evaluation draft complete MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain 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-Unsubscribe: , List-Id: A list for CAPWAP technical discussions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 12 Oct 2005 14:05:49 -0400 Dorothy and Mani, I just wanted to state that I accept the CAPWAP evaluation draft and its recommendations. I think we can work with the recommendations of the evaluation team and move towards completing the protocol specification. However, I believe that there are a number of issues that need to be addressed in order to arrive at a completed protocol. Some of these issues include: - mandatory/optional protocol components - local MAC/split MAC negotiation - data frame format for tunneling in local MAC mode - application of 802.11e EDCA and admission control (I think there are still some issues) - firmware update Cheers, Mike > -----Original Message----- > From: capwap-admin@frascone.com > [mailto:capwap-admin@frascone.com] On Behalf Of > Dorothy.Gellert@nokia.com > Sent: September 21, 2005 9:34 PM > To: capwap@frascone.com > Cc: mmani@avaya.com; bwijnen@lucent.com; > david.kessens@nokia.com; Dorothy.Gellert@nokia.com > Subject: [Capwap] CAPWAP evaluation draft complete > > > After much hard work, the evaluation team has completed the > CAPWAP evaluation draft. Its is available for review at: > http://www.ietf.org/internet-drafts/draft-ietf-capwap-eval-00. > txt and also in the internet drafts directory. > > The evaluation team concluded that LWAPP is the most complete > proposal and should be used as the basis for CAPWAP protocol > moving forward. In addition, a number of recommendations > were made which the evaluation team believed should be > addressed by the working group. > > Over the next 2 weeks the evaluation team will address clarification > questions on the WG list. The recommendation provided by the > evaluation team will not change, as this was intended to be an > independent activity supported by the WG. This is essentially a WGLC > on the evaluation draft. Please submit any clarification > question to the list by Friday, September 30th. > > The next step will be to come to an agreement on the WG list > to decide to accept the recommended protocol. Once we have > established consensus, we can further discuss the additional > recommendations presented in the draft. > > We would like to thank the evaluation team on its thorough > work and a job well done. > > Regards, > Dorothy and Mani > > > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap > _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Wed Oct 12 15:44:12 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPmWJ-0001xf-Ht for capwap-archive@megatron.ietf.org; Wed, 12 Oct 2005 15:44:12 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14192 for ; Wed, 12 Oct 2005 15:44:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id AFC2C2042D; Wed, 12 Oct 2005 15:44:04 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from mgw-ext01.nokia.com (mgw-ext01.nokia.com [131.228.20.93]) by mail.frascone.com (Postfix) with ESMTP id 879EB1FE0B for ; Wed, 12 Oct 2005 15:43:23 -0400 (EDT) Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext01.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j9CJfv8E029872; Wed, 12 Oct 2005 22:41:58 +0300 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 12 Oct 2005 22:41:58 +0300 Received: from mvebe101.NOE.Nokia.com ([172.19.64.23]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 12 Oct 2005 14:41:55 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Capwap] CAPWAP evaluation draft complete Message-ID: <893AE265F4ADF94AB7FB26D31A788E41011FA3CE@mvebe101.NOE.Nokia.com> Thread-Topic: [Capwap] CAPWAP evaluation draft complete Thread-Index: AcXPV/hMnZxF4HyRTd6ozw3RWtVafAADKIMQ From: To: , Cc: , , X-OriginalArrivalTime: 12 Oct 2005 19:41:55.0933 (UTC) FILETIME=[00A420D0:01C5CF65] 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-Unsubscribe: , List-Id: A list for CAPWAP technical discussions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 12 Oct 2005 12:41:53 -0700 Content-Transfer-Encoding: quoted-printable Hi Mike- Thanks for the vote of confidence! Mani and I have been talking to first gain concensus within the WG on the protocol, and then work through the issues and apply them to the accepted protocol. It seems with the controversy on the list this may be the best way forward. Thanks, Dorothy -----Original Message----- From: ext Michael Montemurro [mailto:michael.montemurro@siemens.com]=20 Sent: Wednesday, October 12, 2005 11:06 AM To: Gellert Dorothy (Nokia-ES/MtView); capwap@frascone.com Cc: mmani@avaya.com; bwijnen@lucent.com; Kessens David (Nokia-NET/MtView) Subject: RE: [Capwap] CAPWAP evaluation draft complete Dorothy and Mani, I just wanted to state that I accept the CAPWAP evaluation draft and its recommendations. I think we can work with the recommendations of the evaluation team and move towards completing the protocol specification. However, I believe that there are a number of issues that need to be addressed in order to arrive at a completed protocol. Some of these issues include: - mandatory/optional protocol components - local MAC/split MAC negotiation - data frame format for tunneling in local MAC mode - application of 802.11e EDCA and admission control (I think there are still some issues) - firmware update Cheers, Mike=20 > -----Original Message----- > From: capwap-admin@frascone.com > [mailto:capwap-admin@frascone.com] On Behalf Of=20 > Dorothy.Gellert@nokia.com > Sent: September 21, 2005 9:34 PM > To: capwap@frascone.com > Cc: mmani@avaya.com; bwijnen@lucent.com; david.kessens@nokia.com;=20 > Dorothy.Gellert@nokia.com > Subject: [Capwap] CAPWAP evaluation draft complete >=20 >=20 > After much hard work, the evaluation team has completed the CAPWAP=20 > evaluation draft. Its is available for review at: > http://www.ietf.org/internet-drafts/draft-ietf-capwap-eval-00. > txt and also in the internet drafts directory. >=20 > The evaluation team concluded that LWAPP is the most complete proposal > and should be used as the basis for CAPWAP protocol moving forward. =20 > In addition, a number of recommendations were made which the=20 > evaluation team believed should be addressed by the working group. >=20 > Over the next 2 weeks the evaluation team will address clarification > questions on the WG list. The recommendation provided by the > evaluation team will not change, as this was intended to be an > independent activity supported by the WG. This is essentially a WGLC > on the evaluation draft. Please submit any clarification question to=20 > the list by Friday, September 30th. >=20 > The next step will be to come to an agreement on the WG list to decide > to accept the recommended protocol. Once we have established=20 > consensus, we can further discuss the additional recommendations=20 > presented in the draft. >=20 > We would like to thank the evaluation team on its thorough work and a=20 > job well done. >=20 > Regards, > Dorothy and Mani >=20 >=20 > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap >=20 _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From moses@aspenfurniture.com Thu Oct 13 18:48:34 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQBsI-0006ye-2m; Thu, 13 Oct 2005 18:48:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24333; Thu, 13 Oct 2005 18:48:29 -0400 (EDT) Received: from c-24-11-180-126.hsd1.mi.comcast.net ([24.11.180.126]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EQC2r-0003tU-I9; Thu, 13 Oct 2005 18:59:31 -0400 Received: (from tomcat@localhost) by 24.11.180.126 (8.12.8/8.12.8/Submit) id j5CHmn0V515155 for capwap-archive@ietf.org; Thu, 13 Oct 2005 17:48:10 -0600 Message-ID: <967v519q.2143345@132.151.6.1> Date: Thu, 13 Oct 2005 17:48:10 -0600 From: "Mayra Norman" X-Mailer: MIME-tools 5.445 (Entity 5.307) MIME-Version: 1.0 To: capwap-archive@ietf.org, ccips@ietf.org, cclark@ietf.org, cdi-archive@ietf.org, cdir-admin@ietf.org, cfrg@ietf.org, cfrg-admin@ietf.org, cfrg-archive@ietf.org, cfrg-bounces@ietf.org, cfrg-web-archive@ietf.org, chair@ietf.org, chiname.cn@ietf.org, chive@ietf.org X-Spam-Score: (-2.716) BAYES_00 X-Scanned-By: MIMEDefang 2.52 on 24.11.180.126 X-Scanned-By: SpamAssassin 3.064868, File::Scan 0.35, Archive::Zip 1.39 X-Recipient: Subject: Re-finance before rates skyrocket Content-Type: multipart/related; boundary="------------AttPart_56533291==.OLA" X-Spam-Score: 4.5 (++++) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c This is a multi-part message in MIME format. --------------AttPart_56533291==.OLA Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
a chang , combatant ! ambivalent and membrane but megavolt , southwest ! dramaturgy or mechanic but bengal may buzzing may bimini or bullhead try benedikt on landlord Or maybe not

--------------AttPart_56533291==.OLA Content-Type: image/gif; name="mutatis.7.gif" Content-ID: <5.0.0.99.0.24431689722691.44828338@yoghurt.yahoo.com.3> Content-Disposition: inline; filename="mutatis.7.gif" Content-Transfer-Encoding: base64 R0lGODlh5gHOALMAAP/////MzP+Zmf9mZv8zM/8AAMzM/8zMzMyZ/5mZ/5mZmZlmzGYzzDMz MzMAzAAAACH5BAAAAAAALAAAAADmAc4AAAT/EMhJq7046827/2AojmRpnmiqrmzrvnAsz3Rt 33iu73zv/8CgcEgsGo/IpHLJbDqf0Kh0Sq2CDo+sIvs4ZLaPCthKLpvP6BPWu95sLe+0fE6v T9ttTZyyt/v/gIE4eF0AWFyFEn2KYRMNiA2CkpOUlRiHXAd5homLAHsNkY6ilqWmp2iEmoiZ jHCNAKEUsqi1trdMqptisBOgpLHAuMPExTm6iZxen72uErTPwsbT1NVqXGBdmFle2VmMiM+Q s9LW5ufoO9Dp7O3u7/Dx8vP09fb3+Pn6+/z9/v8AAwocSLCgwYMI02DKtgzGug1apOyqMubC okflhmCcE5GFJz+q/0R8VPFAgYyHIUr+GYkBZRGXIFQWkakDZouJLEKGYImC5gubHXzS4WkB aBCjHIQGUWoDaQqcK0JuS/aKi7gHobBeBcbKJICuGaZ2Y8Ws5LerWtGSAvsVmwRMyw6BWebt bNEsWbU+4hIpYscL29hgy7SlYtlmwWaNy4DI61RtrBpWtbsXL1qtfmU2DjuYW92yoPdmzUjB Z9eFrSxaBWe4MqnKmLV0BCuWU+qbZresagjVmeJI0KCZLjyBqbIJWPq8GfMrg6zhEpRuOrR7 D09astY992q8gtRCzHt5Cg7Mack8a6ZTxRCHvPa+3L1+lc9Z8AHlYeKA0ks6uvzhOn0h3v83 zY1CTnQq5VaabsgV0ttTuUHGynp8IOaScBMS598l6+HHjG8PwQYfBtIlo4p1iB2Y2Hvzbcgh IoIVBl4jHlYQ3ISknZZIeiZSCM5q7pU3YosuanDigB8mmZgHNAEYoWSqVQhieTgW2ZaO3FDw IArJmbXbB+OVIxx9RRo3kYf6wcJiNERaUCJvDnaB4gahYCckkWbuGKeMY/mmpIFsBvWfAuhB BieUvrX3Wp0HajZoB1326Ut+NKrZXwVN0nfek24gqeSabmpKppZZHhdDpKam+sqnYq4laqYc wolmpQZmt2ibeJpEk3r2HWZXS4wuyWaCecalJ4NJ1qiisMwuWJz/SWLxGqUzQTaqK6zdccLg rKAFKuizzqLaqZSsrngnrsP1aN+WJYhbmx5niejIYmxl+GIrn2WTzbyv8fXcZsXJFG1nVBHF rLwIgjHqW43tOaNsBJIVy2IIkzgYfYTAKOBgsKVVMcT/ZctwQ5+xhtdijAHMlrjskaXvahP3 y9eVf9EWWYM+JtSCwU7Zwe4RP+ss9KQwt5QWJYFFQd3QTDft9NNQRy311FRXbfXVWGet9dZc d+31PQQvDIJhp5ZKxF8zbASRyECgjZDBQcAdU3wpyH0NokuJzYHd3pKo90x/q8A3k4E/MTgP h0NENwqJixC0Dmy3HIJRkedNQ+MaVC4D/2rGwvhypTB3DNzMCG7GlgWoPWyXN/OSnpKGA0uI NyOtkS6aaDR3V1tt+UJMJ70AF7n7zaz/GC/KFwSPpVk5+0rp8xNjpXbmmjaWuoT4Sly80dKn pbxbtt02Q5e6SRuen+QVNWSL0L345aTwA9o34SrxGmBVfwZqJ7piF6rerJRyjpDaRyReqetP +Ekf9ZwFLupAhVuf4o/iwPUsZMjKU3LbyENgNbIGzQ43fDIfYvqgQHlhy16xqlA40FclEQhM XffjBbUoJop/nc47enoM81xGK+dYpnTKc8yEuuAj/ODoVguk4IbYBcECfctKmwrhEO9TtPwJ EFNBxNnNaEA+Q/950IokvFX6sFW4LyYKFmFMwQsPFUNyvUGBwaBF5fzXoRSlqQMb6c4acYg3 ZcmPcqIKV/P8tJweNiuJ/Ovi+1SDxhRdYB0cbNPjQOglEa6qPeNQIFgIiLpkzMkVbzzX6zo4 Mh41745wrJMoOEkqY/0PSXcEFjkIuMeRHbCQCJSe/PzGwCUOMpcfas2legkdVL3SjQHUACQf taFNHYqLspmLWEpGtEfW0F/C0EzwcKgxX6FITcgzT0feJRezqXCH0ZMeEoGYp5vxjocQc2Q6 vaeyzQyvm91y3mWO5ibw5Y5QW2zZCssChopZDHwr8xLDNEbNfD4SZQ0LmRDxSYaeae7/axil h2vW5raMevSjIA2pSEdK0pKa9KQoTalKV8pSQEyypTCNqUxnStOaCg0uC53LxtCJsI1eSWHs LKNNh7q5HnlRch8Clbf8oiErEfWpNpDWg1BZpY+RyZ9QzWpUD7glGc1PWGOymFC1StZ2cXWQ Xj1YsITFyYuW9a0ciN0OP/innmLzdKebyJnkCde+lgBzfg2sEsgm2MIa9rCITaxiF8vYxjr2 sZCNrGQnK4EAFOCyBLhsAQYQhMwS4AKe/QMBPlsBy3K2spo9LQAEoFkBbIC1l3WtBAag2QBM gLaXte0GQisE3Or2tgX4bQh4uwPWypYCtP0tboM7gcwWgLRH//DtBZLrAtYSIADWFW4PBDDa C3AXuicwbhGcC17Lbha1BBAAazm7XgHQ9rgWaO97AfBe7jK3vpnVbgVGq94hBCC/pYUvfZlL ge5W4Ls8gG0B4CvdAasXwPxFcBDEW1kAW4C6LTAtADQsBANbwMPhXTARIuxh86pWALbVsHgp 7F0Ri5e6ML4vgTEA4t7OOAMYbi54dVzczbpXxLPNbZBtS10D13i7QB7ydG+8Aus+N8WavewA YKve2OI4yjKOcgB822AAgNi5mM2AeaM8gDFLebVRFvCBsfxjzNZ2ubklL3FBS9r+bvi55y3t eVec5Pi6WMQxJrKM9dtczUIXzE829P+ZMWDm0yrYyhrI8XKVq2UJgHnHJcayai3QaAk8us9r di12dUtbCwfay6Q9coENLWZFO5rNsHWubB8t21ILGbiERoFlM8vZXau3ygR475ZBDdxf2zez xs5vfv87Yw9HWMKcfu6vE53eaZeZtlPONZqnrN73IpvZP072go8N7fiSdwK7zjO6n4xm17LY z+4G9KAHLGhtf9fOz753rNebAWP72MfdJjZyZ4xdC28Y2cfV935J62tr99va7Q24miu73OPa mtTzNvKOD/xrVXsaz7yOeLhxO4D5DjvbQV6wwXPcguzeWbWm5fPE6Y3uH1N62PXmsaUPvXHU nta0Zk5tu1//m2TjBhrOtUW1u2fu6Qd/1tfqvvN1Px5vpsuc5qdm+YfB++WnsxvFjNb0sGM7 6kgzmeVaV7WBg77oaJN57AsuO6Ml7mAMn1rjGkB0z9GL5ykXfdybxS6Q3z1fSTN5BRzm8Muv vmTtGh7nNN+5zlEd9p8HXtrGtu27W5zwuHtW3sbG994XLvmgW37qVB86Bq6e9XlnoOsF9vqm L9BwfmO3zUxX8sCFm/aerx3zvyZ07c97e9xa/c+uRXrOi5zq0T/b41LvO4uNy3jCuz7yLki8 umMOeIFj/+K4Tm6Xnc3zfot9+3sG/MynL28AP57yHLCvtJvu8l0Ll/GcH3rrc/56/677/+Ub oH1+J2rhZnaOd2PiR2DdBXsA6HO0l2fcR4DzRXvLVWYb9mBAdnfN13+TF22fN4ATQH3IR3Uv dn3YBQNj9mpRdl1jJ2u0h2iex2YH52bBpXerBYOj52/shWVTN3YWSIFiN4OyxWxpZoOvxV8U kIJ3RmYbVoG/xWJwZ4FECGRTmHuX5ml692mzt2aKFmxBuGSVpnwVBmk3OH9etoJotoK59mie hXQ/CIRvOGBCVoVYiFlWd2mqZl6f91xuqGBgJmokB3dghnHaFl7q9YSZV1mHeIhzZ2yK6IiP eHurFXr0B4kawGGh91u3V4i3F3w1l4SUGHq5F4Jq5omTaP+KnfiEgQeKjPiI8NWJr2WJoniK rfhwixgAnViLnEaJF2iJvchxCceLmagBmYdiuQh2l4iMNWdnvQhfvuhdswiNo3aIx4iLwYeK jJiKv/aJ52BmqIcKckdZWpOI4liO5niO6JiO6riO7NiO7viO9/AYdAUONfAXL6VMrDBMWDRW P/FDB9VRLtAzVgCQxDA9ThUCS4MbrrQ3fMUC2XKPf6SPvVQTNdQfjpI2wiCQHrBXN+BWK6CR PQCSHwCRcZVDDGkDD/lLV/RVEwQEQBFJP5GREjmSddSR/MgCIqkOM4mQKuk4OZQ0+uRDM3M7 9IRQ9nQbQAkC6eNTIAMuWpA6qyD/O3UBOlZBlPx0SMQEUBrzTuGgML/yUP6YPNG0UKUClNvz GUS5k70kVwzBSMyjFq1zNPWyTdyUJZ9jPHzlUz8VMDukla3wLlVRO65DKhSlDJ9kTSqiQY/w KsykKiQ5T9IgRwlCN7vCDTzSKyjiIfuzLLzkH+rSIwBkRTaijxFCJv4jQ/EzQ8Chli5iP3FC V+ezLMu0IKwEGJ0QMX6kPskTSPNhQAspUEklSmZkSoTRSCupm3wZUUq0C4+5lPSyOApiRh3U BpmZIpvJkpgyKJ85IVT0K7F0nNSjIORUk0QjMTnJQK7JJ/BiIygDSfaCVbbZTUYkMbIUKlhU P1NkkkgV/0qcSUprkEOHiZwCiitlIh/M2ZOIGQ2aBJ1oc6CY2UgjoUqjmRTaeSindBbfWZ+K kxunqSrAlKAlUEvKoEjrGZG7lC0E2aG5SSflIBRuoVf6OS38uUv+SUSuFKATCiiz+SyR5KD3 WC2BcpHsY6BUYUqSwgw1IqEuFB++2SBN1JC2Ep6F0aGXCUrJRC2smZ2kdBwsg1TespTrMx+1 aSp54EfX0aK86UweFKOrEpz9KY/h4yVTKZSW8TH1ZD0BlZB+Apa2c1fxBFRtURdwwjzduRoN hRKUAzD3lD1dSTC/Y5ERsimD0TmSYRhoiTxYeZ8RMZ7I4paUgU38kpzaBJ+EGf9N9NlQd+GP m/Sniyo+5bkvBrUSDRk3s9qf+nCe8FgH+8IBBpmrvvqrwBqswjqsxFqsxnqsyJqsT6WnJABY yjo0nuCskIKgHyGtz5oQ0Vqrd+MB1aqt1woQnEOWtwkz2yMvaZkyfdklepIa27On35oQJNpK 7ppGOipBnYmfR2VG3fquTEOi75KtipGP2Jmd4vmacXqb08KvOqNIKjpCvQAT5iEj0PKaDZuw CosQDKufuGSlajWwBCtE66KxV3qxQ1NO0tQwdPGVglmnmLqb+DpX24AshGWtJFuzNnuzOJuz OruzPNuzPvuzQBu0Qju0RFu0Rnu0SJu0Sru0TNu0Tvv/tFAbtVI7tVRbtVZ7tVibtVq7tVzb tV67WAbgAGLrAAsQtmN7tmgrtgmQAQsgtgagAW2btmnLAADAAHNrt2hLtx6QAGrLt2oLAH7r AGsLt2f7tgAQtw7wtnZLt3jLuGfruA7AAHibtgsAAGaLtpXrt4MbuGebAJwruBKAuG8btwYg uhnQuBLQuKh7uZV7uY8rt5V7AZ+bAKRruhZAuofrtpMbuXXLu7srtpP7u8ALu7M7AXw7uP8Q tgzguXy7AHy7vJ47tgvQttMLuhhgAHZruNdrt8zLvZLbvQyAAN/ruZIrvtCbAJL7AaUruOtb ts1Lu9Z7AW3bvYk7v+ibuOYL/wDma77Mi77hW777G73L+7bK+7zNa7nzKwHNS73zawDw67yj K7j3awDYm7gVjLwWML7pu7/7W8DNW8CR+74hHL2xawEOTL0JQMHZe8Hbm7i5u7YI4L8JgAD6 u8Hl+7wOHLkgvLxka8DRK7bO67kJDLjx2w/Kq70pHLYlnMJMzL4pTLjaiwFta7gOXLd6a8VY LAEIQMPpq8U0/AGae7wfjMBFPAFDbLnwO7gVXMGM28YUsMVZ3MVKTAFJTLaAa7jHKwEOnMNM jMfWO8RrXLsufAHlq8Xp28WSe8QK3MMUbMd1vMRRbAF5HLpuO8VsO7yDnMWp67t0O8dz/Mh3 PMcKPP/JaOzHGMwPokwBSpzKRHzK8hu5mfzK62u4XYzFh3zFtywCYSzB8UvKFGDJv5zJU7y4 tnzFFIDIesvKemzHxgvLGOzLrUzJ2jvFghzJE1DLxZy6DJDKoszNZKvMshu/1XzJsJzJ2EzM 6evJzGy567zKjlzGzezK+gDOrlvC0bwBbZu9hDu2tPy4XDy2uAzQugzL3EvK0CzNFQDMuYu9 ktvQNfy42hzR7GzPy2zPz1vE0DzJCk3NBB3Lx2zMuWzF3hy73iy9HEDK+QzL1mzGHa2959zQ 6WzHIz0B9UzGnRvPAKHOQAzCFg3PCc2++izFghvU31vIVuy/17y82Ly3ghv/t9GLvAe90D89 zYlbvsSsv/0b0nK8zjS9zh98xhn9x8Jcvw4gvm6LAS8dx9vczszszTxM0eGMvG1r1h4dzItr ziD9v7yrziXs1geMxsw7xFGdD6JMwp8cxYPN0oV7yRSMvCGNxXAc0ZENAmLct73s0wqN0NJ8 yLybwW6cxfTs1WgL1WWs0WM9y7hLyHmt1jM90V2duStdAShN1nXN0jGs0GlNzHz92rz9xJJs vYmND3/tziTNzMH9whPM2BVgw3pby4+91BtwvOubwgk8xiYc1MPswgnM3JqczaAt020t2s4L 1qVtvWv8wgt93heQv1bMxc1NtwesyK5d0fSdAbOt/8K1jdC4vdr5u9v1Pd+XS9pq7NsAwblr TblE/LdCjcm1jbiDjLqLK7ySO7f/Hc6Wvbbru9MZUMFji+GTu7YQTrd0Dbw0TNfh67omzboJ Xs6gG7ibO9qW++G5W8n5/dCR+8Um/sWBu83LDMTsjOAW3uGim9nBzOAcDry9y8mLDLxUnOJy ywAO/s2LLM/80L9v27/MS8BZvuFZzrzX278TEMMzjNVbjOUzLOb9S8Py/eWe29hUvOUa4MBe rsdzLuYljuNpHuaeq+NmjsdtDthM/Ody7tuD/ueATueei8YbEOGdbed0bOij7NtmTuAVUOhJ 7OVVzOaBDsN57uiTDeeR7v/nWN7YVk7TlL5Ypz4QMVzmX/y1rs40MB3rsj7rtF7rtn7ruJ7r ur7rvN7rvv7rwB7swj7sxF7sxm7rcP3qyr7szN7szv7s0B7t0j7t1F7t1n7t2J7t2r7t3N7t 3v7t4B7u4j7u5F7u5n7u6A60cNqPLesChJXuSsOmHQA3cBQDNAvvO9ChYFKr9Q4D947vx/CT xKM9A6WhNjQbyxMnEDMWK4SqAG8EA3NByIRH45AujVmjkDEnK/rwQ0BH3LmrqalMq8lOY+lL 3bQJnwTyHI8EdPRBlsrvI0+gbaKmZOpJxqlCK8/yOQSaGDSyyLkdzqIjv4nyxrnxOe8DcMqV RfPV7gE7On1Bly0Ss0QknxMSlB579LfgkUqZpVgfCFDf9WAf9mI/9mRf9mZ/9u+YlP14KQSJ 9mbwmFtPoSbw726fEwhqAkih9SFf9x2/royKob7DopJ5LdxxlDAClb7C90QQILuQJj6vPmGV Kzz6TA40GXA9BBkTGSWToT+/StkfkbzpoXR/+SPwHVCS8obEp97toypvm6fvraQPA6bvpDfP +TkqR4RfoGfUJzYZ+zWAU+KqOpGKTmCZRRU0PFM5sYcfUA7l+8rI7tAf/dI//dRf/dZPUhEA ADs= --------------AttPart_56533291==.OLA-- From jeffa@ihep.com Thu Oct 13 18:49:46 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQBtS-0007cJ-A1; Thu, 13 Oct 2005 18:49:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24799; Thu, 13 Oct 2005 18:49:41 -0400 (EDT) Received: from pool-71-96-164-100.dfw.dsl-w.verizon.net ([71.96.164.100]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EQC42-000464-6T; Thu, 13 Oct 2005 19:00:43 -0400 Received: (from tomcat@localhost) by 71.96.164.100 (8.12.8/8.12.8/Submit) id j7CHmn4V445277 for capwap-archive@ietf.org; Thu, 13 Oct 2005 17:49:38 -0600 Message-ID: <605f110d.4248231@132.151.6.1> Date: Thu, 13 Oct 2005 17:49:38 -0600 From: "Ward Pierce" X-Mailer: MIME-tools 5.422 (Entity 5.322) MIME-Version: 1.0 To: capwap-archive@ietf.org X-Spam-Score: (-2.865) BAYES_00 X-Scanned-By: MIMEDefang 2.52 on 71.96.164.100 X-Scanned-By: SpamAssassin 3.396295, File::Scan 0.98, Archive::Zip 1.42 X-Recipient: Subject: Your account #157499238 Content-Type: multipart/related; boundary="------------AttPart_76046893==.OLA" X-Spam-Score: 2.0 (++) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c This is a multi-part message in MIME format. --------------AttPart_76046893==.OLA Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
! dangerous try boylston on bichromate it's bloc it irene the amplify try boat try bless the rattlesnake , invention try doric and clown in christine see procession Or maybe not

--------------AttPart_76046893==.OLA Content-Type: image/gif; name="cambridge.1.gif" Content-ID: <1.0.0.02.0.58427304591691.96779240@procreate.hotmail.com.4> Content-Disposition: inline; filename="cambridge.1.gif" Content-Transfer-Encoding: base64 R0lGODlh5gHOALMAAP/////MzP+Zmf9mZv8zM/8AAMzM/8zMzMyZ/5mZ/5mZmZlmzGYzzDMz MzMAzAAAACH5BAAAAAAALAAAAADmAc4AAAT/EMhJq7046827/2AojmRpnmiqrmzrvnAsz3Rt 33iu73zv/8CgcEgsGo/IpHLJbDqf0Kh0Sq2CDo+sIvs4ZLaPCthKLpvP6BPWu95sLe+0fE6v T9ttTZyyt/v/gIE4eF0AWFyFEn2KYRMNiA2CkpOUlRiHXAd5homLAHsNkY6ilqWmp2iEmoiZ jHCNAKEUsqi1trdMqptisBOgpLHAuMPExTm6iZxen72uErTPwsbT1NVqXGBdmFle2VmMiM+Q s9LW5ufoO9Dp7O3u7/Dx8vP09fb3+Pn6+/z9/v8AAwocSLCgwYMI02DKtgzGug1apOyqMubC okflhmCcE5GFJz+q/0R8VPFAgYyHIUr+GYkBZRGXIFQWkakDZouJLEKGYImC5gubHXzS4WkB aBCjHIQGUWoDaQqcK0JuS/aKi7gHobBeBcbKJICuGaZ2Y8Ws5LerWtGSAvsVmwRMyw6BWebt bNEsWbU+4hIpYscL29hgy7SlYtlmwWaNy4DI61RtrBpWtbsXL1qtfmU2DjuYW92yoPdmzUjB Z9eFrSxaBWe4MqnKmLV0BCuWU+qbZresagjVmeJI0KCZLjyBqbIJWPq8GfMrg6zhEpRuOrR7 D09astY992q8gtRCzHt5Cg7Mack8a6ZTxRCHvPa+3L1+lc9Z8AHlYeKA0ks6uvzhOn0h3v83 zY1CTnQq5VaabsgV0ttTuUHGynp8IOaScBMS598l6+HHjG8PwQYfBtIlo4p1iB2Y2Hvzbcgh IoIVBl4jHlYQ3ISknZZIeiZSCM5q7pU3YosuanDigB8mmZgHNAEYoWSqVQhieTgW2ZaO3FDw IArJmbXbB+OVIxx9RRo3kYf6wcJiNERaUCJvDnaB4gahYCckkWbuGKeMY/mmpIFsBvWfAuhB BieUvrX3Wp0HajZoB1326Ut+NKrZXwVN0nfek24gqeSabmpKppZZHhdDpKam+sqnYq4laqYc wolmpQZmt2ibeJpEk3r2HWZXS4wuyWaCecalJ4NJ1qiisMwuWJz/SWLxGqUzQTaqK6zdccLg rKAFKuizzqLaqZSsrngnrsP1aN+WJYhbmx5niejIYmxl+GIrn2WTzbyv8fXcZsXJFG1nVBHF rLwIgjHqW43tOaNsBJIVy2IIkzgYfYTAKOBgsKVVMcT/ZctwQ5+xhtdijAHMlrjskaXvahP3 y9eVf9EWWYM+JtSCwU7Zwe4RP+ss9KQwt5QWJYFFQd3QTDft9NNQRy311FRXbfXVWGet9dZc d+31PQQvDIJhp5ZKxF8zbASRyECgjZDBQcAdU3wpyH0NokuJzYHd3pKo90x/q8A3k4E/MTgP h0NENwqJixC0Dmy3HIJRkedNQ+MaVC4D/2rGwvhypTB3DNzMCG7GlgWoPWyXN/OSnpKGA0uI NyOtkS6aaDR3V1tt+UJMJ70AF7n7zaz/GC/KFwSPpVk5+0rp8xNjpXbmmjaWuoT4Sly80dKn pbxbtt02Q5e6SRuen+QVNWSL0L345aTwA9o34SrxGmBVfwZqJ7piF6rerJRyjpDaRyReqetP +Ekf9ZwFLupAhVuf4o/iwPUsZMjKU3LbyENgNbIGzQ43fDIfYvqgQHlhy16xqlA40FclEQhM XffjBbUoJop/nc47enoM81xGK+dYpnTKc8yEuuAj/ODoVguk4IbYBcECfctKmwrhEO9TtPwJ EFNBxNnNaEA+Q/950IokvFX6sFW4LyYKFmFMwQsPFUNyvUGBwaBF5fzXoRSlqQMb6c4acYg3 ZcmPcqIKV/P8tJweNiuJ/Ovi+1SDxhRdYB0cbNPjQOglEa6qPeNQIFgIiLpkzMkVbzzX6zo4 Mh41745wrJMoOEkqY/0PSXcEFjkIuMeRHbCQCJSe/PzGwCUOMpcfas2legkdVL3SjQHUACQf taFNHYqLspmLWEpGtEfW0F/C0EzwcKgxX6FITcgzT0feJRezqXCH0ZMeEoGYp5vxjocQc2Q6 vaeyzQyvm91y3mWO5ibw5Y5QW2zZCssChopZDHwr8xLDNEbNfD4SZQ0LmRDxSYaeae7/axil h2vW5raMevSjIA2pSEdK0pKa9KQoTalKV8pSQEyypTCNqUxnStOaCg0uC53LxtCJsI1eSWHs LKNNh7q5HnlRch8Clbf8oiErEfWpNpDWg1BZpY+RyZ9QzWpUD7glGc1PWGOymFC1StZ2cXWQ Xj1YsITFyYuW9a0ciN0OP/innmLzdKebyJnkCde+lgBzfg2sEsgm2MIa9rCITaxiF8vYxjr2 sZCNrGQnK4EAFOCyBLhsAQYQhMwS4AKe/QMBPlsBy3K2spo9LQAEoFkBbIC1l3WtBAag2QBM gLaXte0GQisE3Or2tgX4bQh4uwPWypYCtP0tboM7gcwWgLRH//DtBZLrAtYSIADWFW4PBDDa C3AXuicwbhGcC17Lbha1BBAAazm7XgHQ9rgWaO97AfBe7jK3vpnVbgVGq94hBCC/pYUvfZlL ge5W4Ls8gG0B4CvdAasXwPxFcBDEW1kAW4C6LTAtADQsBANbwMPhXTARIuxh86pWALbVsHgp 7F0Ri5e6ML4vgTEA4t7OOAMYbi54dVzczbpXxLPNbZBtS10D13i7QB7ydG+8Aus+N8WavewA YKve2OI4yjKOcgB822AAgNi5mM2AeaM8gDFLebVRFvCBsfxjzNZ2ubklL3FBS9r+bvi55y3t eVec5Pi6WMQxJrKM9dtczUIXzE829P+ZMWDm0yrYyhrI8XKVq2UJgHnHJcayai3QaAk8us9r di12dUtbCwfay6Q9coENLWZFO5rNsHWubB8t21ILGbiERoFlM8vZXau3ygR475ZBDdxf2zez xs5vfv87Yw9HWMKcfu6vE53eaZeZtlPONZqnrN73IpvZP072go8N7fiSdwK7zjO6n4xm17LY z+4G9KAHLGhtf9fOz753rNebAWP72MfdJjZyZ4xdC28Y2cfV935J62tr99va7Q24miu73OPa mtTzNvKOD/xrVXsaz7yOeLhxO4D5DjvbQV6wwXPcguzeWbWm5fPE6Y3uH1N62PXmsaUPvXHU nta0Zk5tu1//m2TjBhrOtUW1u2fu6Qd/1tfqvvN1Px5vpsuc5qdm+YfB++WnsxvFjNb0sGM7 6kgzmeVaV7WBg77oaJN57AsuO6Ml7mAMn1rjGkB0z9GL5ykXfdybxS6Q3z1fSTN5BRzm8Muv vmTtGh7nNN+5zlEd9p8HXtrGtu27W5zwuHtW3sbG994XLvmgW37qVB86Bq6e9XlnoOsF9vqm L9BwfmO3zUxX8sCFm/aerx3zvyZ07c97e9xa/c+uRXrOi5zq0T/b41LvO4uNy3jCuz7yLki8 umMOeIFj/+K4Tm6Xnc3zfot9+3sG/MynL28AP57yHLCvtJvu8l0Ll/GcH3rrc/56/677/+Ub oH1+J2rhZnaOd2PiR2DdBXsA6HO0l2fcR4DzRXvLVWYb9mBAdnfN13+TF22fN4ATQH3IR3Uv dn3YBQNj9mpRdl1jJ2u0h2iex2YH52bBpXerBYOj52/shWVTN3YWSIFiN4OyxWxpZoOvxV8U kIJ3RmYbVoG/xWJwZ4FECGRTmHuX5ml692mzt2aKFmxBuGSVpnwVBmk3OH9etoJotoK59mie hXQ/CIRvOGBCVoVYiFlWd2mqZl6f91xuqGBgJmokB3dghnHaFl7q9YSZV1mHeIhzZ2yK6IiP eHurFXr0B4kawGGh91u3V4i3F3w1l4SUGHq5F4Jq5omTaP+KnfiEgQeKjPiI8NWJr2WJoniK rfhwixgAnViLnEaJF2iJvchxCceLmagBmYdiuQh2l4iMNWdnvQhfvuhdswiNo3aIx4iLwYeK jJiKv/aJ52BmqIcKckdZWpOI4liO5niO6JiO6riO7NiO7viO9/AYdAUONfAXL6VMrDBMWDRW P/FDB9VRLtAzVgCQxDA9ThUCS4MbrrQ3fMUC2XKPf6SPvVQTNdQfjpI2wiCQHrBXN+BWK6CR PQCSHwCRcZVDDGkDD/lLV/RVEwQEQBFJP5GREjmSddSR/MgCIqkOM4mQKuk4OZQ0+uRDM3M7 9IRQ9nQbQAkC6eNTIAMuWpA6qyD/O3UBOlZBlPx0SMQEUBrzTuGgML/yUP6YPNG0UKUClNvz GUS5k70kVwzBSMyjFq1zNPWyTdyUJZ9jPHzlUz8VMDukla3wLlVRO65DKhSlDJ9kTSqiQY/w KsykKiQ5T9IgRwlCN7vCDTzSKyjiIfuzLLzkH+rSIwBkRTaijxFCJv4jQ/EzQ8Chli5iP3FC V+ezLMu0IKwEGJ0QMX6kPskTSPNhQAspUEklSmZkSoTRSCupm3wZUUq0C4+5lPSyOApiRh3U BpmZIpvJkpgyKJ85IVT0K7F0nNSjIORUk0QjMTnJQK7JJ/BiIygDSfaCVbbZTUYkMbIUKlhU P1NkkkgV/0qcSUprkEOHiZwCiitlIh/M2ZOIGQ2aBJ1oc6CY2UgjoUqjmRTaeSindBbfWZ+K kxunqSrAlKAlUEvKoEjrGZG7lC0E2aG5SSflIBRuoVf6OS38uUv+SUSuFKATCiiz+SyR5KD3 WC2BcpHsY6BUYUqSwgw1IqEuFB++2SBN1JC2Ep6F0aGXCUrJRC2smZ2kdBwsg1TespTrMx+1 aSp54EfX0aK86UweFKOrEpz9KY/h4yVTKZSW8TH1ZD0BlZB+Apa2c1fxBFRtURdwwjzduRoN hRKUAzD3lD1dSTC/Y5ERsimD0TmSYRhoiTxYeZ8RMZ7I4paUgU38kpzaBJ+EGf9N9NlQd+GP m/Sniyo+5bkvBrUSDRk3s9qf+nCe8FgH+8IBBpmrvvqrwBqswjqsxFqsxnqsyJqsT6WnJABY yjo0nuCskIKgHyGtz5oQ0Vqrd+MB1aqt1woQnEOWtwkz2yMvaZkyfdklepIa27On35oQJNpK 7ppGOipBnYmfR2VG3fquTEOi75KtipGP2Jmd4vmacXqb08KvOqNIKjpCvQAT5iEj0PKaDZuw CosQDKufuGSlajWwBCtE66KxV3qxQ1NO0tQwdPGVglmnmLqb+DpX24AshGWtJFuzNnuzOJuz OruzPNuzPvuzQBu0Qju0RFu0Rnu0SJu0Sru0TNu0Tvv/tFAbtVI7tVRbtVZ7tVibtVq7tVzb tV67WAbgAGLrAAsQtmN7tmgrtgmQAQsgtgagAW2btmnLAADAAHNrt2hLtx6QAGrLt2oLAH7r AGsLt2f7tgAQtw7wtnZLt3jLuGfruA7AAHibtgsAAGaLtpXrt4MbuGebAJwruBKAuG8btwYg uhnQuBLQuKh7uZV7uY8rt5V7AZ+bAKRruhZAuofrtpMbuXXLu7srtpP7u8ALu7M7AXw7uP8Q tgzguXy7AHy7vJ47tgvQttMLuhhgAHZruNdrt8zLvZLbvQyAAN/ruZIrvtCbAJL7AaUruOtb ts1Lu9Z7AW3bvYk7v+ibuOYL/wDma77Mi77hW777G73L+7bK+7zNa7nzKwHNS73zawDw67yj K7j3awDYm7gVjLwWML7pu7/7W8DNW8CR+74hHL2xawEOTL0JQMHZe8Hbm7i5u7YI4L8JgAD6 u8Hl+7wOHLkgvLxka8DRK7bO67kJDLjx2w/Kq70pHLYlnMJMzL4pTLjaiwFta7gOXLd6a8VY LAEIQMPpq8U0/AGae7wfjMBFPAFDbLnwO7gVXMGM28YUsMVZ3MVKTAFJTLaAa7jHKwEOnMNM jMfWO8RrXLsufAHlq8Xp28WSe8QK3MMUbMd1vMRRbAF5HLpuO8VsO7yDnMWp67t0O8dz/Mh3 PMcKPP/JaOzHGMwPokwBSpzKRHzK8hu5mfzK62u4XYzFh3zFtywCYSzB8UvKFGDJv5zJU7y4 tnzFFIDIesvKemzHxgvLGOzLrUzJ2jvFghzJE1DLxZy6DJDKoszNZKvMshu/1XzJsJzJ2EzM 6evJzGy567zKjlzGzezK+gDOrlvC0bwBbZu9hDu2tPy4XDy2uAzQugzL3EvK0CzNFQDMuYu9 ktvQNfy42hzR7GzPy2zPz1vE0DzJCk3NBB3Lx2zMuWzF3hy73iy9HEDK+QzL1mzGHa2959zQ 6WzHIz0B9UzGnRvPAKHOQAzCFg3PCc2++izFghvU31vIVuy/17y82Ly3ghv/t9GLvAe90D89 zYlbvsSsv/0b0nK8zjS9zh98xhn9x8Jcvw4gvm6LAS8dx9vczszszTxM0eGMvG1r1h4dzItr ziD9v7yrziXs1geMxsw7xFGdD6JMwp8cxYPN0oV7yRSMvCGNxXAc0ZENAmLct73s0wqN0NJ8 yLybwW6cxfTs1WgL1WWs0WM9y7hLyHmt1jM90V2duStdAShN1nXN0jGs0GlNzHz92rz9xJJs vYmND3/tziTNzMH9whPM2BVgw3pby4+91BtwvOubwgk8xiYc1MPswgnM3JqczaAt020t2s4L 1qVtvWv8wgt93heQv1bMxc1NtwesyK5d0fSdAbOt/8K1jdC4vdr5u9v1Pd+XS9pq7NsAwblr TblE/LdCjcm1jbiDjLqLK7ySO7f/Hc6Wvbbru9MZUMFji+GTu7YQTrd0Dbw0TNfh67omzboJ Xs6gG7ibO9qW++G5W8n5/dCR+8Um/sWBu83LDMTsjOAW3uGim9nBzOAcDry9y8mLDLxUnOJy ywAO/s2LLM/80L9v27/MS8BZvuFZzrzX278TEMMzjNVbjOUzLOb9S8Py/eWe29hUvOUa4MBe rsdzLuYljuNpHuaeq+NmjsdtDthM/Ody7tuD/ueATueei8YbEOGdbed0bOij7NtmTuAVUOhJ 7OVVzOaBDsN57uiTDeeR7v/nWN7YVk7TlL5Ypz4QMVzmX/y1rs40MB3rsj7rtF7rtn7ruJ7r ur7rvN7rvv7rwB7swj7sxF7sxm7rcP3qyr7szN7szv7s0B7t0j7t1F7t1n7t2J7t2r7t3N7t 3v7t4B7u4j7u5F7u5n7u6A60cNqPLesChJXuSsOmHQA3cBQDNAvvO9ChYFKr9Q4D947vx/CT xKM9A6WhNjQbyxMnEDMWK4SqAG8EA3NByIRH45AujVmjkDEnK/rwQ0BH3LmrqalMq8lOY+lL 3bQJnwTyHI8EdPRBlsrvI0+gbaKmZOpJxqlCK8/yOQSaGDSyyLkdzqIjv4nyxrnxOe8DcMqV RfPV7gE7On1Bly0Ss0QknxMSlB579LfgkUqZpVgfCFDf9WAf9mI/9mRf9mZ/9u+YlP14KQSJ 9mbwmFtPoSbw726fEwhqAkih9SFf9x2/royKob7DopJ5LdxxlDAClb7C90QQILuQJj6vPmGV Kzz6TA40jDfzBBkTGSWToT+/StX9p8zpoXR/+SPwHVCS8obEp97OIDBvm6fvraQPA6bvpDfP +TkqR4RfoGfMuOEZ+zWAU+KqOpGKTmCZ9RWvPFM5sYcfUA7l+8zn91Af/dI//dRf/dZPUhEA ADs= --------------AttPart_76046893==.OLA-- From capwap-admin@frascone.com Fri Oct 14 13:35:43 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQTT4-00045U-RH for capwap-archive@megatron.ietf.org; Fri, 14 Oct 2005 13:35:43 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02098 for ; Fri, 14 Oct 2005 13:35:28 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 45DDD20437; Fri, 14 Oct 2005 13:35:05 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from SMTP5.centerbeam.com (smtp5.centerbeam.com [64.95.100.154]) by mail.frascone.com (Postfix) with ESMTP id E060B202A3 for ; Fri, 14 Oct 2005 13:34:04 -0400 (EDT) Received: from CBA0E2K01.CBA0.centerbeam.com ([64.95.101.24]) by SMTP5.centerbeam.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 14 Oct 2005 10:25:50 -0700 Received: from CBA0E2K06.CBA0.centerbeam.com ([64.95.101.40]) by CBA0E2K01.CBA0.centerbeam.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 14 Oct 2005 10:31:15 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5D0E5.15507B53" Subject: RE: [Capwap] Change Request 9.1.3.1. Support for Local MAC User Data Tunneling Message-ID: Thread-Topic: [Capwap] Change Request 9.1.3.1. Support for Local MAC User Data Tunneling Thread-Index: AcXEZkqBuwf+LMdnQ8KyHVKiUjMwyAA02ebAAAHWmtAAJ8HLcAAM1MswASFdofABkSUkgA== From: "Darren Loher" To: "Sadot, Emek (Emek)" , "Pat Calhoun (pacalhou)" , , "Puneet Agarwal" , "Michael Montemurro" , "Saravanan Govindan" , "Dan Harkins" X-OriginalArrivalTime: 14 Oct 2005 17:31:15.0127 (UTC) FILETIME=[13FB9470:01C5D0E5] 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-Unsubscribe: , List-Id: A list for CAPWAP technical discussions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 14 Oct 2005 10:31:16 -0700 This is a multi-part message in MIME format. ------_=_NextPart_001_01C5D0E5.15507B53 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable The evaluation draft made a strongly recommendation that an option for a Local-MAC mode with user data tunneling be explored on by the working group. The eval draft listed a few reasons why it might be worth having such a solution. I heard support for such a solution from members of the working group off and on the mailing list. In addition, it appears to be an innovative solution which CTP and SLAPP allowed for in some way. =20 There are many details that need to be specified for exactly how this would work which we are starting to talk about. However, it is useful to hear from the WG at large if a capability like this is necessary. =20 =20 Is a capability for tunneling of user data in 802.3 format for Local MAC mode needed? =20 =20 -Darren =20 =20 ________________________________ From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Sadot, Emek (Emek) Sent: Thursday, October 06, 2005 11:18 AM To: Pat Calhoun (pacalhou); capwap@frascone.com Subject: RE: [Capwap] Change Request 9.1.3.1. Support for Local MAC User Data Tunneling =20 Pat, =20 Yes, that's how I interpreted it, with a disclaimer for 802.11 control and management frames only. It goes for option #3 and #2. =20 Regards, Emek =20 ________________________________ From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com]=20 Sent: Saturday, October 01, 2005 4:26 PM To: Sadot, Emek (Emek); capwap@frascone.com Subject: RE: [Capwap] Change Request 9.1.3.1. Support for Local MAC User Data Tunneling Emek, =20 In option 3, when a user associates with the WTP, the association is handled locally, but the packet is tunneled to the AC in order for the AC to have access to usage information (and make overriding policy decisions). So 802.11 needs to be supported on the AC regardless, right? =20 Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 =20 =09 ________________________________ From: Sadot, Emek (Emek) [mailto:esadot@avaya.com]=20 Sent: Friday, September 30, 2005 10:16 AM To: Pat Calhoun (pacalhou); capwap@frascone.com Subject: RE: [Capwap] Change Request 9.1.3.1. Support for Local MAC User Data Tunneling Regarding the points you raised I believe option #2 and #3 share the same qualities. In both options 802.11 encryption and 11e cannot be implemented at the AC. In both options a mechanism shall be design to extract RF and data-traffic statistics either (a) appended in the tunneling (option #3 only) or (b) exposed by the WTP as read-only values for the AC inquiries (both options). =20 Am I missing something? =20 On the other hand one can respect the unique merits that these options offer: - option 2: non-appliance product. meaning a software based AC that can be executed on any server / platform. - option 3: avoid parse 802.11 traffic in silicon at the AC. Leverage existing products (e.g. routers) with "only" add-on 802.11 code running at the Cpu. =20 Emek =20 =09 ________________________________ From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com]=20 Sent: Thursday, September 29, 2005 6:01 PM To: Sadot, Emek (Emek); capwap@frascone.com Subject: RE: [Capwap] Change Request 9.1.3.1. Support for Local MAC User Data Tunneling In terms of option 2, no traffic is sent to the AC, so the model is quite different. =20 Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 =20 =09 ________________________________ From: Sadot, Emek (Emek) [mailto:esadot@avaya.com]=20 Sent: Thursday, September 29, 2005 2:16 PM To: Pat Calhoun (pacalhou); capwap@frascone.com Subject: RE: [Capwap] Change Request 9.1.3.1. Support for Local MAC User Data Tunneling Pat, you certainly raise valid questions w.r.t. option #3, however I am curious as to the differences between the challenges you listed between options #2 and #3. In other words, in what sense option #2 and #3 are differ w.r.t. encryption and 11e at the AC, as well as RSSI/SNR/data-rate/other monitoring support? =20 Regards, Emek =20 =09 ________________________________ From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Pat Calhoun (pacalhou) Sent: Wednesday, September 28, 2005 5:32 PM To: capwap@frascone.com Subject: [Capwap] Change Request 9.1.3.1. Support for Local MAC User Data Tunneling This change request is to allow for 802.3 tunneling of user data in local bridging mode. I believe that the changes should be relatively straightforward, but do introduce an interesting set of complications that need to be evaluated and agreed upon as a group. =20 The LWAPP protocol currently allows for 802.11 tunneling in Split-MAC mode, allowing for such things as centralized encryption of user data frames. However, the current definition of the protocol is that when running in Local-MAC mode, no traffic is tunneled to the controller. =20 If we were to introduce this change, the LWAPP protocol would have three modes of operation: 1. Split-MAC: Tunnel native MAC frames in UDP (e.g., 802.11) 2. Local-MAC w/ Local Bridge: Do not tunnel 802.3 frames 3. Local-MAC w/ Tunnel: Tunnel 802.3 frames in UDP =20 The issue that we need to decide as a group is whether we really want a protocol that has three modes of operation, and if so, which one is mandatory. The evaluation draft states that option 3 is useful for support of non 802.11 technologies, but this introduces a set of restrictions. For instance, today the LWAPP protocol allows for centralized control of various 802.11 functions, including encryption and 802.11e. This function is not possible with option 3, and therefore any new technology that assumes this option would not be able to provide centralization of data frame functions. =20 There is a comment in the recommendation that LWAPP could retain the RSSI/SNR fields, and then perform 802.3 encapsulation, allowing the AC to have more visibility. However, I have had some requests to expand these fields to also include the data rate. Further, there are possible fields in the header (of technologies we know nothing about) that the WTP may want to extract and expose to the AC - and how could this be done with 802.3? Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 ------_=_NextPart_001_01C5D0E5.15507B53 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

The evaluation draft made a strongly= recommendation that an option for a Local-MAC mode with user data tunneling be explored = on by the working group.  The eval draft listed a few reasons why it might= be worth having such a solution.  I heard support for such a solution from me= mbers of the working group off and on the mailing list.   In addition, it ap= pears to be an innovative solution which CTP and SLAPP allowed for in some way.

 

There are many details that need to = be specified for exactly how this would work which we are starting to talk a= bout.  However, it is useful to hear from the WG at large if a capability like t= his is necessary. 

 

Is a capability for tunneling of use= r data in 802.3 format for Local MAC mode needed? 

 

-Darren

=

 

 

From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Sadot, Emek (Emek)
= Sent: Thursday, October 06= , 2005 11:18 AM
To: Pat Calhoun (pacalhou)= ; capwap@frascone.com
Subject: RE: [Capwap] Chan= ge Request 9.1.3.1. Support for Local MAC User Data Tunneling<= o:p>

 

Pat,

 

Yes, that's how I interpreted it, wi= th a disclaimer for 802.11 control and management frames only.<= /span>

It goes for option #3 and #2= =2E

 

Regards,

Emek

 

From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com]
Sent: Saturday, October 01= , 2005 4:26 PM
To: Sadot, Emek (Emek); capwap@frascone.com
Subject: RE: [Capwap] Chan= ge Request 9.1.3.1. Support for Local MAC User Data Tunneling<= o:p>

Emek,

 

In option 3, when a user associates = with the WTP, the association is handled locally, but the packet is tunneled t= o the AC in order for the AC to have access to usage information (and make over= riding policy decisions). So 802.11 needs to be supported on the AC regardless, = right?

 

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems

 

 

From: Sadot, Emek (Emek) [mailto:esadot@avaya.com]
Sent: Friday, September 30= , 2005 10:16 AM
To: Pat Calhoun (pacalhou)= ; capwap@frascone.com
Subject: RE: [Capwap] Chan= ge Request 9.1.3.1. Support for Local MAC User Data Tunneling<= o:p>

Regarding the points you raised I be= lieve option #2 and #3 share the same qualities.

In both options 802.11 encryption an= d 11e cannot be implemented at the AC.

In both options a mechanism sha= ll be design to extract RF and data-traffic statistics either (a) appended= in the tunneling (option #3 only) or (b) exposed by the WTP as read-onl= y values for the AC inquiries (both options).<= /o:p>

 

Am I missing something?

 

On the other hand one can respect th= e unique merits that these options offer:

=

- option 2: non-appliance product. m= eaning a software based AC that can be executed on any server / platform.=

- option 3: avoid parse 802.11 traff= ic in silicon at the AC. Leverage existing products (e.g. routers) with "only" add-on 802.11 code running at the Cpu.

 

Emek

 

From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com]
Sent: Thursday, September = 29, 2005 6:01 PM
To: Sadot, Emek (Emek); capwap@frascone.com
Subject: RE: [Capwap] Chan= ge Request 9.1.3.1. Support for Local MAC User Data Tunneling<= o:p>

In terms of option 2, no traffic is = sent to the AC, so the model is quite different.

 

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems

 

 

From: Sadot, Emek (Emek) [mailto:esadot@avaya.com]
Sent: Thursday, September = 29, 2005 2:16 PM
To: Pat Calhoun (pacalhou)= ; capwap@frascone.com
Subject: RE: [Capwap] Chan= ge Request 9.1.3.1. Support for Local MAC User Data Tunneling<= o:p>

Pat, you certainly raise valid quest= ions w.r.t. option #3, however I am curious as to the differences between= the challenges you listed between options #2 and #3. In other words, in = what sense option #2 and #3 are differ w.r.t. encryption and 11e at the A= C, as well as RSSI/SNR/data-rate/other monitoring support?

 

Regards,

Emek

 

From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Pat Calhoun (pacalhou)=
Sent: Wednesday, September= 28, 2005 5:32 PM
To: capwap@frascone.com Subject: [Capwap] Change R= equest 9.1.3.1. Support for Local MAC User Data Tunneling

This change request is to allow for 802.3 tunneling of= user data in local bridging mode. I believe that the changes should be relativ= ely straightforward, but do introduce an interesting set of complications tha= t need to be evaluated and agreed upon as a group.

 

The LWAPP protocol currently allows for 802.11 tunneli= ng in Split-MAC mode, allowing for such things as centralized encryption of use= r data frames. However, the current definition of the protocol is that when runn= ing in Local-MAC mode, no traffic is tunneled to the controller.

 

If we were to introduce this change, the LWAPP protoco= l would have three modes of operation:

1. Split-MAC: Tunnel native MAC frames in UD= P (e.g., 802.11)

2. Local-MAC w/ Local Bridge: Do not tu= nnel 802.3 frames

3. Local-MAC w/ Tunnel: Tunnel 802.3 frames in UDP

 

The issue that we need to decide as a group is whether= we really want a protocol that has three modes of operation, and if so, whic= h one is mandatory. The evaluation draft states that option 3 is useful for sup= port of non 802.11 technologies, but this introduces a set of restrictions. Fo= r instance, today the LWAPP protocol allows for centralized control of vari= ous 802.11 functions, including encryption and 802.11e. This function is= not possible with option 3, and therefore any new technology that assumes thi= s option would not be able to provide centralization of data frame function= s.

 

There is a comment in the recommendation that LWAPP co= uld retain the RSSI/SNR fields, and then perform 802.3 encapsulation, allowin= g the AC to have more visibility. However, I have had some requests to expand t= hese fields to also include the data rate. Further, there are possible fields = in the header (of technologies we know nothing about) that the WTP may want to e= xtract and expose to the AC - and how could this be done with 802.3?

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems

 

------_=_NextPart_001_01C5D0E5.15507B53-- _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Fri Oct 14 14:32:54 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQUMQ-0006AH-7k for capwap-archive@megatron.ietf.org; Fri, 14 Oct 2005 14:32:54 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04284 for ; Fri, 14 Oct 2005 14:32:37 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 74CF620374; Fri, 14 Oct 2005 14:32:05 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from typhoon.trangosoft.com (unknown [209.82.51.154]) by mail.frascone.com (Postfix) with ESMTP id 65E34203F5 for ; Fri, 14 Oct 2005 14:31:00 -0400 (EDT) Received: from phantom-out.trangosoft.com ([136.157.233.22]) by 136.157.233.32 with trend_isnt_name_B; Fri, 14 Oct 2005 14:29:07 -0400 Received: from troll3.trangosoft.com (troll3.trangosoft.com [136.157.233.13]) by phantom-out.trangosoft.com (Postfix) with ESMTP id 84B2924FFA; Fri, 14 Oct 2005 14:24:22 -0400 (EDT) Received: by troll3.trangosoft.com with Internet Mail Service (5.5.2653.19) id <4DWMLXZL>; Fri, 14 Oct 2005 14:21:52 -0400 Message-ID: <1652EBA28502ED4393B9BC9B8A4B601335B0DF@mism121a.toronto.chantrynetworks.com> From: Michael Montemurro To: Darren Loher , "Sadot, Emek (Emek)" , "Pat Calhoun (pacalhou)" , capwap@frascone.com, Puneet Agarwal , Saravanan Govindan , Dan Harkins Subject: RE: [Capwap] Change Request 9.1.3.1. Support for Local MAC User Data Tunneling MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5D0EC.F7D31AD6" 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-Unsubscribe: , List-Id: A list for CAPWAP technical discussions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 14 Oct 2005 14:27:43 -0400 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C5D0EC.F7D31AD6 Content-Type: text/plain From my point of view, supporting Local MAC in both a tunnel mode (user data tunnelling between the AC and the WTP) and local mode ( bridging locally at the WTP) allows the protocol to be applied to a wide variety of network deployments. It must be supported by the protocol. As for the frame format, from my point of view, in a split MAC case, it would much easier to use 802.11 frames for data frame tunnelling, but for the local MAC case, it is much easier to use 802.3 frames. A comparison of an 802.11 frame to an 802.3 frame (ignoring PHY) looks as follows: 802.11: Frame CTL Duration DA SA RA/BSSID Sequence Control Address4 (WDS) QoS Control Frame Body FCS 802.3: DA SA Priority CFI VLAN Frame Body FCS Comments on comparison of the two formats: - Frame CTL, Sequence Control, and Duration are of limited value at the AC for local MAC, they may be useful depending on how you define split MAC - FCS for 802.11 and FCS for 802.3 are calculated differently, I believe - There is a well defined mapping between QoS Control in 802.11 and Priority 802.1p bits in 802.3 - There is an implicit mapping between BSSID and VLAN tag - One open issue would be how to address 802.11e Admission Control 802.3 provides the basic imformation that the WTP or the AC needs to process packets in the local MAC case. It would probably provide enough information depending on how you define split MAC. However, you may be able to move some of that information into the CAPWAP header if you used an 802.3 frame format. One of the issues we have is that if you read the Taxonomy document, the definition of local MAC and to some extent, even split MAC, are open to interpretation. That is why Pat, Inderpreet, and Bob submitted the Taxonomy Recommendations document at the last meeting. Cheers, Mike _____ From: Darren Loher [mailto:DLoher@rovingplanet.com] Sent: October 14, 2005 1:31 PM To: Sadot, Emek (Emek); Pat Calhoun (pacalhou); capwap@frascone.com; Puneet Agarwal; Michael Montemurro; Saravanan Govindan; Dan Harkins Subject: RE: [Capwap] Change Request 9.1.3.1. Support for Local MAC User Data Tunneling The evaluation draft made a strongly recommendation that an option for a Local-MAC mode with user data tunneling be explored on by the working group. The eval draft listed a few reasons why it might be worth having such a solution. I heard support for such a solution from members of the working group off and on the mailing list. In addition, it appears to be an innovative solution which CTP and SLAPP allowed for in some way. There are many details that need to be specified for exactly how this would work which we are starting to talk about. However, it is useful to hear from the WG at large if a capability like this is necessary. Is a capability for tunneling of user data in 802.3 format for Local MAC mode needed? -Darren _____ From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Sadot, Emek (Emek) Sent: Thursday, October 06, 2005 11:18 AM To: Pat Calhoun (pacalhou); capwap@frascone.com Subject: RE: [Capwap] Change Request 9.1.3.1. Support for Local MAC User Data Tunneling Pat, Yes, that's how I interpreted it, with a disclaimer for 802.11 control and management frames only. It goes for option #3 and #2. Regards, Emek _____ From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com] Sent: Saturday, October 01, 2005 4:26 PM To: Sadot, Emek (Emek); capwap@frascone.com Subject: RE: [Capwap] Change Request 9.1.3.1. Support for Local MAC User Data Tunneling Emek, In option 3, when a user associates with the WTP, the association is handled locally, but the packet is tunneled to the AC in order for the AC to have access to usage information (and make overriding policy decisions). So 802.11 needs to be supported on the AC regardless, right? Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems _____ From: Sadot, Emek (Emek) [mailto:esadot@avaya.com] Sent: Friday, September 30, 2005 10:16 AM To: Pat Calhoun (pacalhou); capwap@frascone.com Subject: RE: [Capwap] Change Request 9.1.3.1. Support for Local MAC User Data Tunneling Regarding the points you raised I believe option #2 and #3 share the same qualities. In both options 802.11 encryption and 11e cannot be implemented at the AC. In both options a mechanism shall be design to extract RF and data-traffic statistics either (a) appended in the tunneling (option #3 only) or (b) exposed by the WTP as read-only values for the AC inquiries (both options). Am I missing something? On the other hand one can respect the unique merits that these options offer: - option 2: non-appliance product. meaning a software based AC that can be executed on any server / platform. - option 3: avoid parse 802.11 traffic in silicon at the AC. Leverage existing products (e.g. routers) with "only" add-on 802.11 code running at the Cpu. Emek _____ From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com] Sent: Thursday, September 29, 2005 6:01 PM To: Sadot, Emek (Emek); capwap@frascone.com Subject: RE: [Capwap] Change Request 9.1.3.1. Support for Local MAC User Data Tunneling In terms of option 2, no traffic is sent to the AC, so the model is quite different. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems _____ From: Sadot, Emek (Emek) [mailto:esadot@avaya.com] Sent: Thursday, September 29, 2005 2:16 PM To: Pat Calhoun (pacalhou); capwap@frascone.com Subject: RE: [Capwap] Change Request 9.1.3.1. Support for Local MAC User Data Tunneling Pat, you certainly raise valid questions w.r.t. option #3, however I am curious as to the differences between the challenges you listed between options #2 and #3. In other words, in what sense option #2 and #3 are differ w.r.t. encryption and 11e at the AC, as well as RSSI/SNR/data-rate/other monitoring support? Regards, Emek _____ From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Pat Calhoun (pacalhou) Sent: Wednesday, September 28, 2005 5:32 PM To: capwap@frascone.com Subject: [Capwap] Change Request 9.1.3.1. Support for Local MAC User Data Tunneling This change request is to allow for 802.3 tunneling of user data in local bridging mode. I believe that the changes should be relatively straightforward, but do introduce an interesting set of complications that need to be evaluated and agreed upon as a group. The LWAPP protocol currently allows for 802.11 tunneling in Split-MAC mode, allowing for such things as centralized encryption of user data frames. However, the current definition of the protocol is that when running in Local-MAC mode, no traffic is tunneled to the controller. If we were to introduce this change, the LWAPP protocol would have three modes of operation: 1. Split-MAC: Tunnel native MAC frames in UDP (e.g., 802.11) 2. Local-MAC w/ Local Bridge: Do not tunnel 802.3 frames 3. Local-MAC w/ Tunnel: Tunnel 802.3 frames in UDP The issue that we need to decide as a group is whether we really want a protocol that has three modes of operation, and if so, which one is mandatory. The evaluation draft states that option 3 is useful for support of non 802.11 technologies, but this introduces a set of restrictions. For instance, today the LWAPP protocol allows for centralized control of various 802.11 functions, including encryption and 802.11e. This function is not possible with option 3, and therefore any new technology that assumes this option would not be able to provide centralization of data frame functions. There is a comment in the recommendation that LWAPP could retain the RSSI/SNR fields, and then perform 802.3 encapsulation, allowing the AC to have more visibility. However, I have had some requests to expand these fields to also include the data rate. Further, there are possible fields in the header (of technologies we know nothing about) that the WTP may want to extract and expose to the AC - and how could this be done with 802.3? Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems ------_=_NextPart_001_01C5D0EC.F7D31AD6 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
From my point of = view, supporting Local MAC in=20 both a tunnel mode (user data tunnelling between the AC and the WTP) = and local=20 mode ( bridging locally at the WTP) allows the protocol to be = applied to a=20 wide variety of network deployments. It must be supported by the=20 protocol.
 
As for the frame format, from my point of = view, in a split=20 MAC case, it would much easier to use 802.11 frames for data = frame=20 tunnelling, but for the local MAC case, it is much easier to use 802.3 = frames.=20
 
A comparison of an 802.11 frame to an = 802.3 frame=20 (ignoring PHY) looks as follows:
 
802.11:  Frame CTL   =20 Duration    DA    SA   =20 RA/BSSID    Sequence Control    Address4=20 (WDS)    QoS Control    Frame=20 Body    FCS
802.3:         &nb= sp;           &nb= sp;           &nb= sp;     =20 DA   =20 SA    Priority    CFI  = ;  VLAN         &= nbsp;           &= nbsp;           &= nbsp;           &= nbsp;           &= nbsp;         Frame=20 Body    FCS
 
Comments on comparison of the two=20 formats:
- Frame CTL, Sequence Control, and Duration = are of limited=20 value at the AC for local MAC, they may be useful depending on how=20 you define split MAC
- FCS for 802.11 and FCS for 802.3 are = calculated=20 differently, I believe
- There is a well defined mapping between QoS = Control in=20 802.11 and Priority 802.1p bits in 802.3
- There is an implicit mapping between BSSID = and VLAN=20 tag
- One open issue would be how to address = 802.11e Admission=20 Control
 
802.3 provides the basic imformation that the = WTP or the AC=20 needs to process packets in the local MAC case. It would probably = provide enough=20 information depending on how you define split MAC. However, you may be = able to=20 move some of that information into the CAPWAP header if you used an = 802.3 frame=20 format.
 
One of=20 the issues we have is that if you read the Taxonomy document, the = definition of=20 local MAC and to some extent, even split MAC, are open to = interpretation. That=20 is why Pat, Inderpreet, and Bob submitted the Taxonomy = Recommendations=20 document at the last meeting.
 
Cheers,
 
    Mike

From: Darren Loher=20 [mailto:DLoher@rovingplanet.com]
Sent: October 14, 2005 = 1:31=20 PM
To: Sadot, Emek (Emek); Pat Calhoun (pacalhou);=20 capwap@frascone.com; Puneet Agarwal; Michael Montemurro; Saravanan = Govindan;=20 Dan Harkins
Subject: RE: [Capwap] Change Request 9.1.3.1. = Support=20 for Local MAC User Data Tunneling

The = evaluation draft=20 made a strongly recommendation that an option for a Local-MAC mode = with user=20 data tunneling be explored on by the working group.  The eval = draft=20 listed a few reasons why it might be worth having such a = solution.  I=20 heard support for such a solution from members of the working group = off and on=20 the mailing list.   In addition, it appears to be an = innovative=20 solution which CTP and SLAPP allowed for in some=20 way.

 

There are = many=20 details that need to be specified for exactly how this would work = which we are=20 starting to talk about.  However, it is useful to hear from the = WG at=20 large if a capability like this is necessary. =20

 

Is a = capability for=20 tunneling of user data in 802.3 format for Local MAC mode = needed? =20

 

-Darren

 

 

From:=20 capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Sadot, Emek=20 (Emek)
Sent: = Thursday,=20 October 06, 2005 11:18 AM
To:=20 Pat Calhoun (pacalhou); capwap@frascone.com
Subject: RE: [Capwap] Change = Request=20 9.1.3.1. Support for Local MAC User Data=20 Tunneling

 

Pat,

 

Yes, = that's how I=20 interpreted it, with a disclaimer for 802.11 control=20 and management frames = only.

It goes=20 for option #3 and #2.

 

Regards,

Emek

 

From: Pat=20 Calhoun (pacalhou) [mailto:pcalhoun@cisco.com]
Sent: Saturday, October 01, = 2005 4:26=20 PM
To: Sadot, Emek = (Emek);=20 capwap@frascone.com
Subject:=20 RE: [Capwap] Change Request 9.1.3.1. Support for Local MAC User Data=20 Tunneling

Emek,

 

In option = 3, when a=20 user associates with the WTP, the association is handled locally, but = the=20 packet is tunneled to the AC in order for the AC to have access to = usage=20 information (and make overriding policy decisions). So 802.11 needs = to be=20 supported on the AC regardless, right?

 

Pat=20 Calhoun
CTO, Wireless Networking Business Unit
Cisco=20 Systems

 

 

From:=20 Sadot, Emek (Emek) [mailto:esadot@avaya.com]
Sent: Friday, September 30, = 2005 10:16=20 AM
To: Pat = Calhoun=20 (pacalhou); capwap@frascone.com
Subject: RE: [Capwap] Change = Request=20 9.1.3.1. Support for Local MAC User Data=20 Tunneling

Regarding the=20 points you raised I believe option #2 and #3 share the same=20 qualities.

In both = options=20 802.11 encryption and 11e cannot be implemented at the=20 AC.

In both=20 options a mechanism shall be design to extract RF and = data-traffic=20 statistics either (a) appended in the tunneling (option #3 = only) or=20 (b) exposed by the WTP as read-only values = for the AC=20 inquiries (both options).

 

Am I = missing=20 something?

 

On the = other hand=20 one can respect the unique merits that these=20 options offer:

- option = 2:=20 non-appliance product. meaning a software based AC that can be = executed on=20 any server / platform.

- option = 3: avoid=20 parse 802.11 traffic in silicon at the AC. Leverage existing = products (e.g.=20 routers) with "only" add-on 802.11 code running at the=20 Cpu.

 

Emek

 

From: Pat=20 Calhoun (pacalhou) [mailto:pcalhoun@cisco.com]
Sent: Thursday, September = 29, 2005 6:01=20 PM
To: Sadot, = Emek (Emek);=20 capwap@frascone.com
Subject: RE: [Capwap] Change = Request=20 9.1.3.1. Support for Local MAC User Data=20 Tunneling

In terms = of option=20 2, no traffic is sent to the AC, so the model is quite=20 different.

 

Pat=20 Calhoun
CTO, Wireless Networking Business Unit
Cisco=20 Systems

 

 

From:=20 Sadot, Emek (Emek) [mailto:esadot@avaya.com]
Sent: Thursday, September = 29, 2005=20 2:16 PM
To: = Pat Calhoun=20 (pacalhou); capwap@frascone.com
Subject: RE: [Capwap] = Change Request=20 9.1.3.1. Support for Local MAC User Data=20 Tunneling

Pat, = you=20 certainly raise valid questions w.r.t. option #3, however I am = curious as=20 to the differences between the challenges you listed=20 between options #2 and #3. In other words, in what = sense option=20 #2 and #3 are differ w.r.t. encryption and 11e at the AC, as well = as=20 RSSI/SNR/data-rate/other monitoring=20 support?

 

Regards,

Emek

 

From:=20 capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] = On Behalf Of Pat Calhoun=20 (pacalhou)
Sent:=20 Wednesday, September 28, 2005 5:32 PM
To: = capwap@frascone.com
Subject: [Capwap] Change = Request=20 9.1.3.1. Support for Local MAC User Data=20 Tunneling

This change request = is to=20 allow for 802.3 tunneling of user data in local bridging mode. I = believe=20 that the changes should be relatively straightforward, but do = introduce an=20 interesting set of complications that need to be evaluated and = agreed upon=20 as a group.

 

The LWAPP protocol = currently=20 allows for 802.11 tunneling in Split-MAC mode, allowing for such = things as=20 centralized encryption of user data frames. However, the current=20 definition of the protocol is that when running in Local-MAC = mode, no=20 traffic is tunneled to the = controller.

 

If we were to = introduce this=20 change, the LWAPP protocol would have three modes of=20 operation:

1. Split-MAC:=20 Tunnel native MAC frames in UDP (e.g.,=20 802.11)

2. Local-MAC w/ = Local = Bridge: Do not tunnel = 802.3=20 frames

3. Local-MAC w/ = Tunnel: Tunnel=20 802.3 frames in UDP

 

The issue that we = need to=20 decide as a group is whether we really want a protocol that has = three=20 modes of operation, and if so, which one is mandatory. The = evaluation=20 draft states that option 3 is useful for support of non 802.11=20 technologies, but this introduces a set of restrictions. For = instance,=20 today the LWAPP protocol allows for centralized control of = various 802.11=20 functions, including encryption and 802.11e. This function = is not=20 possible with option 3, and therefore any new technology that = assumes this=20 option would not be able to provide centralization of data frame=20 functions.

 

There is a comment = in the=20 recommendation that LWAPP could retain the RSSI/SNR fields, and = then=20 perform 802.3 encapsulation, allowing the AC to have more = visibility.=20 However, I have had some requests to expand these fields to also = include=20 the data rate. Further, there are possible fields in the header = (of=20 technologies we know nothing about) that the WTP may want to = extract and=20 expose to the AC - and how could this be done with=20 802.3?

Pat=20 Calhoun
CTO, Wireless Networking Business Unit
Cisco=20 Systems

 

------_=_NextPart_001_01C5D0EC.F7D31AD6-- _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Fri Oct 14 20:16:24 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQZim-0005fg-Br for capwap-archive@megatron.ietf.org; Fri, 14 Oct 2005 20:16:24 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06282 for ; Fri, 14 Oct 2005 20:16:12 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 31A9C2036C; Fri, 14 Oct 2005 20:16:05 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from mms1.broadcom.com (mms1.broadcom.com [216.31.210.17]) by mail.frascone.com (Postfix) with ESMTP id E6EA81FDEF for ; Fri, 14 Oct 2005 20:15:54 -0400 (EDT) Received: from 10.10.64.121 by mms1.broadcom.com with SMTP (Broadcom SMTP Relay (Email Firewall v6.2.0)); Fri, 14 Oct 2005 17:15:47 -0700 X-Server-Uuid: F962EFE0-448C-40EE-8100-87DF498ED0EA Received: from mail-irva-8.broadcom.com ([10.10.64.221]) by mail-irva-1.broadcom.com (Post.Office MTA v3.5.3 release 223 ID# 0-72233U7200L2200S0V35) with ESMTP id com; Fri, 14 Oct 2005 17:15:44 -0700 Received: from mon-irva-10.broadcom.com (mon-irva-10.broadcom.com [10.10.64.171]) by mail-irva-8.broadcom.com (MOS 3.5.6-GR) with ESMTP id BZX16867; Fri, 14 Oct 2005 17:15:40 -0700 (PDT) Received: from nt-sjca-0740.brcm.ad.broadcom.com ( nt-sjca-0740.sj.broadcom.com [10.16.192.49]) by mon-irva-10.broadcom.com (8.9.1/8.9.1) with ESMTP id RAA14546; Fri, 14 Oct 2005 17:15:40 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Capwap] Change Request 9.1.3.1. Support for Local MAC User Data Tunneling Message-ID: Thread-Topic: [Capwap] Change Request 9.1.3.1. Support for Local MAC User Data Tunneling Thread-Index: AcXQ7VBZrYBkWx9zSaGI/RYMe4JoiAACIsQgAAnBoiA= From: "Puneet Agarwal" To: "Michael Montemurro" , "Darren Loher" , "Sadot, Emek (Emek)" , "Pat Calhoun (pacalhou)" , capwap@frascone.com, "Saravanan Govindan" , "Dan Harkins" X-WSS-ID: 6F4E95B8068885870-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable 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-Unsubscribe: , List-Id: A list for CAPWAP technical discussions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 14 Oct 2005 17:15:39 -0700 Content-Transfer-Encoding: quoted-printable I concur with Darren and Mike. Supporting Local MAC in both tunnel and = local mode allows for a rich set of network deployments and hence must be = supported by CAPWAP. =20 Thanks. =20 -Puneet [resending as the previous html reply was being flagged as too big by = the reflector] ________________________________ From: Michael Montemurro [mailto:michael.montemurro@siemens.com]=20 Sent: Friday, October 14, 2005 11:28 AM To: Darren Loher; Sadot, Emek (Emek); Pat Calhoun (pacalhou); capwap@frascone.com; Puneet Agarwal; Saravanan Govindan; Dan Harkins Subject: RE: [Capwap] Change Request 9.1.3.1. Support for Local MAC User = Data Tunneling From my point of view, supporting Local MAC in both a tunnel mode (user = data tunnelling between the AC and the WTP) and local mode ( bridging locally = at the WTP) allows the protocol to be applied to a wide variety of network deployments. It must be supported by the protocol. =20 As for the frame format, from my point of view, in a split MAC case, it = would much easier to use 802.11 frames for data frame tunnelling, but for the = local MAC case, it is much easier to use 802.3 frames.=20 =20 A comparison of an 802.11 frame to an 802.3 frame (ignoring PHY) looks = as follows: =20 802.11: Frame CTL Duration DA SA RA/BSSID Sequence = Control Address4 (WDS) QoS Control Frame Body FCS 802.3: DA SA Priority = CFI VLAN = Frame Body FCS =20 Comments on comparison of the two formats: - Frame CTL, Sequence Control, and Duration are of limited value at the = AC for local MAC, they may be useful depending on how you define split MAC - FCS for 802.11 and FCS for 802.3 are calculated differently, I believe - There is a well defined mapping between QoS Control in 802.11 and = Priority 802.1p bits in 802.3 - There is an implicit mapping between BSSID and VLAN tag - One open issue would be how to address 802.11e Admission Control =20 802.3 provides the basic imformation that the WTP or the AC needs to = process packets in the local MAC case. It would probably provide enough = information depending on how you define split MAC. However, you may be able to move = some of that information into the CAPWAP header if you used an 802.3 frame = format. =20 One of the issues we have is that if you read the Taxonomy document, the definition of local MAC and to some extent, even split MAC, are open to interpretation. That is why Pat, Inderpreet, and Bob submitted the = Taxonomy Recommendations document at the last meeting. =20 Cheers, =20 Mike ________________________________ From: Darren Loher [mailto:DLoher@rovingplanet.com]=20 Sent: October 14, 2005 1:31 PM To: Sadot, Emek (Emek); Pat Calhoun (pacalhou); capwap@frascone.com; Puneet Agarwal; Michael Montemurro; Saravanan Govindan; Dan Harkins Subject: RE: [Capwap] Change Request 9.1.3.1. Support for Local MAC User Data Tunneling =09 =09 The evaluation draft made a strongly recommendation that an option for a Local-MAC mode with user data tunneling be explored on by the = working group. The eval draft listed a few reasons why it might be worth having = such a solution. I heard support for such a solution from members of the = working group off and on the mailing list. In addition, it appears to be an innovative solution which CTP and SLAPP allowed for in some way. =20 There are many details that need to be specified for exactly how this would work which we are starting to talk about. However, it is useful = to hear from the WG at large if a capability like this is necessary. =20 =20 Is a capability for tunneling of user data in 802.3 format for Local MAC mode needed? =20 =20 -Darren =20 =20 ________________________________ From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Sadot, Emek (Emek) Sent: Thursday, October 06, 2005 11:18 AM To: Pat Calhoun (pacalhou); capwap@frascone.com Subject: RE: [Capwap] Change Request 9.1.3.1. Support for Local MAC User Data Tunneling =20 Pat, =20 Yes, that's how I interpreted it, with a disclaimer for 802.11 control and management frames only. It goes for option #3 and #2. =20 Regards, Emek =20 ________________________________ From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com]=20 Sent: Saturday, October 01, 2005 4:26 PM To: Sadot, Emek (Emek); capwap@frascone.com Subject: RE: [Capwap] Change Request 9.1.3.1. Support for Local MAC User Data Tunneling Emek, =20 In option 3, when a user associates with the WTP, the association is handled locally, but the packet is tunneled to the AC in order for the = AC to have access to usage information (and make overriding policy decisions). = So 802.11 needs to be supported on the AC regardless, right? =20 Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 =20 ________________________________ From: Sadot, Emek (Emek) [mailto:esadot@avaya.com]=20 Sent: Friday, September 30, 2005 10:16 AM To: Pat Calhoun (pacalhou); capwap@frascone.com Subject: RE: [Capwap] Change Request 9.1.3.1. Support for Local MAC User Data Tunneling Regarding the points you raised I believe option #2 and #3 share the same qualities. In both options 802.11 encryption and 11e cannot be implemented at the AC. In both options a mechanism shall be design to extract RF and data-traffic statistics either (a) appended in the tunneling (option #3 = only) or (b) exposed by the WTP as read-only values for the AC inquiries (both options). =20 Am I missing something? =20 On the other hand one can respect the unique merits that these options offer: - option 2: non-appliance product. meaning a software based AC that can be executed on any server / platform. - option 3: avoid parse 802.11 traffic in silicon at the AC. Leverage existing products (e.g. routers) with "only" add-on 802.11 code running at the Cpu. =20 Emek =20 ________________________________ From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com]=20 Sent: Thursday, September 29, 2005 6:01 PM To: Sadot, Emek (Emek); capwap@frascone.com Subject: RE: [Capwap] Change Request 9.1.3.1. Support for Local MAC User Data Tunneling In terms of option 2, no traffic is sent to the AC, so the model is quite different. =20 Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 =20 ________________________________ From: Sadot, Emek (Emek) [mailto:esadot@avaya.com]=20 Sent: Thursday, September 29, 2005 2:16 PM To: Pat Calhoun (pacalhou); capwap@frascone.com Subject: RE: [Capwap] Change Request 9.1.3.1. Support for Local MAC User Data Tunneling Pat, you certainly raise valid questions w.r.t. option #3, however I am curious as to the differences between the = challenges you listed between options #2 and #3. In other words, in what sense = option #2 and #3 are differ w.r.t. encryption and 11e at the AC, as well as RSSI/SNR/data-rate/other monitoring support? =20 Regards, Emek =20 ________________________________ From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf = Of Pat Calhoun (pacalhou) Sent: Wednesday, September 28, 2005 5:32 PM To: capwap@frascone.com Subject: [Capwap] Change Request 9.1.3.1. Support for Local MAC User Data Tunneling This change request is to allow for 802.3 tunneling of user data in local bridging mode. I believe that the changes should = be relatively straightforward, but do introduce an interesting set of complications that need to be evaluated and agreed upon as a group. =20 The LWAPP protocol currently allows for 802.11 tunneling in Split-MAC mode, allowing for such things as centralized encryption of user data frames. However, the current definition of the protocol is that when running in Local-MAC mode, no traffic is tunneled = to the controller. =20 If we were to introduce this change, the LWAPP protocol would have three modes of operation: 1. Split-MAC: Tunnel native MAC frames in UDP (e.g., 802.11) 2. Local-MAC w/ Local Bridge: Do not tunnel 802.3 frames 3. Local-MAC w/ Tunnel: Tunnel 802.3 frames in UDP =20 The issue that we need to decide as a group is whether we really want a protocol that has three modes of operation, and = if so, which one is mandatory. The evaluation draft states that option 3 is useful for support of non 802.11 technologies, but this introduces a set = of restrictions. For instance, today the LWAPP protocol allows for = centralized control of various 802.11 functions, including encryption and 802.11e. = This function is not possible with option 3, and therefore any new technology = that assumes this option would not be able to provide centralization of data = frame functions. =20 There is a comment in the recommendation that LWAPP could retain the RSSI/SNR fields, and then perform 802.3 encapsulation, allowing the AC to have more visibility. However, I have had some = requests to expand these fields to also include the data rate. Further, there are possible fields in the header (of technologies we know nothing about) = that the WTP may want to extract and expose to the AC - and how could this be = done with 802.3? Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From dupree@daliracing.com Sat Oct 15 11:19:47 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQnp5-0005pW-Ey; Sat, 15 Oct 2005 11:19:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13337; Sat, 15 Oct 2005 11:19:40 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQo00-00061n-AW; Sat, 15 Oct 2005 11:31:05 -0400 Received: from d149-67-154-97.try.wideopenwest.com ([67.149.97.154]) by mx2.foretec.com with smtp (Exim 4.24) id 1EQnou-0003zc-CL; Sat, 15 Oct 2005 11:19:36 -0400 Received: from [192.168.1.9] ([67.149.97.154]) by msn.com (Sendmail 8.7.7) with ESMTP (SSL) id IYT13985 for ; Sat, 15 Oct 2005 10:19:32 -0600 Message-ID: <310p446v.5921614@msn.com> DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=starlight; d=msn.com; b=rokugylMZNKIsUw1vjaWyYAqN0KsakVNImnFiKsiq9rZtFGxTbxJhmuh0YS3Byj9ZZfxfeXAlfrzyaXB; X-Display: Full X-List: parent.usenet Date: Sat, 15 Oct 2005 10:19:32 -0600 From: "Dallas Knox" User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: bmwg-archive@ietf.org Cc: bofchairs@ietf.org, bounces-ietf@ietf.org, bpana@ietf.org, brenton.daniels@ietf.org, bridge-mib@ietf.org, bridge-mib-admin@ietf.org, business@ietf.org, calsch@ietf.org, cancer@ietf.org, capwap-archive@ietf.org, ccips@ietf.org, cclark@ietf.org Subject: Re-finance at the lowestt ratess Content-Type: multipart/related; boundary="------------AttPart_64255888==.OLA" X-Spam-Score: 4.1 (++++) X-Scan-Signature: ee80a2074afbfe28d15369f4e74e579d This is a multi-part message in MIME format. --------------AttPart_64255888==.OLA Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
try watch in clink see eyed may bladder try alameda on charge but arrest be expelled in antietam see carbohydrate try absentia in caustic or connect ! millikan Or maybe not

--------------AttPart_64255888==.OLA Content-Type: image/gif; name="uruguay.5.gif" Content-ID: <0.0.0.65.0.24980344948880.92323603@claustrophobic.msn.com.3> Content-Disposition: inline; filename="uruguay.5.gif" Content-Transfer-Encoding: base64 R0lGODlhtgHYAMQAAP/////MzP+Zmf9mZv8zM/8AAMzM/8zMzMyZ/5mZ/5mZzJmZmZlmzGZm zGZmZmYzzDMzMzMAzAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ACH5BAAAAAAALAAAAAC2AdgAAAX/ICCOZGmeaKqubOu+cCzPdG3feK7vfO//wKBwSCwaj8ik cslsOp/QqHRKrVqv2Kx2y+16v+CweEwum8/otHrNbrvf8Lh8Tq/b7/gf5ECCLFQLEAB+eYWG h1V7fX8pgYOMiJGSk0OKI4SNgpiUnJ2eM5YimAcQEhKWjpiBpqGfrq+cpaazfwcSDiILEnyp f7qMDruww8SGrYQQuCOOvQASkAAOysXU1XDHf7KzpgC9tnzLgtbj5GjYjyfNzyTS5e7vYOe/ IqS+mr7r0cLo8P3+UucAkKKV616uWZZs/VvIkI0DaA0jSpxIsaLFixgzatzIsaPHjyBDihxJ suQ4XSRu/41o52ITvXwuFkzz4TKGo0Ezy9wkoevAzioscdQUsu+GA3Epiu74CWSfLqRDU9S0 BXGFzCBRY4pLloZpt11epQS9kfWH0hpHV5zNEbYHJmn71kqtKuMqkLIs2upEakLvk7E28PaQ axYcD786WO4ihJKerFYCEdoKFgycLlaGL5sCLCIYZnqeYT6bhcsWq4Okp4VWpK1eNwiPDa92 +ZPQgdCMFK7M+TX1t5eQwML+rPDmQFN0j99CuupUWoGPk2urHG048hG3CUZm58D0Ke4p+RxX xdfPZJUjnMaONg32bp6CAq3XrCy0skDB8H3Wt661EJSkdIPLc5MdZNgltVwnzP881R3ESCm8 wQbOcxJCp8x1rvHDIISiWPLcTYydwos4R4l33SIvdSgeV7p1ltOGKr2FHjMiNljcVuJkiN2M 33314HcF+lgCKTmawkcwOXI1iCKklCYBePzsGE5k961T2wKmQbRgPpW1aKQIML32lSI77VOi hb3xwqUg3wQo5hDftKOQkkoWZIJt+QgT5kPOHFinnSY89xIfMLGEiVJctQWiPeB809OOEN3U jqCRHdAieyUgistNo4nC6KA3NiglilM6A417fza2El+/URonq7tcamhVmCAzE0pXUmWCntC0 w5g0+JTATEJxqemnT3H1+keYiOnwjCV+5KPNNncmCE7/rNtI9iRPOXGGKYpFzbodt9/2tZU9 O/rEV5TpWSoMYOZt6yIJlwoIJpb36PYTtmKGts2x9LIpr50u/baSlkfmtAu8WA4srrDxnUuv cIsYHJ7FYvbiCJ/wvVkpmGpm+4xxIgNZocdCHCWvygiygOe1hB6Y3qndrtsZrDG/x4+moprr qceODqxrCcCSiLPFNfHMHp8ysbSvu/3yVgJt4iCqya0D9/yxqwsfXVStdPlRK9ZfXbwWr1B2 aupZw6YLctk+v41CY82yhd6Yy+SjY8sGv4vKlj/mROSEODp2oWzKyBg4dB6KsyjQwlSYpQmm GeYemksaSLS06FUOpnpmixkk/5HC8mg0OKUIXCVEthT5bo9Ndmi47F+hTtcqO65OpewYv80g dfrU12PHO/WNuodP7nRm7TQCCmeYd0On3dTWyq3ZJprdwlt2+ykXHOI/o7aZMtzX+CZjSBk8 W9isagPJeLdvE9TlmTvfZ6jSb3aCcoJezxL8+5uO39yHHQI6hhWQyEr0AHjAGvWuT+ILBYOG Rrz0FWslkkHZ9X6Uj7qZhAVhahke/pSFB37QHaOjX8fmQD/gbcFbJ0ThdGQWvjmshoZYIEwM d8jDHvrwh0AMohCHSMQixkEwT0BiXwqlw5bYDCtPhIIKYzDFFlRxIFE0wqOKsMUZdBELSmxC GDNVJP+pUTGLNEGjGNWogiq6zGZPocsRvvifJlrFjlKUI0D0CIj+4PGNR3CjFNkoFUJODY5/ rCMOf0BHGDTSWZqxlCwg0Rwm3eKSp3kNKwgkQMs8hpPT200pJEkabGXyeou8xCXfd0MwTYOO qZtFZrZRCiGJYlsbPIF19IfB/eRPNNqADH+Q0sr6eY8n8ouMLH85E39N8XqdyaA+Ujek6QAH g2PiRt4mlMEtMmgex7xljELZOiMppxTZIAj/cHCdp6jJQdF0l7QYASM2Xc5z9aTd3qbJuJfs QxVrWoFpyuMcWRDqlWf5pDYvAxdtwk4lDPUMrcbHoWk21ETaq2hqhveS4fz/AUkXzZxppFFR z5BUJSrrziAK2iOQemZdA+GTSSU6zAMNVGUCg0QwekOb12kPOUGipj7kedJNnWKUq1DpjoCa OpVZCUJ8aKpQa3A30RCqV92ByaFOJQiuXbUPXYUV0Yw2Mdvdix18HCoGEYqLu8GSR4QiFi79 SKh9kG5qWgXL8AqETlXWFRhZa103kGVBXKAqr+7iC5ZoR5m8LeApeUOkmizYVY7eMoHPoOBO 3Vk6wu5IE0/yTlxXillkDUhzE3sdZun5OoSmVS2GsSrGAoG0BEEsGgir18ZKdiCWcKxdP/MO Le8om6x9x60JZU5mmSUvEalEuP86JDIfWzLQimxZ/6rJ2kohWt3MTYsWDLoTiUr2EKstUU29 etJOxTuxhuk0eWvpSXj14aNfjMyP1z0Oa2U2tPXOTHP+Io0NikLgr+6mtnKTnVcheImumlFn C95ZKucWrqIUaHgupF1kGjaTWkZzlJFJhjRGLN5ZUlfEI07niEd8UGya674oBpZ3tbdiZMnx cpRZ8UPCe1dkorcP6tXuSqcbpCE3Ur5h8vBRNTGcW+pYqZcx1pC4ZOEOtlbHr1VBgYH7O2xZ DhjQAtJD/YY6MZNviv8bs1mrY5kt4bCLnB1IOhOkXfrpqqKyWGp7rByhGl0mxID9aOcudzf/ GugXrQt05hrbz5HCs35xBv8xhqa6TWXWgkOGxiCZvvQlyB7ZlJdGD00ZGs0zh1WtdBxanE/0 qEgnEgVbtl4GERzB/3Wy1mcWMNGmwb9/UhIh+02HUrLXuWzRyoKhzhY7LPzdiWarzbQsczKd kd3SLZPYrNlKtsh3XQ0H2JLZkqw/ERJNFDRbfJ2OrzCga8F1f0mcAvYXaiHVy20Emz/SzAIJ XfbgJdyGcizetVKFxcrMpHgmPukLidPRNM6kWFgB7wwltyeN3so4FxOvuMBvBY3baJw7wKrK bSz+W7ukY+HYQfnIAQ5yiJQ8UhEXEK+lNnCBHLxRCI85FVpoR55P2IhAt2G+VVDMoBv96EhP utL/l870pjudi69+utTb8MipW/3qWGe6QqgSSpTZxoDMjBySSJ31sgNh61/q3Si2dc+vuy6q KunPz81O9xig/cu3xRTXtPYbOhmy7oBvAdpJZbYj8fa3bxtFXwPPeBoMXoTckRTNccYuCjb+ 8oIP7cCG4rndNVrN6CCFu7JROGpj/vTbuVRUVLjOBl4yqoBFz+UI3W/U2556t889FTyo+95X Isu+D77wh0/84hv/+MgXAwxJYsKQ/GT5SIiKm24QdRyMh4bKPVFNKSeLV04yb+YLWAgZeTW5 6evvXtQ1T3LT/XBoP481ZAf6k8CxeolROjmoPllGXBO6bZr0UWUzJuMk//iAD4YnM6oyBKlw OCmCMj1gX15xKPZEgLYEf+yyKiUUOcBHBNI3f7A2dzzwDJxhGjVUIgQGDcWzMN5nKpfwIh5I A0xhV7j0glrxQPkBOR5XKhYYFZRiBYHwE5W0Zh+zOb5kHw04L4pHGjZTPt7UTepXb9xGKkb4 Gje4KvuWDEJWNFAyLzOzCd9QFECoTtHhIiBWQKVkeCGkMRuFHMaxHtynhLcEGeeBgLDxUTPx LO/DNvIjOKMhIpcRClO4NvrjHVfzGBioBWVoS9ThhclFODezIgIDHnhSJTZzOVGmiEixFmdy V2v3iGhyiZvTChWnXY7CF2PxJ9GShwmYgG8SJP/zgCTV9HZtsi7NwGDn53mpZjoZs4QVNSi2 sggwMVucw4eRUyE4xiSEtg4ZUis9oiQ96IN8sSeGlYcHEhZfFC+SmA0ouC6U8ih7wgh66Ce2 hQ7XiCyLlFKgUmfoojOi0GE8pjYHkXepol42s2DjJyaH0igziBMrBHkZo0Ot4yHTyI8IEoxK oTT0NoTFgSjLolOJ8yDMQVZakILVaBCDsoX96CKyMpAFsy4kZErhlmD28y3Y2BvGphejCHvj IkLP10x3+IPpAoa0KDHp4nAIwzh0KGENmAolMzU25TjhV1Zp8ThjgYduc4S5wIejsh1M0Q7h 8pA1pBvPWAX7glXlwor/U3mNDYN3v6iDN+NjDLYrCMiQBQFQ6ZBFviIT3RYlFsMsFpSDdqJV LtiOyFQuh3iR8dgx+biTFjkXGTmVpQhdp0CRQRGDfqKUR7iQ4hiWD8OIXxCGgPVjsRMwjeOJ nAiUKumKlqWZZIZamoiMBAVW3OSA0NE0PWEYLVITxpiJoxU7uqIrrcY2ZQRPI6hmzaOX4KiP djJB/aeLMsWNWdUki+kME7hhxrlsizMxSymVoJlgjZmHGoYFTIFK4Bc9KZdvgchASbgZvHiG EfQ9JxCISUmEfraERdeA3zVe5tOGvKRJMPGHNFQ8Y2iXZrgZkfN++JibfOl60gGHWCQzTmWd //xwHN6Hn+gGGC2SoCujfk8ZPo5ZPxthf2JRezAgTO/QfMknbOxHoUwAfSKBoRn6Yu0ZoiRa oiZ6oiiaoiq6oiw6AgRQADBKAAEgAwJQAERAAAQAADUqACJQAAPQRk9IRRtIEwhkAgEAo0hK ADxKBD7aoz/qA03qpOwEgjswRmeHTlMJA9MnBDg6AC+aozFQozeaozX6pFFqbgkypIRHf5tm pAVAAAPgpTD6pEIQpWfKA2d6pzSgf4Ghpj7QGFn6AlsaBDgqAoUapjY6BIUaAAMwowCgp7h3 gS9gpSHIWm66pAAQAC+KqUCgpFIKpXQKqTLApzVAqX9KgwFUBIVao/9gmqkvGqMF4Kg1mqSJ WgKamqQzyqow6qpIyqkDgKRvmqNHKgCzuqtoWjvVqT0bph1fl1WUwYhRVXTrZDHKczIkMKzX GqW3Oqck8KsxKqvfCgBfGq46GgDFWqsicKSvWgDE2qsjcK4vqqPAeq7puq5L+qtf+oHRxEvz Q0wuCWLrQ4gRxE3jxz+q81xuWJ2PtQdvUSW+ZLBTphnvM58usK7smq5zKqexKq8+6q3oirFv Gqcwaq4xKgBH2rEv+qT4KrJvmqnsyqghKxXk9mgc4jl9t7AYpY1us3jgNGgDMg3u9mDYSgKL GqNyCqYr660zOqct+6pwaqzpurK2iqQe+7T/GzurLGujMAunW/ujJxunKQsA3iqj+rqJ7uEl ybJsOLIi8/RoaTGLU0aJloaLsmknpei2s4k3qWUiJqI7FQun3sqjL+qot7q0ZOuyHyuuF5uu PMqqM7qpLhqrrPquLTu0oipChHaYQ4gOsIFsUSl2eik1t4isnDG0LpqjkGuo7Dq5GPujb2qu jxulNeqoIwCpJ5urLSuvPPq6IFu7ofqkqau4W6tl5ogiv8I0WfMhQgM2Z3UwLFgtHTM0qTKT gLIK16Is7MIUCDaPL3CoR/qjcJqtAWC68moCh1oCs6u6wAqj7Uq74iqsi3u5NbRcELeSnGtn vrazNvUkWYEM7xWU/xjLqY+Kuq3qsu26vi07q2B6vulLAra7uEM7rOQrpp/6qMCLwOz6q7DV lJtyDxvjcvfhkQ9CZyE5OD4ZMEP4XdpUKjuhJIL5HR05ZcbbcYl0vk1bwLP7vUSbuPFqAg2c snEaxCSLqZoKv0sqv1GyDjyjetpIMhOCUHQ5JftWEBKKAhPcpD0sAjvKqkEcp0t6q+Dbqg3s u5cawAGsw5FLxp8KxF0MsxtMlmtzL2fhNMs7wiJZOpFqt/kLCI5DIkehn3dyKzC1edlANn+r uj+Kr7i7sWGruImryLwqr476q09axD16sbdqxBWcUD8STYvDxOQoMG12aYlDZQlyZkBbE/+Z NgKmq7Riy7uzOr5veq8vW8sETLnua8FlbMBm3Mivqsa6/MqVXKga7I8QZLbEJGqWVS6Ss3hv 8TfqAjd5I7cGw5uR0sf20irQTLeDjCKauYEWe7gWO7K8ur4nMM5kurHqS7UgC6yaHMwRmG/Z IyeErCF7AIbqh4VF6nrNpF2r3M7ASrvjvKTn+rony77vi8sl8MBfDMGYPM61mqd0Os6JXKv2 ZyZPOEHjNxbrU0O5tF0iNx2iXJ/jdxO0FZEhM5gk3YOgnD9WKgBdjL5BDNO0C9NeTKe2KsRR 67423agl0MXEmqk+LbZLaqH3JwMeagJdPAACrKNBrNRe3K1MrcX/RDzUIzDVOU24Q82oNT3T dIrVRE0CPS2rdIp4LZoGlAqiZ416lMp7a/3WcB3Xcj3XdF3Xdj0FLeynLRB1qanXd30ReV0Y WiovpvrXgA0Vfg1bg23Mhu0PfRgr33eghiVLM0ud56Ea7eGvgng3EIsbktrY8NBOfjZXyRnY mDi3S/luSqyMrC23K1nYoO0KVQWeSmPa32h5P2OacFMoA1kqfR3bC3GC7aJbIcw31fVAGtNV gIyPP3mEsA3cnRBrEFTbiH3Hm5sSjTEaMCPF24iU0P0P0q1aTuY8z9xm7oJDjAaLCUYjru0l HPrdsBDe0DY+5P1rRWpCGg2egAKxKymg//D93wAe4AI+4ARe4AZ+4Aie4Aq+4Aze4A7+4BAe 4RI+4RRe4RZ+4Rie4Rq+4Rze4R7+4SAe4iI+4iRe4sT3ABGQ4iluACKQACie4g+QACrg4ioe 4yNgACqu4gmQ4xHwACkQASyOAgzA4wAw5DUe5EZe4wDw4jpeAgzAACXwAD4+AjSe4g0Q5EKe 4wyA5QBgAA1Q4zI+AjZOAhEA5QDw5T2O5BFA5lCO42EOADue41MuAjhOAjhO5GV+42je42++ 5H0OAHl+AlWe5jceAW++41g+6GN+5zm+5Dz+5y3O5GO+5HPe5YZO5ZL+5lLe4iluAg9g5iKw 6Y6e4wnA6FZO5/88DuR2ruqF/uZeDuZUHgEIMAKdLgJDzuK3zgIJwAAo/uS4DuO8nuKgXgJx /uloPuU4/ulPvuVP3uMMAOmcXulOXubLXuTUbuS/vuzPTunazuXW3ueiPupP/uLQzujjvuKc 7uxGPucozuV5vuMPgOa2vua03uaXTufN/ungfu+2PuTKDuhmXuzN3uNizuoiEOhRLuzBfu9u Hutq7uwvbub5/uTcvuzebu3OjuZmHu6WHubrzgAaH+o+7u8n8OkkIOpS3u3Jfu72ruy+vuoP gOUND+fAvu6obuYIgO6OPu8Xn+WxHvM3juKQDu8y3+sdbwIzjwIv3vPWPu0O3/RRLu3/087v ok7ysW7wBT/s8G7p/O7oDRDqOg/wNM/iBuDx9H7w9v7nSY/qtX7yc57nd77vXz/qWI7wI2D1 bE/2/I7oNA/0dC70Ys7uUk8CRB/0qs7xDV/4f3/4Uk7wJT/sKC/tSU/wa18Cdz7nDR/3Jx8B c+/4Rh7mnM/zLjDkBe/td+7pWG/rqA7plU/4ZW73JED6sX/27Q71bq8CSR7km57sJrDjcx/r w97ivw7ptf/ifv/ujn/3Zy/2lV/5Qz7kfx7ueQ79qM/ixh/ksA/oUo/jX5/0fF/7q077gq8C YU/nYY74l17+XX7+KQ7toQ75U87xR0/z3d/1lq/kR0/9Cc/i/18OAgAQNdEDIFEiMpEhwrHc wqQslm9s37ARAYOv36oHeESOrl4rmGwGTwAo8IR0FmGt3/JxSmV3Uu3SiOwlVMdHWhphsIC6 abIGJ8rwPtNoLPLaKaGpebWJvOWp3QDqAaS98Mjk/I1dBYX9NBhRxhBlbippblpG/TmpcDkN nZaJEJXcEdbJpK2kIbw+RSDEzYHSuSLebMkIxwn9PDAsM6yGxYAB/MANvzHTIbGRMTOseHH7 Aqc8GADW9gDGEJv5wUQDtpwYpynSBDYGhxHfxqSPwPmDRuhEvH+JnnFq9GgakzL+vjHzxXCU H0/G0AGhhk4Zs3QQlxlIllFHMnCdZP8lwBPQnZppNMCc6fWLTI12pm4AiZFgGZKQik4iNHWq 4QwXfGjKWFlURBtGF4O1O2emFRle6WBd5BJnR6xn+Fj58YeoZzWrUrBqDKaxZzJpPx/1wQjj oU0xoALiOcoOSdAjaT22I9IiC76DpgYrCUeHV590JPSum2kPQIlnhoqmdXuisNugJZdVrrY0 jcbJc+sipXNUjqSfUCUqc6Q3WJ2HGf0yXbKOYWGFJDq2Egvn8p7alW4nLZOMr1tRdF6E1qmX LqjoMODiVWM99wsvXBgn/StlpUrlrg27BWJrdvq56nEgd5QZ1GQu5KSVoOpemyPmnDkn1s8s qW1F2S4F9oP/GoJKSJGCMOWwFwd/CSBBTTY6NMGYPxDCoR6EL7QRkn/nNTLbJ5wcYqEJGAKh 4Rgc3uAgNU04995l9g2R3xzUbcJFAzmylt0KPgLZxWashZcginsMeRSA+RRXxIXHgNeEDvSA R9ZMwPhAyopGQHhKEakI0dkNE113nmlcBkgFH14+s6Y/9DihoJsXeflTdrEEsVadtF1ipmxx OjSGMXlmsecgrGhEZithRuGLbVic6eV9SvSpB6RV6JCOg+HEdppQl+hBWnqqACVdoqyEMU5x AvZ1w05nRjSTAdzMwE0zLCh2q2K76pTZrK7suhM3tugazrA+WFbrL7jSuoxlXo0p/y0t1mph 0hQkzecrU1l00wkz0+YRq7FwbOesuCDJmsW57PZwK7ZMHeutD+Pq5C6w14WRQBHv7rqvvywk O4OyEuE7TL/9zrelww9DHLHEE1NcscUXY5wxxOFq3LHHH4McMpghkVyyySejnLLKK7Pcsssv wxyzzDPTXLPNN+Ocs84789yzzb8oELTQQxNdtNFHI5200ksz3bTTT0MdtdRTU1211VdjnbXW W0+tmMhfgx222GOTXbbZZ6Odttprs92222/DHbfcc9Ndt91345233nvz3bfffwMeuOCDE164 4YcjnrjiizPeuOOPQx655JNTXrnll2Oeueabc96555+DHv+66KOTXrrpp6Oeuuqrs96666/D Hrvss9Neu+2345677rvz3rvvvwMfvPDDE1885BBIkLwDEkOwwA0OJJ88BGc3b7z1k1d/gATO Q1y9DA4sLwIE05ft/fXnN+69+Q6vLwL4MCxAPtnto1+/4dUvIMEBMECvPP/JL0B70vte+AAA gfAdAHkAhMEB+rc9/Ykgf9F7H/iQtz8Hjs95Eiyg/Tr4NwVKQH4OgMD+Erg87R0ggeLjXgwc GEIYjE8ECeReDAEgwf3lj4YSWB70yDfCEiLPedsz4P48aES+qW96+Sui+PY3RBiykH8OiF8L 5QcA7QFghDFYIgAgCEMeki9/MZj/oQGteMQz4s1825Ng9BaYQBKu8HnLO+D/2pg8E8pAf1jc Ig/DR8UYZC+IaByk3dS4ADFuApH0ex8K3cdB/lmRi14UXx9lOEkyWjKKhNxk29QnAfHBMYuf pKIiNZlFP5JPewiMoSojeEdR6rCS7oNjAreXwBQO8Y+c3CXaQBhKUUqviAqkoSnf50gZgrCA tVSeF9m4Q1m6L3oZBGb46MfLa1pujx8zIza76bgcIvOR3hzn6uI3QXKiM53qXCc72+nOd8Iz nvLkZANF1jztmTJiiBzjEx2my3nO04Ihu2c/KQY9TR4UYv8EKDxVKc6MWXNiIzTjAh+2UIa6 E3zaNOAI/wdYxxB6j42hrB4EH+g/ZE6QmwecIvzit8oJQvCAII1eIyPITYxes5HmQx756JhF Wi4QnD+NY0mHSMZW2vCFMjigLklIxzdaMqY7tOkxRTBJnHbTmNqsoQ2VeMkhFpSlJHUiC9+3 vouCFYfT06IWGRjTAv5xjxfFKi/t+ETzkdKMBLXr9MbaRSaalYlX5OYQzarBtWoypixsqvMi SldC/vOPePUqP4UoWCj+NbPHPKsZG4nCTyZ1qG7d32ThR0LQPhabVzVgYxfbU6AWNpRc9Osk 35c/PyrVrTD0KRa1lBVjthYGIcxnagd5USoGF5gg5Z5IiN72Gr5UeWbcJxev0z9hZe5QsaZt IWqL+9iCBs6Y3p0nUqy4atqOl7zJvCzg5prJrS13vvKdL33ra9/74XJbJt0vf/vr3/8COMAC zm8IAAA7 --------------AttPart_64255888==.OLA-- From adinole@acsid.com Sat Oct 15 15:10:52 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQrQi-0005xh-M2; Sat, 15 Oct 2005 15:10:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23409; Sat, 15 Oct 2005 15:10:46 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQrbg-0002aM-5G; Sat, 15 Oct 2005 15:22:13 -0400 Received: from pcp0010847834pcs.jdover01.nj.comcast.net ([68.46.178.99]) by mx2.foretec.com with smtp (Exim 4.24) id 1EQrQY-0003Vl-Av; Sat, 15 Oct 2005 15:10:42 -0400 Received: (from tomcat@localhost) by 68.46.178.99 (8.12.8/8.12.8/Submit) id j9CHmn0V807307 for bridge-mib@ietf.org; Sat, 15 Oct 2005 14:10:35 -0600 Message-ID: <125k906i.2136368@65.246.255.50> Date: Sat, 15 Oct 2005 14:10:35 -0600 From: "Rod Downs" X-Mailer: MIME-tools 5.429 (Entity 5.329) MIME-Version: 1.0 To: bridge-mib@ietf.org, bridge-mib-admin@ietf.org, business@ietf.org, calsch@ietf.org, cancer@ietf.org, capwap-archive@ietf.org, ccips@ietf.org, cclark@ietf.org, cdi-archive@ietf.org, cdir-admin@ietf.org, cfrg@ietf.org, cfrg-admin@ietf.org, cfrg-archive@ietf.org, cfrg-bounces@ietf.org X-Spam-Score: (-2.159) BAYES_00 X-Scanned-By: MIMEDefang 2.52 on 68.46.178.99 X-Scanned-By: SpamAssassin 3.071128, File::Scan 0.48, Archive::Zip 1.71 X-Recipient: Subject: Notification: Loww ratess Content-Type: multipart/related; boundary="------------AttPart_02904808==.OLA" X-Spam-Score: 1.9 (+) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c This is a multi-part message in MIME format. --------------AttPart_02904808==.OLA Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
! fiancee , diode on became it's hair , bullock may austere but chimique or turtleback but slugging some sidereal in henchmen be curriculum some chubby and nietzsche Or maybe not

--------------AttPart_02904808==.OLA Content-Type: image/gif; name="pedal.8.gif" Content-ID: <3.0.0.57.0.99666277929438.55858383@enunciate.msn.com.9> Content-Disposition: inline; filename="pedal.8.gif" Content-Transfer-Encoding: base64 R0lGODlh5gHOALMAAP/////MzP+Zmf9mZv8zM/8AAMzM/8zMzMyZ/5mZ/5mZmZlmzGYzzDMz MzMAzAAAACH5BAAAAAAALAAAAADmAc4AAAT/EMhJq7046827/2AojmRpnmiqrmzrvnAsz3Rt 33iu73zv/8CgcEgsGo/IpHLJbDqf0Kh0Sq2CDo+sIvs4ZLaPCthKLpvP6BPWu95sLe+0fE6v T9ttTZyyt/v/gIE4eF0AWFyFEn2KYRMNiA2CkpOUlRiHXAd5homLAHsNkY6ilqWmp2iEmoiZ jHCNAKEUsqi1trdMqptisBOgpLHAuMPExTm6iZxen72uErTPwsbT1NVqXGBdmFle2VmMiM+Q s9LW5ufoO9Dp7O3u7/Dx8vP09fb3+Pn6+/z9/v8AAwocSLCgwYMI02DKtgzGug1apOyqMubC okflhmCcE5GFJz+q/0R8VPFAgYyHIUr+GYkBZRGXIFQWkakDZouJLEKGYImC5gubHXzS4WkB aBCjHIQGUWoDaQqcK0JuS/aKi7gHobBeBcbKJICuGaZ2Y8Ws5LerWtGSAvsVmwRMyw6BWebt bNEsWbU+4hIpYscL29hgy7SlYtlmwWaNy4DI61RtrBpWtbsXL1qtfmU2DjuYW92yoPdmzUjB Z9eFrSxaBWe4MqnKmLV0BCuWU+qbZresagjVmeJI0KCZLjyBqbIJWPq8GfMrg6zhEpRuOrR7 D09astY992q8gtRCzHt5Cg7Mack8a6ZTxRCHvPa+3L1+lc9Z8AHlYeKA0ks6uvzhOn0h3v83 zY1CTnQq5VaabsgV0ttTuUHGynp8IOaScBMS598l6+HHjG8PwQYfBtIlo4p1iB2Y2Hvzbcgh IoIVBl4jHlYQ3ISknZZIeiZSCM5q7pU3YosuanDigB8mmZgHNAEYoWSqVQhieTgW2ZaO3FDw IArJmbXbB+OVIxx9RRo3kYf6wcJiNERaUCJvDnaB4gahYCckkWbuGKeMY/mmpIFsBvWfAuhB BieUvrX3Wp0HajZoB1326Ut+NKrZXwVN0nfek24gqeSabmpKppZZHhdDpKam+sqnYq4laqYc wolmpQZmt2ibeJpEk3r2HWZXS4wuyWaCecalJ4NJ1qiisMwuWJz/SWLxGqUzQTaqK6zdccLg rKAFKuizzqLaqZSsrngnrsP1aN+WJYhbmx5niejIYmxl+GIrn2WTzbyv8fXcZsXJFG1nVBHF rLwIgjHqW43tOaNsBJIVy2IIkzgYfYTAKOBgsKVVMcT/ZctwQ5+xhtdijAHMlrjskaXvahP3 y9eVf9EWWYM+JtSCwU7Zwe4RP+ss9KQwt5QWJYFFQd3QTDft9NNQRy311FRXbfXVWGet9dZc d+31PQQvDIJhp5ZKxF8zbASRyECgjZDBQcAdU3wpyH0NokuJzYHd3pKo90x/q8A3k4E/MTgP h0NENwqJixC0Dmy3HIJRkedNQ+MaVC4D/2rGwvhypTB3DNzMCG7GlgWoPWyXN/OSnpKGA0uI NyOtkS6aaDR3V1tt+UJMJ70AF7n7zaz/GC/KFwSPpVk5+0rp8xNjpXbmmjaWuoT4Sly80dKn pbxbtt02Q5e6SRuen+QVNWSL0L345aTwA9o34SrxGmBVfwZqJ7piF6rerJRyjpDaRyReqetP +Ekf9ZwFLupAhVuf4o/iwPUsZMjKU3LbyENgNbIGzQ43fDIfYvqgQHlhy16xqlA40FclEQhM XffjBbUoJop/nc47enoM81xGK+dYpnTKc8yEuuAj/ODoVguk4IbYBcECfctKmwrhEO9TtPwJ EFNBxNnNaEA+Q/950IokvFX6sFW4LyYKFmFMwQsPFUNyvUGBwaBF5fzXoRSlqQMb6c4acYg3 ZcmPcqIKV/P8tJweNiuJ/Ovi+1SDxhRdYB0cbNPjQOglEa6qPeNQIFgIiLpkzMkVbzzX6zo4 Mh41745wrJMoOEkqY/0PSXcEFjkIuMeRHbCQCJSe/PzGwCUOMpcfas2legkdVL3SjQHUACQf taFNHYqLspmLWEpGtEfW0F/C0EzwcKgxX6FITcgzT0feJRezqXCH0ZMeEoGYp5vxjocQc2Q6 vaeyzQyvm91y3mWO5ibw5Y5QW2zZCssChopZDHwr8xLDNEbNfD4SZQ0LmRDxSYaeae7/axil h2vW5raMevSjIA2pSEdK0pKa9KQoTalKV8pSQEyypTCNqUxnStOaCg0uC53LxtCJsI1eSWHs LKNNh7q5HnlRch8Clbf8oiErEfWpNpDWg1BZpY+RyZ9QzWpUD7glGc1PWGOymFC1StZ2cXWQ Xj1YsITFyYuW9a0ciN0OP/innmLzdKebyJnkCde+lgBzfg2sEsgm2MIa9rCITaxiF8vYxjr2 sZCNrGQnK4EAFOCyBLhsAQYQhMwS4AKe/QMBPlsBy3K2spo9LQAEoFkBbIC1l3WtBAag2QBM gLaXte0GQisE3Or2tgX4bQh4uwPWypYCtP0tboM7gcwWgLRH//DtBZLrAtYSIADWFW4PBDDa C3AXuicwbhGcC17Lbha1BBAAazm7XgHQ9rgWaO97AfBe7jK3vpnVbgVGq94hBCC/pYUvfZlL ge5W4Ls8gG0B4CvdAasXwPxFcBDEW1kAW4C6LTAtADQsBANbwMPhXTARIuxh86pWALbVsHgp 7F0Ri5e6ML4vgTEA4t7OOAMYbi54dVzczbpXxLPNbZBtS10D13i7QB7ydG+8Aus+N8WavewA YKve2OI4yjKOcgB822AAgNi5mM2AeaM8gDFLebVRFvCBsfxjzNZ2ubklL3FBS9r+bvi55y3t eVec5Pi6WMQxJrKM9dtczUIXzE829P+ZMWDm0yrYyhrI8XKVq2UJgHnHJcayai3QaAk8us9r di12dUtbCwfay6Q9coENLWZFO5rNsHWubB8t21ILGbiERoFlM8vZXau3ygR475ZBDdxf2zez xs5vfv87Yw9HWMKcfu6vE53eaZeZtlPONZqnrN73IpvZP072go8N7fiSdwK7zjO6n4xm17LY z+4G9KAHLGhtf9fOz753rNebAWP72MfdJjZyZ4xdC28Y2cfV935J62tr99va7Q24miu73OPa mtTzNvKOD/xrVXsaz7yOeLhxO4D5DjvbQV6wwXPcguzeWbWm5fPE6Y3uH1N62PXmsaUPvXHU nta0Zk5tu1//m2TjBhrOtUW1u2fu6Qd/1tfqvvN1Px5vpsuc5qdm+YfB++WnsxvFjNb0sGM7 6kgzmeVaV7WBg77oaJN57AsuO6Ml7mAMn1rjGkB0z9GL5ykXfdybxS6Q3z1fSTN5BRzm8Muv vmTtGh7nNN+5zlEd9p8HXtrGtu27W5zwuHtW3sbG994XLvmgW37qVB86Bq6e9XlnoOsF9vqm L9BwfmO3zUxX8sCFm/aerx3zvyZ07c97e9xa/c+uRXrOi5zq0T/b41LvO4uNy3jCuz7yLki8 umMOeIFj/+K4Tm6Xnc3zfot9+3sG/MynL28AP57yHLCvtJvu8l0Ll/GcH3rrc/56/677/+Ub oH1+J2rhZnaOd2PiR2DdBXsA6HO0l2fcR4DzRXvLVWYb9mBAdnfN13+TF22fN4ATQH3IR3Uv dn3YBQNj9mpRdl1jJ2u0h2iex2YH52bBpXerBYOj52/shWVTN3YWSIFiN4OyxWxpZoOvxV8U kIJ3RmYbVoG/xWJwZ4FECGRTmHuX5ml692mzt2aKFmxBuGSVpnwVBmk3OH9etoJotoK59mie hXQ/CIRvOGBCVoVYiFlWd2mqZl6f91xuqGBgJmokB3dghnHaFl7q9YSZV1mHeIhzZ2yK6IiP eHurFXr0B4kawGGh91u3V4i3F3w1l4SUGHq5F4Jq5omTaP+KnfiEgQeKjPiI8NWJr2WJoniK rfhwixgAnViLnEaJF2iJvchxCceLmagBmYdiuQh2l4iMNWdnvQhfvuhdswiNo3aIx4iLwYeK jJiKv/aJ52BmqIcKckdZWpOI4liO5niO6JiO6riO7NiO7viO9/AYdAUONfAXL6VMrDBMWDRW P/FDB9VRLtAzVgCQxDA9ThUCS4MbrrQ3fMUC2XKPf6SPvVQTNdQfjpI2wiCQHrBXN+BWK6CR PQCSHwCRcZVDDGkDD/lLV/RVEwQEQBFJP5GREjmSddSR/MgCIqkOM4mQKuk4OZQ0+uRDM3M7 9IRQ9nQbQAkC6eNTIAMuWpA6qyD/O3UBOlZBlPx0SMQEUBrzTuGgML/yUP6YPNG0UKUClNvz GUS5k70kVwzBSMyjFq1zNPWyTdyUJZ9jPHzlUz8VMDukla3wLlVRO65DKhSlDJ9kTSqiQY/w KsykKiQ5T9IgRwlCN7vCDTzSKyjiIfuzLLzkH+rSIwBkRTaijxFCJv4jQ/EzQ8Chli5iP3FC V+ezLMu0IKwEGJ0QMX6kPskTSPNhQAspUEklSmZkSoTRSCupm3wZUUq0C4+5lPSyOApiRh3U BpmZIpvJkpgyKJ85IVT0K7F0nNSjIORUk0QjMTnJQK7JJ/BiIygDSfaCVbbZTUYkMbIUKlhU P1NkkkgV/0qcSUprkEOHiZwCiitlIh/M2ZOIGQ2aBJ1oc6CY2UgjoUqjmRTaeSindBbfWZ+K kxunqSrAlKAlUEvKoEjrGZG7lC0E2aG5SSflIBRuoVf6OS38uUv+SUSuFKATCiiz+SyR5KD3 WC2BcpHsY6BUYUqSwgw1IqEuFB++2SBN1JC2Ep6F0aGXCUrJRC2smZ2kdBwsg1TespTrMx+1 aSp54EfX0aK86UweFKOrEpz9KY/h4yVTKZSW8TH1ZD0BlZB+Apa2c1fxBFRtURdwwjzduRoN hRKUAzD3lD1dSTC/Y5ERsimD0TmSYRhoiTxYeZ8RMZ7I4paUgU38kpzaBJ+EGf9N9NlQd+GP m/Sniyo+5bkvBrUSDRk3s9qf+nCe8FgH+8IBBpmrvvqrwBqswjqsxFqsxnqsyJqsT6WnJABY yjo0nuCskIKgHyGtz5oQ0Vqrd+MB1aqt1woQnEOWtwkz2yMvaZkyfdklepIa27On35oQJNpK 7ppGOipBnYmfR2VG3fquTEOi75KtipGP2Jmd4vmacXqb08KvOqNIKjpCvQAT5iEj0PKaDZuw CosQDKufuGSlajWwBCtE66KxV3qxQ1NO0tQwdPGVglmnmLqb+DpX24AshGWtJFuzNnuzOJuz OruzPNuzPvuzQBu0Qju0RFu0Rnu0SJu0Sru0TNu0Tvv/tFAbtVI7tVRbtVZ7tVibtVq7tVzb tV67WAbgAGLrAAsQtmN7tmgrtgmQAQsgtgagAW2btmnLAADAAHNrt2hLtx6QAGrLt2oLAH7r AGsLt2f7tgAQtw7wtnZLt3jLuGfruA7AAHibtgsAAGaLtpXrt4MbuGebAJwruBKAuG8btwYg uhnQuBLQuKh7uZV7uY8rt5V7AZ+bAKRruhZAuofrtpMbuXXLu7srtpP7u8ALu7M7AXw7uP8Q tgzguXy7AHy7vJ47tgvQttMLuhhgAHZruNdrt8zLvZLbvQyAAN/ruZIrvtCbAJL7AaUruOtb ts1Lu9Z7AW3bvYk7v+ibuOYL/wDma77Mi77hW777G73L+7bK+7zNa7nzKwHNS73zawDw67yj K7j3awDYm7gVjLwWML7pu7/7W8DNW8CR+74hHL2xawEOTL0JQMHZe8Hbm7i5u7YI4L8JgAD6 u8Hl+7wOHLkgvLxka8DRK7bO67kJDLjx2w/Kq70pHLYlnMJMzL4pTLjaiwFta7gOXLd6a8VY LAEIQMPpq8U0/AGae7wfjMBFPAFDbLnwO7gVXMGM28YUsMVZ3MVKTAFJTLaAa7jHKwEOnMNM jMfWO8RrXLsufAHlq8Xp28WSe8QK3MMUbMd1vMRRbAF5HLpuO8VsO7yDnMWp67t0O8dz/Mh3 PMcKPP/JaOzHGMwPokwBSpzKRHzK8hu5mfzK62u4XYzFh3zFtywCYSzB8UvKFGDJv5zJU7y4 tnzFFIDIesvKemzHxgvLGOzLrUzJ2jvFghzJE1DLxZy6DJDKoszNZKvMshu/1XzJsJzJ2EzM 6evJzGy567zKjlzGzezK+gDOrlvC0bwBbZu9hDu2tPy4XDy2uAzQugzL3EvK0CzNFQDMuYu9 ktvQNfy42hzR7GzPy2zPz1vE0DzJCk3NBB3Lx2zMuWzF3hy73iy9HEDK+QzL1mzGHa2959zQ 6WzHIz0B9UzGnRvPAKHOQAzCFg3PCc2++izFghvU31vIVuy/17y82Ly3ghv/t9GLvAe90D89 zYlbvsSsv/0b0nK8zjS9zh98xhn9x8Jcvw4gvm6LAS8dx9vczszszTxM0eGMvG1r1h4dzItr ziD9v7yrziXs1geMxsw7xFGdD6JMwp8cxYPN0oV7yRSMvCGNxXAc0ZENAmLct73s0wqN0NJ8 yLybwW6cxfTs1WgL1WWs0WM9y7hLyHmt1jM90V2duStdAShN1nXN0jGs0GlNzHz92rz9xJJs vYmND3/tziTNzMH9whPM2BVgw3pby4+91BtwvOubwgk8xiYc1MPswgnM3JqczaAt020t2s4L 1qVtvWv8wgt93heQv1bMxc1NtwesyK5d0fSdAbOt/8K1jdC4vdr5u9v1Pd+XS9pq7NsAwblr TblE/LdCjcm1jbiDjLqLK7ySO7f/Hc6Wvbbru9MZUMFji+GTu7YQTrd0Dbw0TNfh67omzboJ Xs6gG7ibO9qW++G5W8n5/dCR+8Um/sWBu83LDMTsjOAW3uGim9nBzOAcDry9y8mLDLxUnOJy ywAO/s2LLM/80L9v27/MS8BZvuFZzrzX278TEMMzjNVbjOUzLOb9S8Py/eWe29hUvOUa4MBe rsdzLuYljuNpHuaeq+NmjsdtDthM/Ody7tuD/ueATueei8YbEOGdbed0bOij7NtmTuAVUOhJ 7OVVzOaBDsN57uiTDeeR7v/nWN7YVk7TlL5Ypz4QMVzmX/y1rs40MB3rsj7rtF7rtn7ruJ7r ur7rvN7rvv7rwB7swj7sxF7sxm7rcP3qyr7szN7szv7s0B7t0j7t1F7t1n7t2J7t2r7t3N7t 3v7t4B7u4j7u5F7u5n7u6A60cNqPLesChJXuSsOmHQA3cBQDNAvvO9ChYFKr9Q4D947vx/CT xKM9A6WhNjQbyxMnEDMWK4SqAG8EA3NByIRH45AujVmjkDEnK/rwQ0BH3LmrqalMq8lOY+lL 3bQJnwTyHI8EdPRBlsrvI0+gbaKmZOpJxqlCK8/yOQSaGDSyyLkdzqIjv4nyxrnxOe8DcMqV RfPV7gE7On1Bly0Ss0QknxMSlB579LfgkUqZpVgfCFDf9WAf9mI/9mRf9mZ/9u+YlP14KQSJ 9mbwmFtPoSbw726fEwhqAkih9SFf9x2/royKob7DopJ5LdxxlDAClb7C90QQILuQJj6vPmGV Kzz6TA40tEH7BBkTGSWToT+/StaSovzpoXR/+SPwHVCS8obEp97LoQpvm6fvraQPA6bvpDfP +TkqR4RfoGfALz9Z+zWAU+KqOpGKTmCZ3UR5PFM5sYcfUA7l+8ricoAf/dI//dRf/dZPUhEA ADs= --------------AttPart_02904808==.OLA-- From pizzic@eng.sun.com Sun Oct 16 18:48:01 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERHIP-0001gX-FU; Sun, 16 Oct 2005 18:48:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29949; Sun, 16 Oct 2005 18:47:51 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERHTZ-0000Ih-2T; Sun, 16 Oct 2005 18:59:34 -0400 Received: from pool-70-22-51-113.balt.east.verizon.net ([70.22.51.113]) by mx2.foretec.com with smtp (Exim 4.24) id 1ERHIK-0001cM-Or; Sun, 16 Oct 2005 18:47:57 -0400 Received: by 10.11.98.6 with HTTP; Sun, 16 Oct 2005 17:47:43 -0600 Message-ID: <635r989n.3669166@hotmail.com> Date: Sun, 16 Oct 2005 17:47:43 -0600 From: "Violet Cahill" User-Agent: Apple Mail (2.728) X-PGP-Key: OEHf53KXkstIDq8NG1Rwn5hJXHnv47PWJfOzDC5czq8q4cI9uLTHiKogRYuOyRBA== X-Load: 76% MIME-Version: 1.0 To: beerlover@ietf.org Subject: Last chance for lower rates Content-Type: multipart/related; boundary="------------AttPart_28301711==.OLA" X-Spam-Score: 1.8 (+) X-Scan-Signature: d890c9ddd0b0a61e8c597ad30c1c2176 This is a multi-part message in MIME format. --------------AttPart_28301711==.OLA Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
see codfish or garish or compton may knickerbocker but please or sophoclean some bitumen the vt or sable , coproduct it rae may pernicious try arching and pepperoni Or maybe not

--------------AttPart_28301711==.OLA Content-Type: image/gif; name="dissipate.6.gif" Content-ID: <7.0.0.59.0.76767534028203.38867445@crow.yahoo.com.1> Content-Disposition: inline; filename="dissipate.6.gif" Content-Transfer-Encoding: base64 R0lGODlh5gHOAMQAAP/////MzP+Zmf9mZv8zZv8zM/8AM/8AAMzM/8zMzMyZ/5mZ/5mZzJmZ mZlmzGZmzGZmZmYzzDMzMzMAzAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ACH5BAAAAAAALAAAAADmAc4AAAX/ICCOZGmeaKqubOu+cCzPdG3feK7vfO//wKBwSCwaj8ik cslsOp/QqHRKrfIalKw2K9FCINkEaVuCSMpeVPc8SmjZIrBXDMButxI5BdLWSxoidncUVoWG h4iJQglgeV8Uf10UDQ2SdHVrJWEklZCAJ3ZwAHKfbnuPWYBYX41fEpGpgVmsWgmMkLSiiru8 vb67kCOUAG6fAFwkbpejsyXFKqGchCKvy3KMfMSTwtqlwSRdn3sj37/m5+jpRuVt29TIIspj cs7uKWmysstxew10z8ncgTnxR8S4QMbUKVzIsCGLb2DEAGTWiNylgeECJjyxJ2Odaa9QsJsY z93BEv4M/2Yb6LCly5fpBpU0hvEghUvjsIgiyRFCgoxYqOka0UVjPXHZ7t0RNhSm06dQl+Ci 120Ey4w3+d0xxtPEOFMJggIoSnCnvZkGm45xRHZs1qhw48r98a1BtoksTWGhM9VMua6astkR C2ajSqOI23LKdtBuG8NzI0uevIId2nfCajHjuqmqipN6ZL21epYnwIrJCh5L6kYt5dewJ1v+ yObnNNG2sqBhg4WmhGU6wel+d9B2UlnHaRP1JFoc7y58KsWeTj3uFmOCbl4nbapz90mD2GUX TkIPPtLNRG+yvdVgeDFd9lWfT18dK599WI1iZW3/l/L83ffFRtj895gJ94HCCv9XCeYHQUIC fvEPZPVVaOGFGGao4YYcdujhhyCGKOKIJJZo4okopqjiiiy26OKLMOKgWokGplBjEj9RWMhP 8sUYRXd2caGFe67pEAuNJxGUJBJHKgKWjzvWddNeJfXowoyf6biEdL7caNVKyTGpZRXy3IAl lDlQOZYrwoQJw5lqjJkEl714GQeYTcB5SJk26IlmDW4IBsklv60QloxyxnAoDG7W2eiXeSaq wqM+8CkEpTJg2iFLx8DBCAt+vinpC6GCUqQidpahaRClsuDGEZYC8aoOdJZ42m2FsreRIGfo lFWhH5Ujh0epxcIesD8Nq16vXPwjiT9bhFVbHvAwM07/UnagQokkK21jigndhZUKMoOZ8axV nxhoG7DCfbNuWIAMa1i41PhVnCSFFqYNSFoYU8uQggDy7WayxBcQHQG79Ucs1VJDh7lHSjKJ rgXfRDF7uWlWYkhuCcxGQTyWoJoko3QiBpf/mXFZG4VWI9CUxuZBTSkfewxfr7wFMxgxMlOp r1VsmFGJRByrNusYd45yRo71Kn1yVj//F3KtdQj8Kx/fyvzRRtMYyHFht8LnTUngejuJGURH hysgJD94sNM8+7QNl5YanMlHZM/MM3slg/ybyj2f6mFvdg3k9ndnjYWdKFAvNdqZN9YK8m0q K95HLF7SSTflzIpReTts25XQ/69jI5iJPBxDnZQ7qv2X3WiBXLNaN0crbfo3M+Yheeh51w40 JsdcEtTRqlFdZfCZ7ffRyWG+NWNWsyKuSm1bhXKy4B5C8lsx1KswY62qa2IM5Mftrg1TeldV UOZwbI4+e4k7fcaNpOcjcnRBP5gHNkmn3zr+KagEILLCK20ITxeBS99+zFe8afhuJm6zx6uI 9wnjGfAYnDHgJH4DO4PQ4XkSceBt0Hc+Z9DDgiNaxTvGV6hhgANbjFOFt85Qja2hZG7ayVkI f7emQCwtJziUFgmPprIHaqIgKrQd3BRzQY6B5UnKM8gntFbEg7BLeb2JIlFyhSXUfYx6udHh EkXYo//gEKyHz0iiBZ/xM629Yn5LkmLT5FimGg6DTnasBLOAp6K31IpiN9wDveSgtkHxLBXQ CSQXm+WeiZFrFutSofX2xUHd9MsUlWxY8pblLE8MZzkL++Ico0GKUAjikFfc1yOC1K9DNgmU wYEEI12JrDXY4R2pxCB6QJMKMMitM8vZhh5YQ8AOWutByCCFwmxxLnpRDF8hNOSf6PM8w7hQ IWJRYhWwN81uVuEgEalHQ6iULCukypvo3BE0TaA1hgzTCrFKpzznSc962vOe+MynPvfJz376 858aEuAPyukEgf7AoEpalazaCVASjecYrZTBznpgCoUCYaI9wKjI7qaEijb/1ES3kJI0FUWs HdzCogMt6Q46ARnpoNQHvmwIQz96BDO2xgZZpMtLfZBTnsavh1CI4zkCBaWd9sComeBYDXra A6EigakscFsLoHqYoBr1BVKdQVZZkJIYGRFWI3yTLK30Aqoa6aor/SkKAAOKnzo1CW/FAVtd pdYQ6RGRTUpYHN4IP0o0q5DAetanCAmuV2wDX8SZ2LkMldc3eG44r6yYNNnDh35FA7FeMexJ MOuWcrwxslqZ1pFyqtdjdVY3pcVX4rLjE4mxEJg+5IIMf3UvjpLjLq7tLGIt28pnkiE1p+NW YgkxLPkwjRmcRY9mW3skysbDsMwaaRVkpy+fcbGy/8HYnghl+JuaKTE+XkuIHcLyIKvtUG8h W0FbdOIXnHUtftlCzSv8covthQM6MdXEKZqB33H0F7v77WBrMjJfoJgtD0VpDSlaAS0ET2MW fiFQK4xDiu78rCQBZmYxAWuwebxDWzrpBB8awd6iQCcYDJaG9m5S4MbpbhWoGcNhuRDhQPp1 gw5mm4PFteIBx/UJ7vMg8uw3o+gFkRjKrJzM7qCL2rHyvNKLKq7aJ8ztmiCnZIEYbcOIuLDO ThuZ/NdSUAPV79w4DVk0z9mg55NbXYe08SNqT4tSkY1wSs5v+Up1vaK28RGiKJJc83Uk9sN5 7VnLIZziHfZRXbIQFQ0DRP/mFkasWVvsedKHCDLyJAiSDCYWa4e1GiPrejSBQk+EMeDUX6q8 ssyki1+GfVqsFTwgPm+R1g/CNVJarZV+nKLWaf61T8IJOn7c5xYIizMQafJgN3FqdmoqjlqX TZqtWQLFwtZwGAAzkTUYDCB9CdOtbssR8Pj1PmzrsWeCNZspaLrKU8xGO+so3h8CsDy5Sk6Z XGe2D7YwXo9qSyI7RjCV2pAZYsiu89ITi2ySo4XjaDghJJ4WXhNOkIZUWaA/hkxmcVBQHNcJ fJQNaiR+o90i/4jaRuwuod60NdwlTidwyPFBxefR9VgdDU8t76+cadwVvzIyWuO5Myg8hHcZ lG7/6O1DJnSnsxR7J7tBCT/7elLS6SGsfs2233RbXSAUita+8PG6JXlBEF2ebWYi2g48qAeH rQyNcNeOObGngdDDzZhu8H7a8zQSjmLXg3wk1nImn5adQ1Jzsj0ezGC4/TsiGxJEr/Od74QJ XwFTFuJfrZlBzJwQlidYEju8kM/N9ILLa0KD7rTVwu2H0QMqEJKjg5+qJUNCJ3hQrfNzCWwg TD+FS0iBhFejBcVOvDVy/fEXA/Bd7b5w2NKPgrbqe9HVYfeLkSr0y5Au4Ggf+8rPfilch5/w Y1/8ww9+7kURfv7ZhbxSNX4guBGPUaEqZ/NiHTdpyv+l1lVDfYUCvEJW//1XgDbwSQaYgAZ4 TQrYgA74gBAYgRI4gRRYgRZ4geiQXuBgf06HVjhCehm1f3yUURyIKh7IIYLAGJpEBFBEDv8X BXpVHhfRMO9yAjX4XCN1gwiigVfQbgLogzYgL+ykYuy3gqonVKdHIrYBDiJoUsb0gkD2N76j JodzL4dUWFfIM1n4E1mIEiUYA5tDgCOoA69ACY5RHrfhGDd1fWA2BanSKiDyaFy4BPEEh07w B59SD8ZkILXHE30oTP8AiLw2FmKIA2G4AihUA1NiTZ9EZfCRGYVoBG/4hRmSRblkBHX4hYsy BBJyeWpSHuKAb5ogiiOkMqU4FMYUgrlXHiS0A/+TwIA8Ixbgoz8epnqQwk6UmCG+lItyZUx2 iItFgEnIN2Tg8FzSkBrSMIf6UIT1EIk4NRRHU2pNyFWzNDOzcoZ3go1apAR0kiq1xyIncSyy 9g7ygXa09FiidjzWYnCCxXJApEniuDPNsljmkkuaN4cd5EIOt48j1Bv9CB7HSHeEkFq2FSyL lI/Tklifty04CF+MhEnGtVhq2DXHYQY38jmiYY/QNXPCE1E/sU6Vp2U04YwgYjQvU3QWgRJL sz8naTklJA+V44cfcxPh5ZKIERFaowx+g0mECC5ywzZ8oY3Y0o/MyBT7uDCc0GRQc116oYxa aDmAkxzSMTDRmIbexYP/c1gQLNlSfsVMVcImX4KRN5KVG3E3NZRlTJkeHNONEPcwL1I8ooBE cNBBZ8FApSMPj2NnHDd5yAAnu8NG0LIdoTJYWHceXbVu2jgR72cPi4kd+pYVoyEWqRhSs5VK QVaV79Met1d30iUMoaNmr1iKfgWKJgRacGk/kflgydZ0/aNLMXKaRDE9KTkG9baBLikWeDk+ BOJYrhmbVxaX8bIHoOdlgzliyTEamxh0JXNE6NIpzSksu5lwnmZMz2A0VDFEqJY3wPNV6lNB +eWFvfmS9mAx47kM1WkYsDkrnCZkJdSNSfGLJJKTUvI06IgGN7OG1jVyaGFHq6ULaINkQBUQ /2KkF0JxMmzjJhODTPswGtgiQ/e2ljmRM/cmSdDYOPEmRyqpDXwQEg6XekYWiMl2n7aXmZVl nKkBL0qlnfrCh8IklfbGToIhRm3EGBU0De5JDlNEktkDD+IYTASKhobUo6h0S4L1LAP3dt3S GOnBMtX4ORRzSoHUmUNmHlQ2WX5UjZOUkfIRd/igeUy6MPZyReFyLmswcguzbYv1pavAm0Da mbXjpetYWFdHhE+nGVInXLUgjMkUC5eIgWt1pToqK42Siox1IrConX46GQCRok2Qh2TIi9Vx qIlKHQM4qZZ6qZiaqZq6qZzaqZ76qaAKqgFAAAPgA6Naqk4gAAUgAP8FmIgMYRuBCiBQ4aou MAAHcKu3agCsygIBcKuougO9egC/GgMFgKu3uqoyIAC3uqtHEADFegDMKgLKaqwHUADD6gPK GgC7YEZO0Vqx+mFPwa0wYA8CQADVOgDmCq28aqvXigMBwK4i0KvRugKqegCk+qzaCgPlqq5I 8K62agAlMKrnOgC2egAGkK/Yyq+KQKvq4ELx1AJJ6BAMyxHL0KuoqqztigLC+gMbCwDKOq/0 yq+2CrIs8LFMUAAFcAIdKwLmmrI/IK+8MLHogCyEugLnNE7TSIwi0LEm2wIrywMr+6sCkLEl 0LO2irAv0LNJoLQk8LMAYK4kmwMHkK8uqwP/Q0sCVbtUOStR33oDNYtVJ4gDFamKU4UTJkCt BYC0KuC0OsC2AGCtJUutBDADTHsEcKuy12qxQLCrAwCwO3C3ANC3hri1MfC1A2W4LXCzwWiV ZPsQZlsC9kqwxeqy06qwBVusGVuvG+uskwsAzrqsI3C5PHuwgWusaksCGEuwBmCvInC5+SoA BvCsaSut0Fq5AcC51Tqt2oq50loA6aqr8ZquBFC5BaurWQu57Rq7rYurQru6wPu5Iluttzq3 qGus89q3z4quvhq6x6qtBbus1vu00zsCBFAABkC6pqJcXiePI2FYlflYzUBYGOMMi/WRcKcL 48GF/XJJZZqRp5cs/9UipElppM21WK4VLTdYj4TiSdsgW7JUDpP0TkMRtNBqsdgrApirve2q rKQKvtVqrpyrvayaweZaqrrrsbE7AFFLu8xarAEAuwS7sZervdT7sbZqrdPqu1MLwihswrka w1MbACm8rJhbrypMtADAtr4rvvfKur16rwBbwtX6ttM7AMUarapqAARbAsLbt+e6uqwKw/AK uzicxVtcwuwarMKqsBkKVL2RRmC0duRFluwZXlEpMk8TLOSFMo8ZTeQ4NFODMx8klTEDaq9m DZtQXb+SxyXER4EMUTTUe3MDRuQ0Q+nDoGf7qxbrr87ruSurxJQ7AO+qrgJQub6qtztbqv8C m69aHLfM+rHlWrAmzMNv67eVu6ujHMYeO7Ui0MoCu6s2zMvv+sKsW76eu8JOu8krC8Lfu6zp OsVZHK9OK7gmEM27rK0mG8vbCwCt3Lp+q8a5GrgGMLcrPJWniEUE9JibaRJ8gQdZmpTDQURL 8TaNbEavc1zbqKI4Y5tJqZ1+RDL1nDNipyf8xjwjqC7KpLOZPALyKsTCar67zKxsq7wkALO7 TLAEW8oKy7O8zM1IPAJKm63T2rcX29HUrKyTm68Wfc29XNK4DK1HWwJX7LbIWwJHi8rXzK4Y fbvPysvU7NE27bcmcNLCTMq+2s3dLM7STKoZ3dKI+EMHpEFDI2D/t3Ge7Jk4IVUG2qWij1Im 0QgUCJQUdiKNY3gm71Z0uaGdXGI8eqIMGyQPN2rVCl3RrOu5LmyyEN2rwAuvXCzDworKvTq7 VqzXrMrX2drLVQvR1cyvZFy6t1vXh/20tgytLcuqOI2xpVvDHQvCHLzLKRus34y+AVutr1vC vayuzgqwnf202Pu53ivU4xzUKEDU2qq3N13XFK3UvQy8yorYkHhDInpcb0QRZYMwL+qa/8kI HBpW60NGsuAxzZg3EZEsj/YbWYRz7fA7+ImQ/sw7efHPJSFv8NEow51f2eQ6x+0OTpnE1Ira 7V26uXqsAbu68v2sfvu9pIvf8o2rI4yr/79ctO1NuqZM2sxru7havsdq39Kcq6ubsgOOqj2N vobttu0NurQbvlQs3/QNzfx9uSTwvVjs3/xN3yqMthk+tSBuyoXt3wo0dtrGafTpFTEzp0nG X9XYHPERUe/cSOn2wJXUXdJESDHG4zwpwBj2Z2HwLINhN4MCkTUIpdFdyWFgPbZ0LanAgxiN 0airwoF7sVs8tCTb1B4r5mM+rENrwlyO0ZZNsNjMxp6b5VwO0ir8roWd0f5aqmrur6VM5v76 wlyeuqK85Wbe0R4723AOsneOtGAurWKe6Gd+vXHO0Du9048+5gJA528e6F2Oy2zO6Fvc4qFa IbldBXWLAs760f8Woo2hXiGXbgi4erwnMLKrPutwoeYlu8K0nuu6vuu83uu+/uvAHuzCPuzE XuzGfuzInuzKvuzM3uzO/uzQHu3SPu3UXu3Wfu3Ynu3avu3c3u3e/u3gHu7iPu7kXu7mfu7o nu7qvu79tAARMAHwHgELMALwXu/1vgAOYO/6Pu8noAAToAL6HvD1Lu8jsAAC/+8PIPAPgAIO 8O7xzu8AYO8k4PATgAAFT/ERoAAi4O8HHwEJH/ALTwLwHvIiYPDw7gAjgAD5Xu8oDwAfPwEr r+8AsPIPgAAwXwIjTwImf/MjEPMwb/Ep4O4sD/Q9b+8OAPQrT/QRX+8l7/Atv/MtDwD/HD8B DzD1ETACFB/wRN/wE3/wE7Dz/37xA6/xUg/vEO/y9a7xBk/2JZLvEeAADc/0ACD0cB/3+P72 cV/3b48C7372JSD0DwD3fZ/wb+/wQI8AhA/3hD/374737x71XY/3LF/yOV/w8Y71E+D4Jz/3 MA/3mS/48t74gs/zRU/6iA/vZG/yih/vCCD0EaDyJ//4AIAAfW/zfr/yUX/6E0D2Nt/5Mc/2 JSD6cU/1ItD7dZ/2Um/4Yn/1Bv/29Y4AtJ/5bB/9X6/7EB8Bmn/8bA/vRI/9o3/8Qk/6wu/0 s+/wEO/6Fm/wSi8iBg/5HA/06k/5CpDxlH/4wD8CHH/1Qb/7/8UPAg4CTA8AONNyniU7RSei ypPDstGk4MtEoyaj3u6k47F8KscNMFudVs9aE5cCGk1OGA6gi82EwVTMCMayrtBsLjI8Xd+s B9pXjritv+GvXBvR5YiRVL34ubzMTSQNXVUtngRGjXAZFSX9QOkMtkD5yHWFio6Slpqeoqaq 4uCFzgx9ytysxZZGPByR+iDhIE69aAEsQP2igM4URlWmgO5urWFGKAwV16yJuP5gOWi1huqs 6DRpExfN8LKEbWvV6iUjh/oIc6bZWFZuAV76QCH2HgYTpkiUjR9JBnbxhUZZGSWcIniCtGoi xYoWL3apxkjZCHhEQHVRIMRHwC7OZv9oQaRDDiJJz8zEoydoBDOTRdqxkvgSxy9vGQsO4tYi 2QmRN0RCIjOnzKtsceB085NQ6jyQAn1OjVTw0AglEURgI1GSBMBRLut5WQjgbAt2Mi0pU2ok Isa6du/aFYkurcF52ux9tFVmzyiHP8b9BfW375a/VINYrVmTCI8UhTlpVNdH1BOkNFMSbWtJ SqVibzsTFurlMVw9gkfp0Jp2XKO/j8bi89eFLSEAIh/zRmRZVKxPciEWZY13OfPmvhcuEBeX G2BMVosurm7zgQPpZNVMZRK7xle5eqzGmoyp8tuq6RbOKI+PJw07KFIqB2xfyYruvTjXx4Vq 431DlXrf6MT/ShmSgEOCHN0dJlpWEobC1hV/7RWcFgda594XXkChgHLOkVjiRPHFBEtQe+HU hThM0JHgenAg4cJTwERRxS/DxDRWEBzZ1JVubdAHzU48ZgMFGQO+JdIaP4j4YR0AKgmDaikY SWFcoriBJUFaSBJGLP6gKFYoufm4VoJWijefmme65aM3tYiDnBNZmpinnqY0GJh7cFzyZyhG 5YSnMwl1Mx+ZXBTjQzIR0ueWkSu1AJ12mWHh6E9rbLKhm2npAeUXMlIpCCKedZHCXiQECuhz Mqna2qtiUAoTqETcZpZOsdZAj4YvWNpELQhsgueexyL7Uwkq+lETAjG+QYexuUQj/4qX9DG1 WQsNSeckoJbCgIR9wBKjQzBKPFAbVZri4G0QC6VQiLmC2BkdGmHEoEQhIoEUb07BbNIEsUMq A9jAd0A6sBYDEyEGGTQB9nDB1OATnSaDhJHqfLWSh8mygPpBbWNKjpisySUi9dc12VW3iVou P6nNg9pIpbJfKrAsRMqOcZldHiyIuNi6Pmv8QzA701w0Piil4zI5FQJBWD1GXugH04osFlrB jkWb3SPa8OKs0DjEaHNj2VVKWGK99rX22UAYpi1f1fFjyXUn4+3cAkwkowDffEOzNxMgCR6W MHzL4TcT0Pw9hOIo/D24E5EzAWAJSROHeGGahwR4OpQTpf+4A9AoYCQCnnNWBZI9DIp6UVn+ jUrhkfGdKudw9MDEqpCPbnvkadTOeyGxC2/F7YdLngTf6CxAjbF5Qx+99M3VPTAMd0+fvfbb c9+99xYhEL7445Nfvvnno5+++uuzX/7e4194ffvz01+//ffjn7/++/Pfv//ify+AOGAAAQto wAMiMIEKXCADG+jAB0IQDxGAIAUraMELYjCDGtwgBzvowQ8eUIAiHCEJS2jCE6IwhSpcIQtb 6MIXwjCGMpwhDWtowxviMIc63CEPe+jDHwIxiEIcIhGLaMQjIjGJSlwiE5voxCdCMYpSnCIV q2jFK2Ixi1rcIhe76MUvgjGMYhz/IxnLaMYzojGNalwjG9voxjfCMY5ynCMd62jHO+Ixj3rc Ix/76Mc/AjKQghwkIQtpyEMiMpEYSYAEEqDIRwoRAhSY5CQbWRdKUrIBJWrAJB0JyU/6kJOO ZCQF7CIBCQCAlJokUQIo4ElQwjKHrXylK+vSAFSeQAKrdM4sY+nLG/YSAA2AgCoa8Eoc3JIF uixRMH/pzBi2kpLLTEUtQ5FMYeKSldV8JjdbGExOElOYlczlJDUpyUmGkwWcHCcy2UnKRjbA mJT0JCcl4EpSUsCejlxnNrvpzxE2k5PYPAEEICBKSZ5gm8hEJTjVicuCAkACxIwmAEoJAIja s5QGlegJ/0RZ0Xgq9J8i7V4zW3lRTLoykwk9pkPJucpzUrKiE6XAS+2Jy2sK9AS9zGg6R+rT 7QVUoz1NJQT0WVGWdhSX0XQkRNvJTo7i9KYWTWU1i0rTn2I1e61cJSM1yUlNMlKSCejlVUNx SnXmMwFfTSUqm6rTWp51oAm1pFjXStOwZjWvJoumNHfJT7Wq9KRlJWhg1wnStAq2nBHNZz35 OkqbRnOdFAhnTvVqWR1WtqjLueZlO2tDj+IVLyH1LGlhCNOhlja1ql0ta1vr2tfCNrayna33 murWU1yTkUilLW/zBNNKItWexBRuFySLSZCicqm9Xe6xQGtPFtg2nLd9qye3Kv/XYE6Tudpd TjOrKt3vimKbV81tNbO73fMusprDFEV0w4tU8u4WvfKlCF8Zy17whqK8lFXqaOfrX1V8c7IE fSl+u4DS/VI3l57MqFJPCdz/+jeoJyUwQVF71FwimKqONGo8NRzNcMYVwugtqUWn2d78vpe/ nlTvOVdMz6mKeLsSjiiFL2rhbW4VvivFpiarWU2Txvi81mXrKjl60Yf2862rXKc4R1nWq0J0 rR/tKIyD3Nv62lecjM1kTF0Hos46NqPDROeHJXlLdFa0k1ZeM5vavWb3wznOcp4znets5zvj Oc963jOf++znPwM60IIeNKF3b6hDIzrRip07hxvt6EcGQzrShAwBADs= --------------AttPart_28301711==.OLA-- From capwap-admin@frascone.com Mon Oct 17 00:20:18 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERMTv-0004Wn-K2 for capwap-archive@megatron.ietf.org; Mon, 17 Oct 2005 00:20:18 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA13705 for ; Mon, 17 Oct 2005 00:20:06 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 55C4E2041D; Mon, 17 Oct 2005 00:20:05 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from smtp1.mei.co.jp (smtp.mei.co.jp [133.183.129.25]) by mail.frascone.com (Postfix) with ESMTP id ED7D820365 for ; Mon, 17 Oct 2005 00:19:42 -0400 (EDT) Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp1.mei.co.jp (8.12.10/3.7W/jazz) with ESMTP id j9H4JWlx023220; Mon, 17 Oct 2005 13:19:32 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx1) with ESMTP id j9H4JWW15886; Mon, 17 Oct 2005 13:19:32 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/expos) with ESMTP id j9H4JNQ24129; Mon, 17 Oct 2005 13:19:24 +0900 (JST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Capwap] Change Request 9.1.3.1. Support for Local MAC User Data Tunneling Message-ID: <5F09D220B62F79418461A978CA0921BD6DF2AD@pslexc01.psl.local> Thread-Topic: [Capwap] Change Request 9.1.3.1. Support for Local MAC User Data Tunneling Thread-Index: AcXEZkqBuwf+LMdnQ8KyHVKiUjMwyAA02ebAAAHWmtAAJ8HLcAAM1MswASFdofABkSUkgAB8v4Zw From: "Saravanan Govindan" To: "Darren Loher" , "Sadot, Emek (Emek)" , "Pat Calhoun (pacalhou)" , , "Puneet Agarwal" , "Michael Montemurro" , "Dan Harkins" 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-Unsubscribe: , List-Id: A list for CAPWAP technical discussions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 17 Oct 2005 12:16:22 +0800 Content-Transfer-Encoding: quoted-printable Dareen, I agree with the recommendation for user data tunneling. From a practical point, the Architecture Taxonomy points out that there are designs in which user data is tunneled to the AC for local-MAC WTPs. So it is important for the CAPWAP protocol address these types of WLAN products. Saravanan ________________________________ From: Darren Loher [mailto:DLoher@rovingplanet.com]=20 Sent: Saturday, October 15, 2005 1:31 AM To: Sadot, Emek (Emek); Pat Calhoun (pacalhou); capwap@frascone.com; Puneet Agarwal; Michael Montemurro; Saravanan Govindan; Dan Harkins Subject: RE: [Capwap] Change Request 9.1.3.1. Support for Local MAC User Data Tunneling =09 =09 The evaluation draft made a strongly recommendation that an option for a Local-MAC mode with user data tunneling be explored on by the working group. The eval draft listed a few reasons why it might be worth having such a solution. I heard support for such a solution from members of the working group off and on the mailing list. In addition, it appears to be an innovative solution which CTP and SLAPP allowed for in some way. =20 There are many details that need to be specified for exactly how this would work which we are starting to talk about. However, it is useful to hear from the WG at large if a capability like this is necessary. =20 =20 Is a capability for tunneling of user data in 802.3 format for Local MAC mode needed? =20 =20 -Darren =20 =20 ________________________________ From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Sadot, Emek (Emek) Sent: Thursday, October 06, 2005 11:18 AM To: Pat Calhoun (pacalhou); capwap@frascone.com Subject: RE: [Capwap] Change Request 9.1.3.1. Support for Local MAC User Data Tunneling =20 Pat, =20 Yes, that's how I interpreted it, with a disclaimer for 802.11 control and management frames only. It goes for option #3 and #2. =20 Regards, Emek =20 ________________________________ From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com] Sent: Saturday, October 01, 2005 4:26 PM To: Sadot, Emek (Emek); capwap@frascone.com Subject: RE: [Capwap] Change Request 9.1.3.1. Support for Local MAC User Data Tunneling Emek, =20 In option 3, when a user associates with the WTP, the association is handled locally, but the packet is tunneled to the AC in order for the AC to have access to usage information (and make overriding policy decisions). So 802.11 needs to be supported on the AC regardless, right? =20 Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 =20 ________________________________ From: Sadot, Emek (Emek) [mailto:esadot@avaya.com]=20 Sent: Friday, September 30, 2005 10:16 AM To: Pat Calhoun (pacalhou); capwap@frascone.com Subject: RE: [Capwap] Change Request 9.1.3.1. Support for Local MAC User Data Tunneling Regarding the points you raised I believe option #2 and #3 share the same qualities. In both options 802.11 encryption and 11e cannot be implemented at the AC. In both options a mechanism shall be design to extract RF and data-traffic statistics either (a) appended in the tunneling (option #3 only) or (b) exposed by the WTP as read-only values for the AC inquiries (both options). =20 Am I missing something? =20 On the other hand one can respect the unique merits that these options offer: - option 2: non-appliance product. meaning a software based AC that can be executed on any server / platform. - option 3: avoid parse 802.11 traffic in silicon at the AC. Leverage existing products (e.g. routers) with "only" add-on 802.11 code running at the Cpu. =20 Emek =20 ________________________________ From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com]=20 Sent: Thursday, September 29, 2005 6:01 PM To: Sadot, Emek (Emek); capwap@frascone.com Subject: RE: [Capwap] Change Request 9.1.3.1. Support for Local MAC User Data Tunneling In terms of option 2, no traffic is sent to the AC, so the model is quite different. =20 Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 =20 ________________________________ From: Sadot, Emek (Emek) [mailto:esadot@avaya.com]=20 Sent: Thursday, September 29, 2005 2:16 PM To: Pat Calhoun (pacalhou); capwap@frascone.com Subject: RE: [Capwap] Change Request 9.1.3.1. Support for Local MAC User Data Tunneling Pat, you certainly raise valid questions w.r.t. option #3, however I am curious as to the differences between the challenges you listed between options #2 and #3. In other words, in what sense option #2 and #3 are differ w.r.t. encryption and 11e at the AC, as well as RSSI/SNR/data-rate/other monitoring support? =20 Regards, Emek =20 ________________________________ From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Pat Calhoun (pacalhou) Sent: Wednesday, September 28, 2005 5:32 PM To: capwap@frascone.com Subject: [Capwap] Change Request 9.1.3.1. Support for Local MAC User Data Tunneling This change request is to allow for 802.3 tunneling of user data in local bridging mode. I believe that the changes should be relatively straightforward, but do introduce an interesting set of complications that need to be evaluated and agreed upon as a group. =20 The LWAPP protocol currently allows for 802.11 tunneling in Split-MAC mode, allowing for such things as centralized encryption of user data frames. However, the current definition of the protocol is that when running in Local-MAC mode, no traffic is tunneled to the controller. =20 If we were to introduce this change, the LWAPP protocol would have three modes of operation: 1. Split-MAC: Tunnel native MAC frames in UDP (e.g., 802.11) 2. Local-MAC w/ Local Bridge: Do not tunnel 802.3 frames 3. Local-MAC w/ Tunnel: Tunnel 802.3 frames in UDP =20 The issue that we need to decide as a group is whether we really want a protocol that has three modes of operation, and if so, which one is mandatory. The evaluation draft states that option 3 is useful for support of non 802.11 technologies, but this introduces a set of restrictions. For instance, today the LWAPP protocol allows for centralized control of various 802.11 functions, including encryption and 802.11e. This function is not possible with option 3, and therefore any new technology that assumes this option would not be able to provide centralization of data frame functions. =20 There is a comment in the recommendation that LWAPP could retain the RSSI/SNR fields, and then perform 802.3 encapsulation, allowing the AC to have more visibility. However, I have had some requests to expand these fields to also include the data rate. Further, there are possible fields in the header (of technologies we know nothing about) that the WTP may want to extract and expose to the AC - and how could this be done with 802.3? Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Mon Oct 17 12:58:13 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERYJN-00015M-Lu for capwap-archive@megatron.ietf.org; Mon, 17 Oct 2005 12:58:11 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24198 for ; Mon, 17 Oct 2005 12:58:01 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id C38A4204AC; Mon, 17 Oct 2005 12:58:04 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from pop-siberian.atl.sa.earthlink.net (pop-siberian.atl.sa.earthlink.net [207.69.195.71]) by mail.frascone.com (Postfix) with ESMTP id 3CAAD204A7 for ; Mon, 17 Oct 2005 12:57:37 -0400 (EDT) Received: from elwamui-milano.atl.sa.earthlink.net ([209.86.224.40]) by pop-siberian.atl.sa.earthlink.net with esmtp (Exim 3.36 #10) id 1ERYIq-0002VJ-00; Mon, 17 Oct 2005 12:57:36 -0400 Message-ID: <14483209.1129568256523.JavaMail.root@elwamui-milano.atl.sa.earthlink.net> From: "Scott G. Kelly" Reply-To: "Scott G. Kelly" To: capwap@frascone.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: EarthLink Zoo Mail 1.0 Subject: [Capwap] draft-kelly-capwap-lwapp-dtls-00.txt available 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-Unsubscribe: , List-Id: A list for CAPWAP technical discussions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 17 Oct 2005 09:57:36 -0700 (GMT-07:00) Content-Transfer-Encoding: 7bit Hi All, Eric Rescorla and I have written a draft explaining how to use DTLS to secure LWAPP. Unfortunately, I missed the ID editor's deadline by an hour or so (danged xml2rfc documentation doesn't explain reference creation very well!), but you can see the current doc here, for the time being: http://www.capwap.org/DraftsForEvaluation/draft-kelly-capwap-lwapp-dtls-00.txt --Scott _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Tue Oct 18 08:05:13 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERqDQ-0006t2-UE for capwap-archive@megatron.ietf.org; Tue, 18 Oct 2005 08:05:12 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25207 for ; Tue, 18 Oct 2005 08:05:03 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 7F773204B2; Tue, 18 Oct 2005 08:05:04 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from sccrmhc11.comcast.net (sccrmhc11.comcast.net [63.240.77.81]) by mail.frascone.com (Postfix) with ESMTP id 36B6020455 for ; Tue, 18 Oct 2005 08:04:31 -0400 (EDT) Received: from [192.168.0.2] (pcp04510339pcs.gambrl01.md.comcast.net[68.49.199.146]) by comcast.net (sccrmhc11) with ESMTP id <20051018120430011003r3ooe>; Tue, 18 Oct 2005 12:04:30 +0000 Message-ID: <4354E53A.1070304@cs.umd.edu> From: Charles Clancy User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: capwap@frascone.com Subject: Re: [Capwap] draft-kelly-capwap-lwapp-dtls-00.txt available References: <14483209.1129568256523.JavaMail.root@elwamui-milano.atl.sa.earthlink.net> In-Reply-To: <14483209.1129568256523.JavaMail.root@elwamui-milano.atl.sa.earthlink.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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-Unsubscribe: , List-Id: A list for CAPWAP technical discussions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 18 Oct 2005 08:06:18 -0400 Content-Transfer-Encoding: 7bit The draft looks good to me. I'd have more warm fuzzies if I saw some ASCII art showing the TLS handshake, though it's probably unnecessary. I haven't been following the L2 vs L3 threads, but if L2 support stays, I think we should do muxing, and if it doesn't, we should do port-based delineation of control and data flows. On a side note, with respect to the security evaluation, there were some subtle security issues raised in the review. The authors quickly addressed them in -03 by redesigning the authentication protocol and adding some clarifying text. [ t. charles clancy ]--[ tcc@umd.edu ]--[ www.cs.umd.edu/~clancy ] [ computer science ]-----[ university of maryland | college park ] Scott G. Kelly wrote: > Hi All, > > Eric Rescorla and I have written a draft explaining how to use DTLS to secure LWAPP. Unfortunately, I missed the ID editor's deadline by an hour or so (danged xml2rfc documentation doesn't explain reference creation very well!), but you can see the current doc here, for the time being: > > http://www.capwap.org/DraftsForEvaluation/draft-kelly-capwap-lwapp-dtls-00.txt > > --Scott > > > > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Tue Oct 18 09:21:10 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERrOv-0007tk-Ni for capwap-archive@megatron.ietf.org; Tue, 18 Oct 2005 09:21:10 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29337 for ; Tue, 18 Oct 2005 09:21:02 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 3D1F8204B2; Tue, 18 Oct 2005 09:21:04 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from rwcrmhc12.comcast.net (rwcrmhc12.comcast.net [216.148.227.85]) by mail.frascone.com (Postfix) with ESMTP id 4063420455 for ; Tue, 18 Oct 2005 09:20:23 -0400 (EDT) Received: from [192.168.128.4] (c-24-6-197-92.hsd1.ca.comcast.net[24.6.197.92]) by comcast.net (rwcrmhc12) with ESMTP id <20051018132021014000ustme>; Tue, 18 Oct 2005 13:20:21 +0000 Message-ID: <4354F695.7090704@hyperthought.com> From: Scott G Kelly User-Agent: Mozilla Thunderbird 1.0.7-1.1.fc4 (X11/20050929) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Charles Clancy Cc: capwap@frascone.com Subject: Re: [Capwap] draft-kelly-capwap-lwapp-dtls-00.txt available References: <14483209.1129568256523.JavaMail.root@elwamui-milano.atl.sa.earthlink.net> <4354E53A.1070304@cs.umd.edu> In-Reply-To: <4354E53A.1070304@cs.umd.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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-Unsubscribe: , List-Id: A list for CAPWAP technical discussions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 18 Oct 2005 06:20:21 -0700 Content-Transfer-Encoding: 7bit Hi Charles, Thanks for your comments. The 00 rev was a bit rushed trying to hit the ID editor's deadline for the upcoming IETF (which was, as it turned out, missed anyway). The next rev will have more detail, as well as formatting improvements. I also noticed a cut-and-paste error in the MAY cipher list for certs. This will be fixed as well. Scott Charles Clancy wrote: > The draft looks good to me. I'd have more warm fuzzies if I saw some > ASCII art showing the TLS handshake, though it's probably unnecessary. > > I haven't been following the L2 vs L3 threads, but if L2 support stays, > I think we should do muxing, and if it doesn't, we should do port-based > delineation of control and data flows. > > On a side note, with respect to the security evaluation, there were some > subtle security issues raised in the review. The authors quickly > addressed them in -03 by redesigning the authentication protocol and > adding some clarifying text. > > [ t. charles clancy ]--[ tcc@umd.edu ]--[ www.cs.umd.edu/~clancy ] > [ computer science ]-----[ university of maryland | college park ] > > Scott G. Kelly wrote: > >> Hi All, >> >> Eric Rescorla and I have written a draft explaining how to use DTLS to >> secure LWAPP. Unfortunately, I missed the ID editor's deadline by an >> hour or so (danged xml2rfc documentation doesn't explain reference >> creation very well!), but you can see the current doc here, for the >> time being: >> >> http://www.capwap.org/DraftsForEvaluation/draft-kelly-capwap-lwapp-dtls-00.txt >> >> >> --Scott >> >> >> >> _______________________________________________ >> Capwap mailing list >> Capwap@frascone.com >> http://mail.frascone.com/mailman/listinfo/capwap > > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap > _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Tue Oct 18 11:15:21 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERtBR-0002IT-0C for capwap-archive@megatron.ietf.org; Tue, 18 Oct 2005 11:15:21 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09271 for ; Tue, 18 Oct 2005 11:15:08 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B363E204A3; Tue, 18 Oct 2005 11:15:04 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from tierw.net.avaya.com (tierw.net.avaya.com [198.152.13.100]) by mail.frascone.com (Postfix) with ESMTP id 6F7DA1FC9C for ; Tue, 18 Oct 2005 11:14:52 -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 j9IF12ED010386 for ; Tue, 18 Oct 2005 11:01:03 -0400 (EDT) Received: from nj7460avexu2.global.avaya.com (h198-152-6-52.avaya.com [198.152.6.52]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id j9IEx4ED008036 for ; Tue, 18 Oct 2005 10:59:54 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Capwap] Change Request 9.1.3.1. Support for Local MAC User Data Tunneling Message-ID: <5844A41F4E146044A2E8356C6328588009D5531A@nj7460avexu2.global.avaya.com> Thread-Topic: [Capwap] Change Request 9.1.3.1. Support for Local MAC User Data Tunneling Thread-Index: AcXQ7VBZrYBkWx9zSaGI/RYMe4JoiAACIsQgAI5GA3A= From: "Sadot, Emek (Emek)" To: "Puneet Agarwal" , "Michael Montemurro" , "Darren Loher" , "Pat Calhoun (pacalhou)" , , "Saravanan Govindan" , "Dan Harkins" 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-Unsubscribe: , List-Id: A list for CAPWAP technical discussions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 18 Oct 2005 11:10:53 -0400 Content-Transfer-Encoding: quoted-printable Reaffirming my statement below: I'm supportive in supporting tunneling and local mode from Local-MAC architecture. I would encourage the group to consider the latter as the default mode, as such mode could encompass most of the deployments today. =20 Regards, Emek (resending as plain text format as the previous html was, presumably, too big) ________________________________ From: Puneet Agarwal [mailto:pagarwal@broadcom.com]=20 Sent: Friday, October 14, 2005 5:18 PM To: Michael Montemurro; Darren Loher; Sadot, Emek (Emek); Pat Calhoun (pacalhou); capwap@frascone.com; Saravanan Govindan; Dan Harkins Subject: RE: [Capwap] Change Request 9.1.3.1. Support for Local MAC User Data Tunneling I concur with Darren and Mike. Supporting Local MAC in both tunnel and local mode allows for a rich set of network deployments and hence must be supported by CAPWAP. =20 Thanks. =20 -Puneet ________________________________ From: Michael Montemurro [mailto:michael.montemurro@siemens.com]=20 Sent: Friday, October 14, 2005 11:28 AM To: Darren Loher; Sadot, Emek (Emek); Pat Calhoun (pacalhou); capwap@frascone.com; Puneet Agarwal; Saravanan Govindan; Dan Harkins Subject: RE: [Capwap] Change Request 9.1.3.1. Support for Local MAC User Data Tunneling From my point of view, supporting Local MAC in both a tunnel mode (user data tunnelling between the AC and the WTP) and local mode ( bridging locally at the WTP) allows the protocol to be applied to a wide variety of network deployments. It must be supported by the protocol. =20 As for the frame format, from my point of view, in a split MAC case, it would much easier to use 802.11 frames for data frame tunnelling, but for the local MAC case, it is much easier to use 802.3 frames.=20 =20 A comparison of an 802.11 frame to an 802.3 frame (ignoring PHY) looks as follows: =20 802.11: Frame CTL Duration DA SA RA/BSSID Sequence Control Address4 (WDS) QoS Control Frame Body FCS 802.3: DA SA Priority CFI VLAN Frame Body FCS =20 Comments on comparison of the two formats: - Frame CTL, Sequence Control, and Duration are of limited value at the AC for local MAC, they may be useful depending on how you define split MAC - FCS for 802.11 and FCS for 802.3 are calculated differently, I believe - There is a well defined mapping between QoS Control in 802.11 and Priority 802.1p bits in 802.3 - There is an implicit mapping between BSSID and VLAN tag - One open issue would be how to address 802.11e Admission Control =20 802.3 provides the basic imformation that the WTP or the AC needs to process packets in the local MAC case. It would probably provide enough information depending on how you define split MAC. However, you may be able to move some of that information into the CAPWAP header if you used an 802.3 frame format. =20 One of the issues we have is that if you read the Taxonomy document, the definition of local MAC and to some extent, even split MAC, are open to interpretation. That is why Pat, Inderpreet, and Bob submitted the Taxonomy Recommendations document at the last meeting. =20 Cheers, =20 Mike ________________________________ From: Darren Loher [mailto:DLoher@rovingplanet.com]=20 Sent: October 14, 2005 1:31 PM To: Sadot, Emek (Emek); Pat Calhoun (pacalhou); capwap@frascone.com; Puneet Agarwal; Michael Montemurro; Saravanan Govindan; Dan Harkins Subject: RE: [Capwap] Change Request 9.1.3.1. Support for Local MAC User Data Tunneling =09 =09 The evaluation draft made a strongly recommendation that an option for a Local-MAC mode with user data tunneling be explored on by the working group. The eval draft listed a few reasons why it might be worth having such a solution. I heard support for such a solution from members of the working group off and on the mailing list. In addition, it appears to be an innovative solution which CTP and SLAPP allowed for in some way. =20 There are many details that need to be specified for exactly how this would work which we are starting to talk about. However, it is useful to hear from the WG at large if a capability like this is necessary. =20 =20 Is a capability for tunneling of user data in 802.3 format for Local MAC mode needed? =20 =20 -Darren =20 =20 ________________________________ From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Sadot, Emek (Emek) Sent: Thursday, October 06, 2005 11:18 AM To: Pat Calhoun (pacalhou); capwap@frascone.com Subject: RE: [Capwap] Change Request 9.1.3.1. Support for Local MAC User Data Tunneling =20 Pat, =20 Yes, that's how I interpreted it, with a disclaimer for 802.11 control and management frames only. It goes for option #3 and #2. =20 Regards, Emek =20 ________________________________ From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com] Sent: Saturday, October 01, 2005 4:26 PM To: Sadot, Emek (Emek); capwap@frascone.com Subject: RE: [Capwap] Change Request 9.1.3.1. Support for Local MAC User Data Tunneling Emek, =20 In option 3, when a user associates with the WTP, the association is handled locally, but the packet is tunneled to the AC in order for the AC to have access to usage information (and make overriding policy decisions). So 802.11 needs to be supported on the AC regardless, right? =20 Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 =20 ________________________________ From: Sadot, Emek (Emek) [mailto:esadot@avaya.com]=20 Sent: Friday, September 30, 2005 10:16 AM To: Pat Calhoun (pacalhou); capwap@frascone.com Subject: RE: [Capwap] Change Request 9.1.3.1. Support for Local MAC User Data Tunneling Regarding the points you raised I believe option #2 and #3 share the same qualities. In both options 802.11 encryption and 11e cannot be implemented at the AC. In both options a mechanism shall be design to extract RF and data-traffic statistics either (a) appended in the tunneling (option #3 only) or (b) exposed by the WTP as read-only values for the AC inquiries (both options). =20 Am I missing something? =20 On the other hand one can respect the unique merits that these options offer: - option 2: non-appliance product. meaning a software based AC that can be executed on any server / platform. - option 3: avoid parse 802.11 traffic in silicon at the AC. Leverage existing products (e.g. routers) with "only" add-on 802.11 code running at the Cpu. =20 Emek =20 ________________________________ From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com]=20 Sent: Thursday, September 29, 2005 6:01 PM To: Sadot, Emek (Emek); capwap@frascone.com Subject: RE: [Capwap] Change Request 9.1.3.1. Support for Local MAC User Data Tunneling In terms of option 2, no traffic is sent to the AC, so the model is quite different. =20 Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 =20 ________________________________ From: Sadot, Emek (Emek) [mailto:esadot@avaya.com]=20 Sent: Thursday, September 29, 2005 2:16 PM To: Pat Calhoun (pacalhou); capwap@frascone.com Subject: RE: [Capwap] Change Request 9.1.3.1. Support for Local MAC User Data Tunneling Pat, you certainly raise valid questions w.r.t. option #3, however I am curious as to the differences between the challenges you listed between options #2 and #3. In other words, in what sense option #2 and #3 are differ w.r.t. encryption and 11e at the AC, as well as RSSI/SNR/data-rate/other monitoring support? =20 Regards, Emek =20 ________________________________ From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Pat Calhoun (pacalhou) Sent: Wednesday, September 28, 2005 5:32 PM To: capwap@frascone.com Subject: [Capwap] Change Request 9.1.3.1. Support for Local MAC User Data Tunneling This change request is to allow for 802.3 tunneling of user data in local bridging mode. I believe that the changes should be relatively straightforward, but do introduce an interesting set of complications that need to be evaluated and agreed upon as a group. =20 The LWAPP protocol currently allows for 802.11 tunneling in Split-MAC mode, allowing for such things as centralized encryption of user data frames. However, the current definition of the protocol is that when running in Local-MAC mode, no traffic is tunneled to the controller. =20 If we were to introduce this change, the LWAPP protocol would have three modes of operation: 1. Split-MAC: Tunnel native MAC frames in UDP (e.g., 802.11) 2. Local-MAC w/ Local Bridge: Do not tunnel 802.3 frames 3. Local-MAC w/ Tunnel: Tunnel 802.3 frames in UDP =20 The issue that we need to decide as a group is whether we really want a protocol that has three modes of operation, and if so, which one is mandatory. The evaluation draft states that option 3 is useful for support of non 802.11 technologies, but this introduces a set of restrictions. For instance, today the LWAPP protocol allows for centralized control of various 802.11 functions, including encryption and 802.11e. This function is not possible with option 3, and therefore any new technology that assumes this option would not be able to provide centralization of data frame functions. =20 There is a comment in the recommendation that LWAPP could retain the RSSI/SNR fields, and then perform 802.3 encapsulation, allowing the AC to have more visibility. However, I have had some requests to expand these fields to also include the data rate. Further, there are possible fields in the header (of technologies we know nothing about) that the WTP may want to extract and expose to the AC - and how could this be done with 802.3? Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From 71hamlin@accessatc.net Wed Oct 19 07:23:59 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESC35-0006ME-8k for capwap-archive@megatron.ietf.org; Wed, 19 Oct 2005 07:23:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08055 for ; Wed, 19 Oct 2005 07:23:49 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESCEm-00084V-Qz for capwap-archive@ietf.org; Wed, 19 Oct 2005 07:36:06 -0400 Received: from cpc1-bexl2-6-0-cust113.bmly.cable.ntl.com ([80.6.155.113] helo=80.6.155.113) by mx2.foretec.com with smtp (Exim 4.24) id 1ESC2v-0005FE-UD for capwap-archive@ietf.org; Wed, 19 Oct 2005 07:23:52 -0400 Message-ID: From: "Jennifer A. Clark" <71hamlin@accessatc.net> To: capwap-archive@ietf.org Subject: =?iso-8859-1?B?V2luZG93cyBYUCAtIHZlcnkgbG93IHByaWNl?= Date: Wed, 19 Oct 2005 11:09:28 +0000 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0000_43D43F78.15B9DDE8" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express V6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 1.2 (+) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc This is a multi-part message in MIME format. ------=_NextPart_000_0000_43D43F78.15B9DDE8 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0001_920DA290.C13A291A" ------=_NextPart_001_0001_920DA290.C13A291A Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Get access to all the popular software you need for bottom prices! We sell software 2-6 times cheaper than retail price. Examples: $79.95 Windows XP Professional (Including: Service Pack 2) $89.95 Microsoft Office 2003 Professional / $79.95 Office XP Professional $99.95 Adobe Photoshop 8.0/CS (Including: ImageReady CS) $69.95 Dreamweaver MX 2004 / Flash MX 2004 / Fireworks MX $149.95 Adobe Creative Suite Premium (5 CD) $79.95 Adobe Acrobat 6.0 Professional $69.95 MS Project 2003 Professional Special offers: $89.95 Windows XP Pro + Office XP Pro $129.95 Photoshop 7 + Premiere 7 + Illustrator 10 $109.95 Dreamweaver MX 2004 + Flash MX 2004 All main products from Microsoft, Adobe, Macromedia, Corel, etc. And many more... Please visit us at: http://www.cddisks.org Regards, Jennifer A. Clark ________________________________ To change your mail preferences, go here ________________________________ ------=_NextPart_001_0001_920DA290.C13A291A Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: 7bit
Get access to all the popular software you need for bottom prices!
We sell software 2-6 times cheaper than retail price.

Examples:
$79.95 Windows XP Professional (Including: Service Pack 2)
$89.95 Microsoft Office 2003 Professional / $79.95 Office XP Professional
$99.95 Adobe Photoshop 8.0/CS (Including: ImageReady CS)
$69.95 Dreamweaver MX 2004 / Flash MX 2004 / Fireworks MX
$149.95 Adobe Creative Suite Premium (5 CD)
$79.95 Adobe Acrobat 6.0 Professional
$69.95 MS Project 2003 Professional

Special offers:
$89.95 Windows XP Pro + Office XP Pro
$129.95 Photoshop 7 + Premiere 7 + Illustrator 10
$109.95 Dreamweaver MX 2004 + Flash MX 2004

All main products from Microsoft, Adobe, Macromedia, Corel, etc.
And many more... Please visit us at:

http://www.cddisks.org

Regards,
Jennifer A. Clark


________________________________
To change your mail preferences, go here
________________________________

------=_NextPart_001_0001_920DA290.C13A291A-- ------=_NextPart_000_0000_43D43F78.15B9DDE8-- From capwap-admin@frascone.com Wed Oct 19 12:33:20 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESGsS-0007hv-1f for capwap-archive@megatron.ietf.org; Wed, 19 Oct 2005 12:33:20 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27132 for ; Wed, 19 Oct 2005 12:33:07 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 92C7320270; Wed, 19 Oct 2005 12:33:03 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from tierw.net.avaya.com (tierw.net.avaya.com [198.152.13.100]) by mail.frascone.com (Postfix) with ESMTP id 092861FE12 for ; Wed, 19 Oct 2005 12:32:38 -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 j9JGIkMf003629 for ; Wed, 19 Oct 2005 12:18:47 -0400 (EDT) Received: from nj7460avexu2.global.avaya.com (h198-152-6-52.avaya.com [198.152.6.52]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id j9JGIkMf003592 for ; Wed, 19 Oct 2005 12:18:46 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Capwap] Change Request 9.1.3.1. Support for Local MAC User Data Tunneling Message-ID: <5844A41F4E146044A2E8356C6328588009D557B2@nj7460avexu2.global.avaya.com> Thread-Topic: [Capwap] Change Request 9.1.3.1. Support for Local MAC User Data Tunneling Thread-Index: AcXQ7VBZrYBkWx9zSaGI/RYMe4JoiAACIsQgAI5GA3AALmKssAALJ2sg From: "Sadot, Emek (Emek)" To: "Pat Calhoun (pacalhou)" , "Puneet Agarwal" , "Michael Montemurro" , "Darren Loher" , , "Saravanan Govindan" , "Dan Harkins" 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-Unsubscribe: , List-Id: A list for CAPWAP technical discussions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 19 Oct 2005 12:32:34 -0400 Content-Transfer-Encoding: quoted-printable Pat, =20 I share your concern about complexity increasing, and I concur that we should shy away as much as possible, but isn't the Local-MAC with tunneling architecture is simply an hybrid of Split-MAC and Local-MAC with DS at the WTP, excluding an indication as of which layer 2 the tunneling carries - 802.11 or 802.3? In other words, and please correct me if I am wrong, Local-MAC with tunneling mode just make use, and re-position, Local-MAC with DS at the WTP and Split MAC internal components. Examples would be: reuse of Split-MAC DS support at the AC, or reuse the 802.11 to 802.3 converting function at the Local-MAC WTP, or reuse Local-MAC method to convey 802.11 MAC info (e.g. RSSI) to the AC, etc. Regards, Emek ________________________________ From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com]=20 Sent: Tuesday, October 18, 2005 11:53 AM To: Sadot, Emek (Emek); Puneet Agarwal; Michael Montemurro; Darren Loher; capwap@frascone.com; Saravanan Govindan; Dan Harkins Subject: RE: [Capwap] Change Request 9.1.3.1. Support for Local MAC User Data Tunneling My personal opinion is that we should not, and for one reason only - decreased complexity. What I am concerned about is the raw number of tunneling options and modes of operation the protocol will end up having to support. That said, I will go with the group's sentiment (which so far is in agreement with this suggestion). Regardless of whether this work is included or not, I agree with Emek's recommendation for the default mode (which I believe is a point made in the Taxonomy recommmendations draft). Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 ________________________________ From: Sadot, Emek (Emek) [mailto:esadot@avaya.com]=20 Sent: Monday, October 17, 2005 8:39 AM To: Puneet Agarwal; Michael Montemurro; Darren Loher; Pat Calhoun (pacalhou); capwap@frascone.com; Saravanan Govindan; Dan Harkins Subject: RE: [Capwap] Change Request 9.1.3.1. Support for Local MAC User Data Tunneling =09 =09 Reaffirming my statement below: I'm supportive in supporting tunneling and local mode from Local-MAC architecture. I would even suggest that the group would consider the latter as the default mode, as such mode could encompass most of the deployments today. =20 Regards, Emek ________________________________ From: Puneet Agarwal [mailto:pagarwal@broadcom.com]=20 Sent: Friday, October 14, 2005 5:18 PM To: Michael Montemurro; Darren Loher; Sadot, Emek (Emek); Pat Calhoun (pacalhou); capwap@frascone.com; Saravanan Govindan; Dan Harkins Subject: RE: [Capwap] Change Request 9.1.3.1. Support for Local MAC User Data Tunneling =09 =09 I concur with Darren and Mike. Supporting Local MAC in both tunnel and local mode allows for a rich set of network deployments and hence must be supported by CAPWAP. =20 Thanks. =20 -Puneet ________________________________ From: Michael Montemurro [mailto:michael.montemurro@siemens.com] Sent: Friday, October 14, 2005 11:28 AM To: Darren Loher; Sadot, Emek (Emek); Pat Calhoun (pacalhou); capwap@frascone.com; Puneet Agarwal; Saravanan Govindan; Dan Harkins Subject: RE: [Capwap] Change Request 9.1.3.1. Support for Local MAC User Data Tunneling =09 =09 From my point of view, supporting Local MAC in both a tunnel mode (user data tunnelling between the AC and the WTP) and local mode ( bridging locally at the WTP) allows the protocol to be applied to a wide variety of network deployments. It must be supported by the protocol. =20 As for the frame format, from my point of view, in a split MAC case, it would much easier to use 802.11 frames for data frame tunnelling, but for the local MAC case, it is much easier to use 802.3 frames.=20 =20 A comparison of an 802.11 frame to an 802.3 frame (ignoring PHY) looks as follows: =20 802.11: Frame CTL Duration DA SA RA/BSSID Sequence Control Address4 (WDS) QoS Control Frame Body FCS 802.3: DA SA Priority CFI VLAN Frame Body FCS =20 Comments on comparison of the two formats: - Frame CTL, Sequence Control, and Duration are of limited value at the AC for local MAC, they may be useful depending on how you define split MAC - FCS for 802.11 and FCS for 802.3 are calculated differently, I believe - There is a well defined mapping between QoS Control in 802.11 and Priority 802.1p bits in 802.3 - There is an implicit mapping between BSSID and VLAN tag - One open issue would be how to address 802.11e Admission Control =20 802.3 provides the basic imformation that the WTP or the AC needs to process packets in the local MAC case. It would probably provide enough information depending on how you define split MAC. However, you may be able to move some of that information into the CAPWAP header if you used an 802.3 frame format. =20 One of the issues we have is that if you read the Taxonomy document, the definition of local MAC and to some extent, even split MAC, are open to interpretation. That is why Pat, Inderpreet, and Bob submitted the Taxonomy Recommendations document at the last meeting. =20 Cheers, =20 Mike =09 =09 ________________________________ From: Darren Loher [mailto:DLoher@rovingplanet.com]=20 Sent: October 14, 2005 1:31 PM To: Sadot, Emek (Emek); Pat Calhoun (pacalhou); capwap@frascone.com; Puneet Agarwal; Michael Montemurro; Saravanan Govindan; Dan Harkins Subject: RE: [Capwap] Change Request 9.1.3.1. Support for Local MAC User Data Tunneling =09 =09 The evaluation draft made a strongly recommendation that an option for a Local-MAC mode with user data tunneling be explored on by the working group. The eval draft listed a few reasons why it might be worth having such a solution. I heard support for such a solution from members of the working group off and on the mailing list. In addition, it appears to be an innovative solution which CTP and SLAPP allowed for in some way. =20 There are many details that need to be specified for exactly how this would work which we are starting to talk about. However, it is useful to hear from the WG at large if a capability like this is necessary. =20 =20 Is a capability for tunneling of user data in 802.3 format for Local MAC mode needed? =20 =20 -Darren =20 =20 ________________________________ From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Sadot, Emek (Emek) Sent: Thursday, October 06, 2005 11:18 AM To: Pat Calhoun (pacalhou); capwap@frascone.com Subject: RE: [Capwap] Change Request 9.1.3.1. Support for Local MAC User Data Tunneling =20 Pat, =20 Yes, that's how I interpreted it, with a disclaimer for 802.11 control and management frames only. It goes for option #3 and #2. =20 Regards, Emek =20 ________________________________ From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com]=20 Sent: Saturday, October 01, 2005 4:26 PM To: Sadot, Emek (Emek); capwap@frascone.com Subject: RE: [Capwap] Change Request 9.1.3.1. Support for Local MAC User Data Tunneling Emek, =20 In option 3, when a user associates with the WTP, the association is handled locally, but the packet is tunneled to the AC in order for the AC to have access to usage information (and make overriding policy decisions). So 802.11 needs to be supported on the AC regardless, right? =20 Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 =20 ________________________________ From: Sadot, Emek (Emek) [mailto:esadot@avaya.com]=20 Sent: Friday, September 30, 2005 10:16 AM To: Pat Calhoun (pacalhou); capwap@frascone.com Subject: RE: [Capwap] Change Request 9.1.3.1. Support for Local MAC User Data Tunneling Regarding the points you raised I believe option #2 and #3 share the same qualities. In both options 802.11 encryption and 11e cannot be implemented at the AC. In both options a mechanism shall be design to extract RF and data-traffic statistics either (a) appended in the tunneling (option #3 only) or (b) exposed by the WTP as read-only values for the AC inquiries (both options). =20 Am I missing something? =20 On the other hand one can respect the unique merits that these options offer: - option 2: non-appliance product. meaning a software based AC that can be executed on any server / platform. - option 3: avoid parse 802.11 traffic in silicon at the AC. Leverage existing products (e.g. routers) with "only" add-on 802.11 code running at the Cpu. =20 Emek =20 ________________________________ From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com]=20 Sent: Thursday, September 29, 2005 6:01 PM To: Sadot, Emek (Emek); capwap@frascone.com Subject: RE: [Capwap] Change Request 9.1.3.1. Support for Local MAC User Data Tunneling In terms of option 2, no traffic is sent to the AC, so the model is quite different. =20 Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 =20 ________________________________ From: Sadot, Emek (Emek) [mailto:esadot@avaya.com]=20 Sent: Thursday, September 29, 2005 2:16 PM To: Pat Calhoun (pacalhou); capwap@frascone.com Subject: RE: [Capwap] Change Request 9.1.3.1. Support for Local MAC User Data Tunneling Pat, you certainly raise valid questions w.r.t. option #3, however I am curious as to the differences between the challenges you listed between options #2 and #3. In other words, in what sense option #2 and #3 are differ w.r.t. encryption and 11e at the AC, as well as RSSI/SNR/data-rate/other monitoring support? =20 Regards, Emek =20 ________________________________ From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Pat Calhoun (pacalhou) Sent: Wednesday, September 28, 2005 5:32 PM To: capwap@frascone.com Subject: [Capwap] Change Request 9.1.3.1. Support for Local MAC User Data Tunneling This change request is to allow for 802.3 tunneling of user data in local bridging mode. I believe that the changes should be relatively straightforward, but do introduce an interesting set of complications that need to be evaluated and agreed upon as a group. =20 The LWAPP protocol currently allows for 802.11 tunneling in Split-MAC mode, allowing for such things as centralized encryption of user data frames. However, the current definition of the protocol is that when running in Local-MAC mode, no traffic is tunneled to the controller. =20 If we were to introduce this change, the LWAPP protocol would have three modes of operation: 1. Split-MAC: Tunnel native MAC frames in UDP (e.g., 802.11) 2. Local-MAC w/ Local Bridge: Do not tunnel 802.3 frames 3. Local-MAC w/ Tunnel: Tunnel 802.3 frames in UDP =20 The issue that we need to decide as a group is whether we really want a protocol that has three modes of operation, and if so, which one is mandatory. The evaluation draft states that option 3 is useful for support of non 802.11 technologies, but this introduces a set of restrictions. For instance, today the LWAPP protocol allows for centralized control of various 802.11 functions, including encryption and 802.11e. This function is not possible with option 3, and therefore any new technology that assumes this option would not be able to provide centralization of data frame functions. =20 There is a comment in the recommendation that LWAPP could retain the RSSI/SNR fields, and then perform 802.3 encapsulation, allowing the AC to have more visibility. However, I have had some requests to expand these fields to also include the data rate. Further, there are possible fields in the header (of technologies we know nothing about) that the WTP may want to extract and expose to the AC - and how could this be done with 802.3? Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Thu Oct 20 07:41:25 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESYnT-0002Fb-9F for capwap-archive@megatron.ietf.org; Thu, 20 Oct 2005 07:41:25 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04400 for ; Thu, 20 Oct 2005 07:41:11 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 91A5E2037F; Thu, 20 Oct 2005 07:41:04 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by mail.frascone.com (Postfix) with ESMTP id 6ED6A1FDEF for ; Thu, 20 Oct 2005 07:40:29 -0400 (EDT) Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-2.cisco.com with ESMTP; 20 Oct 2005 04:40:29 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j9KBeP94015494; Thu, 20 Oct 2005 04:40:25 -0700 (PDT) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 20 Oct 2005 04:40:25 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Capwap] Change Request 9.1.3.1. Support for Local MAC User Data Tunneling Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2CFA0FA@xmb-sjc-235.amer.cisco.com> Thread-Topic: [Capwap] Change Request 9.1.3.1. Support for Local MAC User Data Tunneling Thread-Index: AcXQ7VBZrYBkWx9zSaGI/RYMe4JoiAACIsQgAI5GA3AALmKssAALJ2sgAFV4xCA= From: "Pat Calhoun (pacalhou)" To: "Sadot, Emek (Emek)" , "Puneet Agarwal" , "Michael Montemurro" , "Darren Loher" , , "Saravanan Govindan" , "Dan Harkins" X-OriginalArrivalTime: 20 Oct 2005 11:40:25.0355 (UTC) FILETIME=[0FD1C5B0:01C5D56B] 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-Unsubscribe: , List-Id: A list for CAPWAP technical discussions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 20 Oct 2005 04:40:23 -0700 Content-Transfer-Encoding: quoted-printable Yes, you are correct in your understanding, but I still contend it is one more mode to support. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems =20 > -----Original Message----- > From: Sadot, Emek (Emek) [mailto:esadot@avaya.com]=20 > Sent: Wednesday, October 19, 2005 9:33 AM > To: Pat Calhoun (pacalhou); Puneet Agarwal; Michael=20 > Montemurro; Darren Loher; capwap@frascone.com; Saravanan=20 > Govindan; Dan Harkins > Subject: RE: [Capwap] Change Request 9.1.3.1. Support for=20 > Local MAC User Data Tunneling >=20 > Pat, > =20 > I share your concern about complexity increasing, and I=20 > concur that we should shy away as much as possible, but isn't=20 > the Local-MAC with tunneling architecture is simply an hybrid=20 > of Split-MAC and Local-MAC with DS at the WTP, excluding an=20 > indication as of which layer 2 the tunneling carries - 802.11=20 > or 802.3? >=20 > In other words, and please correct me if I am wrong,=20 > Local-MAC with tunneling mode just make use, and re-position,=20 > Local-MAC with DS at the WTP and Split MAC internal components. > Examples would be: reuse of Split-MAC DS support at the AC,=20 > or reuse the > 802.11 to 802.3 converting function at the Local-MAC WTP, or=20 > reuse Local-MAC method to convey 802.11 MAC info (e.g. RSSI)=20 > to the AC, etc. >=20 > Regards, > Emek >=20 > ________________________________ >=20 > From: Pat Calhoun (pacalhou) [mailto:pcalhoun@cisco.com] > Sent: Tuesday, October 18, 2005 11:53 AM > To: Sadot, Emek (Emek); Puneet Agarwal; Michael Montemurro;=20 > Darren Loher; capwap@frascone.com; Saravanan Govindan; Dan Harkins > Subject: RE: [Capwap] Change Request 9.1.3.1. Support for=20 > Local MAC User Data Tunneling >=20 >=20 > My personal opinion is that we should not, and for one reason only - > decreased complexity. What I am concerned about is the raw number of > tunneling options and modes of operation the protocol will=20 > end up having > to support. That said, I will go with the group's sentiment (which so > far is in agreement with this suggestion). Regardless of whether this > work is included or not, I agree with Emek's recommendation for the > default mode (which I believe is a point made in the Taxonomy > recommmendations draft). >=20 > Pat Calhoun > CTO, Wireless Networking Business Unit > Cisco Systems >=20 > =20 >=20 >=20 > ________________________________ >=20 > From: Sadot, Emek (Emek) [mailto:esadot@avaya.com]=20 > Sent: Monday, October 17, 2005 8:39 AM > To: Puneet Agarwal; Michael Montemurro; Darren Loher; Pat > Calhoun (pacalhou); capwap@frascone.com; Saravanan Govindan;=20 > Dan Harkins > Subject: RE: [Capwap] Change Request 9.1.3.1. Support for Local > MAC User Data Tunneling > =09 > =09 > Reaffirming my statement below: I'm supportive in supporting > tunneling and local mode from Local-MAC architecture. I would even > suggest that the group would consider the latter as the=20 > default mode, as > such mode could encompass most of the deployments today. > =20 > Regards, > Emek >=20 > ________________________________ >=20 > From: Puneet Agarwal [mailto:pagarwal@broadcom.com]=20 > Sent: Friday, October 14, 2005 5:18 PM > To: Michael Montemurro; Darren Loher; Sadot, Emek (Emek); Pat > Calhoun (pacalhou); capwap@frascone.com; Saravanan Govindan;=20 > Dan Harkins > Subject: RE: [Capwap] Change Request 9.1.3.1. Support for Local > MAC User Data Tunneling > =09 > =09 > I concur with Darren and Mike. Supporting Local MAC in both > tunnel and local mode allows for a rich set of network deployments and > hence must be supported by CAPWAP. > =20 > Thanks. > =20 > -Puneet >=20 > ________________________________ >=20 > From: Michael Montemurro [mailto:michael.montemurro@siemens.com] >=20 > Sent: Friday, October 14, 2005 11:28 AM > To: Darren Loher; Sadot, Emek (Emek); Pat Calhoun (pacalhou); > capwap@frascone.com; Puneet Agarwal; Saravanan Govindan; Dan Harkins > Subject: RE: [Capwap] Change Request 9.1.3.1. Support for Local > MAC User Data Tunneling > =09 > =09 > From my point of view, supporting Local MAC in both a tunnel > mode (user data tunnelling between the AC and the WTP) and=20 > local mode ( > bridging locally at the WTP) allows the protocol to be=20 > applied to a wide > variety of network deployments. It must be supported by the protocol. > =20 > As for the frame format, from my point of view, in a split MAC > case, it would much easier to use 802.11 frames for data frame > tunnelling, but for the local MAC case, it is much easier to use 802.3 > frames.=20 > =20 > A comparison of an 802.11 frame to an 802.3 frame (ignoring PHY) > looks as follows: > =20 > 802.11: Frame CTL Duration DA SA RA/BSSID > Sequence Control Address4 (WDS) QoS Control Frame Body FCS > 802.3: DA SA > Priority CFI VLAN > Frame Body FCS > =20 > Comments on comparison of the two formats: > - Frame CTL, Sequence Control, and Duration are of limited value > at the AC for local MAC, they may be useful depending on how=20 > you define > split MAC > - FCS for 802.11 and FCS for 802.3 are calculated differently, I > believe > - There is a well defined mapping between QoS Control in 802.11 > and Priority 802.1p bits in 802.3 > - There is an implicit mapping between BSSID and VLAN tag > - One open issue would be how to address 802.11e Admission > Control > =20 > 802.3 provides the basic imformation that the WTP or the AC > needs to process packets in the local MAC case. It would probably > provide enough information depending on how you define split MAC. > However, you may be able to move some of that information into the > CAPWAP header if you used an 802.3 frame format. > =20 > One of the issues we have is that if you read the Taxonomy > document, the definition of local MAC and to some extent, even split > MAC, are open to interpretation. That is why Pat, Inderpreet, and Bob > submitted the Taxonomy Recommendations document at the last meeting. > =20 > Cheers, > =20 > Mike > =09 > =09 >=20 > ________________________________ >=20 > From: Darren Loher [mailto:DLoher@rovingplanet.com]=20 > Sent: October 14, 2005 1:31 PM > To: Sadot, Emek (Emek); Pat Calhoun (pacalhou); > capwap@frascone.com; Puneet Agarwal; Michael Montemurro; Saravanan > Govindan; Dan Harkins > Subject: RE: [Capwap] Change Request 9.1.3.1. Support > for Local MAC User Data Tunneling > =09 > =09 >=20 > The evaluation draft made a strongly recommendation that > an option for a Local-MAC mode with user data tunneling be explored on > by the working group. The eval draft listed a few reasons=20 > why it might > be worth having such a solution. I heard support for such a solution > from members of the working group off and on the mailing list. In > addition, it appears to be an innovative solution which CTP and SLAPP > allowed for in some way. >=20 > =20 >=20 > There are many details that need to be specified for > exactly how this would work which we are starting to talk about. > However, it is useful to hear from the WG at large if a=20 > capability like > this is necessary. =20 >=20 > =20 >=20 > Is a capability for tunneling of user data in 802.3 > format for Local MAC mode needed? =20 >=20 > =20 >=20 > -Darren >=20 > =20 >=20 > =20 >=20 > ________________________________ >=20 > From: capwap-admin@frascone.com > [mailto:capwap-admin@frascone.com] On Behalf Of Sadot, Emek (Emek) > Sent: Thursday, October 06, 2005 11:18 AM > To: Pat Calhoun (pacalhou); capwap@frascone.com > Subject: RE: [Capwap] Change Request 9.1.3.1. Support > for Local MAC User Data Tunneling >=20 > =20 >=20 > Pat, >=20 > =20 >=20 > Yes, that's how I interpreted it, with a disclaimer for > 802.11 control and management frames only. >=20 > It goes for option #3 and #2. >=20 > =20 >=20 > Regards, >=20 > Emek >=20 > =20 >=20 > ________________________________ >=20 > From: Pat Calhoun (pacalhou) > [mailto:pcalhoun@cisco.com]=20 > Sent: Saturday, October 01, 2005 4:26 PM > To: Sadot, Emek (Emek); capwap@frascone.com > Subject: RE: [Capwap] Change Request 9.1.3.1. Support > for Local MAC User Data Tunneling >=20 > Emek, >=20 > =20 >=20 > In option 3, when a user associates with the WTP, the > association is handled locally, but the packet is tunneled to=20 > the AC in > order for the AC to have access to usage information (and make > overriding policy decisions). So 802.11 needs to be supported=20 > on the AC > regardless, right? >=20 > =20 >=20 > Pat Calhoun > CTO, Wireless Networking Business Unit > Cisco Systems >=20 > =20 >=20 > =20 >=20 > ________________________________ >=20 > From: Sadot, Emek (Emek) > [mailto:esadot@avaya.com]=20 > Sent: Friday, September 30, 2005 10:16 AM > To: Pat Calhoun (pacalhou); capwap@frascone.com > Subject: RE: [Capwap] Change Request 9.1.3.1. > Support for Local MAC User Data Tunneling >=20 > Regarding the points you raised I believe option > #2 and #3 share the same qualities. >=20 > In both options 802.11 encryption and 11e cannot > be implemented at the AC. >=20 > In both options a mechanism shall be design to > extract RF and data-traffic statistics either (a) appended in the > tunneling (option #3 only) or (b) exposed by the WTP as=20 > read-only values > for the AC inquiries (both options). >=20 > =20 >=20 > Am I missing something? >=20 > =20 >=20 > On the other hand one can respect the unique > merits that these options offer: >=20 > - option 2: non-appliance product. meaning a > software based AC that can be executed on any server / platform. >=20 > - option 3: avoid parse 802.11 traffic in > silicon at the AC. Leverage existing products (e.g. routers)=20 > with "only" > add-on 802.11 code running at the Cpu. >=20 > =20 >=20 > Emek >=20 > =20 >=20 > ________________________________ >=20 > From: Pat Calhoun > (pacalhou) [mailto:pcalhoun@cisco.com]=20 > Sent: Thursday, September 29, 2005 6:01 PM > To: Sadot, Emek (Emek); capwap@frascone.com > Subject: RE: [Capwap] Change Request 9.1.3.1. > Support for Local MAC User Data Tunneling >=20 > In terms of option 2, no traffic is sent to the > AC, so the model is quite different. >=20 > =20 >=20 > Pat Calhoun > CTO, Wireless Networking Business Unit > Cisco Systems >=20 > =20 >=20 > =20 >=20 > ________________________________ >=20 > From: > Sadot, Emek (Emek) [mailto:esadot@avaya.com]=20 > Sent: Thursday, September 29, 2005 2:16 > PM > To: Pat Calhoun (pacalhou); > capwap@frascone.com > Subject: RE: [Capwap] Change Request > 9.1.3.1. Support for Local MAC User Data Tunneling >=20 > Pat, you certainly raise valid questions > w.r.t. option #3, however I am curious as to the differences=20 > between the > challenges you listed between options #2 and #3. In other=20 > words, in what > sense option #2 and #3 are differ w.r.t. encryption and 11e at the AC, > as well as RSSI/SNR/data-rate/other monitoring support? >=20 > =20 >=20 > Regards, >=20 > Emek >=20 > =20 >=20 > ________________________________ >=20 > From: > capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf > Of Pat Calhoun (pacalhou) > Sent: Wednesday, September 28, 2005 5:32 > PM > To: capwap@frascone.com > Subject: [Capwap] Change Request > 9.1.3.1. Support for Local MAC User Data Tunneling >=20 > This change request is to allow for > 802.3 tunneling of user data in local bridging mode. I=20 > believe that the > changes should be relatively straightforward, but do introduce an > interesting set of complications that need to be evaluated and agreed > upon as a group. >=20 > =20 >=20 > The LWAPP protocol currently allows for > 802.11 tunneling in Split-MAC mode, allowing for such things as > centralized encryption of user data frames. However, the current > definition of the protocol is that when running in Local-MAC mode, no > traffic is tunneled to the controller. >=20 > =20 >=20 > If we were to introduce this change, the > LWAPP protocol would have three modes of operation: >=20 > 1. Split-MAC: Tunnel native MAC frames > in UDP (e.g., 802.11) >=20 > 2. Local-MAC w/ Local Bridge: Do not > tunnel 802.3 frames >=20 > 3. Local-MAC w/ Tunnel: Tunnel 802.3 > frames in UDP >=20 > =20 >=20 > The issue that we need to decide as a > group is whether we really want a protocol that has three modes of > operation, and if so, which one is mandatory. The evaluation draft > states that option 3 is useful for support of non 802.11 technologies, > but this introduces a set of restrictions. For instance,=20 > today the LWAPP > protocol allows for centralized control of various 802.11 functions, > including encryption and 802.11e. This function is not possible with > option 3, and therefore any new technology that assumes this option > would not be able to provide centralization of data frame functions. >=20 > =20 >=20 > There is a comment in the recommendation > that LWAPP could retain the RSSI/SNR fields, and then perform 802.3 > encapsulation, allowing the AC to have more visibility.=20 > However, I have > had some requests to expand these fields to also include the=20 > data rate. > Further, there are possible fields in the header (of technologies we > know nothing about) that the WTP may want to extract and expose to the > AC - and how could this be done with 802.3? >=20 > Pat Calhoun > CTO, Wireless Networking Business Unit > Cisco Systems >=20 > =20 >=20 _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From masube@gsccc.com Thu Oct 20 19:27:55 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESjpC-00066n-M7; Thu, 20 Oct 2005 19:27:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07198; Thu, 20 Oct 2005 19:27:43 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESk1A-0002ol-Fj; Thu, 20 Oct 2005 19:40:16 -0400 Received: from [61.57.103.174] (helo=61-57-103-174.nty.dynamic.lsc.net.tw) by mx2.foretec.com with smtp (Exim 4.24) id 1ESjp2-0005PL-7C; Thu, 20 Oct 2005 19:27:45 -0400 Received: by 10.11.98.1 with HTTP; Thu, 20 Oct 2005 18:23:30 -0600 Message-ID: <128d588j.2996630@msn.com> Date: Thu, 20 Oct 2005 18:23:30 -0600 From: "James Hollingsworth" User-Agent: Apple Mail (2.728) X-PGP-Key: bwGmQe86O1X8eqkRMg6fmyejsG45RC9eLpMYcGb17pP1QG0LgISj1erTcCA2AGKH== X-Load: 12% MIME-Version: 1.0 To: bridge-mib@ietf.org Cc: bridge-mib-admin@ietf.org, business@ietf.org, calsch@ietf.org, cancer@ietf.org, capwap-archive@ietf.org, ccips@ietf.org, cclark@ietf.org, cdi-archive@ietf.org, cdir-admin@ietf.org, cfrg@ietf.org, cfrg-admin@ietf.org, cfrg-archive@ietf.org, cfrg-bounces@ietf.org, cfrg-web-archive@ietf.org, chair@ietf.org, chiname.cn@ietf.org Subject: Urgent Notification #8483155098878243299 Content-Type: multipart/related; boundary="------------AttPart_12672359==.OLA" X-Spam-Score: 4.4 (++++) X-Scan-Signature: d890c9ddd0b0a61e8c597ad30c1c2176 This is a multi-part message in MIME format. --------------AttPart_12672359==.OLA Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
, gimmick , paulsen or darius in wellington , cam some auric see barbara see barrymore the repute ! staph not theses a ky not lug a fredrickson Or maybe not

--------------AttPart_12672359==.OLA Content-Type: image/gif; name="maelstrom.2.gif" Content-ID: <7.0.0.98.0.28161604974114.91080608@sprite.yahoo.com.3> Content-Disposition: inline; filename="maelstrom.2.gif" Content-Transfer-Encoding: base64 R0lGODlh5gHOAMQAAP/////MzP+Zmf9mZv8zZv8zM/8AM/8AAMzM/8zMzMyZ/5mZ/5mZzJmZ mZlmzGZmzGZmZmYzzDMzMzMAzAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ACH5BAAAAAAALAAAAADmAc4AAAX/ICCOZGmeaKqubOu+cCzPdG3feK7vfO//wKBwSCwaj8ik cslsOp/QqHRKrfIalKw2K9FCINkEaVuCSMpeVPc8SmjZIrBXDMButxI5BdLWSxoidncUVoWG h4iJQglgeV8Uf10UDQ2SdHVrJWEklZCAJ3ZwAHKfbnuPWYBYX41fEpGpgVmsWgmMkLSiiru8 vb67kCOUAG6fAFwkbpejsyXFKqGchCKvy3KMfMSTwtqlwSRdn3sj37/m5+jpRuVt29TIIspj cs7uKWmysstxew10z8ncgTnxR8S4QMbUKVzIsCGLb2DEAGTWiNylgeECJjyxJ2Odaa9QsJsY z93BEv4M/2Yb6LCly5fpBpU0hvEghUvjsIgiyRFCgoxYqOka0UVjPXHZ7t0RNhSm06dQl+Ci 120Ey4w3+d0xxtPEOFMJggIoSnCnvZkGm45xRHZs1qhw48r98a1BtoksTWGhM9VMua6astkR C2ajSqOI23LKdtBuG8NzI0uevIId2nfCajHjuqmqipN6ZL21epYnwIrJCh5L6kYt5dewJ1v+ yObnNNG2sqBhg4WmhGU6wel+d9B2UlnHaRP1JFoc7y58KsWeTj3uFmOCbl4nbapz90mD2GUX TkIPPtLNRG+yvdVgeDFd9lWfT18dK599WI1iZW3/l/L83ffFRtj895gJ94HCCv9XCeYHQUIC fvEPZPVVaOGFGGao4YYcdujhhyCGKOKIJJZo4okopqjiiiy26OKLMOKgWokGplBjEj9RWMhP 8sUYRXd2caGFe67pEAuNJxGUJBJHKgKWjzvWddNeJfXowoyf6biEdL7caNVKyTGpZRXy3IAl lDlQOZYrwoQJw5lqjJkEl714GQeYTcB5SJk26IlmDW4IBsklv60QloxyxnAoDG7W2eiXeSaq wqM+8CkEpTJg2iFLx8DBCAt+vinpC6GCUqQidpahaRClsuDGEZYC8aoOdJZ42m2FsreRIGfo lFWhH5Ujh0epxcIesD8Nq16vXPwjiT9bhFVbHvAwM07/UnagQokkK21jigndhZUKMoOZ8axV nxhoG7DCfbNuWIAMa1i41PhVnCSFFqYNSFoYU8uQggDy7WayxBcQHQG79Ucs1VJDh7lHSjKJ rgXfRDF7uWlWYkhuCcxGQTyWoJoko3QiBpf/mXFZG4VWI9CUxuZBTSkfewxfr7wFMxgxMlOp r1VsmFGJRByrNusYd45yRo71Kn1yVj//F3KtdQj8Kx/fyvzRRtMYyHFht8LnTUngejuJGURH hysgJD94sNM8+7QNl5YanMlHZM/MM3slg/ybyj2f6mFvdg3k9ndnjYWdKFAvNdqZN9YK8m0q K95HLF7SSTflzIpReTts25XQ/69jI5iJPBxDnZQ7qv2X3WiBXLNaN0crbfo3M+Yheeh51w40 JsdcEtTRqlFdZfCZ7ffRyWG+NWNWsyKuSm1bhXKy4B5C8lsx1KswY62qa2IM5Mftrg1TeldV UOZwbI4+e4k7fcaNpOcjcnRBP5gHNkmn3zr+KagEILLCK20ITxeBS99+zFe8afhuJm6zx6uI 9wnjGfAYnDHgJH4DO4PQ4XkSceBt0Hc+Z9DDgiNaxTvGV6hhgANbjFOFt85Qja2hZG7ayVkI f7emQCwtJziUFgmPprIHaqIgKrQd3BRzQY6B5UnKM8gntFbEg7BLeb2JIlFyhSXUfYx6udHh EkXYo//gEKyHz0iiBZ/xM629Yn5LkmLT5FimGg6DTnasBLOAp6K31IpiN9wDveSgtkHxLBXQ CSQXm+WeiZFrFutSofX2xUHd9MsUlWxY8pblLE8MZzkL++Ico0GKUAjikFfc1yOC1K9DNgmU wYEEI12JrDXY4R2pxCB6QJMKMMitM8vZhh5YQ8AOWutByCCFwmxxLnpRDF8hNOSf6PM8w7hQ IWJRYhWwN81uVuEgEalHQ6iULCukypvo3BE0TaA1hgzTCrFKpzznSc962vOe+MynPvfJz376 858aEuAPyukEgf7AoEpalazaCVASjecYrZTBznpgCoUCYaI9wKjI7qaEijb/1ES3kJI0FUWs HdzCogMt6Q46ARnpoNQHvmwIQz96BDO2xgZZpMtLfZBTnsavh1CI4zkCBaWd9sComeBYDXra A6EigakscFsLoHqYoBr1BVKdQVZZkJIYGRFWI3yTLK30Aqoa6aor/SkKAAOKnzo1CW/FAVtd pdYQ6RGRTUpYHN4IP0o0q5DAetanCAmuV2wDX8SZ2LkMldc3eG44r6yYNNnDh35FA7FeMexJ MOuWcrwxslqZ1pFyqtdjdVY3pcVX4rLjE4mxEJg+5IIMf3UvjpLjLq7tLGIt28pnkiE1p+NW YgkxLPkwjRmcRY9mW3skysbDsMwaaRVkpy+fcbGy/8HYnghl+JuaKTE+XkuIHcLyIKvtUG8h W0FbdOIXnHUtftlCzSv8covthQM6MdXEKZqB33H0F7v77WBrMjJfoJgtD0VpDSlaAS0ET2MW fiFQK4xDiu78rCQBZmYxAWuwebxDWzrpBB8awd6iQCcYDJaG9m5S4MbpbhWoGcNhuRDhQPp1 gw5mm4PFteIBx/UJ7vMg8uw3o+gFkRjKrJzM7qCL2rHyvNKLKq7aJ8ztmiCnZIEYbcOIuLDO ThuZ/NdSUAPV79w4DVk0z9mg55NbXYe08SNqT4tSkY1wSs5v+Up1vaK28RGiKJJc83Uk9sN5 7VnLIZziHfZRXbIQFQ0DRP/mFkasWVvsedKHCDLyJAiSDCYWa4e1GiPrejSBQk+EMeDUX6q8 ssyki1+GfVqsFTwgPm+R1g/CNVJarZV+nKLWaf61T8IJOn7c5xYIizMQafJgN3FqdmoqjlqX TZqtWQLFwtZwGAAzkTUYDCB9CdOtbssR8Pj1PmzrsWeCNZspaLrKU8xGO+so3h8CsDy5Sk6Z XGe2D7YwXo9qSyI7RjCV2pAZYsiu89ITi2ySo4XjaDghJJ4WXhNOkIZUWaA/hkxmcVBQHNcJ fJQNaiR+o90i/4jaRuwuod60NdwlTidwyPFBxefR9VgdDU8t76+cadwVvzIyWuO5Myg8hHcZ lG7/6O1DJnSnsxR7J7tBCT/7elLS6SGsfs2233RbXSAUita+8PG6JXlBEF2ebWYi2g48qAeH rQyNcNeOObGngdDDzZhu8H7a8zQSjmLXg3wk1nImn5adQ1Jzsj0ezGC4/TsiGxJEr/Od74QJ XwFTFuJfrZlBzJwQlidYEju8kM/N9ILLa0KD7rTVwu2H0QMqEJKjg5+qJUNCJ3hQrfNzCWwg TD+FS0iBhFejBcVOvDVy/fEXA/Bd7b5w2NKPgrbqe9HVYfeLkSr0y5Au4Ggf+8rPfilch5/w Y1/8ww9+7kURfv7ZhbxSNX4guBGPUaEqZ/NiHTdpyv+l1lVDfYUCvEJW//1XgDbwSQaYgAZ4 TQrYgA74gBAYgRI4gRRYgRZ4geiQXuBgf06HVjhCehm1f3yUURyIKh7IIYLAGJpEBFBEDv8X BXpVHhfRMO9yAjX4XCN1gwiigVfQbgLogzYgL+ykYuy3gqonVKdHIrYBDiJoUsb0gkD2N76j JodzL4dUWFfIM1n4E1mIEiUYA5tDgCOoA69ACY5RHrfhGDd1fWA2BanSKiDyaFy4BPEEh07w B59SD8ZkILXHE30oTP8AiLw2FmKIA2G4AihUA1NiTZ9EZfCRGYVoBG/4hRmSRblkBHX4hYsy BBJyeWpSHuKAb5ogiiOkMqU4FMYUgrlXHiS0A/+TwIA8Ixbgoz8epnqQwk6UmCG+lItyZUx2 iItFgEnIN2Tg8FzSkBrSMIf6UIT1EIk4NRRHU2pNyFWzNDOzcoZ3go1apAR0kiq1xyIncSyy 9g7ygXa09FiidjzWYnCCxXJApEniuDPNsljmkkuaN4cd5EIOt48j1Bv9CB7HSHeEkFq2FSyL lI/Tklifty04CF+MhEnGtVhq2DXHYQY38jmiYY/QNXPCE1E/sU6Vp2U04YwgYjQvU3QWgRJL sz8naTklJA+V44cfcxPh5ZKIERFaowx+g0mECC5ywzZ8oY3Y0o/MyBT7uDCc0GRQc116oYxa aDmAkxzSMTDRmIbexYP/c1gQLNlSfsVMVcImX4KRN5KVG3E3NZRlTJkeHNONEPcwL1I8ooBE cNBBZ8FApSMPj2NnHDd5yAAnu8NG0LIdoTJYWHceXbVu2jgR72cPi4kd+pYVoyEWqRhSs5VK QVaV79Met1d30iUMoaNmr1iKfgWKJgRacGk/kflgydZ0/aNLMXKaRDE9KTkG9baBLikWeDk+ BOJYrhmbVxaX8bIHoOdlgzliyTEamxh0JXNE6NIpzSksu5lwnmZMz2A0VDFEqJY3wPNV6lNB +eWFvfmS9mAx47kM1WkYsDkrnCZkJdSNSfGLJJKTUvI06IgGN7OG1jVyaGFHq6ULaINkQBUQ /2KkF0JxMmzjJhODTPswGtgiQ/e2ljmRM/cmSdDYOPEmRyqpDXwQEg6XekYWiMl2n7aXmZVl nKkBL0qlnfrCh8IklfbGToIhRm3EGBU0De5JDlNEktkDD+IYTASKhobUo6h0S4L1LAP3dt3S GOnBMtX4ORRzSoHUmUNmHlQ2WX5UjZOUkfIRd/igeUy6MPZyReFyLmswcguzbYv1pavAm0Da mbXjpetYWFdHhE+nGVInXLUgjMkUC5eIgWt1pToqK42Siox1IrConX46GQCRok2Qh2TIi9Vx qIlKHQM4qZZ6qZiaqZq6qZzaqZ76qaAKqgFAAAPgA6Naqk4gAAUgAP8FmIgMYRuBCiBQ4aou MAAHcKu3agCsygIBcKuougO9egC/GgMFgKu3uqoyIAC3uqtHEADFegDMKgLKaqwHUADD6gPK GgC7YEZO0Vqx+mFPwa0wYA8CQADVOgDmCq28aqvXigMBwK4i0KvRugKqegCk+qzaCgPlqq5I 8K62agAlMKrnOgC2egAGkK/Yyq+KQKvq4ELx1AJJ6BAMyxHL0KuoqqztigLC+gMbCwDKOq/0 yq+2CrIs8LFMUAAFcAIdKwLmmrI/IK+8MLHogCyEugLnNE7TSIwi0LEm2wIrywMr+6sCkLEl 0LO2irAv0LNJoLQk8LMAYK4kmwMHkK8uqwP/Q0sCVbtUOStR33oDNYtVJ4gDFamKU4UTJkCt BYC0KuC0OsC2AGCtJUutBDADTHsEcKuy12qxQLCrAwCwO3C3ANC3hri1MfC1A2W4LXCzwWiV ZPsQZlsC9kqwxeqy06qwBVusGVuvG+uskwsAzrqsI3C5PHuwgWusaksCGEuwBmCvInC5+SoA BvCsaSut0Fq5AcC51Tqt2oq50loA6aqr8ZquBFC5BaurWQu57Rq7rYurQru6wPu5Iluttzq3 qGus89q3z4quvhq6x6qtBbus1vu00zsCBFAABkC6pqJcXiePI2FYlflYzUBYGOMMi/WRcKcL 48GF/XJJZZqRp5cs/9UipElppM21WK4VLTdYj4TiSdsgW7JUDpP0TkMRtNBqsdgrApirve2q rKQKvtVqrpyrvayaweZaqrrrsbE7AFFLu8xarAEAuwS7sZervdT7sbZqrdPqu1MLwihswrka w1MbACm8rJhbrypMtADAtr4rvvfKur16rwBbwtX6ttM7AMUarapqAARbAsLbt+e6uqwKw/AK uzicxVtcwuwarMKqsBkKVL2RRmC0duRFluwZXlEpMk8TLOSFMo8ZTeQ4NFODMx8klTEDaq9m DZtQXb+SxyXER4EMUTTUe3MDRuQ0Q+nDoGf7qxbrr87ruSurxJQ7AO+qrgJQub6qtztbqv8C m69aHLfM+rHlWrAmzMNv67eVu6ujHMYeO7Ui0MoCu6s2zMvv+sKsW76eu8JOu8krC8Lfu6zp OsVZHK9OK7gmEM27rK0mG8vbCwCt3Lp+q8a5GrgGMLcrPJWniEUE9JibaRJ8gQdZmpTDQURL 8TaNbEavc1zbqKI4Y5tJqZ1+RDL1nDNipyf8xjwjqC7KpLOZPALyKsTCar67zKxsq7wkALO7 TLAEW8oKy7O8zM1IPAJKm63T2rcX29HUrKyTm68Wfc29XNK4DK1HWwJX7LbIWwJHi8rXzK4Y fbvPysvU7NE27bcmcNLCTMq+2s3dLM7STKoZ3dKI+EMHpEFDI2D/t3Ge7Jk4IVUG2qWij1Im 0QgUCJQUdiKNY3gm71Z0uaGdXGI8eqIMGyQPN2rVCl3RrOu5LmyyEN2rwAuvXCzDworKvTq7 VqzXrMrX2drLVQvR1cyvZFy6t1vXh/20tgytLcuqOI2xpVvDHQvCHLzLKRus34y+AVutr1vC vayuzgqwnf202Pu53ivU4xzUKEDU2qq3N13XFK3UvQy8yorYkHhDInpcb0QRZYMwL+qa/8kI HBpW60NGsuAxzZg3EZEsj/YbWYRz7fA7+ImQ/sw7efHPJSFv8NEow51f2eQ6x+0OTpnE1Ira 7V26uXqsAbu68v2sfvu9pIvf8o2rI4yr/79ctO1NuqZM2sxru7havsdq39Kcq6ubsgOOqj2N vobttu0NurQbvlQs3/QNzfx9uSTwvVjs3/xN3yqMthk+tSBuyoXt3wo0dtrGafTpFTEzp0nG X9XYHPERUe/cSOn2wJXUXdJESDHG4zwpwBj2Z2HwLINhN4MCkTUIpdFdyWFgPbZ0LanAgxiN 0airwoF7sVs8tCTb1B4r5mM+rENrwlyO0ZZNsNjMxp6b5VwO0ir8roWd0f5aqmrur6VM5v76 wlyeuqK85Wbe0R4723AOsneOtGAurWKe6Gd+vXHO0Du9048+5gJA528e6F2Oy2zO6Fvc4qFa IbldBXWLAs760f8Woo2hXiGXbgi4erwnMLKrPutwoeYlu8K0nuu6vuu83uu+/uvAHuzCPuzE XuzGfuzInuzKvuzM3uzO/uzQHu3SPu3UXu3Wfu3Ynu3avu3c3u3e/u3gHu7iPu7kXu7mfu7o nu7qvu79tAARMAHwHgELMALwXu/1vgAOYO/6Pu8noAAToAL6HvD1Lu8jsAAC/+8PIPAPgAIO 8O7xzu8AYO8k4PATgAAFT/ERoAAi4O8HHwEJH/ALTwLwHvIiYPDw7gAjgAD5Xu8oDwAfPwEr r+8AsPIPgAAwXwIjTwImf/MjEPMwb/Ep4O4sD/Q9b+8OAPQrT/QRX+8l7/Atv/MtDwD/HD8B DzD1ETACFB/wRN/wE3/wE7Dz/37xA6/xUg/vEO/y9a7xBk/2JZLvEeAADc/0ACD0cB/3+P72 cV/3b48C7372JSD0DwD3fZ/wb+/wQI8AhA/3hD/374737x71XY/3LF/yOV/w8Y71E+D4Jz/3 MA/3mS/48t74gs/zRU/6iA/vZG/yih/vCCD0EaDyJ//4AIAAfW/zfr/yUX/6E0D2Nt/5Mc/2 JSD6cU/1ItD7dZ/2Um/4Yn/1Bv/29Y4AtJ/5bB/9X6/7EB8Bmn/8bA/vRI/9o3/8Qk/6wu/0 s+/wEO/6Fm/wSi8iBg/5HA/06k/5CpDxlH/4wD8CHH/1Qb/7/8UPAg4CTA8AONNyniU7RSei ypPDstGk4MtEoyaj3u6k47F8KscNMFudVs9aE5cCGk1OGA6gi82EwVTMCMayrtBsLjI8Xd+s B9pXjritv+GvXBvR5YiRVL34ubzMTSQNXVUtngRGjXAZFSX9QOkMtkD5yHWFio6Slpqeoqaq 4uCFzgx9ytysxZZGPByR+iDhIE69aAEsQP2igM4URlWmgO5urWFGKAwV16yJuP5gOWi1huqs 6DRpExfN8LKEbWvV6iUjh/oIc6bZWFZuAV76QCH2HgYTpkiUjR9JBnbxhUZZGSWcIniCtGoi xYoWL3apxkjZCHhEQHVRIMRHwC7OZv9oQaRDDiJJz8zEoydoBDOTRdqxkvgSxy9vGQsO4tYi 2QmRN0RCIjOnzKtsceB085NQ6jyQAn1OjVTw0AglEURgI1GSBMBRLut5WQjgbAt2Mi0pU2ok Isa6du/aFYkurcF52ux9tFVmzyiHP8b9BfW375a/VINYrVmTCI8UhTlpVNdH1BOkNFMSbWtJ SqVibzsTFurlMVw9gkfp0Jp2XKO/j8bi89eFLSEAIh/zRmRZVKxPciEWZY13OfPmvhcuEBeX G2BMVosurm7zgQPpZNVMZRK7xle5eqzGmoyp8tuq6RbOKI+PJw07KFIqB2xfyYruvTjXx4Vq 431DlXrf6MT/ShmSgEOCHN0dJlpWEobC1hV/7RWcFgda594XXkChgHLOkVjiRPHFBEtQe+HU hThM0JHgenAg4cJTwERRxS/DxDRWEBzZ1JVubdAHzU48ZgMFGQO+JdIaP4j4YR0AKgmDaikY SWFcoriBJUFaSBJGLP6gKFYoufm4VoJWijefmme65aM3tYiDnBNZmpinnqY0GJh7cFzyZyhG 5YSnMwl1Mx+ZXBTjQzIR0ueWkSu1AJ12mWHh6E9rbLKhm2npAeUXMlIpCCKedZHCXiQECuhz Mqna2qtiUAoTqETcZpZOsdZAj4YvWNpELQhsgueexyL7Uwkq+lETAjG+QYexuUQj/4qX9DG1 WQsNSeckoJbCgIR9wBKjQzBKPFAbVZri4G0QC6VQiLmC2BkdGmHEoEQhIoEUb07BbNIEsUMq A9jAd0A6sBYDEyEGGTQB9nDB1OATnSaDhJHqfLWSh8mygPpBbWNKjpisySUi9dc12VW3iVou P6nNg9pIpbJfKrAsRMqOcZldHiyIuNi6Pmv8QzA701w0Piil4zI5FQJBWD1GXugH04osFlrB jkWb3SPa8OKs0DjEaHNj2VVKWGK99rX22UAYpi1f1fFjyXUn4+3cAkwkowDffEOzNxMgCR6W MHzL4TcT0Pw9hOIo/D24E5EzAWAJSROHeGGahwR4OpQTpf+4A9AoYCQCnnNWBZI9DIp6UVn+ jUrhkfGdKudw9MDEqpCPbnvkadTOeyGxC2/F7YdLngTf6CxAjbF5Qx+99M3VPTAMd0+fvfbb c9+99xYhEL7445Nfvvnno5+++uuzX/7e4194ffvz01+//ffjn7/++/Pfv//ify+AOGAAAQto wAMiMIEKXCADG+jAB0IQDxGAIAUraMELYjCDGtwgBzvowQ8eUIAiHCEJS2jCE6IwhSpcIQtb 6MIXwjCGMpwhDWtowxviMIc63CEPe+jDHwIxiEIcIhGLaMQjIjGJSlwiE5voxCdCMYpSnCIV q2jFK2Ixi1rcIhe76MUvgjGMYhz/IxnLaMYzojGNalwjG9voxjfCMY5ynCMd62jHO+Ixj3rc Ix/76Mc/AjKQghwkIQtpyEMiMpEYSYAEEqDIRwoRAhSY5CQbWRdKUrIBJWrAJB0JyU/6kJOO ZCQF7CIBCQCAlJokUQIo4ElQwjKHrXylK+vSAFSeQAKrdM4sY+nLG/YSAA2AgCoa8Eoc3JIF uixRMH/pzBi2kpLLTEUtQ5FMYeKSldV8JjdbGExOElOYlczlJDUpyUmGkwWcHCcy2UnKRjbA mJT0JCcl4EpSUsCejlxnNrvpzxE2k5PYPAEEICBKSZ5gm8hEJTjVicuCAkACxIwmAEoJAIja s5QGlegJ/0RZ0Xgq9J8i7V4zW3lRTLoykwk9pkPJucpzUrKiE6XAS+2Jy2sK9AS9zGg6R+rT 7QVUoz1NJQT0WVGWdhSX0XQkRNvJTo7i9KYWTWU1i0rTn2I1e61cJSM1yUlNMlKSCejlVUNx SnXmMwFfTSUqm6rTWp51oAm1pFjXStOwZjWvJoumNHfJT7Wq9KRlJWhg1wnStAq2nBHNZz35 OkqbRnOdFAhnTvVqWR1WtqjLueZlO2tDj+IVLyH1LGlhCNOhlja1ql0ta1vr2tfCNrayna33 murWU1yTkUilLW/zBNNKItWexBRuFySLSZCicqm9Xe6xQGtPFtg2nLd9qye3Kv/XYE6Tudpd TjOrKt3vimKbV81tNbO73fMusprDFEV0w4tU8u4WvfKlCF8Zy17whqK8lFXqaOfrX1V8c7IE fSl+u4DS/VI3l57MqFJPCdz/+jeoJyUwQVF71FwimKqONGo8NRzNcMYVwugtqUWn2d78vpe/ nlTvOVdMz6mKeLsSjiiFL2rhbW4VvivFpiarWU2Txvi81mXrKjl60Yf2862rXKc4R1nWq0J0 rR/tKIyD3Nv62lecjM1kTFInp446NqPDROeHJXlLdFa0k1ZeM5vit2L3wznOcp4znets5zvj Oc963jOf++znPwM60IIeNKRuE7hDIzrRiXUESxvt6EcGQzrShAwBADs= --------------AttPart_12672359==.OLA-- From murdock@excaliburs.com Thu Oct 20 19:29:03 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESjqJ-00079p-1M; Thu, 20 Oct 2005 19:29:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07911; Thu, 20 Oct 2005 19:28:46 -0400 (EDT) Received: from chello084115008175.wrn.surfer.at ([84.115.8.175]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1ESk26-0002tf-Va; Thu, 20 Oct 2005 19:41:19 -0400 Received: by 10.11.98.6 with HTTP; Thu, 20 Oct 2005 18:24:16 -0600 Message-ID: <858p266t.3785356@msn.com> Date: Thu, 20 Oct 2005 18:24:16 -0600 From: "Dina Webb" User-Agent: Apple Mail (2.728) X-PGP-Key: pswkgJMZ6BDmxiNF3pljtnWswUWT4n8hEmPREzsag318o7IE5SopDyOQa58FfsD2== X-Load: 65% MIME-Version: 1.0 To: bridge-mib-admin@ietf.org, business@ietf.org, calsch@ietf.org, cancer@ietf.org, capwap-archive@ietf.org, ccips@ietf.org, cclark@ietf.org, cdi-archive@ietf.org, cdir-admin@ietf.org, cfrg@ietf.org, cfrg-admin@ietf.org, cfrg-archive@ietf.org, cfrg-bounces@ietf.org, cfrg-web-archive@ietf.org, chair@ietf.org, chiname.cn@ietf.org, chive@ietf.org Subject: Pre-approved Application #gamL4000430 Content-Type: multipart/related; boundary="------------AttPart_41061707==.OLA" X-Spam-Score: 1.8 (+) X-Scan-Signature: d890c9ddd0b0a61e8c597ad30c1c2176 This is a multi-part message in MIME format. --------------AttPart_41061707==.OLA Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
! caterpillar ! commonweal see oregon it demiscible be mephistopheles see barbara not pigging try carrot may deathbed on cutesy not chauffeur it's ocarina not novo try avogadro Or maybe not

--------------AttPart_41061707==.OLA Content-Type: image/gif; name="bella.1.gif" Content-ID: <2.0.0.06.0.32799966839122.84079610@snagging.yahoo.com.1> Content-Disposition: inline; filename="bella.1.gif" Content-Transfer-Encoding: base64 R0lGODlh5gHOAMQAAP/////MzP+Zmf9mZv8zZv8zM/8AM/8AAMzM/8zMzMyZ/5mZ/5mZzJmZ mZlmzGZmzGZmZmYzzDMzMzMAzAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ACH5BAAAAAAALAAAAADmAc4AAAX/ICCOZGmeaKqubOu+cCzPdG3feK7vfO//wKBwSCwaj8ik cslsOp/QqHRKrfIalKw2K9FCINkEaVuCSMpeVPc8SmjZIrBXDMButxI5BdLWSxoidncUVoWG h4iJQglgeV8Uf10UDQ2SdHVrJWEklZCAJ3ZwAHKfbnuPWYBYX41fEpGpgVmsWgmMkLSiiru8 vb67kCOUAG6fAFwkbpejsyXFKqGchCKvy3KMfMSTwtqlwSRdn3sj37/m5+jpRuVt29TIIspj cs7uKWmysstxew10z8ncgTnxR8S4QMbUKVzIsCGLb2DEAGTWiNylgeECJjyxJ2Odaa9QsJsY z93BEv4M/2Yb6LCly5fpBpU0hvEghUvjsIgiyRFCgoxYqOka0UVjPXHZ7t0RNhSm06dQl+Ci 120Ey4w3+d0xxtPEOFMJggIoSnCnvZkGm45xRHZs1qhw48r98a1BtoksTWGhM9VMua6astkR C2ajSqOI23LKdtBuG8NzI0uevIId2nfCajHjuqmqipN6ZL21epYnwIrJCh5L6kYt5dewJ1v+ yObnNNG2sqBhg4WmhGU6wel+d9B2UlnHaRP1JFoc7y58KsWeTj3uFmOCbl4nbapz90mD2GUX TkIPPtLNRG+yvdVgeDFd9lWfT18dK599WI1iZW3/l/L83ffFRtj895gJ94HCCv9XCeYHQUIC fvEPZPVVaOGFGGao4YYcdujhhyCGKOKIJJZo4okopqjiiiy26OKLMOKgWokGplBjEj9RWMhP 8sUYRXd2caGFe67pEAuNJxGUJBJHKgKWjzvWddNeJfXowoyf6biEdL7caNVKyTGpZRXy3IAl lDlQOZYrwoQJw5lqjJkEl714GQeYTcB5SJk26IlmDW4IBsklv60QloxyxnAoDG7W2eiXeSaq wqM+8CkEpTJg2iFLx8DBCAt+vinpC6GCUqQidpahaRClsuDGEZYC8aoOdJZ42m2FsreRIGfo lFWhH5Ujh0epxcIesD8Nq16vXPwjiT9bhFVbHvAwM07/UnagQokkK21jigndhZUKMoOZ8axV nxhoG7DCfbNuWIAMa1i41PhVnCSFFqYNSFoYU8uQggDy7WayxBcQHQG79Ucs1VJDh7lHSjKJ rgXfRDF7uWlWYkhuCcxGQTyWoJoko3QiBpf/mXFZG4VWI9CUxuZBTSkfewxfr7wFMxgxMlOp r1VsmFGJRByrNusYd45yRo71Kn1yVj//F3KtdQj8Kx/fyvzRRtMYyHFht8LnTUngejuJGURH hysgJD94sNM8+7QNl5YanMlHZM/MM3slg/ybyj2f6mFvdg3k9ndnjYWdKFAvNdqZN9YK8m0q K95HLF7SSTflzIpReTts25XQ/69jI5iJPBxDnZQ7qv2X3WiBXLNaN0crbfo3M+Yheeh51w40 JsdcEtTRqlFdZfCZ7ffRyWG+NWNWsyKuSm1bhXKy4B5C8lsx1KswY62qa2IM5Mftrg1TeldV UOZwbI4+e4k7fcaNpOcjcnRBP5gHNkmn3zr+KagEILLCK20ITxeBS99+zFe8afhuJm6zx6uI 9wnjGfAYnDHgJH4DO4PQ4XkSceBt0Hc+Z9DDgiNaxTvGV6hhgANbjFOFt85Qja2hZG7ayVkI f7emQCwtJziUFgmPprIHaqIgKrQd3BRzQY6B5UnKM8gntFbEg7BLeb2JIlFyhSXUfYx6udHh EkXYo//gEKyHz0iiBZ/xM629Yn5LkmLT5FimGg6DTnasBLOAp6K31IpiN9wDveSgtkHxLBXQ CSQXm+WeiZFrFutSofX2xUHd9MsUlWxY8pblLE8MZzkL++Ico0GKUAjikFfc1yOC1K9DNgmU wYEEI12JrDXY4R2pxCB6QJMKMMitM8vZhh5YQ8AOWutByCCFwmxxLnpRDF8hNOSf6PM8w7hQ IWJRYhWwN81uVuEgEalHQ6iULCukypvo3BE0TaA1hgzTCrFKpzznSc962vOe+MynPvfJz376 858aEuAPyukEgf7AoEpalazaCVASjecYrZTBznpgCoUCYaI9wKjI7qaEijb/1ES3kJI0FUWs HdzCogMt6Q46ARnpoNQHvmwIQz96BDO2xgZZpMtLfZBTnsavh1CI4zkCBaWd9sComeBYDXra A6EigakscFsLoHqYoBr1BVKdQVZZkJIYGRFWI3yTLK30Aqoa6aor/SkKAAOKnzo1CW/FAVtd pdYQ6RGRTUpYHN4IP0o0q5DAetanCAmuV2wDX8SZ2LkMldc3eG44r6yYNNnDh35FA7FeMexJ MOuWcrwxslqZ1pFyqtdjdVY3pcVX4rLjE4mxEJg+5IIMf3UvjpLjLq7tLGIt28pnkiE1p+NW YgkxLPkwjRmcRY9mW3skysbDsMwaaRVkpy+fcbGy/8HYnghl+JuaKTE+XkuIHcLyIKvtUG8h W0FbdOIXnHUtftlCzSv8covthQM6MdXEKZqB33H0F7v77WBrMjJfoJgtD0VpDSlaAS0ET2MW fiFQK4xDiu78rCQBZmYxAWuwebxDWzrpBB8awd6iQCcYDJaG9m5S4MbpbhWoGcNhuRDhQPp1 gw5mm4PFteIBx/UJ7vMg8uw3o+gFkRjKrJzM7qCL2rHyvNKLKq7aJ8ztmiCnZIEYbcOIuLDO ThuZ/NdSUAPV79w4DVk0z9mg55NbXYe08SNqT4tSkY1wSs5v+Up1vaK28RGiKJJc83Uk9sN5 7VnLIZziHfZRXbIQFQ0DRP/mFkasWVvsedKHCDLyJAiSDCYWa4e1GiPrejSBQk+EMeDUX6q8 ssyki1+GfVqsFTwgPm+R1g/CNVJarZV+nKLWaf61T8IJOn7c5xYIizMQafJgN3FqdmoqjlqX TZqtWQLFwtZwGAAzkTUYDCB9CdOtbssR8Pj1PmzrsWeCNZspaLrKU8xGO+so3h8CsDy5Sk6Z XGe2D7YwXo9qSyI7RjCV2pAZYsiu89ITi2ySo4XjaDghJJ4WXhNOkIZUWaA/hkxmcVBQHNcJ fJQNaiR+o90i/4jaRuwuod60NdwlTidwyPFBxefR9VgdDU8t76+cadwVvzIyWuO5Myg8hHcZ lG7/6O1DJnSnsxR7J7tBCT/7elLS6SGsfs2233RbXSAUita+8PG6JXlBEF2ebWYi2g48qAeH rQyNcNeOObGngdDDzZhu8H7a8zQSjmLXg3wk1nImn5adQ1Jzsj0ezGC4/TsiGxJEr/Od74QJ XwFTFuJfrZlBzJwQlidYEju8kM/N9ILLa0KD7rTVwu2H0QMqEJKjg5+qJUNCJ3hQrfNzCWwg TD+FS0iBhFejBcVOvDVy/fEXA/Bd7b5w2NKPgrbqe9HVYfeLkSr0y5Au4Ggf+8rPfilch5/w Y1/8ww9+7kURfv7ZhbxSNX4guBGPUaEqZ/NiHTdpyv+l1lVDfYUCvEJW//1XgDbwSQaYgAZ4 TQrYgA74gBAYgRI4gRRYgRZ4geiQXuBgf06HVjhCehm1f3yUURyIKh7IIYLAGJpEBFBEDv8X BXpVHhfRMO9yAjX4XCN1gwiigVfQbgLogzYgL+ykYuy3gqonVKdHIrYBDiJoUsb0gkD2N76j JodzL4dUWFfIM1n4E1mIEiUYA5tDgCOoA69ACY5RHrfhGDd1fWA2BanSKiDyaFy4BPEEh07w B59SD8ZkILXHE30oTP8AiLw2FmKIA2G4AihUA1NiTZ9EZfCRGYVoBG/4hRmSRblkBHX4hYsy BBJyeWpSHuKAb5ogiiOkMqU4FMYUgrlXHiS0A/+TwIA8Ixbgoz8epnqQwk6UmCG+lItyZUx2 iItFgEnIN2Tg8FzSkBrSMIf6UIT1EIk4NRRHU2pNyFWzNDOzcoZ3go1apAR0kiq1xyIncSyy 9g7ygXa09FiidjzWYnCCxXJApEniuDPNsljmkkuaN4cd5EIOt48j1Bv9CB7HSHeEkFq2FSyL lI/Tklifty04CF+MhEnGtVhq2DXHYQY38jmiYY/QNXPCE1E/sU6Vp2U04YwgYjQvU3QWgRJL sz8naTklJA+V44cfcxPh5ZKIERFaowx+g0mECC5ywzZ8oY3Y0o/MyBT7uDCc0GRQc116oYxa aDmAkxzSMTDRmIbexYP/c1gQLNlSfsVMVcImX4KRN5KVG3E3NZRlTJkeHNONEPcwL1I8ooBE cNBBZ8FApSMPj2NnHDd5yAAnu8NG0LIdoTJYWHceXbVu2jgR72cPi4kd+pYVoyEWqRhSs5VK QVaV79Met1d30iUMoaNmr1iKfgWKJgRacGk/kflgydZ0/aNLMXKaRDE9KTkG9baBLikWeDk+ BOJYrhmbVxaX8bIHoOdlgzliyTEamxh0JXNE6NIpzSksu5lwnmZMz2A0VDFEqJY3wPNV6lNB +eWFvfmS9mAx47kM1WkYsDkrnCZkJdSNSfGLJJKTUvI06IgGN7OG1jVyaGFHq6ULaINkQBUQ /2KkF0JxMmzjJhODTPswGtgiQ/e2ljmRM/cmSdDYOPEmRyqpDXwQEg6XekYWiMl2n7aXmZVl nKkBL0qlnfrCh8IklfbGToIhRm3EGBU0De5JDlNEktkDD+IYTASKhobUo6h0S4L1LAP3dt3S GOnBMtX4ORRzSoHUmUNmHlQ2WX5UjZOUkfIRd/igeUy6MPZyReFyLmswcguzbYv1pavAm0Da mbXjpetYWFdHhE+nGVInXLUgjMkUC5eIgWt1pToqK42Siox1IrConX46GQCRok2Qh2TIi9Vx qIlKHQM4qZZ6qZiaqZq6qZzaqZ76qaAKqgFAAAPgA6Naqk4gAAUgAP8FmIgMYRuBCiBQ4aou MAAHcKu3agCsygIBcKuougO9egC/GgMFgKu3uqoyIAC3uqtHEADFegDMKgLKaqwHUADD6gPK GgC7YEZO0Vqx+mFPwa0wYA8CQADVOgDmCq28aqvXigMBwK4i0KvRugKqegCk+qzaCgPlqq5I 8K62agAlMKrnOgC2egAGkK/Yyq+KQKvq4ELx1AJJ6BAMyxHL0KuoqqztigLC+gMbCwDKOq/0 yq+2CrIs8LFMUAAFcAIdKwLmmrI/IK+8MLHogCyEugLnNE7TSIwi0LEm2wIrywMr+6sCkLEl 0LO2irAv0LNJoLQk8LMAYK4kmwMHkK8uqwP/Q0sCVbtUOStR33oDNYtVJ4gDFamKU4UTJkCt BYC0KuC0OsC2AGCtJUutBDADTHsEcKuy12qxQLCrAwCwO3C3ANC3hri1MfC1A2W4LXCzwWiV ZPsQZlsC9kqwxeqy06qwBVusGVuvG+uskwsAzrqsI3C5PHuwgWusaksCGEuwBmCvInC5+SoA BvCsaSut0Fq5AcC51Tqt2oq50loA6aqr8ZquBFC5BaurWQu57Rq7rYurQru6wPu5Iluttzq3 qGus89q3z4quvhq6x6qtBbus1vu00zsCBFAABkC6pqJcXiePI2FYlflYzUBYGOMMi/WRcKcL 48GF/XJJZZqRp5cs/9UipElppM21WK4VLTdYj4TiSdsgW7JUDpP0TkMRtNBqsdgrApirve2q rKQKvtVqrpyrvayaweZaqrrrsbE7AFFLu8xarAEAuwS7sZervdT7sbZqrdPqu1MLwihswrka w1MbACm8rJhbrypMtADAtr4rvvfKur16rwBbwtX6ttM7AMUarapqAARbAsLbt+e6uqwKw/AK uzicxVtcwuwarMKqsBkKVL2RRmC0duRFluwZXlEpMk8TLOSFMo8ZTeQ4NFODMx8klTEDaq9m DZtQXb+SxyXER4EMUTTUe3MDRuQ0Q+nDoGf7qxbrr87ruSurxJQ7AO+qrgJQub6qtztbqv8C m69aHLfM+rHlWrAmzMNv67eVu6ujHMYeO7Ui0MoCu6s2zMvv+sKsW76eu8JOu8krC8Lfu6zp OsVZHK9OK7gmEM27rK0mG8vbCwCt3Lp+q8a5GrgGMLcrPJWniEUE9JibaRJ8gQdZmpTDQURL 8TaNbEavc1zbqKI4Y5tJqZ1+RDL1nDNipyf8xjwjqC7KpLOZPALyKsTCar67zKxsq7wkALO7 TLAEW8oKy7O8zM1IPAJKm63T2rcX29HUrKyTm68Wfc29XNK4DK1HWwJX7LbIWwJHi8rXzK4Y fbvPysvU7NE27bcmcNLCTMq+2s3dLM7STKoZ3dKI+EMHpEFDI2D/t3Ge7Jk4IVUG2qWij1Im 0QgUCJQUdiKNY3gm71Z0uaGdXGI8eqIMGyQPN2rVCl3RrOu5LmyyEN2rwAuvXCzDworKvTq7 VqzXrMrX2drLVQvR1cyvZFy6t1vXh/20tgytLcuqOI2xpVvDHQvCHLzLKRus34y+AVutr1vC vayuzgqwnf202Pu53ivU4xzUKEDU2qq3N13XFK3UvQy8yorYkHhDInpcb0QRZYMwL+qa/8kI HBpW60NGsuAxzZg3EZEsj/YbWYRz7fA7+ImQ/sw7efHPJSFv8NEow51f2eQ6x+0OTpnE1Ira 7V26uXqsAbu68v2sfvu9pIvf8o2rI4yr/79ctO1NuqZM2sxru7havsdq39Kcq6ubsgOOqj2N vobttu0NurQbvlQs3/QNzfx9uSTwvVjs3/xN3yqMthk+tSBuyoXt3wo0dtrGafTpFTEzp0nG X9XYHPERUe/cSOn2wJXUXdJESDHG4zwpwBj2Z2HwLINhN4MCkTUIpdFdyWFgPbZ0LanAgxiN 0airwoF7sVs8tCTb1B4r5mM+rENrwlyO0ZZNsNjMxp6b5VwO0ir8roWd0f5aqmrur6VM5v76 wlyeuqK85Wbe0R4723AOsneOtGAurWKe6Gd+vXHO0Du9048+5gJA528e6F2Oy2zO6Fvc4qFa IbldBXWLAs760f8Woo2hXiGXbgi4erwnMLKrPutwoeYlu8K0nuu6vuu83uu+/uvAHuzCPuzE XuzGfuzInuzKvuzM3uzO/uzQHu3SPu3UXu3Wfu3Ynu3avu3c3u3e/u3gHu7iPu7kXu7mfu7o nu7qvu79tAARMAHwHgELMALwXu/1vgAOYO/6Pu8noAAToAL6HvD1Lu8jsAAC/+8PIPAPgAIO 8O7xzu8AYO8k4PATgAAFT/ERoAAi4O8HHwEJH/ALTwLwHvIiYPDw7gAjgAD5Xu8oDwAfPwEr r+8AsPIPgAAwXwIjTwImf/MjEPMwb/Ep4O4sD/Q9b+8OAPQrT/QRX+8l7/Atv/MtDwD/HD8B DzD1ETACFB/wRN/wE3/wE7Dz/37xA6/xUg/vEO/y9a7xBk/2JZLvEeAADc/0ACD0cB/3+P72 cV/3b48C7372JSD0DwD3fZ/wb+/wQI8AhA/3hD/374737x71XY/3LF/yOV/w8Y71E+D4Jz/3 MA/3mS/48t74gs/zRU/6iA/vZG/yih/vCCD0EaDyJ//4AIAAfW/zfr/yUX/6E0D2Nt/5Mc/2 JSD6cU/1ItD7dZ/2Um/4Yn/1Bv/29Y4AtJ/5bB/9X6/7EB8Bmn/8bA/vRI/9o3/8Qk/6wu/0 s+/wEO/6Fm/wSi8iBg/5HA/06k/5CpDxlH/4wD8CHH/1Qb/7/8UPAg4CTA8AONNyniU7RSei ypPDstGk4MtEoyaj3u6k47F8KscNMFudVs9aE5cCGk1OGA6gi82EwVTMCMayrtBsLjI8Xd+s B9pXjritv+GvXBvR5YiRVL34ubzMTSQNXVUtngRGjXAZFSX9QOkMtkD5yHWFio6Slpqeoqaq 4uCFzgx9ytysxZZGPByR+iDhIE69aAEsQP2igM4URlWmgO5urWFGKAwV16yJuP5gOWi1huqs 6DRpExfN8LKEbWvV6iUjh/oIc6bZWFZuAV76QCH2HgYTpkiUjR9JBnbxhUZZGSWcIniCtGoi xYoWL3apxkjZCHhEQHVRIMRHwC7OZv9oQaRDDiJJz8zEoydoBDOTRdqxkvgSxy9vGQsO4tYi 2QmRN0RCIjOnzKtsceB085NQ6jyQAn1OjVTw0AglEURgI1GSBMBRLut5WQjgbAt2Mi0pU2ok Isa6du/aFYkurcF52ux9tFVmzyiHP8b9BfW375a/VINYrVmTCI8UhTlpVNdH1BOkNFMSbWtJ SqVibzsTFurlMVw9gkfp0Jp2XKO/j8bi89eFLSEAIh/zRmRZVKxPciEWZY13OfPmvhcuEBeX G2BMVosurm7zgQPpZNVMZRK7xle5eqzGmoyp8tuq6RbOKI+PJw07KFIqB2xfyYruvTjXx4Vq 431DlXrf6MT/ShmSgEOCHN0dJlpWEobC1hV/7RWcFgda594XXkChgHLOkVjiRPHFBEtQe+HU hThM0JHgenAg4cJTwERRxS/DxDRWEBzZ1JVubdAHzU48ZgMFGQO+JdIaP4j4YR0AKgmDaikY SWFcoriBJUFaSBJGLP6gKFYoufm4VoJWijefmme65aM3tYiDnBNZmpinnqY0GJh7cFzyZyhG 5YSnMwl1Mx+ZXBTjQzIR0ueWkSu1AJ12mWHh6E9rbLKhm2npAeUXMlIpCCKedZHCXiQECuhz Mqna2qtiUAoTqETcZpZOsdZAj4YvWNpELQhsgueexyL7Uwkq+lETAjG+QYexuUQj/4qX9DG1 WQsNSeckoJbCgIR9wBKjQzBKPFAbVZri4G0QC6VQiLmC2BkdGmHEoEQhIoEUb07BbNIEsUMq A9jAd0A6sBYDEyEGGTQB9nDB1OATnSaDhJHqfLWSh8mygPpBbWNKjpisySUi9dc12VW3iVou P6nNg9pIpbJfKrAsRMqOcZldHiyIuNi6Pmv8QzA701w0Piil4zI5FQJBWD1GXugH04osFlrB jkWb3SPa8OKs0DjEaHNj2VVKWGK99rX22UAYpi1f1fFjyXUn4+3cAkwkowDffEOzNxMgCR6W MHzL4TcT0Pw9hOIo/D24E5EzAWAJSROHeGGahwR4OpQTpf+4A9AoYCQCnnNWBZI9DIp6UVn+ jUrhkfGdKudw9MDEqpCPbnvkadTOeyGxC2/F7YdLngTf6CxAjbF5Qx+99M3VPTAMd0+fvfbb c9+99xYhEL7445Nfvvnno5+++uuzX/7e4194ffvz01+//ffjn7/++/Pfv//ify+AOGAAAQto wAMiMIEKXCADG+jAB0IQDxGAIAUraMELYjCDGtwgBzvowQ8eUIAiHCEJS2jCE6IwhSpcIQtb 6MIXwjCGMpwhDWtowxviMIc63CEPe+jDHwIxiEIcIhGLaMQjIjGJSlwiE5voxCdCMYpSnCIV q2jFK2Ixi1rcIhe76MUvgjGMYhz/IxnLaMYzojGNalwjG9voxjfCMY5ynCMd62jHO+Ixj3rc Ix/76Mc/AjKQghwkIQtpyEMiMpEYSYAEEqDIRwoRAhSY5CQbWRdKUrIBJWrAJB0JyU/6kJOO ZCQF7CIBCQCAlJokUQIo4ElQwjKHrXylK+vSAFSeQAKrdM4sY+nLG/YSAA2AgCoa8Eoc3JIF uixRMH/pzBi2kpLLTEUtQ5FMYeKSldV8JjdbGExOElOYlczlJDUpyUmGkwWcHCcy2UnKRjbA mJT0JCcl4EpSUsCejlxnNrvpzxE2k5PYPAEEICBKSZ5gm8hEJTjVicuCAkACxIwmAEoJAIja s5QGlegJ/0RZ0Xgq9J8i7V4zW3lRTLoykwk9pkPJucpzUrKiE6XAS+2Jy2sK9AS9zGg6R+rT 7QVUoz1NJQT0WVGWdhSX0XQkRNvJTo7i9KYWTWU1i0rTn2I1e61cJSM1yUlNMlKSCejlVUNx SnXmMwFfTSUqm6rTWp51oAm1pFjXStOwZjWvJoumNHfJT7Wq9KRlJWhg1wnStAq2nBHNZz35 OkqbRnOdFAhnTvVqWR1WtqjLueZlO2tDj+IVLyH1LGlhCNOhlja1ql0ta1vr2tfCNrayna33 murWU1yTkUilLW/zBNNKItWexBRuFySLSZCicqm9Xe6xQGtPFtg2nLd9qye3Kv/XYE6Tudpd TjOrKt3vimKbV81tNbO73fMusprDFEV0w4tU8u4WvfKlCF8Zy17whqK8lFXqaOfrX1V8c7IE fSl+u4DS/VI3l57MqFJPCdz/+jeoJyUwQVF71FwimKqONGo8NRzNcMYVwugtqUWn2d78vpe/ nlTvOVdMz6mKeLsSjiiFL2rhbW4VvivFpiarWU2Txvi81mXrKjl60Yf2862rXKc4R1nWq0J0 rR/tKIyD3Nv62lecjM1kTFeq7K46NqPDROeHJXlLdFa0k1ZeM5v6lsl3wznOcp4znets5zvj Oc963jOf++znPwM60IIeNK4u0khDIzrRim1SBxvt6EcGQzrShAwBADs= --------------AttPart_41061707==.OLA-- From capwap-admin@frascone.com Mon Oct 24 10:16:11 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EU37T-000806-KT for capwap-archive@megatron.ietf.org; Mon, 24 Oct 2005 10:16:11 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12056 for ; Mon, 24 Oct 2005 10:15:57 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 8B2DD204B2; Mon, 24 Oct 2005 10:16:04 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from rwcrmhc12.comcast.net (rwcrmhc14.comcast.net [216.148.227.89]) by mail.frascone.com (Postfix) with ESMTP id CDFF52046A for ; Mon, 24 Oct 2005 10:15:37 -0400 (EDT) Received: from [192.168.128.4] (c-24-6-199-181.hsd1.ca.comcast.net[24.6.199.181]) by comcast.net (rwcrmhc14) with ESMTP id <200510241415360140069c48e>; Mon, 24 Oct 2005 14:15:36 +0000 Message-ID: <435CEC88.1090201@hyperthought.com> From: Scott G Kelly User-Agent: Mozilla Thunderbird 1.0.7-1.1.fc4 (X11/20050929) X-Accept-Language: en-us, en MIME-Version: 1.0 To: capwap@frascone.com Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Capwap] lwapp dtls draft rev'd 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-Unsubscribe: , List-Id: A list for CAPWAP technical discussions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 24 Oct 2005 07:15:36 -0700 Content-Transfer-Encoding: 7bit The ID editor rejected the initial copy of the draft because I used the wrong RFC number in the xml2rfc ipr directive, and the required IPR boilerplate was not there. I had to update and resubmit as -00, so I took advantage of the opportunity to fix some formatting issues, add a table of contents, and fix the MAY protocols for use with certificates. It won't be published until after IETF, but in the meantime you can see the updated at http://www.capwap.org/DraftsForEvaluation/draft-kelly-capwap-lwapp-dtls-00.txt _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Thu Oct 27 01:48:13 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EV0cX-0000sl-K7 for capwap-archive@megatron.ietf.org; Thu, 27 Oct 2005 01:48:13 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA25672 for ; Thu, 27 Oct 2005 01:47:56 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id C2C5720485; Thu, 27 Oct 2005 01:48:04 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from huawei.com (szxga02-in.huawei.com [61.144.161.54]) by mail.frascone.com (Postfix) with ESMTP id C685720442 for ; Thu, 27 Oct 2005 01:47:19 -0400 (EDT) Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IP000B4E8HZ3T@szxga02-in.huawei.com> for capwap@frascone.com; Thu, 27 Oct 2005 13:56:23 +0800 (CST) Received: from szxml02-in ([172.24.1.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IP000ERI8HY2J@szxga02-in.huawei.com> for capwap@frascone.com; Thu, 27 Oct 2005 13:56:23 +0800 (CST) Received: from MADHUR ([10.18.4.183]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IP0002498HPD7@szxml02-in.huawei.com> for capwap@frascone.com; Thu, 27 Oct 2005 13:56:16 +0800 (CST) From: Madhur To: capwap@frascone.com Reply-To: madhurnamdev@huawei.com Message-id: <004301c5daba$0e6fd730$b704120a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook, Build 10.0.6626 Content-type: multipart/alternative; boundary="Boundary_(ID_k3aXqEHeNegqRooyFN3kbg)" Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Subject: [Capwap] Need Help 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-Unsubscribe: , List-Id: A list for CAPWAP technical discussions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 27 Oct 2005 11:18:25 +0530 This is a multi-part message in MIME format. --Boundary_(ID_k3aXqEHeNegqRooyFN3kbg) Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7BIT Hi All, Any pointers for conformance and functional test suite of LWAPP would be great help. Regards, Madhur **************************************************************************** ********************************************** This e-mail and attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! **************************************************************************** **************************************************************************** ******************************************** --Boundary_(ID_k3aXqEHeNegqRooyFN3kbg) Content-type: text/html; charset=us-ascii Content-Transfer-Encoding: 7BIT

Hi All,

Any pointers for conformance and functional test suite of LWAPP would be great help.

 

Regards,

Madhur

 

   **************************************************************************************************************************           This e-mail and attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!

****************************************************************************************************************************************************************************************************

 

--Boundary_(ID_k3aXqEHeNegqRooyFN3kbg)-- _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From bullockd@btinternet.com Fri Oct 28 10:45:03 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVVTa-0001RP-Vu; Fri, 28 Oct 2005 10:45:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21693; Fri, 28 Oct 2005 10:44:46 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVVh7-00080D-0K; Fri, 28 Oct 2005 10:59:05 -0400 Received: from 221x244x96x253.ap221.ftth.ucom.ne.jp ([221.244.96.253]) by mx2.foretec.com with smtp (Exim 4.24) id 1EVVTV-00005o-5o; Fri, 28 Oct 2005 10:44:57 -0400 Received: from [192.168.1.0] ([221.244.96.253]) by yahoo.com (Sendmail 8.7.9) with ESMTP (SSL) id IYT10479 for ; Fri, 28 Oct 2005 09:47:01 -0600 Message-ID: <683p656p.4698540@yahoo.com> DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=heighten; d=yahoo.com; b=AdBsGXazElVV4YPr0TDdgEAlJVJhqYWijmhhRja4tK2k0dWFjxunCCRfVnlGsMaFoNOBVpNWM9YOa3NC; X-Display: Full X-List: autocracy.usenet Date: Fri, 28 Oct 2005 09:47:01 -0600 From: "Cornelia Cooke" User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: calsch@ietf.org Subject: Lowest rate approved Content-Type: multipart/related; boundary="------------AttPart_43396289==.OLA" X-Spam-Score: 4.1 (++++) X-Scan-Signature: ee80a2074afbfe28d15369f4e74e579d This is a multi-part message in MIME format. --------------AttPart_43396289==.OLA Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
or mccullough some beneath it's bouncy be slave the loveland ! backplate try recline ! anteroom and curie try string be piccolo a convolute and elaine on clayton Or maybe not

--------------AttPart_43396289==.OLA Content-Type: image/gif; name="sherry.5.gif" Content-ID: <8.0.0.05.0.72340207053822.50576362@switzer.msn.com.7> Content-Disposition: inline; filename="sherry.5.gif" Content-Transfer-Encoding: base64 R0lGODlhtgHYAMQAAP/////MzP+Zmf9mZv8zM/8AAMzM/8zMzMyZ/5mZ/5mZzJmZmZlmzGZm zGZmZmYzzDMzMzMAzAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ACH5BAAAAAAALAAAAAC2AdgAAAX/ICCOZGmeaKqubOu+cCzPdG3feK7vfO//wKBwSCwaj8ik cslsOp/QqHRKrVqv2Kx2y+16v+CweEwum8/otHrNbrvf8Lh8Tq/b7/gf5ECCLFQLEAB+eYWG h1V7fX8pgYOMiJGSk0OKI4SNgpiUnJ2eM5YimAcQEhKWjpiBpqGfrq+cpaazfwcSDiILEnyp f7qMDruww8SGrYQQuCOOvQASkAAOysXU1XDHf7KzpgC9tnzLgtbj5GjYjyfNzyTS5e7vYOe/ IqS+mr7r0cLo8P3+UucAkKKV616uWZZs/VvIkI0DaA0jSpxIsaLFixgzatzIsaPHjyBDihxJ suQ4XSRu/41o52ITvXwuFkzz4TKGo0Ezy9wkoevAzioscdQUsu+GA3Epiu74CWSfLqRDU9S0 BXGFzCBRY4pLloZpt11epQS9kfWH0hpHV5zNEbYHJmn71kqtKuMqkLIs2upEakLvk7E28PaQ axYcD786WO4ihJKerFYCEdoKFgycLlaGL5sCLCIYZnqeYT6bhcsWq4Okp4VWpK1eNwiPDa92 +ZPQgdCMFK7M+TX1t5eQwML+rPDmQFN0j99CuupUWoGPk2urHG048hG3CUZm58D0Ke4p+RxX xdfPZJUjnMaONg32bp6CAq3XrCy0skDB8H3Wt661EJSkdIPLc5MdZNgltVwnzP881R3ESCm8 wQbOcxJCp8x1rvHDIISiWPLcTYydwos4R4l33SIvdSgeV7p1ltOGKr2FHjMiNljcVuJkiN2M 33314HcF+lgCKTmawkcwOXI1iCKklCYBePzsGE5k961T2wKmQbRgPpW1aKQIML32lSI77VOi hb3xwqUg3wQo5hDftKOQkkoWZIJt+QgT5kPOHFinnSY89xIfMLGEiVJctQWiPeB809OOEN3U jqCRHdAieyUgistNo4nC6KA3NiglilM6A417fza2El+/URonq7tcamhVmCAzE0pXUmWCntC0 w5g0+JTATEJxqemnT3H1+keYiOnwjCV+5KPNNncmCE7/rNtI9iRPOXGGKYpFzbodt9/2tZU9 O/rEV5TpWSoMYOZt6yIJlwoIJpb36PYTtmKGts2x9LIpr50u/baSlkfmtAu8WA4srrDxnUuv cIsYHJ7FYvbiCJ/wvVkpmGpm+4xxIgNZocdCHCWvygiygOe1hB6Y3qndrtsZrDG/x4+moprr qceODqxrCcCSiLPFNfHMHp8ysbSvu/3yVgJt4iCqya0D9/yxqwsfXVStdPlRK9ZfXbwWr1B2 aupZw6YLctk+v41CY82yhd6Yy+SjY8sGv4vKlj/mROSEODp2oWzKyBg4dB6KsyjQwlSYpQmm GeYemksaSLS06FUOpnpmixkk/5HC8mg0OKUIXCVEthT5bo9Ndmi47F+hTtcqO65OpewYv80g dfrU12PHO/WNuodP7nRm7TQCCmeYd0On3dTWyq3ZJprdwlt2+ykXHOI/o7aZMtzX+CZjSBk8 W9isagPJeLdvE9TlmTvfZ6jSb3aCcoJezxL8+5uO39yHHQI6hhWQyEr0AHjAGvWuT+ILBYOG Rrz0FWslkkHZ9X6Uj7qZhAVhahke/pSFB37QHaOjX8fmQD/gbcFbJ0ThdGQWvjmshoZYIEwM d8jDHvrwh0AMohCHSMQixkEwT0BiXwqlw5bYDCtPhIIKYzDFFlRxIFE0wqOKsMUZdBELSmxC GDNVJP+pUTGLNEGjGNWogiq6zGZPocsRvvifJlrFjlKUI0D0CIj+4PGNR3CjFNkoFUJODY5/ rCMOf0BHGDTSWZqxlCwg0Rwm3eKSp3kNKwgkQMs8hpPT200pJEkabGXyeou8xCXfd0MwTYOO qZtFZrZRCiGJYlsbPIF19IfB/eRPNNqADH+Q0sr6eY8n8ouMLH85E39N8XqdyaA+Ujek6QAH g2PiRt4mlMEtMmgex7xljELZOiMppxTZIAj/cHCdp6jJQdF0l7QYASM2Xc5z9aTd3qbJuJfs QxVrWoFpyuMcWRDqlWf5pDYvAxdtwk4lDPUMrcbHoWk21ETaq2hqhveS4fz/AUkXzZxppFFR z5BUJSrrziAK2iOQemZdA+GTSSU6zAMNVGUCg0QwekOb12kPOUGipj7kedJNnWKUq1DpjoCa OpVZCUJ8aKpQa3A30RCqV92ByaFOJQiuXbUPXYUV0Yw2Mdvdix18HCoGEYqLu8GSR4QiFi79 SKh9kG5qWgXL8AqETlXWFRhZa103kGVBXKAqr+7iC5ZoR5m8LeApeUOkmizYVY7eMoHPoOBO 3Vk6wu5IE0/yTlxXillkDUhzE3sdZun5OoSmVS2GsSrGAoG0BEEsGgir18ZKdiCWcKxdP/MO Le8om6x9x60JZU5mmSUvEalEuP86JDIfWzLQimxZ/6rJ2kohWt3MTYsWDLoTiUr2EKstUU29 etJOxTuxhuk0eWvpSXj14aNfjMyP1z0Oa2U2tPXOTHP+Io0NikLgr+6mtnKTnVcheImumlFn C95ZKucWrqIUaHgupF1kGjaTWkZzlJFJhjRGLN5ZUlfEI07niEd8UGya674oBpZ3tbdiZMnx cpRZ8UPCe1dkorcP6tXuSqcbpCE3Ur5h8vBRNTGcW+pYqZcx1pC4ZOEOtlbHr1VBgYH7O2xZ DhjQAtJD/YY6MZNviv8bs1mrY5kt4bCLnB1IOhOkXfrpqqKyWGp7rByhGl0mxID9aOcudzf/ GugXrQt05hrbz5HCs35xBv8xhqa6TWXWgkOGxiCZvvQlyB7ZlJdGD00ZGs0zh1WtdBxanE/0 qEgnEgVbtl4GERzB/3Wy1mcWMNGmwb9/UhIh+02HUrLXuWzRyoKhzhY7LPzdiWarzbQsczKd kd3SLZPYrNlKtsh3XQ0H2JLZkqw/ERJNFDRbfJ2OrzCga8F1f0mcAvYXaiHVy20Emz/SzAIJ XfbgJdyGcizetVKFxcrMpHgmPukLidPRNM6kWFgB7wwltyeN3so4FxOvuMBvBY3baJw7wKrK bSz+W7ukY+HYQfnIAQ5yiJQ8UhEXEK+lNnCBHLxRCI85FVpoR55P2IhAt2G+VVDMoBv96EhP utL/l870pjudi69+utTb8MipW/3qWGe6QqgSSpTZxoDMjBySSJ31sgNh61/q3Si2dc+vuy6q KunPz81O9xig/cu3xRTXtPYbOhmy7oBvAdpJZbYj8fa3bxtFXwPPeBoMXoTckRTNccYuCjb+ 8oIP7cCG4rndNVrN6CCFu7JROGpj/vTbuVRUVLjOBl4yqoBFz+UI3W/U2556t889FTyo+95X Isu+D77wh0/84hv/+MgXAwxJYsKQ/GT5SIiKm24QdRyMh4bKPVFNKSeLV04yb+YLWAgZeTW5 6evvXtQ1T3LT/XBoP481ZAf6k8CxeolROjmoPllGXBO6bZr0UWUzJuMk//iAD4YnM6oyBKlw OCmCMj1gX15xKPZEgLYEf+yyKiUUOcBHBNI3f7A2dzzwDJxhGjVUIgQGDcWzMN5nKpfwIh5I A0xhV7j0glrxQPkBOR5XKhYYFZRiBYHwE5W0Zh+zOb5kHw04L4pHGjZTPt7UTepXb9xGKkb4 Gje4KvuWDEJWNFAyLzOzCd9QFECoTtHhIiBWQKVkeCGkMRuFHMaxHtynhLcEGeeBgLDxUTPx LO/DNvIjOKMhIpcRClO4NvrjHVfzGBioBWVoS9ThhclFODezIgIDHnhSJTZzOVGmiEixFmdy V2v3iGhyiZvTChWnXY7CF2PxJ9GShwmYgG8SJP/zgCTV9HZtsi7NwGDn53mpZjoZs4QVNSi2 sggwMVucw4eRUyE4xiSEtg4ZUis9oiQ96IN8sSeGlYcHEhZfFC+SmA0ouC6U8ih7wgh66Ce2 hQ7XiCyLlFKgUmfoojOi0GE8pjYHkXepol42s2DjJyaH0igziBMrBHkZo0Ot4yHTyI8IEoxK oTT0NoTFgSjLolOJ8yDMQVZakILVaBCDsoX96CKyMpAFsy4kZErhlmD28y3Y2BvGphejCHvj IkLP10x3+IPpAoa0KDHp4nAIwzh0KGENmAolMzU25TjhV1Zp8ThjgYduc4S5wIejsh1M0Q7h 8pA1pBvPWAX7glXlwor/U3mNDYN3v6iDN+NjDLYrCMiQBQFQ6ZBFviIT3RYlFsMsFpSDdqJV LtiOyFQuh3iR8dgx+biTFjkXGTmVpQhdp0CRQRGDfqKUR7iQ4hiWD8OIXxCGgPVjsRMwjeOJ nAiUKumKlqWZZIZamoiMBAVW3OSA0NE0PWEYLVITxpiJoxU7uqIrrcY2ZQRPI6hmzaOX4KiP djJB/aeLMsWNWdUki+kME7hhxrlsizMxSymVoJlgjZmHGoYFTIFK4Bc9KZdvgchASbgZvHiG EfQ9JxCISUmEfraERdeA3zVe5tOGvKRJMPGHNFQ8Y2iXZrgZkfN++JibfOl60gGHWCQzTmWd //xwHN6Hn+gGGC2SoCujfk8ZPo5ZPxthf2JRezAgTO/QfMknbOxHoUwAfSKBoRn6Yu0ZoiRa oiZ6oiiaoiq6oiw6AgRQADBKAAEgAwJQAERAAAQAADUqACJQAAPQRk9IRRtIEwhkAgEAo0hK ADxKBD7aoz/qA03qpOwEgjswRmeHTlMJA9MnBDg6AC+aozFQozeaozX6pFFqbgkypIRHf5tm pAVAAAPgpTD6pEIQpWfKA2d6pzSgf4Ghpj7QGFn6AlsaBDgqAoUapjY6BIUaAAMwowCgp7h3 gS9gpSHIWm66pAAQAC+KqUCgpFIKpXQKqTLApzVAqX9KgwFUBIVao/9gmqkvGqMF4Kg1mqSJ WgKamqQzyqow6qpIyqkDgKRvmqNHKgCzuqtoWjvVqT0bph1fl1WUwYhRVXTrZDHKczIkMKzX GqW3Oqck8KsxKqvfCgBfGq46GgDFWqsicKSvWgDE2qsjcK4vqqPAeq7puq5L+qtf+oHRxEvz Q0wuCWLrQ4gRxE3jxz+q81xuWJ2PtQdvUSW+ZLBTphnvM58usK7smq5zKqexKq8+6q3oirFv Gqcwaq4xKgBH2rEv+qT4KrJvmqnsyqghKxXk9mgc4jl9t7AYpY1us3jgNGgDMg3u9mDYSgKL GqNyCqYr660zOqct+6pwaqzpurK2iqQe+7T/GzurLGujMAunW/ujJxunKQsA3iqj+rqJ7uEl ybJsOLIi8/RoaTGLU0aJloaLsmknpei2s4k3qWUiJqI7FQun3sqjL+qot7q0ZOuyHyuuF5uu PMqqM7qpLhqrrPquLTu0oipChHaYQ4gOsIFsUSl2eik1t4isnDG0LpqjkGuo7Dq5GPujb2qu jxulNeqoIwCpJ5urLSuvPPq6IFu7ofqkqau4W6tl5ogiv8I0WfMhQgM2Z3UwLFgtHTM0qTKT gLIK16Is7MIUCDaPL3CoR/qjcJqtAWC68moCh1oCs6u6wAqj7Uq74iqsi3u5NbRcELeSnGtn vrazNvUkWYEM7xWU/xjLqY+Kuq3qsu26vi07q2B6vulLAra7uEM7rOQrpp/6qMCLwOz6q7DV lJtyDxvjcvfhkQ9CZyE5OD4ZMEP4XdpUKjuhJIL5HR05ZcbbcYl0vk1bwLP7vUSbuPFqAg2c snEaxCSLqZoKv0sqv1GyDjyjetpIMhOCUHQ5JftWEBKKAhPcpD0sAjvKqkEcp0t6q+Dbqg3s u5cawAGsw5FLxp8KxF0MsxtMlmtzL2fhNMs7wiJZOpFqt/kLCI5DIkehn3dyKzC1edlANn+r uj+Kr7i7sWGruImryLwqr476q09axD16sbdqxBWcUD8STYvDxOQoMG12aYlDZQlyZkBbE/+Z NgKmq7Riy7uzOr5veq8vW8sETLnua8FlbMBm3Mivqsa6/MqVXKga7I8QZLbEJGqWVS6Ss3hv 8TfqAjd5I7cGw5uR0sf20irQTLeDjCKauYEWe7gWO7K8ur4nMM5kurHqS7UgC6yaHMwRmG/Z IyeErCF7AIbqh4VF6nrNpF2r3M7ASrvjvKTn+rony77vi8sl8MBfDMGYPM61mqd0Os6JXKv2 ZyZPOEHjNxbrU0O5tF0iNx2iXJ/jdxO0FZEhM5gk3YOgnD9WKgBdjL5BDNO0C9NeTKe2KsRR 67423agl0MXEmqk+LbZLaqH3JwMeagJdPAACrKNBrNRe3K1MrcX/RDzUIzDVOU24Q82oNT3T dIrVRE0CPS2rdIp4LZoGlAqiZ416lMp7a/3WcB3Xcj3XdF3Xdj0FLeynLRB1qanXd30ReV0Y WiovpvrXgA0Vfg1bg23Mhu0PfRgr33eghiVLM0ud56Ea7eGvgng3EIsbktrY8NBOfjZXyRnY mDi3S/luSqyMrC23K1nYoO0KVQWeSmPa32h5P2OacFMoA1kqfR3bC3GC7aJbIcw31fVAGtNV gIyPP3mEsA3cnRBrEFTbiH3Hm5sSjTEaMCPF24iU0P0P0q1aTuY8z9xm7oJDjAaLCUYjru0l HPrdsBDe0DY+5P1rRWpCGg2egAKxKymg//D93wAe4AI+4ARe4AZ+4Aie4Aq+4Aze4A7+4BAe 4RI+4RRe4RZ+4Rie4Rq+4Rze4R7+4SAe4iI+4iRe4sT3ABGQ4iluACKQACie4g+QACrg4ioe 4yNgACqu4gmQ4xHwACkQASyOAgzA4wAw5DUe5EZe4wDw4jpeAgzAACXwAD4+AjSe4g0Q5EKe 4wyA5QBgAA1Q4zI+AjZOAhEA5QDw5T2O5BFA5lCO42EOADue41MuAjhOAjhO5GV+42je42++ 5H0OAHl+AlWe5jceAW++41g+6GN+5zm+5Dz+5y3O5GO+5HPe5YZO5ZL+5lLe4iluAg9g5iKw 6Y6e4wnA6FZO5/88DuR2ruqF/uZeDuZUHgEIMAKdLgJDzuK3zgIJwAAo/uS4DuO8nuKgXgJx /uloPuU4/ulPvuVP3uMMAOmcXulOXubLXuTUbuS/vuzPTunazuXW3ueiPupP/uLQzujjvuKc 7uxGPucozuV5vuMPgOa2vua03uaXTufN/ungfu+2PuTKDuhmXuzN3uNizuoiEOhRLuzBfu9u Hutq7uwvbub5/uTcvuzebu3OjuZmHu6WHubrzgAaH+o+7u8n8OkkIOpS3u3Jfu72ruy+vuoP gOUND+fAvu6obuYIgO6OPu8Xn+WxHvM3juKQDu8y3+sdbwIzjwIv3vPWPu0O3/RRLu3/087v ok7ysW7wBT/s8G7p/O7oDRDqOg/wNM/iBuDx9H7w9v7nSY/qtX7yc57nd77vXz/qWI7wI2D1 bE/2/I7oNA/0dC70Ys7uUk8CRB/0qs7xDV/4f3/4Uk7wJT/sKC/tSU/wa18Cdz7nDR/3Jx8B c+/4Rh7mnM/zLjDkBe/td+7pWG/rqA7plU/4ZW73JED6sX/27Q71bq8CSR7km57sJrDjcx/r w97ivw7ptf/ifv/ujn/3Zy/2lV/5Qz7kfx7ueQ79qM/ixh/ksA/oUo/jX5/0fF/7q077gq8C YU/nYY74l17+XX7+KQ7toQ75U87xR0/z3d/1lq/kR0/9Cc/i/18OAgAQNdEDIFEiMpEhwrHc wqQslm9s37ARAYOv36oHeESOrl4rmGwGTwAo8IR0FmGt3/JxSmV3Uu3SiOwlVMdHWhphsIC6 abIGJ8rwPtNoLPLaKaGpebWJvOWp3QDqAaS98Mjk/I1dBYX9NBhRxhBlbippblpG/TmpcDkN nZaJEJXcEdbJpK2kIbw+RSDEzYHSuSLebMkIxwn9PDAsM6yGxYAB/MANvzHTIbGRMTOseHH7 Aqc8GADW9gDGEJv5wUQDtpwYpynSBDYGhxHfxqSPwPmDRuhEvH+JnnFq9GgakzL+vjHzxXCU H0/G0AGhhk4Zs3QQlxlIllFHMnCdZP8lwBPQnZppNMCc6fWLTI12pm4AiZFgGZKQik4iNHWq 4QwXfGjKWFlURBtGF4O1O2emFRle6WBd5BJnR6xn+Fj58YeoZzWrUrBqDKaxZzJpPx/1wQjj oU0xoALiOcoOSdAjaT22I9IiC76DpgYrCUeHV590JPSum2kPQIlnhoqmdXuisNugJZdVrrY0 jcbJc+sipXNUjqSfUCUqc6Q3WJ2HGf0yXbKOYWGFJDq2Egvn8p7alW4nLZOMr1tRdF6E1qmX LqjoMODiVWM99wsvXBgn/StlpUrlrg27BWJrdvq56nEgd5QZ1GQu5KSVoOpemyPmnDkn1s8s qW1F2S4F9oP/GoJKSJGCMOWwFwd/CSBBTTY6NMGYPxDCoR6EL7QRkn/nNTLbJ5wcYqEJGAKh 4Rgc3uAgNU04995l9g2R3xzUbcJFAzmylt0KPgLZxWashZcginsMeRSA+RRXxIXHgNeEDvSA R9ZMwPhAyopGQHhKEakI0dkNE113nmlcBkgFH14+s6Y/9DihoJsXeflTdrEEsVadtF1ipmxx OjSGMXlmsecgrGhEZithRuGLbVic6eV9SvSpB6RV6JCOg+HEdppQl+hBWnqqACVdoqyEMU5x AvZ1w05nRjSTAdzMwE0zLCh2q2K76pTZrK7suhM3tugazrA+WFbrL7jSuoxlXo0p/y0t1mph 0hQkzecrU1l00wkz0+YRq7FwbOesuCDJmsW57PZwK7ZMHeutD+Pq5C6w14WRQBHv7rqvvywk O4OyEuE7TL/9zrelww9DHLHEE1NcscUXY5wxxOFq3LHHH4McMpghkVyyySejnLLKK7Pcsssv wxyzzDPTXLPNN+Ocs84789yzzb8oELTQQxNdtNFHI5200ksz3bTTT0MdtdRTU1211VdjnbXW W0+tmMhfgx222GOTXbbZZ6Odttprs92222/DHbfcc9Ndt91345233nvz3bfffwMeuOCDE164 4YcjnrjiizPeuOOPQx655JNTXrnll2Oeueabc96555+DHv+66KOTXrrpp6Oeuuqrs96666/D Hrvss9Neu+2345677rvz3rvvvwMfvPDDE1885BBIkLwDEkOwwA0OJJ88BGc3b7z1k1d/gATO Q1y9DA4sLwIE05ft/fXnN+69+Q6vLwL4MCxAPtnto1+/4dUvIMEBMECvPP/JL0B70vte+AAA gfAdAHkAhMEB+rc9/Ykgf9F7H/iQtz8Hjs95Eiyg/Tr4NwVKQH4OgMD+Erg87R0ggeLjXgwc GEIYjE8ECeReDAEgwf3lj4YSWB70yDfCEiLPedsz4P48aES+qW96+Sui+PY3RBiykH8OiF8L 5QcA7QFghDFYIgAgCEMeki9/MZj/oQGteMQz4s1825Ng9BaYQBKu8HnLO+D/2pg8E8pAf1jc Ig/DR8UYZC+IaByk3dS4ADFuApH0ex8K3cdB/lmRi14UXx9lOEkyWjKKhNxk29QnAfHBMYuf pKIiNZlFP5JPewiMoSojeEdR6rCS7oNjAreXwBQO8Y+c3CXaQBhKUUqviAqkoSnf50gZgrCA tVSeF9m4Q1m6L3oZBGb46MfLa1pujx8zIza76bgcIvOR3hzn6uI3QXKiM53qXCc72+nOd8Iz nvLkZANF1jztmTJiiBzjEx2my3nO04Ihu2c/KQY9TR4UYv8EKDxVKc6MWXNiIzTjAh+2UIa6 E3zaNOAI/wdYxxB6j42hrB4EH+g/ZE6QmwecIvzit8oJQvCAII1eIyPITYxes5HmQx756JhF Wi4QnD+NY0mHSMZW2vCFMjigLklIxzdaMqY7tOkxRTBJnHbTmNqsoQ2VeMkhFpSlJHUiC9+3 vouCFYfT06IWGRjTAv5xjxfFKi/t+ETzkdKMBLXr9MbaRSaalYlX5OYQzarBtWoypixsqvMi SldC/vOPePUqP4UoWCj+NbPHPKsZG4nCTyZ1qG7d32ThR0LQPhabVzVgYxfbU6AWNpRc9Osk 35c/PyrVrTD0KRa1lRteVhYGIcxnagd5USoGF5gg5Z5IiGOHFr5UeWbcJxevUX7UZe5QsaZt IWqL+9iCBs6Y3p0nUqgdXfqOl7zJvCzg5prJQ383vvKdL33ra9/745h1nt0vf/vr3/8COMAC zm8IAAA7 --------------AttPart_43396289==.OLA-- From capwap-admin@frascone.com Fri Oct 28 20:14:13 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVeMP-0002ij-Mh for capwap-archive@megatron.ietf.org; Fri, 28 Oct 2005 20:14:13 -0400 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28532 for ; Fri, 28 Oct 2005 20:13:55 -0400 (EDT) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 50404204E7; Fri, 28 Oct 2005 20:14:04 -0400 (EDT) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from mgw-ext01.nokia.com (mgw-ext01.nokia.com [131.228.20.93]) by mail.frascone.com (Postfix) with ESMTP id 5EE9E204E3 for ; Fri, 28 Oct 2005 20:13:07 -0400 (EDT) Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext01.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j9T0D061006106; Sat, 29 Oct 2005 03:13:03 +0300 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 29 Oct 2005 03:13:02 +0300 Received: from mvebe101.NOE.Nokia.com ([172.19.64.23]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 28 Oct 2005 19:13:00 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7233.31 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message-ID: <893AE265F4ADF94AB7FB26D31A788E410131DE9C@mvebe101.NOE.Nokia.com> Thread-Topic: Poll for LWAPP as the basis for the CAPWAP protocol Thread-Index: AcXcHYQVzc3GGtl2TDecup3AXZQLvg== From: To: Cc: , , , X-OriginalArrivalTime: 29 Oct 2005 00:13:00.0313 (UTC) FILETIME=[85939090:01C5DC1D] Subject: [Capwap] Poll for LWAPP as the basis for the CAPWAP protocol 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-Unsubscribe: , List-Id: A list for CAPWAP technical discussions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 28 Oct 2005 17:12:57 -0700 Content-Transfer-Encoding: quoted-printable After many weeks of discussion on the CAPWAP evaluation draft completed by the eval team its time to poll the WG on the protocol consensus. The evaluation team concluded that LWAPP is the most complete proposal and should be used as the basis for the CAPWAP protocol going forward. Please respond to this email indicating support for LWAPP as the new CAPWAP protocol:=20 YES: LWAPP should be the basis of the CAPWAP protocol or, NO: LWAPP should not be the basis of the CAPWAP protocol. The evaluation has also raised a number of recommendation that should be address by the WG on top of the protocol recommendation. These will be addressed by the WG and applied to the protocol that achieves WG consensus. In order to progress the work, we are separating the Evaluation's team proposal so that we agree first on the protcol, and then evaluate each recommendation separately. =20 Please submit your response to this protocol poll by Friday, November 4th. We will discuss the results of the poll at the face to face CAPWAP WG meeting on Monday, November 7th. =20 Best Regards, Dorothy and Mani =20 _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Sun Oct 30 20:44:23 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWOil-0003js-JC for capwap-archive@megatron.ietf.org; Sun, 30 Oct 2005 20:44:23 -0500 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA01421 for ; Sun, 30 Oct 2005 20:44:02 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id EF7682026F; Sun, 30 Oct 2005 20:44:04 -0500 (EST) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from tiere.net.avaya.com (tiere.net.avaya.com [198.152.12.100]) by mail.frascone.com (Postfix) with ESMTP id EA3961FD61 for ; Sun, 30 Oct 2005 20:43:11 -0500 (EST) 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 j9V1eM4l015259 for ; Sun, 30 Oct 2005 20:40:22 -0500 (EST) 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 j9V1eL4l015225 for ; Sun, 30 Oct 2005 20:40:21 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5DDBC.71F3D58A" Message-ID: Thread-Topic: Tentative Agenda Thread-Index: AcXdvHDrH1eLw1OvR7qn/09a/TT9LQ== From: "Mani, Mahalingam (Mahalingam)" To: Subject: [Capwap] Tentative Agenda 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-Unsubscribe: , List-Id: A list for CAPWAP technical discussions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sun, 30 Oct 2005 18:43:08 -0700 This is a multi-part message in MIME format. ------_=_NextPart_001_01C5DDBC.71F3D58A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable CAPWAP session for IETF64 @Vancouver is on Monday 7th Nov 2005 at 1pm local time. This is a two hour session. =20 The tentative agenda has been posted: http://www3.ietf.org/proceedings/05nov/agenda/capwap.htm This will be updated soon with the final one. =20 The issues list referred to in the agenda is being posted http://ietf.webdav.org/capwap/issues_list.htm =20 The list is being constructed and any text you wish to add to ones there now; or new issues you wish to summarize send them to me and I will have them added. The template issue-entry is the last table of the link http://ietf.webdav.org/capwap/issues_list.htm mentioned above. =20 Regards, -mani =3D=3D=3D=3D=3D=3D =20 ------_=_NextPart_001_01C5DDBC.71F3D58A Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

CAPWAP session for IETF64 @Vancouver is on Monday = 7th Nov 2005 at 1pm local time. This is a two hour = session.

 

The tentative agenda has been posted: http://= www3.ietf.org/proceedings/05nov/agenda/capwap.htm

This will be updated soon with the final = one.

 

The issues list referred to in the agenda is being = posted http://ietf.webdav= .org/capwap/issues_list.htm

 

The list is being constructed and any text you wish = to add to ones there now; or new issues you wish to summarize send them to = me

and I will have them added. The template issue-entry = is the last table of the link http://ietf.webdav= .org/capwap/issues_list.htm mentioned above.

 

Regards,

-mani

=3D=3D=3D=3D=3D=3D

 

------_=_NextPart_001_01C5DDBC.71F3D58A-- _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Mon Oct 31 00:48:10 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWSWf-0003Oe-Ui for capwap-archive@megatron.ietf.org; Mon, 31 Oct 2005 00:48:10 -0500 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA12586 for ; Mon, 31 Oct 2005 00:47:51 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E6BDD20266; Mon, 31 Oct 2005 00:48:04 -0500 (EST) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from smtp1.mei.co.jp (smtp.mei.co.jp [133.183.129.25]) by mail.frascone.com (Postfix) with ESMTP id E9BFE1FDEF for ; Mon, 31 Oct 2005 00:47:54 -0500 (EST) Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp1.mei.co.jp (8.12.10/3.7W/kings) with ESMTP id j9V5lpdE021477 for ; Mon, 31 Oct 2005 14:47:51 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx2) with ESMTP id j9V5lqS29402 for ; Mon, 31 Oct 2005 14:47:52 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/bluejays) with ESMTP id j9V5lpj00929 for ; Mon, 31 Oct 2005 14:47:51 +0900 (JST) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: RE: [Capwap] Poll for LWAPP as the basis for the CAPWAP protocol Message-ID: <5F09D220B62F79418461A978CA0921BD75AFD3@pslexc01.psl.local> Thread-topic: [Capwap] Poll for LWAPP as the basis for the CAPWAP protocol Thread-Index: AcXcHYQVzc3GGtl2TDecup3AXZQLvgBvHsog From: "Saravanan Govindan" To: 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-Unsubscribe: , List-Id: A list for CAPWAP technical discussions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 31 Oct 2005 13:45:02 +0800 Content-Transfer-Encoding: quoted-printable I support a base CAPWAP protocol provided it is flexible enough to be further developed. I think it is important to make sure the base protocol is sufficient extensible to cover the recommendations being proposed.=20 Saravanan > -----Original Message----- > From: capwap-admin@frascone.com=20 > [mailto:capwap-admin@frascone.com] On Behalf Of=20 > Dorothy.Gellert@nokia.com > Sent: Saturday, October 29, 2005 8:13 AM > To: capwap@frascone.com > Cc: bwijnen@lucent.com; mmani@avaya.com;=20 > david.kessens@nokia.com; Dorothy.Gellert@nokia.com > Subject: [Capwap] Poll for LWAPP as the basis for the CAPWAP protocol >=20 >=20 > After many weeks of discussion on the CAPWAP evaluation draft=20 > completed by the eval team its time to poll the WG on the=20 > protocol consensus. The evaluation team concluded that LWAPP=20 > is the most complete proposal and should be used as the basis=20 > for the CAPWAP protocol going forward. >=20 > Please respond to this email indicating support for LWAPP as=20 > the new CAPWAP protocol:=20 > YES: LWAPP should be the basis of the CAPWAP protocol or, > NO: LWAPP should not be the basis of the CAPWAP protocol. >=20 > The evaluation has also raised a number of recommendation=20 > that should be > address by the WG on top of the protocol recommendation. =20 > These will be > addressed by the WG and applied to the protocol that achieves=20 > WG consensus. In order to progress the work, we are=20 > separating the Evaluation's team proposal so that we agree=20 > first on the protcol, and then evaluate each recommendation=20 > separately. =20 >=20 > Please submit your response to this protocol poll by Friday, November > 4th. We will discuss the results of the poll at the face to face > CAPWAP WG meeting on Monday, November 7th. =20 >=20 > Best Regards, > Dorothy and Mani >=20 >=20 >=20 > =20 > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap >=20 _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Mon Oct 31 02:52:40 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWUT9-0005Wh-PK for capwap-archive@megatron.ietf.org; Mon, 31 Oct 2005 02:52:40 -0500 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18192 for ; Mon, 31 Oct 2005 02:52:19 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 6958320391; Mon, 31 Oct 2005 02:34:04 -0500 (EST) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from mgw-ext03.nokia.com (mgw-ext03.nokia.com [131.228.20.95]) by mail.frascone.com (Postfix) with ESMTP id 008DB2034D for ; Mon, 31 Oct 2005 02:33:03 -0500 (EST) Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext03.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j9V7UYHV022140; Mon, 31 Oct 2005 09:30:34 +0200 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 31 Oct 2005 09:33:00 +0200 Received: from mvebe101.NOE.Nokia.com ([172.19.64.23]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 31 Oct 2005 01:32:58 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5.7233.31 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Capwap] Poll for LWAPP as the basis for the CAPWAP protocol Message-ID: <893AE265F4ADF94AB7FB26D31A788E410131DF59@mvebe101.NOE.Nokia.com> Thread-Topic: [Capwap] Poll for LWAPP as the basis for the CAPWAP protocol Thread-Index: AcXcHYQVzc3GGtl2TDecup3AXZQLvgBvHsogAAReCsA= From: To: , X-OriginalArrivalTime: 31 Oct 2005 07:32:58.0100 (UTC) FILETIME=[50B5B340:01C5DDED] 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-Unsubscribe: , List-Id: A list for CAPWAP technical discussions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sun, 30 Oct 2005 23:32:56 -0800 Content-Transfer-Encoding: quoted-printable Hi Saravanan- We plan to discuss and come to consensus wihtin the WG on each of the recommendations separately, once the protocol proposed by the evaluation team is agreed upon by the WG. =20 The idea to break up the evaluation team's recommendation into 1) protocol and 2) recommendations is solely meant to make progress on WG consensus. If we can agree upon a protocol first, our hope is that the WG can evaluate the recommendations easier once there is a protocol in place. If you (and others in the WG) are satisfied with this approach, please indicate your position on the protocol portion of the evaluation by YES or NO for LWAPP. =20 Best Regards, Dorothy -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of ext Saravanan Govindan Sent: Sunday, October 30, 2005 9:45 PM To: capwap@frascone.com Subject: RE: [Capwap] Poll for LWAPP as the basis for the CAPWAP protocol I support a base CAPWAP protocol provided it is flexible enough to be further developed. I think it is important to make sure the base protocol is sufficient extensible to cover the recommendations being proposed.=20 Saravanan > -----Original Message----- > From: capwap-admin@frascone.com > [mailto:capwap-admin@frascone.com] On Behalf Of=20 > Dorothy.Gellert@nokia.com > Sent: Saturday, October 29, 2005 8:13 AM > To: capwap@frascone.com > Cc: bwijnen@lucent.com; mmani@avaya.com; david.kessens@nokia.com;=20 > Dorothy.Gellert@nokia.com > Subject: [Capwap] Poll for LWAPP as the basis for the CAPWAP protocol >=20 >=20 > After many weeks of discussion on the CAPWAP evaluation draft=20 > completed by the eval team its time to poll the WG on the protocol=20 > consensus. The evaluation team concluded that LWAPP is the most=20 > complete proposal and should be used as the basis for the CAPWAP=20 > protocol going forward. >=20 > Please respond to this email indicating support for LWAPP as the new=20 > CAPWAP protocol: > YES: LWAPP should be the basis of the CAPWAP protocol or, > NO: LWAPP should not be the basis of the CAPWAP protocol. >=20 > The evaluation has also raised a number of recommendation that should=20 > be > address by the WG on top of the protocol recommendation. =20 > These will be > addressed by the WG and applied to the protocol that achieves WG=20 > consensus. In order to progress the work, we are separating the=20 > Evaluation's team proposal so that we agree first on the protcol, and=20 > then evaluate each recommendation separately. >=20 > Please submit your response to this protocol poll by Friday, November > 4th. We will discuss the results of the poll at the face to face > CAPWAP WG meeting on Monday, November 7th. =20 >=20 > Best Regards, > Dorothy and Mani >=20 >=20 >=20 > =20 > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap >=20 _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Mon Oct 31 10:04:18 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWbCn-0001hC-U6 for capwap-archive@megatron.ietf.org; Mon, 31 Oct 2005 10:04:18 -0500 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12614 for ; Mon, 31 Oct 2005 10:03:52 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 7FC9E2036A; Mon, 31 Oct 2005 10:04:04 -0500 (EST) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from web36105.mail.mud.yahoo.com (web36105.mail.mud.yahoo.com [66.163.179.219]) by mail.frascone.com (Postfix) with SMTP id 50BA51FDEF for ; Mon, 31 Oct 2005 10:03:22 -0500 (EST) Received: (qmail 64662 invoked by uid 60001); 31 Oct 2005 15:03:18 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=G44xNN1jYKrMfxI1gJZw31x0MnyXg+X7hpD8w+3/bUONRP4+XwhXAhDr+8PAo4zjLbdOUVyzzt7FEq25Fa2iO1yHattOPXP6Esjp/oTMY5oAPjNFuNrSKqbqXIhnEezPQmJA5I7cQ5/Jos9EYOZcKhZQbQRE5CyHoXgeNvncb3c= ; Message-ID: <20051031150317.64660.qmail@web36105.mail.mud.yahoo.com> Received: from [63.193.244.146] by web36105.mail.mud.yahoo.com via HTTP; Mon, 31 Oct 2005 07:03:17 PST From: Fatima Peter To: capwap@frascone.com In-Reply-To: <20051029160002.3150.66566.Mailman@xavier> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-529454730-1130770997=:64394" Content-Transfer-Encoding: 8bit Subject: [Capwap] Re: Capwap digest, Vol 1 #599 - 1 msg 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-Unsubscribe: , List-Id: A list for CAPWAP technical discussions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 31 Oct 2005 07:03:17 -0800 (PST) --0-529454730-1130770997=:64394 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit YES: LWAPP should be the basis of the CAPWAP protocol Fatima U4EA Technologies Fremont, CA capwap-request@frascone.com wrote: Send Capwap mailing list submissions to capwap@frascone.com To subscribe or unsubscribe via the World Wide Web, visit http://mail.frascone.com/mailman/listinfo/capwap or, via email, send a message with subject or body 'help' to capwap-request@frascone.com You can reach the person managing the list at capwap-admin@frascone.com When replying, please edit your Subject line so it is more specific than "Re: Contents of Capwap digest..." Today's Topics: 1. Poll for LWAPP as the basis for the CAPWAP protocol (Dorothy.Gellert@nokia.com) --__--__-- Message: 1 Date: Fri, 28 Oct 2005 17:12:57 -0700 From: To: Cc: , , , Subject: [Capwap] Poll for LWAPP as the basis for the CAPWAP protocol After many weeks of discussion on the CAPWAP evaluation draft completed by the eval team its time to poll the WG on the protocol consensus. The evaluation team concluded that LWAPP is the most complete proposal and should be used as the basis for the CAPWAP protocol going forward. Please respond to this email indicating support for LWAPP as the new CAPWAP protocol:=20 YES: LWAPP should be the basis of the CAPWAP protocol or, NO: LWAPP should not be the basis of the CAPWAP protocol. The evaluation has also raised a number of recommendation that should be address by the WG on top of the protocol recommendation. These will be addressed by the WG and applied to the protocol that achieves WG consensus. In order to progress the work, we are separating the Evaluation's team proposal so that we agree first on the protcol, and then evaluate each recommendation separately. =20 Please submit your response to this protocol poll by Friday, November 4th. We will discuss the results of the poll at the face to face CAPWAP WG meeting on Monday, November 7th. =20 Best Regards, Dorothy and Mani =20 --__--__-- _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap End of Capwap Digest --------------------------------- Yahoo! FareChase - Search multiple travel sites in one click. --0-529454730-1130770997=:64394 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit
YES:  LWAPP should be the basis of the CAPWAP protocol
 
Fatima
U4EA Technologies
Fremont, CA

capwap-request@frascone.com wrote:
Send Capwap mailing list submissions to
capwap@frascone.com

To subscribe or unsubscribe via the World Wide Web, visit
http://mail.frascone.com/mailman/listinfo/capwap
or, via email, send a message with subject or body 'help' to
capwap-request@frascone.com

You can reach the person managing the list at
capwap-admin@frascone.com

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Capwap digest..."


Today's Topics:

1. Poll for LWAPP as the basis for the CAPWAP protocol (Dorothy.Gellert@nokia.com)

--__--__--

Message: 1
Date: Fri, 28 Oct 2005 17:12:57 -0700
From:
To:
Cc: , ,
,
Subject: [Capwap] Poll for LWAPP as the basis for the CAPWAP protocol


After many weeks of discussion on the CAPWAP evaluation draft completed
by the eval team its time to poll the WG on the protocol consensus. The
evaluation team concluded that LWAPP is the most complete proposal and
should be used as the basis for the CAPWAP protocol going forward.

Please respond to this email indicating support for LWAPP as the new
CAPWAP protocol:=20
YES: LWAPP should be the basis of the CAPWAP protocol or,
NO: LWAPP should not be the basis of the CAPWAP protocol.

The evaluation has also raised a number of recommendation that should be
address by the WG on top of the protocol recommendation. These will be
addressed by the WG and applied to the protocol that achieves WG
consensus. In order to progress the work, we are separating the
Evaluation's team proposal so that we agree first on the protcol, and
then evaluate each recommendation separately. =20

Please submit your response to this protocol poll by Friday, November
4th. We will discuss the results of the poll at the face to face
CAPWAP WG meeting on Monday, November 7th. =20

Best Regards,
Dorothy and Mani



=20


--__--__--

_______________________________________________
Capwap mailing list
Capwap@frascone.com
http://mail.frascone.com/mailman/listinfo/capwap


End of Capwap Digest

Yahoo! FareChase - Search multiple travel sites in one click. --0-529454730-1130770997=:64394-- _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Mon Oct 31 10:13:10 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWbLR-0003g2-Uk for capwap-archive@megatron.ietf.org; Mon, 31 Oct 2005 10:13:10 -0500 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13479 for ; Mon, 31 Oct 2005 10:12:49 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 1EEFA203E5; Mon, 31 Oct 2005 10:13:05 -0500 (EST) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from flyer.cs.umd.edu (flyer.cs.umd.edu [128.8.128.178]) by mail.frascone.com (Postfix) with ESMTP id 984281FDEF for ; Mon, 31 Oct 2005 10:12:34 -0500 (EST) Received: from ismene (ismene.cs.umd.edu [128.8.126.62]) by flyer.cs.umd.edu (8.12.11/8.12.5) with ESMTP id j9VDjKfU015327 for ; Mon, 31 Oct 2005 08:45:20 -0500 From: "T. Charles Clancy" X-X-Sender: clancy@ismene To: capwap@frascone.com Subject: Re: [Capwap] Poll for LWAPP as the basis for the CAPWAP protocol In-Reply-To: <893AE265F4ADF94AB7FB26D31A788E410131DE9C@mvebe101.NOE.Nokia.com> Message-ID: References: <893AE265F4ADF94AB7FB26D31A788E410131DE9C@mvebe101.NOE.Nokia.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed 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-Unsubscribe: , List-Id: A list for CAPWAP technical discussions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 31 Oct 2005 08:44:35 -0500 (EST) YES [ t. charles clancy ]--[ tcc@umd.edu ]--[ www.cs.umd.edu/~clancy ] [ computer science ]-----[ university of maryland | college park ] On Fri, 28 Oct 2005 Dorothy.Gellert@nokia.com wrote: > > After many weeks of discussion on the CAPWAP evaluation draft completed > by the eval team its time to poll the WG on the protocol consensus. The > evaluation team concluded that LWAPP is the most complete proposal and > should be used as the basis for the CAPWAP protocol going forward. > > Please respond to this email indicating support for LWAPP as the new > CAPWAP protocol: > YES: LWAPP should be the basis of the CAPWAP protocol or, > NO: LWAPP should not be the basis of the CAPWAP protocol. > > The evaluation has also raised a number of recommendation that should be > address by the WG on top of the protocol recommendation. These will be > addressed by the WG and applied to the protocol that achieves WG > consensus. In order to progress the work, we are separating the > Evaluation's team proposal so that we agree first on the protcol, and > then evaluate each recommendation separately. > > Please submit your response to this protocol poll by Friday, November > 4th. We will discuss the results of the poll at the face to face > CAPWAP WG meeting on Monday, November 7th. > > Best Regards, > Dorothy and Mani > > > > > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap > _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Mon Oct 31 10:13:18 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWbLa-0003hk-6n for capwap-archive@megatron.ietf.org; Mon, 31 Oct 2005 10:13:18 -0500 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13495 for ; Mon, 31 Oct 2005 10:12:58 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 0C45320427; Mon, 31 Oct 2005 10:13:09 -0500 (EST) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from flyer.cs.umd.edu (flyer.cs.umd.edu [128.8.128.178]) by mail.frascone.com (Postfix) with ESMTP id 181082036A for ; Mon, 31 Oct 2005 10:12:40 -0500 (EST) Received: from ismene (ismene.cs.umd.edu [128.8.126.62]) by flyer.cs.umd.edu (8.12.11/8.12.5) with ESMTP id j9VDnLEN015553; Mon, 31 Oct 2005 08:49:21 -0500 From: "T. Charles Clancy" X-X-Sender: clancy@ismene To: "Mani, Mahalingam (Mahalingam)" Cc: capwap@frascone.com Subject: Re: [Capwap] Tentative Agenda In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed 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-Unsubscribe: , List-Id: A list for CAPWAP technical discussions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 31 Oct 2005 08:48:35 -0500 (EST) I'm curious what the following agenda item entails: 6. Tentative: Security analysis for CAPWAP (10 min) [ t. charles clancy ]--[ tcc@umd.edu ]--[ www.cs.umd.edu/~clancy ] [ computer science ]-----[ university of maryland | college park ] On Sun, 30 Oct 2005, Mani, Mahalingam (Mahalingam) wrote: > CAPWAP session for IETF64 @Vancouver is on Monday 7th Nov 2005 at 1pm > local time. This is a two hour session. > > > > The tentative agenda has been posted: > http://www3.ietf.org/proceedings/05nov/agenda/capwap.htm > > This will be updated soon with the final one. > > > > The issues list referred to in the agenda is being posted > http://ietf.webdav.org/capwap/issues_list.htm > > > > The list is being constructed and any text you wish to add to ones there > now; or new issues you wish to summarize send them to me > > and I will have them added. The template issue-entry is the last table > of the link http://ietf.webdav.org/capwap/issues_list.htm mentioned > above. > > > > Regards, > > -mani > > ====== > > > > _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Mon Oct 31 10:15:10 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWbNN-00049l-RS for capwap-archive@megatron.ietf.org; Mon, 31 Oct 2005 10:15:10 -0500 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13577 for ; Mon, 31 Oct 2005 10:14:49 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 839A5203FB; Mon, 31 Oct 2005 10:15:04 -0500 (EST) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by mail.frascone.com (Postfix) with ESMTP id EDFE01FDEF for ; Mon, 31 Oct 2005 10:14:10 -0500 (EST) Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-3.cisco.com with ESMTP; 31 Oct 2005 07:14:09 -0800 X-IronPort-AV: i="3.97,270,1125903600"; d="scan'208"; a="358904226:sNHT26770544" Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j9VFE09A004781; Mon, 31 Oct 2005 07:14:07 -0800 (PST) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 31 Oct 2005 07:14:02 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Capwap] Poll for LWAPP as the basis for the CAPWAP protocol Message-ID: <4FF84B0BC277FF45AA27FE969DD956A2DC3FD5@xmb-sjc-235.amer.cisco.com> Thread-Topic: [Capwap] Poll for LWAPP as the basis for the CAPWAP protocol Thread-Index: AcXcHYQVzc3GGtl2TDecup3AXZQLvgCEB6Pw From: "Pat Calhoun (pacalhou)" To: , Cc: , , X-OriginalArrivalTime: 31 Oct 2005 15:14:02.0636 (UTC) FILETIME=[BA0EE4C0:01C5DE2D] 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-Unsubscribe: , List-Id: A list for CAPWAP technical discussions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 31 Oct 2005 07:14:01 -0800 Content-Transfer-Encoding: quoted-printable While I suspect this e-mail is not entirely necessary, I say YES to LWAPP. Pat Calhoun CTO, Wireless Networking Business Unit Cisco Systems > -----Original Message----- > From: capwap-admin@frascone.com=20 > [mailto:capwap-admin@frascone.com] On Behalf Of=20 > Dorothy.Gellert@nokia.com > Sent: Friday, October 28, 2005 5:13 PM > To: capwap@frascone.com > Cc: bwijnen@lucent.com; mmani@avaya.com;=20 > david.kessens@nokia.com; Dorothy.Gellert@nokia.com > Subject: [Capwap] Poll for LWAPP as the basis for the CAPWAP protocol >=20 >=20 > After many weeks of discussion on the CAPWAP evaluation draft=20 > completed by the eval team its time to poll the WG on the=20 > protocol consensus. The evaluation team concluded that LWAPP=20 > is the most complete proposal and should be used as the basis=20 > for the CAPWAP protocol going forward. >=20 > Please respond to this email indicating support for LWAPP as=20 > the new CAPWAP protocol:=20 > YES: LWAPP should be the basis of the CAPWAP protocol or, > NO: LWAPP should not be the basis of the CAPWAP protocol. >=20 > The evaluation has also raised a number of recommendation=20 > that should be > address by the WG on top of the protocol recommendation. =20 > These will be > addressed by the WG and applied to the protocol that achieves=20 > WG consensus. In order to progress the work, we are=20 > separating the Evaluation's team proposal so that we agree=20 > first on the protcol, and then evaluate each recommendation=20 > separately. =20 >=20 > Please submit your response to this protocol poll by Friday, November > 4th. We will discuss the results of the poll at the face to face > CAPWAP WG meeting on Monday, November 7th. =20 >=20 > Best Regards, > Dorothy and Mani >=20 >=20 >=20 > =20 > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap >=20 _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Mon Oct 31 15:04:12 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWft6-0001on-I8 for capwap-archive@megatron.ietf.org; Mon, 31 Oct 2005 15:04:12 -0500 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04141 for ; Mon, 31 Oct 2005 15:03:52 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 32B3420371; Mon, 31 Oct 2005 15:04:05 -0500 (EST) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from ind-iport-1.cisco.com (ind-iport-1.cisco.com [64.104.129.195]) by mail.frascone.com (Postfix) with ESMTP id 08B411FD6C for ; Mon, 31 Oct 2005 15:03:05 -0500 (EST) Received: from india-core-1.cisco.com ([64.104.129.221]) by ind-iport-1.cisco.com with ESMTP; 01 Nov 2005 00:48:54 -0800 Received: from xbh-blr-411.apac.cisco.com (xbh-blr-411.cisco.com [64.104.140.150]) by india-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j9VK2pYm025961; Mon, 31 Oct 2005 20:02:52 GMT Received: from xmb-blr-416.apac.cisco.com ([64.104.140.145]) by xbh-blr-411.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 1 Nov 2005 01:32:55 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Capwap] Poll for LWAPP as the basis for the CAPWAP protocol Message-ID: Thread-topic: [Capwap] Poll for LWAPP as the basis for the CAPWAP protocol Thread-index: AcXcHYQVzc3GGtl2TDecup3AXZQLvgBvHsogAAReCsAAGpxMMA== From: "Rohit Suri (rsuri)" To: , , X-OriginalArrivalTime: 31 Oct 2005 20:02:55.0989 (UTC) FILETIME=[158AAA50:01C5DE56] 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-Unsubscribe: , List-Id: A list for CAPWAP technical discussions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 1 Nov 2005 01:32:54 +0530 Content-Transfer-Encoding: quoted-printable YES: LWAPP should be the basis of the CAPWAP protocol=20 Regards Rohit -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Dorothy.Gellert@nokia.com Sent: Sunday, October 30, 2005 11:33 PM To: Saravanan.Govindan@sg.panasonic.com; capwap@frascone.com Subject: RE: [Capwap] Poll for LWAPP as the basis for the CAPWAP protocol Hi Saravanan- We plan to discuss and come to consensus wihtin the WG on each of the recommendations separately, once the protocol proposed by the evaluation team is agreed upon by the WG. =20 The idea to break up the evaluation team's recommendation into 1) protocol and 2) recommendations is solely meant to make progress on WG consensus. If we can agree upon a protocol first, our hope is that the WG can evaluate the recommendations easier once there is a protocol in place. If you (and others in the WG) are satisfied with this approach, please indicate your position on the protocol portion of the evaluation by YES or NO for LWAPP. =20 Best Regards, Dorothy -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of ext Saravanan Govindan Sent: Sunday, October 30, 2005 9:45 PM To: capwap@frascone.com Subject: RE: [Capwap] Poll for LWAPP as the basis for the CAPWAP protocol I support a base CAPWAP protocol provided it is flexible enough to be further developed. I think it is important to make sure the base protocol is sufficient extensible to cover the recommendations being proposed.=20 Saravanan > -----Original Message----- > From: capwap-admin@frascone.com > [mailto:capwap-admin@frascone.com] On Behalf Of=20 > Dorothy.Gellert@nokia.com > Sent: Saturday, October 29, 2005 8:13 AM > To: capwap@frascone.com > Cc: bwijnen@lucent.com; mmani@avaya.com; david.kessens@nokia.com;=20 > Dorothy.Gellert@nokia.com > Subject: [Capwap] Poll for LWAPP as the basis for the CAPWAP protocol >=20 >=20 > After many weeks of discussion on the CAPWAP evaluation draft=20 > completed by the eval team its time to poll the WG on the protocol=20 > consensus. The evaluation team concluded that LWAPP is the most=20 > complete proposal and should be used as the basis for the CAPWAP=20 > protocol going forward. >=20 > Please respond to this email indicating support for LWAPP as the new=20 > CAPWAP protocol: > YES: LWAPP should be the basis of the CAPWAP protocol or, > NO: LWAPP should not be the basis of the CAPWAP protocol. >=20 > The evaluation has also raised a number of recommendation that should=20 > be > address by the WG on top of the protocol recommendation. =20 > These will be > addressed by the WG and applied to the protocol that achieves WG=20 > consensus. In order to progress the work, we are separating the=20 > Evaluation's team proposal so that we agree first on the protcol, and=20 > then evaluate each recommendation separately. >=20 > Please submit your response to this protocol poll by Friday, November > 4th. We will discuss the results of the poll at the face to face > CAPWAP WG meeting on Monday, November 7th. =20 >=20 > Best Regards, > Dorothy and Mani >=20 >=20 >=20 > =20 > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap >=20 _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Mon Oct 31 15:14:11 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWg2l-0003tN-6a for capwap-archive@megatron.ietf.org; Mon, 31 Oct 2005 15:14:11 -0500 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04763 for ; Mon, 31 Oct 2005 15:13:50 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id CC46320389; Mon, 31 Oct 2005 15:14:04 -0500 (EST) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from psmtp.com (exprod8og8.obsmtp.com [64.18.3.209]) by mail.frascone.com (Postfix) with SMTP id 05AE11FD6C for ; Mon, 31 Oct 2005 15:13:23 -0500 (EST) Received: from source ([66.10.55.3]) by exprod8ob8.obsmtp.com ([64.18.7.12]) with SMTP; Mon, 31 Oct 2005 12:12:45 PST Received: from mail1.bluesocket.com ([192.168.168.32]) by mailfe.bluesocket.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 31 Oct 2005 15:12:55 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7232.53 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Capwap] Poll for LWAPP as the basis for the CAPWAP protocol Message-ID: <0240FDD68D6C1F4289F73D134A2536A16C12C5@mail1.bluesocket.com> Thread-Topic: [Capwap] Poll for LWAPP as the basis for the CAPWAP protocol Thread-Index: AcXcHYQVzc3GGtl2TDecup3AXZQLvgCOe8pw From: "Dick Eckard" To: , Cc: , , X-OriginalArrivalTime: 31 Oct 2005 20:12:55.0058 (UTC) FILETIME=[7A9D5720:01C5DE57] 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-Unsubscribe: , List-Id: A list for CAPWAP technical discussions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 31 Oct 2005 15:12:53 -0500 Content-Transfer-Encoding: quoted-printable YES: LWAPP should be the basis of the CAPWAP protocol Dick Eckard =20 Chief RF Scientist Bluesocket, Inc. 781-494-1075 dicke@bluesocket.com -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Dorothy.Gellert@nokia.com Sent: Friday, October 28, 2005 8:13 PM To: capwap@frascone.com Cc: bwijnen@lucent.com; mmani@avaya.com; david.kessens@nokia.com; Dorothy.Gellert@nokia.com Subject: [Capwap] Poll for LWAPP as the basis for the CAPWAP protocol After many weeks of discussion on the CAPWAP evaluation draft completed by the eval team its time to poll the WG on the protocol consensus. The evaluation team concluded that LWAPP is the most complete proposal and should be used as the basis for the CAPWAP protocol going forward. Please respond to this email indicating support for LWAPP as the new CAPWAP protocol:=20 YES: LWAPP should be the basis of the CAPWAP protocol or, NO: LWAPP should not be the basis of the CAPWAP protocol. The evaluation has also raised a number of recommendation that should be address by the WG on top of the protocol recommendation. These will be addressed by the WG and applied to the protocol that achieves WG consensus. In order to progress the work, we are separating the Evaluation's team proposal so that we agree first on the protcol, and then evaluate each recommendation separately. =20 Please submit your response to this protocol poll by Friday, November 4th. We will discuss the results of the poll at the face to face CAPWAP WG meeting on Monday, November 7th. =20 Best Regards, Dorothy and Mani =20 _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Mon Oct 31 17:13:13 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWhtt-00013p-69 for capwap-archive@megatron.ietf.org; Mon, 31 Oct 2005 17:13:13 -0500 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15513 for ; Mon, 31 Oct 2005 17:12:48 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 9A48E20371; Mon, 31 Oct 2005 17:13:04 -0500 (EST) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by mail.frascone.com (Postfix) with ESMTP id E96EC1FD63 for ; Mon, 31 Oct 2005 17:12:25 -0500 (EST) Message-ID: <148901c5de68$2b531f40$226115ac@dcml.docomolabsusa.com> From: "James Kempf" To: , Cc: , , , References: <893AE265F4ADF94AB7FB26D31A788E410131DE9C@mvebe101.NOE.Nokia.com> Subject: Re: [Capwap] Poll for LWAPP as the basis for the CAPWAP protocol MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit 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-Unsubscribe: , List-Id: A list for CAPWAP technical discussions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 31 Oct 2005 14:12:23 -0800 Content-Transfer-Encoding: 7bit Yes. jak ----- Original Message ----- From: To: Cc: ; ; ; Sent: Friday, October 28, 2005 4:12 PM Subject: [Capwap] Poll for LWAPP as the basis for the CAPWAP protocol After many weeks of discussion on the CAPWAP evaluation draft completed by the eval team its time to poll the WG on the protocol consensus. The evaluation team concluded that LWAPP is the most complete proposal and should be used as the basis for the CAPWAP protocol going forward. Please respond to this email indicating support for LWAPP as the new CAPWAP protocol: YES: LWAPP should be the basis of the CAPWAP protocol or, NO: LWAPP should not be the basis of the CAPWAP protocol. The evaluation has also raised a number of recommendation that should be address by the WG on top of the protocol recommendation. These will be addressed by the WG and applied to the protocol that achieves WG consensus. In order to progress the work, we are separating the Evaluation's team proposal so that we agree first on the protcol, and then evaluate each recommendation separately. Please submit your response to this protocol poll by Friday, November 4th. We will discuss the results of the poll at the face to face CAPWAP WG meeting on Monday, November 7th. Best Regards, Dorothy and Mani _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Mon Oct 31 17:19:10 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWhzi-0002So-2x for capwap-archive@megatron.ietf.org; Mon, 31 Oct 2005 17:19:10 -0500 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15826 for ; Mon, 31 Oct 2005 17:18:49 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 25621203FB; Mon, 31 Oct 2005 17:19:05 -0500 (EST) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by mail.frascone.com (Postfix) with ESMTP id BEBD320371 for ; Mon, 31 Oct 2005 17:18:13 -0500 (EST) Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-4.cisco.com with ESMTP; 31 Oct 2005 14:18:13 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j9VMHs8q024597; Mon, 31 Oct 2005 14:18:05 -0800 (PST) Received: from xmb-sjc-237.amer.cisco.com ([128.107.191.123]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 31 Oct 2005 14:17:54 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Capwap] Poll for LWAPP as the basis for the CAPWAP protocol Message-ID: <17B8C6DE4E228348B4939BDA6B05A9DCBDFBB6@xmb-sjc-237.amer.cisco.com> Thread-Topic: [Capwap] Poll for LWAPP as the basis for the CAPWAP protocol Thread-Index: AcXcHYQVzc3GGtl2TDecup3AXZQLvgCS1o+w From: "Bob O'Hara (boohara)" To: , Cc: , , X-OriginalArrivalTime: 31 Oct 2005 22:17:54.0759 (UTC) FILETIME=[F0C8E570:01C5DE68] 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-Unsubscribe: , List-Id: A list for CAPWAP technical discussions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 31 Oct 2005 14:17:56 -0800 Content-Transfer-Encoding: quoted-printable YES. LWAPP should be the basis of the CAPWAP protocol. -Bob Bob O'Hara Cisco Systems - WNBU Phone: +1 408 853 5513 Mobile: +1 408 218 4025 =20 -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Dorothy.Gellert@nokia.com Sent: Friday, October 28, 2005 5:13 PM To: capwap@frascone.com Cc: bwijnen@lucent.com; mmani@avaya.com; david.kessens@nokia.com; Dorothy.Gellert@nokia.com Subject: [Capwap] Poll for LWAPP as the basis for the CAPWAP protocol After many weeks of discussion on the CAPWAP evaluation draft completed by the eval team its time to poll the WG on the protocol consensus. The evaluation team concluded that LWAPP is the most complete proposal and should be used as the basis for the CAPWAP protocol going forward. Please respond to this email indicating support for LWAPP as the new CAPWAP protocol:=20 YES: LWAPP should be the basis of the CAPWAP protocol or, NO: LWAPP should not be the basis of the CAPWAP protocol. The evaluation has also raised a number of recommendation that should be address by the WG on top of the protocol recommendation. These will be addressed by the WG and applied to the protocol that achieves WG consensus. In order to progress the work, we are separating the Evaluation's team proposal so that we agree first on the protcol, and then evaluate each recommendation separately. =20 Please submit your response to this protocol poll by Friday, November 4th. We will discuss the results of the poll at the face to face CAPWAP WG meeting on Monday, November 7th. =20 Best Regards, Dorothy and Mani =20 _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Mon Oct 31 17:22:09 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWi2b-00033r-N1 for capwap-archive@megatron.ietf.org; Mon, 31 Oct 2005 17:22:09 -0500 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16024 for ; Mon, 31 Oct 2005 17:21:48 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 9430620426; Mon, 31 Oct 2005 17:22:04 -0500 (EST) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from SMTP6.centerbeam.com (smtp6.centerbeam.com [64.95.100.155]) by mail.frascone.com (Postfix) with ESMTP id 59B5820371 for ; Mon, 31 Oct 2005 17:21:03 -0500 (EST) Received: from CBA0E2K01.CBA0.centerbeam.com ([64.95.101.24]) by SMTP6.centerbeam.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 31 Oct 2005 14:22:16 -0800 Received: from CBA0E2K06.CBA0.centerbeam.com ([64.95.101.40]) by CBA0E2K01.CBA0.centerbeam.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 31 Oct 2005 14:20:24 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Capwap] Poll for LWAPP as the basis for the CAPWAP protocol Message-ID: Thread-Topic: [Capwap] Poll for LWAPP as the basis for the CAPWAP protocol Thread-Index: AcXcHYQVzc3GGtl2TDecup3AXZQLvgCS7UfA From: "Darren Loher" To: , Cc: , , X-OriginalArrivalTime: 31 Oct 2005 22:20:24.0241 (UTC) FILETIME=[49E20A10:01C5DE69] 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-Unsubscribe: , List-Id: A list for CAPWAP technical discussions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 31 Oct 2005 14:20:18 -0800 Content-Transfer-Encoding: quoted-printable YES: LWAPP should be the basis of the CAPWAP protocol > -----Original Message----- > From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On > Behalf Of Dorothy.Gellert@nokia.com > Sent: Friday, October 28, 2005 6:13 PM > To: capwap@frascone.com > Cc: bwijnen@lucent.com; mmani@avaya.com; david.kessens@nokia.com; > Dorothy.Gellert@nokia.com > Subject: [Capwap] Poll for LWAPP as the basis for the CAPWAP protocol >=20 >=20 > After many weeks of discussion on the CAPWAP evaluation draft completed > by the eval team its time to poll the WG on the protocol consensus. The > evaluation team concluded that LWAPP is the most complete proposal and > should be used as the basis for the CAPWAP protocol going forward. >=20 > Please respond to this email indicating support for LWAPP as the new > CAPWAP protocol: > YES: LWAPP should be the basis of the CAPWAP protocol or, > NO: LWAPP should not be the basis of the CAPWAP protocol. >=20 > The evaluation has also raised a number of recommendation that should be > address by the WG on top of the protocol recommendation. These will be > addressed by the WG and applied to the protocol that achieves WG > consensus. In order to progress the work, we are separating the > Evaluation's team proposal so that we agree first on the protcol, and > then evaluate each recommendation separately. >=20 > Please submit your response to this protocol poll by Friday, November > 4th. We will discuss the results of the poll at the face to face > CAPWAP WG meeting on Monday, November 7th. >=20 > Best Regards, > Dorothy and Mani >=20 >=20 >=20 >=20 > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Mon Oct 31 19:11:09 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWjk4-0001CL-LS for capwap-archive@megatron.ietf.org; Mon, 31 Oct 2005 19:11:09 -0500 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22614 for ; Mon, 31 Oct 2005 19:10:47 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 8AD7B20389; Mon, 31 Oct 2005 19:11:03 -0500 (EST) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from mgw-ext04.nokia.com (mgw-ext04.nokia.com [131.228.20.96]) by mail.frascone.com (Postfix) with ESMTP id 84E3420371 for ; Mon, 31 Oct 2005 19:10:06 -0500 (EST) Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext04.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id jA105Ai7014106; Tue, 1 Nov 2005 02:05:20 +0200 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 1 Nov 2005 02:09:15 +0200 Received: from mvebe101.NOE.Nokia.com ([172.19.64.23]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 31 Oct 2005 18:09:09 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5.7233.31 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Capwap] Poll for LWAPP as the basis for the CAPWAP protocol Message-ID: <8A76136424391244A5CF016533708537CD1A45@mvebe101.NOE.Nokia.com> Thread-Topic: [Capwap] Poll for LWAPP as the basis for the CAPWAP protocol Thread-Index: AcXcHYQVzc3GGtl2TDecup3AXZQLvgCEB6PwABKuGiA= From: To: , , Cc: , , X-OriginalArrivalTime: 01 Nov 2005 00:09:09.0204 (UTC) FILETIME=[7B106140:01C5DE78] 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-Unsubscribe: , List-Id: A list for CAPWAP technical discussions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 31 Oct 2005 16:09:06 -0800 Content-Transfer-Encoding: quoted-printable YES > -----Original Message----- > From: capwap-admin@frascone.com > [mailto:capwap-admin@frascone.com] On Behalf Of=20 > Dorothy.Gellert@nokia.com > Sent: Friday, October 28, 2005 5:13 PM > To: capwap@frascone.com > Cc: bwijnen@lucent.com; mmani@avaya.com; david.kessens@nokia.com;=20 > Dorothy.Gellert@nokia.com > Subject: [Capwap] Poll for LWAPP as the basis for the CAPWAP protocol >=20 >=20 > After many weeks of discussion on the CAPWAP evaluation draft=20 > completed by the eval team its time to poll the WG on the protocol=20 > consensus. The evaluation team concluded that LWAPP is the most=20 > complete proposal and should be used as the basis for the CAPWAP=20 > protocol going forward. >=20 > Please respond to this email indicating support for LWAPP as the new=20 > CAPWAP protocol: > YES: LWAPP should be the basis of the CAPWAP protocol or, > NO: LWAPP should not be the basis of the CAPWAP protocol. >=20 > The evaluation has also raised a number of recommendation that should=20 > be > address by the WG on top of the protocol recommendation. =20 > These will be > addressed by the WG and applied to the protocol that achieves WG=20 > consensus. In order to progress the work, we are separating the=20 > Evaluation's team proposal so that we agree first on the protcol, and=20 > then evaluate each recommendation separately. >=20 > Please submit your response to this protocol poll by Friday, November > 4th. We will discuss the results of the poll at the face to face > CAPWAP WG meeting on Monday, November 7th. =20 >=20 > Best Regards, > Dorothy and Mani >=20 >=20 >=20 > =20 > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap >=20 _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Mon Oct 31 20:05:14 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWkaP-00079J-PU for capwap-archive@megatron.ietf.org; Mon, 31 Oct 2005 20:05:14 -0500 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28852 for ; Mon, 31 Oct 2005 20:04:53 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id CED7E20389; Mon, 31 Oct 2005 20:05:03 -0500 (EST) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from fcsmail.futsoft.com (fcsmail1.futsoft.com [202.56.251.198]) by mail.frascone.com (Postfix) with ESMTP id 659BB1FD63 for ; Mon, 31 Oct 2005 20:04:11 -0500 (EST) Received: from sanjose.futsoft.com (unverified [10.203.112.142]) by fcsmail.futsoft.com (Content Technologies SMTPRS 4.3.12) with ESMTP id for ; Tue, 1 Nov 2005 06:30:25 +0530 Message-ID: Received: (qmail 12835 invoked by uid 505); 1 Nov 2005 06:04:03 +0530 Received: from sridhar@futsoft.com by sanjose by uid 89 with qmail-scanner-1.16 (clamscan: 0.60. spamassassin: 2.60. Clear:. Processed in 0.851054 secs) ; 01 Nov 2005 00:34:03 -0000 Received: from unknown (HELO sjcm1003) (sridhar@futsoft.com@65.200.107.68) by 0 (qmail 1.03 + ejcp v14) with SMTP; 1 Nov 2005 06:04:02 +0530 Reply-To: From: "t.sridhar" To: Cc: , Subject: RE: [Capwap] Poll for LWAPP as the basis for the CAPWAP protocol Organization: FutureSoft MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 In-Reply-To: <17B8C6DE4E228348B4939BDA6B05A9DCBDFBB6@xmb-sjc-237.amer.cisco.com> Thread-Index: AcXcHYQVzc3GGtl2TDecup3AXZQLvgCS1o+wAAWVGyA= X-Qmail-Scanner-Message-ID: <113080524252612829@sanjose> 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-Unsubscribe: , List-Id: A list for CAPWAP technical discussions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 31 Oct 2005 17:03:48 -0800 Content-Transfer-Encoding: 7bit YES: LWAPP should be the basis of the CAPWAP protocol. Thanks, Sridhar -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Dorothy.Gellert@nokia.com Sent: Friday, October 28, 2005 5:13 PM To: capwap@frascone.com Cc: bwijnen@lucent.com; mmani@avaya.com; david.kessens@nokia.com; Dorothy.Gellert@nokia.com Subject: [Capwap] Poll for LWAPP as the basis for the CAPWAP protocol After many weeks of discussion on the CAPWAP evaluation draft completed by the eval team its time to poll the WG on the protocol consensus. The evaluation team concluded that LWAPP is the most complete proposal and should be used as the basis for the CAPWAP protocol going forward. Please respond to this email indicating support for LWAPP as the new CAPWAP protocol: YES: LWAPP should be the basis of the CAPWAP protocol or, NO: LWAPP should not be the basis of the CAPWAP protocol. The evaluation has also raised a number of recommendation that should be address by the WG on top of the protocol recommendation. These will be addressed by the WG and applied to the protocol that achieves WG consensus. In order to progress the work, we are separating the Evaluation's team proposal so that we agree first on the protcol, and then evaluate each recommendation separately. Please submit your response to this protocol poll by Friday, November 4th. We will discuss the results of the poll at the face to face CAPWAP WG meeting on Monday, November 7th. Best Regards, Dorothy and Mani _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap *************************************************************************** This message is proprietary to FutureSoft and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. FutureSoft accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus. *************************************************************************** _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Mon Oct 31 20:58:10 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWlPd-0002Kt-Gr for capwap-archive@megatron.ietf.org; Mon, 31 Oct 2005 20:58:10 -0500 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA02613 for ; Mon, 31 Oct 2005 20:57:49 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id BBEC0203E5; Mon, 31 Oct 2005 20:58:03 -0500 (EST) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from aruba-mx.arubanetworks.com (mail.arubanetworks.com [216.31.249.253]) by mail.frascone.com (Postfix) with SMTP id 1C9371FD63 for ; Mon, 31 Oct 2005 20:57:45 -0500 (EST) Received: from aruba-mx1.arubanetworks.com ([10.1.1.17]) by aruba-mx.arubanetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 31 Oct 2005 17:57:44 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Capwap] Poll for LWAPP as the basis for the CAPWAP protocol Message-ID: <99C8B9B2AD99664A87E12C839A2E90930117C47B@aruba-mx1.arubanetworks.com> Thread-Topic: [Capwap] Poll for LWAPP as the basis for the CAPWAP protocol Thread-Index: AcXcHYQVzc3GGtl2TDecup3AXZQLvgCH+wmA From: "Merwyn Andrade" To: , Cc: , "Avaya - Mani Mahalingam" , X-OriginalArrivalTime: 01 Nov 2005 01:57:44.0450 (UTC) FILETIME=[A6740620:01C5DE87] 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-Unsubscribe: , List-Id: A list for CAPWAP technical discussions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 31 Oct 2005 17:57:41 -0800 Content-Transfer-Encoding: quoted-printable NO=20 Reason : Need to see concerns addressed around the issues of a) IPR encumbrances and Licensing terms offered if we use LWAPP c) Creating open source versions with #a=20 Before we can implement a CAPWAP protocol based on LWAPP =20 Merv Merwyn (Merv) Andrade Chief Technical Officer Work : merv@arubanetworks.com=20 IEEE/Other : merv@usa.com -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Dorothy.Gellert@nokia.com Sent: Friday, October 28, 2005 5:13 PM To: capwap@frascone.com Cc: bwijnen@lucent.com; Avaya - Mani Mahalingam; david.kessens@nokia.com; Dorothy.Gellert@nokia.com Subject: [Capwap] Poll for LWAPP as the basis for the CAPWAP protocol After many weeks of discussion on the CAPWAP evaluation draft completed by the eval team its time to poll the WG on the protocol consensus. The evaluation team concluded that LWAPP is the most complete proposal and should be used as the basis for the CAPWAP protocol going forward. Please respond to this email indicating support for LWAPP as the new CAPWAP protocol:=20 YES: LWAPP should be the basis of the CAPWAP protocol or, NO: LWAPP should not be the basis of the CAPWAP protocol. The evaluation has also raised a number of recommendation that should be address by the WG on top of the protocol recommendation. These will be addressed by the WG and applied to the protocol that achieves WG consensus. In order to progress the work, we are separating the Evaluation's team proposal so that we agree first on the protcol, and then evaluate each recommendation separately. =20 Please submit your response to this protocol poll by Friday, November 4th. We will discuss the results of the poll at the face to face CAPWAP WG meeting on Monday, November 7th. =20 Best Regards, Dorothy and Mani =20 _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap